From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/8] reftable/stack: test compaction with already-locked tables
Date: Fri, 02 Aug 2024 14:05:43 -0700 [thread overview]
Message-ID: <xmqqle1ebpp4.fsf@gitster.g> (raw)
In-Reply-To: <123fb9d80eecbd3690280991e0415cbb718b7202.1722435214.git.ps@pks.im> (Patrick Steinhardt's message of "Wed, 31 Jul 2024 16:14:57 +0200")
Patrick Steinhardt <ps@pks.im> writes:
> +static void test_reftable_stack_auto_compaction_with_locked_tables(void)
> +{
> + struct reftable_write_options opts = {
> + .disable_auto_compact = 1,
> + };
> + struct reftable_stack *st = NULL;
> + struct strbuf buf = STRBUF_INIT;
> + char *dir = get_tmp_dir(__LINE__);
> + int err;
> +
> + err = reftable_new_stack(&st, dir, &opts);
> + EXPECT_ERR(err);
> +
> + for (size_t i = 0; i < 5; i++) {
> + struct reftable_ref_record ref = {
> + .update_index = reftable_stack_next_update_index(st),
> + .value_type = REFTABLE_REF_VAL1,
> + .value.val1 = { i },
> + };
As val1 is an array of unsigned char, i cannot reasonably go beyond
255, but that is perfectly fine. We are preparing 5 original tables
to compact, and that might grow to 17 tables over time, but 255 ought
to be more than enough.
> +
> + strbuf_reset(&buf);
> + strbuf_addf(&buf, "refs/heads/branch-%04" PRIuMAX, (uintmax_t) i);
Yet we are prepared to handle i that is beyond any usual integer ;-)
I am tempted to suggest using the bog-standard int for everything
for the sake of consistency within this loop, but it does not matter
all that much in a standalone test program ;-)
> + ref.refname = buf.buf;
> +
> + err = reftable_stack_add(st, &write_test_ref, &ref);
> + EXPECT_ERR(err);
> + }
> + EXPECT(st->merged->stack_len == 5);
> +
> + /*
> + * Given that all tables we have written should be roughly the same
> + * size, we expect that auto-compaction will want to compact all of the
> + * tables. Locking any of the tables will keep it from doing so.
> + */
> + strbuf_reset(&buf);
> + strbuf_addf(&buf, "%s/%s.lock", dir, st->readers[2]->name);
> + write_file_buf(buf.buf, "", 0);
OK. [2] is just a random number pulled out of 0..5?
> +static void test_reftable_stack_compaction_with_locked_tables(void)
> +{
> + struct reftable_write_options opts = {
> + .disable_auto_compact = 1,
> + };
> + struct reftable_stack *st = NULL;
> + struct strbuf buf = STRBUF_INIT;
> + char *dir = get_tmp_dir(__LINE__);
> + int err;
> +
> + err = reftable_new_stack(&st, dir, &opts);
> + EXPECT_ERR(err);
> +
> + for (size_t i = 0; i < 3; i++) {
> +...
> + }
> + EXPECT(st->merged->stack_len == 3);
Hmph, this somehow looks familiar. The only difference is how many
tables are compacted with which one locked, and whether it is
compact_all() or auto_compact() that triggers the compaction
behaviour, right?
I wonder if we want to factor out the commonality into a shared
function, or it is too much trouble only for two duplicates and we
can worry about it when we were about to add the third one?
Thanks.
next prev parent reply other threads:[~2024-08-02 21:05 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-31 14:14 [PATCH 0/8] reftable: improvements and fixes for compaction Patrick Steinhardt
2024-07-31 14:14 ` [PATCH 1/8] reftable/stack: refactor function to gather table sizes Patrick Steinhardt
2024-08-02 20:26 ` Junio C Hamano
2024-07-31 14:14 ` [PATCH 2/8] reftable/stack: test compaction with already-locked tables Patrick Steinhardt
2024-08-02 21:05 ` Junio C Hamano [this message]
2024-08-05 12:11 ` Patrick Steinhardt
2024-07-31 14:15 ` [PATCH 3/8] reftable/stack: update stats on failed full compaction Patrick Steinhardt
2024-07-31 14:15 ` [PATCH 4/8] reftable/stack: simplify tracking of table locks Patrick Steinhardt
2024-07-31 21:57 ` Justin Tobler
2024-08-02 23:00 ` Junio C Hamano
2024-08-05 12:11 ` Patrick Steinhardt
2024-07-31 14:15 ` [PATCH 5/8] reftable/stack: do not die when fsyncing lock file files Patrick Steinhardt
2024-07-31 14:15 ` [PATCH 6/8] reftable/stack: use lock_file when adding table to "tables.list" Patrick Steinhardt
2024-07-31 23:02 ` Justin Tobler
2024-08-01 8:40 ` Patrick Steinhardt
2024-07-31 14:15 ` [PATCH 7/8] reftable/stack: fix corruption on concurrent compaction Patrick Steinhardt
2024-08-01 1:04 ` Justin Tobler
2024-08-01 8:41 ` Patrick Steinhardt
2024-07-31 14:15 ` [PATCH 8/8] reftable/stack: handle locked tables during auto-compaction Patrick Steinhardt
2024-08-02 23:24 ` Junio C Hamano
2024-08-05 12:11 ` Patrick Steinhardt
2024-08-05 13:07 ` [PATCH v2 0/9] reftable: improvements and fixes for compaction Patrick Steinhardt
2024-08-05 13:07 ` [PATCH v2 1/9] reftable/stack: refactor function to gather table sizes Patrick Steinhardt
2024-08-05 13:07 ` [PATCH v2 2/9] reftable/stack: extract function to setup stack with N tables Patrick Steinhardt
2024-08-05 13:07 ` [PATCH v2 3/9] reftable/stack: test compaction with already-locked tables Patrick Steinhardt
2024-08-08 10:46 ` Karthik Nayak
2024-08-05 13:08 ` [PATCH v2 4/9] reftable/stack: update stats on failed full compaction Patrick Steinhardt
2024-08-05 13:08 ` [PATCH v2 5/9] reftable/stack: simplify tracking of table locks Patrick Steinhardt
2024-08-05 13:08 ` [PATCH v2 6/9] reftable/stack: do not die when fsyncing lock file files Patrick Steinhardt
2024-08-05 13:08 ` [PATCH v2 7/9] reftable/stack: use lock_file when adding table to "tables.list" Patrick Steinhardt
2024-08-05 13:08 ` [PATCH v2 8/9] reftable/stack: fix corruption on concurrent compaction Patrick Steinhardt
2024-08-08 12:14 ` Karthik Nayak
2024-08-08 13:29 ` Patrick Steinhardt
2024-08-05 13:08 ` [PATCH v2 9/9] reftable/stack: handle locked tables during auto-compaction Patrick Steinhardt
2024-08-06 18:46 ` Justin Tobler
2024-08-07 5:31 ` Patrick Steinhardt
2024-08-07 19:12 ` Justin Tobler
2024-08-08 12:25 ` Karthik Nayak
2024-08-08 12:26 ` [PATCH v2 0/9] reftable: improvements and fixes for compaction Karthik Nayak
2024-08-08 14:06 ` [PATCH v3 " Patrick Steinhardt
2024-08-08 14:06 ` [PATCH v3 1/9] reftable/stack: refactor function to gather table sizes Patrick Steinhardt
2024-08-08 14:06 ` [PATCH v3 2/9] reftable/stack: extract function to setup stack with N tables Patrick Steinhardt
2024-08-08 14:06 ` [PATCH v3 3/9] reftable/stack: test compaction with already-locked tables Patrick Steinhardt
2024-08-08 14:06 ` [PATCH v3 4/9] reftable/stack: update stats on failed full compaction Patrick Steinhardt
2024-08-08 14:06 ` [PATCH v3 5/9] reftable/stack: simplify tracking of table locks Patrick Steinhardt
2024-08-08 14:06 ` [PATCH v3 6/9] reftable/stack: do not die when fsyncing lock file files Patrick Steinhardt
2024-08-08 14:06 ` [PATCH v3 7/9] reftable/stack: use lock_file when adding table to "tables.list" Patrick Steinhardt
2024-08-08 14:06 ` [PATCH v3 8/9] reftable/stack: fix corruption on concurrent compaction Patrick Steinhardt
2024-08-08 14:06 ` [PATCH v3 9/9] reftable/stack: handle locked tables during auto-compaction Patrick Steinhardt
2024-08-08 16:52 ` [PATCH v3 0/9] reftable: improvements and fixes for compaction Karthik Nayak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqle1ebpp4.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=ps@pks.im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).