On Thu, Jun 13, 2019 at 4:10 PM Alvaro Herrera 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
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
On Thu, Jun 13, 2019 at 1:04 PM 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
The documentation for the new REINDEX CONCURRENTLY option says:
"When this option is used, PostgreSQL will rebuild the index without
taking any locks that prevent concurrent inserts, updates, or deletes
on the table; whereas a standard reindex build locks out writes (but
not reads) on the table
