Re: race condition in pg_class

From: Noah Misch <noah(at)leadboat(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Smolkin Grigory <smallkeen(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>
Subject: Re: race condition in pg_class
Date: 2024-06-14 00:35:49
Message-ID: 20240614003549.c2.nmisch@google.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 10, 2024 at 07:45:25PM -0700, Noah Misch wrote:
> On Thu, Jun 06, 2024 at 09:48:51AM -0400, Robert Haas wrote:
> > It's not this patch set's fault, but I'm not very pleased to see that
> > the injection point wait events have been shoehorned into the
> > "Extension" category
>
> I've replied on that branch of the thread.

I think the attached covers all comments to date. I gave everything v3, but
most patches have just a no-conflict rebase vs. v2. The exceptions are
inplace031-inj-wait-event (implements the holding from that branch of the
thread) and inplace050-tests-inj (updated to cooperate with inplace031). Much
of inplace031-inj-wait-event is essentially s/Extension/Custom/ for the
infrastructure common to the two custom wait event types.

Thanks,
nm

Attachment Content-Type Size
inplace005-UNEXPECTEDPASS-tap-meson-v3.patch text/plain 1.7 KB
inplace010-tests-v3.patch text/plain 21.5 KB
inplace031-inj-wait-event-v3.patch text/plain 24.6 KB
inplace040-waitfuncs-v3.patch text/plain 8.2 KB
inplace050-tests-inj-v3.patch text/plain 8.5 KB
inplace060-nodeModifyTable-comments-v3.patch text/plain 7.5 KB
inplace065-lock-SequenceChangePersistence-v3.patch text/plain 1.5 KB
inplace071-lock-SetRelationHasSubclass-v3.patch text/plain 8.3 KB
inplace075-lock-heap_create-v3.patch text/plain 1.3 KB
inplace080-catcache-detoast-inplace-stale-v3.patch text/plain 4.5 KB
inplace090-LOCKTAG_TUPLE-eoxact-v3.patch text/plain 1.2 KB
inplace110-successors-v3.patch text/plain 44.5 KB
inplace120-locktag-v3.patch text/plain 42.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-06-14 00:38:05 Re: Revive num_dead_tuples column of pg_stat_progress_vacuum
Previous Message Masahiko Sawada 2024-06-14 00:35:18 Re: Revive num_dead_tuples column of pg_stat_progress_vacuum