Re: Alter index rename concurrently to
От | Robert Haas |
---|---|
Тема | Re: Alter index rename concurrently to |
Дата | |
Msg-id | CA+TgmoZVYSVqNuuw3tzUWcTNaeBj_XvAB8F9+bsesw-NKj=SKA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Alter index rename concurrently to (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: Alter index rename concurrently to
|
Список | pgsql-hackers |
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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: