From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@lists.postgresql.org
Subject: Re: pgsql: Prevent instability in contrib/pageinspect's regression
 test.
In-reply-to: <20221121201818.u32xtvpqc5wd6tx7@alap3.anarazel.de>
References: <E1ox94a-000EHu-VH@gemulon.postgresql.org>
 <20221121172206.h6kywxrzqcmhoqom@awork3.anarazel.de>
 <3214376.1669051457@sss.pgh.pa.us> <3215927.1669052115@sss.pgh.pa.us>
 <CA+TgmoaYMUv1ab2vAh7AoSUqUYHtPx9Cmehue2=JCXO3gvsDbw@mail.gmail.com>
 <20221121195628.2rlqpbkjgjsvqn6w@alap3.anarazel.de>
 <3264594.1669061535@sss.pgh.pa.us>
 <20221121201818.u32xtvpqc5wd6tx7@alap3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Mon, 21 Nov 2022 12:18:18 -0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3267208.1669062831.1@sss.pgh.pa.us>
Date: Mon, 21 Nov 2022 15:33:51 -0500
Message-ID: <3267209.1669062831@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3267209.1669062831%40sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> On 2022-11-21 15:12:15 -0500, Tom Lane wrote:
>> If I were trying to find a better fix I'd be looking for ways for
>> parallel workers to be able to read the parent's temp tables.
>> (Perhaps that could tie in with the blue-sky discussion we had
>> the other day about allowing autovacuum on temp tables??)

> That'd be a nontrivial change, because we explicitly don't use any
> locking for anything relating to localbuf.c. One possible benefit could
> be that we could substantially reduce the code duplication between
> "normal" bufmgr.c and localbuf.c.

I didn't say this was easy ;-).  Aside from locking, the local buffers
are inside the process's address space and not accessible from outside.
Maybe they could be mapped into a shared memory region instead?
And there are optimizations like commit a7212be8b that depend on the
assumption that nothing else is accessing our process's temp tables.
That'd need a lot of thought, if we don't want to give up all the
performance benefits of temp tables.

			regards, tom lane