Re: Resetting snapshots during the first phase of [CREATE |RE]INDEX CONCURRENTLY - Mailing list pgsql-hackers

From Mihail Nikalayeu
Subject Re: Resetting snapshots during the first phase of [CREATE |RE]INDEX CONCURRENTLY
Date
Msg-id CADzfLwV+EYL0qDorDKEuJbHNaXqnWbZXRZtKcOgG-KuL9+R2-Q@mail.gmail.com
Whole thread
In response to Re: Resetting snapshots during the first phase of [CREATE |RE]INDEX CONCURRENTLY  (Álvaro Herrera <alvherre@kurilemu.de>)
Responses Re: Resetting snapshots during the first phase of [CREATE |RE]INDEX CONCURRENTLY
List pgsql-hackers
Hello, Álvaro!

Thanks for looking into it.

> Or should we just consider the test as not-for-commit, and only a
> development aid?

Initially I thought so, but looks like it is possible to make it committable.

> The test in 0001 is a bit on the slow side; should we make it
> optional with PG_TEST_EXTRA?

I made *parameters* to be depended  on PG_TEST_EXTRA ~= stress. It is
possible to apply the same pattern for other stress tests too.

> The last pgbench subtest mentions GIN in the test name but doesn't
> actually run it.  Do we care?  Would it be good to make the table be
> unlogged?

Fixed, it has its own pgbench because it has its own gin_index_check.

> Would it be good to make the table be unlogged?

Good idea, done.

> I think all-but-one backends will
>complete all the 999 transactions in the first 10ms sleep that the one
> backend running the CIC does.  Am I right about this?

It actually has enough time to do multiple CIC (I see it from the
log). I updated the test to random delay, for non-stress variants -
from 0 to 1, for stress - up to 10.

Also, fixed a few small styling issues + added additional fixes for
waiting for a snapshot to be restored by a parallel worker.

Best regards,
Mikhail.

Attachment

pgsql-hackers by date:

Previous
From: Gyan Sreejith
Date:
Subject: Re: [Proposal] Adding Log File Capability to pg_createsubscriber
Next
From: Bharath Rupireddy
Date:
Subject: Re: another autovacuum scheduling thread