From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: REINDEX locking |
Date: | 2019-06-13 20:22:24 |
Message-ID: | CA+TgmoZ1kJpvXY9ZG_ymc7vbz+t67j2taR=1NKw0zNwN-pW4EA@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jun 13, 2019 at 4:10 PM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> On 2019-Jun-13, Robert Haas wrote:
> > Typing "COMMIT;" or "ROLLBACK;" in S1 unblocks the reindex and it
> > succeeds, but otherwise it doesn't, contrary to the claim that a
> > regular REINDEX does not block reads. The reason for this seems to be
> > that the REINDEX acquires AccessExclusiveLock on all of the indexes of
> > the table, and a SELECT acquires AccessShareLock on all indexes of the
> > table (even if the particular plan at issue does not use them); e.g.
> > in this case the plan is a Seq Scan. REINDEX acquires only ShareLock
> > on the table itself, but this apparently does nobody wanting to run a
> > query any good.
>
> Yeah, this has been mentioned before, and it's pretty infuriating, but I
> don't think we have any solution currently in the cards. I think a
> workaround is to use prepared queries that don't involve the index,
> since it's only the planning phase that wants to acquire lock on indexes
> that execution doesn't use. I don't see this as a practical solution.
Wow, that's not nice at all. I feel like we should at least document
this better.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2019-06-13 20:53:05 | Re: release notes: tids & self-joins |
Previous Message | Alvaro Herrera | 2019-06-13 20:10:37 | Re: REINDEX locking |