Re: Alter index rename concurrently to

From: Andres Freund <andres(at)anarazel(dot)de>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrey Klychkov <aaklychkov(at)mail(dot)ru>, Victor Yegorov <vyegorov(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Alter index rename concurrently to
Date: 2018-08-14 07:04:54
Message-ID: 20180814070454.37lteqtvo3bmmzfd@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2018-08-14 08:44:46 +0200, Peter Eisentraut wrote:
> On 03/08/2018 15:00, Robert Haas wrote:
> > On Thu, Aug 2, 2018 at 4:44 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> >> ISTM, if you want to increase consistency in this area, you've to go
> >> further. E.g. processing invalidations in StartTransactionCommand() in
> >> all states, which'd give you a lot more consistency.
> >
> > Hmm, that seems like a pretty good idea.
>
> That would only affect top-level commands, not things like SPI. Is that
> what we want? Or we could sprinkle additional
> AcceptInvalidationMessages() calls in spi.c.

I'd say it's not unreasonable to *not* to guarantee spi (and various
other functions) immediately take concurrent activity into account,
unless locking rules guarantee that independently. Definining it as
"commands sent by the client see effects of previously issued
non-conflicting DDL, others might see them earlier" doesn't seem insane.

If you want to take account of SPI and PLs it gets more comoplicated
quickly, because we don't always parse functions afresh. So you'd need
invalidations in a lot more places.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2018-08-14 09:03:16 Re: libpq connection timeout mismanagement
Previous Message Peter Eisentraut 2018-08-14 06:44:46 Re: Alter index rename concurrently to