Re: Alter index rename concurrently to

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Alter index rename concurrently to
Дата
Msg-id 20180814070454.37lteqtvo3bmmzfd@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Alter index rename concurrently to  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список 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@anarazel.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Alter index rename concurrently to
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: libpq connection timeout mismanagement