Re: Alter index rename concurrently to
От | Andres Freund |
---|---|
Тема | Re: Alter index rename concurrently to |
Дата | |
Msg-id | 20180801193616.gi7mfs4kn5kggamf@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Alter index rename concurrently to (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Alter index rename concurrently to
|
Список | pgsql-hackers |
On 2018-08-01 15:33:09 -0400, Robert Haas wrote: > On Wed, Aug 1, 2018 at 3:04 AM, Peter Eisentraut > <peter.eisentraut@2ndquadrant.com> wrote: > > On 31/07/2018 23:25, Tom Lane wrote: > >> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: > >>> On 27/07/2018 16:16, Robert Haas wrote: > >>>> I also suspect that an appropriate fix might be to ensure that > >>>> AcceptInvalidationMessages() is run at least once at the beginning of > >>>> parse analysis. > >> > >>> Why don't we just do that? > >> > >> Don't we do that already? Certainly it should get run in advance of > >> any relation name lookup. There is one at transaction start also, > >> if memory serves. > > > > Right, we do it at transaction start and when opening a relation with a > > lock that you don't already have. Which I suppose in practice is almost > > equivalent to at least once per command, but you can construct cases > > where subsequent commands in a transaction use the all same tables as > > the previous commands, in which case they don't run AIM() again. > > Right. If nobody sees a reason not to change that, I think we should. > It would make the behavior more predictable with, I hope, no real > loss. What precisely are you proposing? Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: