From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
Subject: Re: Subscription tests fail under CLOBBER_CACHE_ALWAYS
In-reply-to: <3382681.1621381328@sss.pgh.pa.us>
References: <3382681.1621381328@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Tue, 18 May 2021 19:42:08 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <165921.1621635259.1@sss.pgh.pa.us>
Date: Fri, 21 May 2021 18:14:19 -0400
Message-ID: <165922.1621635259@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/165922.1621635259%40sss.pgh.pa.us>
Precedence: bulk

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