Re: [PATCH] Logical decoding of TRUNCATE - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [PATCH] Logical decoding of TRUNCATE
Date
Msg-id 20201221174247.67pnoem5dtscocv4@alap3.anarazel.de
Whole thread Raw
In response to Re: [PATCH] Logical decoding of TRUNCATE  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: [PATCH] Logical decoding of TRUNCATE
List pgsql-hackers
Hi,

On 2020-12-20 15:54:31 -0800, Peter Geoghegan wrote:
> On Sun, Dec 20, 2020 at 3:13 PM Andres Freund <andres@anarazel.de> wrote:
> > Hm. Do I understand correctly that this problem is hit solely because
> > the parallel mode code relies on there already have been a transaction
> > snapshot set, thus avoiding the error? And that the code normally only
> > works because GetTransactionSnapshot() will already have been called
> > somewhere, before EnterParallelMode()?
> 
> It seems unlikely that InitializeParallelDSM() was ever intended to be
> run in a background worker.

IDK, the environment in a bgworker shouldn't be that different from the
normal query environment in a normal connection. And it's far from
insane to want to be able to run a paralell query in a bgworker (and I
*think* I have seen that work before). This case here seems more like
an accidental dependency than anything to me, once that could perhaps
even hint at problems in normal backends too.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: BUG #16079: Question Regarding the BUG #16064
Next
From: Surafel Temesgen
Date:
Subject: Re: WIP: System Versioned Temporal Table