On 2020-Jan-07, Tom Lane wrote: > Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > > On 2020-Jan-07, Tom Lane wrote:
> > That seems a pretty simple patch; attached (untested). > > I think you want && not ||, but otherwise that looks about right. Thanks, you were right; pushed. > > However, my > > patch seemed a pretty decent way to achieve the goal, and I don't > > understand why it causes the failure, or indeed why we care about > > stmtStartTimestamp at all. I'll look into this again tomorrow. > > I'm not 100% sure why the failure either. The assertion is in > code that should only be reached in a parallel worker, and surely > walsenders don't launch parallel queries? But it looks to me > that all the critters using force_parallel_mode are unhappy. I reproduced here with force_parallel_mode=regress, and indeed what is happening is that log.rep. subscription walsenders (???) are running queries per commands/subscriptioncmds.c::fetch_table_list(), and under that GUC they beget parallel workers; and because the parent has am_walsender=true then they pass a timestamp of 0 to the children; but the children retain am_walsender=false, so the assertion fires. I didn't spend more time on that, but it seems strange and possibly dangerous, since am_walsender is used to implement some restrictions. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
