Re: pgsql: Perform provider-specific initialization in new functions.

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: pgsql: Perform provider-specific initialization in new functions.
Дата
Msg-id 4524ed61a015d3496fc008644dcb999bb31916a7.camel@j-davis.com
обсуждение
Ответ на Re: pgsql: Perform provider-specific initialization in new functions.  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: pgsql: Perform provider-specific initialization in new functions.
Список pgsql-committers
On Thu, 2026-04-16 at 11:42 -0700, Jeff Davis wrote:
> I plan to commit this soon.
>
> I don't plan to backport unless someone sees a reason that it should
> be
> backported (and if so, how far?).

Actually, this does need to be backported, a NULL pointer dereference
is easily reproducible on master and v18:

  PGOPTIONS="-c zero_damaged_pages=on" \
  pg_receivewal -D archive -U repl

On 17 the symptom is slightly different but the fix is the same.

I attached a new patch, and only the commit message is different, which
I plan to backport to 17.

There's another bug, though. Even with the patch applied, if you do the
same pg_receivewal command immediately after starting the server
(without any other connections), you get:

  FATAL:  cannot read pg_class without having selected a database

The path is similar: it's trying to do pg_parameter_aclcheck, but is
unable to open pg_parameter_acl at all because it can't read pg_class.
It seems to work if you connect another backend first, where it does
some initialization first, through I haven't worked out the details. I
think it goes back to when parameter ACLs were introduced in
a0ffa885e47, so CC Mark Dilger.

Regards,
    Jeff Davis


Вложения

В списке pgsql-committers по дате отправления: