Re: delay starting WAL receiver

2023-01-10 Thread Nathan Bossart
On Wed, Jan 11, 2023 at 05:20:38PM +1300, Thomas Munro wrote: > Is the problem here that SIGCHLD is processed ... > > PG_SETMASK(); <--- here? > > selres = select(nSockets, , NULL, NULL, ); > > Meanwhile the SIGCHLD handler code says: > > * Was it the wal

Re: delay starting WAL receiver

2023-01-10 Thread Thomas Munro
On Wed, Jan 11, 2023 at 5:20 PM Thomas Munro wrote: > (I don't know why you didn't make it 0) (Oh, I see why it had to be non-zero to avoiding burning CPU, ignore that part.)

Re: delay starting WAL receiver

2023-01-10 Thread Thomas Munro
On Wed, Jan 11, 2023 at 2:08 PM Nathan Bossart wrote: > I discussed this a bit in a different thread [0], but I thought it deserved > its own thread. > > After setting wal_retrieve_retry_interval to 1ms in the tests, I noticed > that the recovery tests consistently take much longer. Upon further

delay starting WAL receiver

2023-01-10 Thread Nathan Bossart
I discussed this a bit in a different thread [0], but I thought it deserved its own thread. After setting wal_retrieve_retry_interval to 1ms in the tests, I noticed that the recovery tests consistently take much longer. Upon further inspection, it looks like a similar race condition to the one