Re: Alter index rename concurrently to
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andrey Klychkov <aaklychkov@mail.ru>, Victor Yegorov <vyegorov@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2018-08-01T19:33:09Z
Lists: 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
Commits
-
Lower lock level for renaming indexes
- 1b5d797cd4f7 12.0 landed