Re: BUG #19690: Possible stale partition descriptor after concurrent ATTACH PARTITION

Hi,

Thank you for the report.

> I would like to ask about a possible build-time invalidation race in
> RelationBuildPartitionDesc().
>
> This issue was reproduced in a clean PostgreSQL upstream checkout . The
> checkout was current master at commit
> ff39a858b984d8088caa2a9777948d211f549b65.
>
> SELECT version(); returned:
> PostgreSQL 20devel on aarch64-apple-darwin25.6.0, compiled by Apple clang
> version 21.0.0 (clang-2100.1.1.101), 64-bit
>
> The host runs macOS 26.6.2 on arm64.
>
> Observed behavior
> -----------------
> Backend A starts a read that builds the partition descriptor when the parent
> has one partition. During that build, backend B commits ATTACH PARTITION and
> inserts a row into the newly attached partition. A subsequent statement in
> the same reader connection still reports only the original row and
> partition:
>
> first_count
> -------------
> 1
>
> second_count | partitions_seen
> --------------+-----------------
> 1 | 1
>
> An independent query after the writer commits reports 2 rows across 2
> partitions.
>
> Both SELECT statements run in the same psql connection with normal
> autocommit. The second SELECT follows SELECT pg_sleep(1). The writer command
> returned ALTER TABLE and INSERT 0 1 before the reader finished.
>
> Test-only instrumentation
> -------------------------
> Immediately after find_inheritance_children_extended() in
> RelationBuildPartitionDesc(), and before processing the child list, this
> temporary code was added:
>
> #ifdef RELCACHE_PARTDESC_TEST_DELAY
> if (debug_query_string != NULL &&
> strstr(debug_query_string, "partdesc-race-reader") != NULL)
> pg_usleep(8000000L);
> #endif
>

I can reproduce this after adding the above instrumentation to increase the
window.

This seems to fall under the serializability issues mentioned in the following
commit that allows ATTACH PARTITION to run with only a ShareUpdateExclusiveLock.

898e5e3290a72d288923260143930fb32036c00c
"There would still be a small window where a query
that started just after an ATTACH PARTITION command committed might
fail to notice its results -- but only if the command starts before
the commit has been acknowledged to the user. All in all, the warts
here around serializability seem small enough to be worth accepting
for the considerable advantage of being able to add partitions without
a full table lock"

The inconsistency highlighted by the report is slightly different and
more visible in that the psql connection continues to report incorrect
number of partitions until it gets another invalidation message.

Thank you,
Rahila Syed