Re: [PATCH] Logical decoding of TRUNCATE

From: Noah Misch <noah(at)leadboat(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Peter Geoghegan <pg(at)bowt(dot)ie>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Marco Nenciarini <marco(dot)nenciarini(at)2ndquadrant(dot)it>, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Logical decoding of TRUNCATE
Date: 2020-12-24 02:58:36
Message-ID: 20201224025836.GA4158910@rfd.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Mon, Dec 21, 2020 at 09:42:47AM -0800, Andres Freund wrote:
> On 2020-12-20 15:54:31 -0800, Peter Geoghegan wrote:
> > On Sun, Dec 20, 2020 at 3:13 PM Andres Freund <andres(at)anarazel(dot)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.

Yeah. SPI_execute("TRUNCATE foo", false, 0) has no trouble doing a parallel
index build in a bgworker. Let's ignore intention and be pleased about that.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Kyotaro Horiguchi 2020-12-24 03:05:20 Re: Problem with ssl and psql in Postgresql 13
Previous Message Guyren Howe 2020-12-24 01:55:57 Is there a good discussion of optimizations?

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2020-12-24 03:06:38 Re: WIP: WAL prefetch (another approach)
Previous Message Li Japin 2020-12-24 02:28:53 Re: Confused about stream replication protocol documentation