Re: GenBKI emits useless open;close for catalogs without rows - Mailing list pgsql-hackers

From Tom Lane
Subject Re: GenBKI emits useless open;close for catalogs without rows
Date
Msg-id 564720.1693590749@sss.pgh.pa.us
Whole thread Raw
In response to Re: GenBKI emits useless open;close for catalogs without rows  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: GenBKI emits useless open;close for catalogs without rows
List pgsql-hackers
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> On 2023-Sep-01, Matthias van de Meent wrote:
>> A potential addition to the patch would to stop manually closing
>> relations: initdb and check-world succeed without manual 'close'
>> operations because the 'open' command auto-closes the previous open
>> relation (in boot_openrel). Testing also suggests that the last opened
>> relation apparently doesn't need closing - check-world succeeds
>> without issues (incl. with TAP enabled). That is therefore implemented
>> in attached patch 2 - it removes the 'close' syntax in its entirety.

> Hmm, what happens with the last relation in the bootstrap process?  Is
> closerel() called via some other path for that one?

Taking a quick census of existing closerel() callers: there is
cleanup() in bootstrap.c, but it's called uncomfortably late
and outside any transaction, so I misdoubt that it works
properly if asked to actually shoulder any responsibility.
(A little code reshuffling could fix that.)
There are also a couple of low-level elog warnings in CREATE
that would likely get triggered, though I suppose we could just
remove those elogs.

I guess my reaction to this patch is "why bother?".  It seems
unlikely to yield any measurable benefit, though of course
that guess could be wrong.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Inefficiency in parallel pg_restore with many tables
Next
From: Nathan Bossart
Date:
Subject: Re: Adding a pg_get_owned_sequence function?