Re: Subscription tests fail under CLOBBER_CACHE_ALWAYS

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Subscription tests fail under CLOBBER_CACHE_ALWAYS
Дата
Msg-id 165922.1621635259@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Subscription tests fail under CLOBBER_CACHE_ALWAYS  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Subscription tests fail under CLOBBER_CACHE_ALWAYS  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
I wrote:
> I count three distinct bugs that were exposed by this attempt:
> ...
> 2. Said bug causes a segfault in the apply worker process.
> This causes the parent postmaster to give up and die.
> I don't understand why we don't treat that like a crash
> in a regular backend, considering that an apply worker
> is running largely user-defined code.

Figured that one out: we *do* treat it like a crash in a regular
backend, which explains the lack of field complaints.  What's
contributing to the TAP test getting stuck is that PostgresNode.pm
does this:

    open my $conf, '>>', "$pgdata/postgresql.conf";
    print $conf "\n# Added by PostgresNode.pm\n";
    ...
    print $conf "restart_after_crash = off\n";

So that'd be fine, if only the TAP tests were a bit more robust
about postmasters disappearing unexpectedly.

BTW, I wonder whether it wouldn't be a good idea for the
postmaster to log something along the lines of "stopping
because restart_after_crash is off".  The present behavior
can be quite mysterious otherwise (it certainly confused me).

            regards, tom lane



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: seawasp failing, maybe in glibc allocator
Следующее
От: Tom Lane
Дата:
Сообщение: Re: seawasp failing, maybe in glibc allocator