Re: GenBKI emits useless open;close for catalogs without rows

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: GenBKI emits useless open;close for catalogs without rows
Дата
Msg-id 564720.1693590749@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: GenBKI emits useless open;close for catalogs without rows  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: GenBKI emits useless open;close for catalogs without rows  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Nathan Bossart
Дата:
Сообщение: Re: Inefficiency in parallel pg_restore with many tables
Следующее
От: Nathan Bossart
Дата:
Сообщение: Re: Adding a pg_get_owned_sequence function?