Alvaro Herrera <alvherre@2ndquadrant.com> writes:
>> 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.
Indeed. I think it's a truly horrible idea that we are issuing SPI
queries inside replication mechanisms. Quite aside from this problem,
do we really think that's free of security issues? Or even if you
think it is today, can it be kept so?
(I've ranted before about keeping a proper layering design in this
stuff. Just because it's easier to do stuff by calling a SQL query
doesn't mean that we should consider that acceptable.)
regards, tom lane
