From: Tom Lane <tgl@sss.pgh.pa.us>
To: Justin Pryzby <pryzby@telsasoft.com>
cc: Robert Haas <robertmhaas@gmail.com>,
        =?utf-8?B?0JDQvdC00YDQtdC5INCg0LDRh9C40YbQutC40Lk=?=
 <therealgofman@mail.ru>,
        pgsql-hackers@lists.postgresql.org
Subject: Re: BUG #18545: \dt breaks transaction,
 calling error when executed in SET SESSION AUTHORIZATION
In-reply-to: <ZuoU_8EbSTE14o1U@pryzbyj2023>
References: <18545-feba138862f19aaa@postgresql.org>
 <72802.1721415837@sss.pgh.pa.us> <1722241488.182053205@f169.i.mail.ru>
 <3593204.1722466756@sss.pgh.pa.us> <3618203.1722473994@sss.pgh.pa.us>
 <916377.1722809337@sss.pgh.pa.us>
 <CA+TgmoZ8owNGNkHUsoSL3cEd8C+zbb8w7-Oje0HYvfBp+btDBA@mail.gmail.com>
 <1807627.1722970465@sss.pgh.pa.us> <ZuoU_8EbSTE14o1U@pryzbyj2023>
Comments: In-reply-to Justin Pryzby <pryzby@telsasoft.com>
	message dated "Tue, 17 Sep 2024 18:47:11 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1912092.1726716624.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 18 Sep 2024 23:30:24 -0400
Message-ID: <1912093.1726716624@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1912093.1726716624%40sss.pgh.pa.us>
Precedence: bulk

Justin Pryzby <pryzby@telsasoft.com> writes:
> This commit seems to trigger elog(), not reproducible in the
> parent commit.

> 6e086fa2e77 Allow parallel workers to cope with a newly-created session =
user ID.

> postgres=3D# SET min_parallel_table_scan_size=3D0; CLUSTER pg_attribute =
USING pg_attribute_relid_attnum_index;
> ERROR:  pg_attribute catalog is missing 26 attribute(s) for relation OID=
 70321

I've been poking at this all day, and I still have little idea what's
going on.  I've added a bunch of throwaway instrumentation, and have
managed to convince myself that the problem is that parallel heap
scan is broken.  The scans done to rebuild pg_attribute's indexes
seem to sometimes miss heap pages or visit pages twice (in different
workers).  I have no idea why this is, and even less idea how
6e086fa2e is provoking it.  As you say, the behavior isn't entirely
reproducible, but I couldn't make it happen at all after reverting
6e086fa2e's changes in transam/parallel.c, so apparently there is
some connection.

Another possibly useful data point is that for me it reproduces
fairly well (more than one time in two) on x86_64 Linux, but
I could not make it happen on macOS ARM64.  If it's a race
condition, which smells plausible, that's perhaps not hugely
surprising.

			regards, tom lane