From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Subscription tests fail under CLOBBER_CACHE_ALWAYS |
Date: | 2021-05-21 22:14:19 |
Message-ID: | 165922.1621635259@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-05-21 22:18:54 | Re: seawasp failing, maybe in glibc allocator |
Previous Message | Andres Freund | 2021-05-21 21:58:38 | Re: seawasp failing, maybe in glibc allocator |