| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(at)paquier(dot)xyz>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, James Coleman <jtc331(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: remove spurious CREATE INDEX CONCURRENTLY wait |
| Date: | 2021-11-11 12:38:07 |
| Message-ID: | 202111111238.5sql3jupeshe@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2021-Nov-10, Andres Freund wrote:
> > Reverts 27838981be9d (some comments are kept). Per discussion, it does
> > not seem safe to relax the lock level used for this; in order for it to
> > be safe, there would have to be memory barriers between the point we set
> > the flag and the point we set the trasaction Xid, which perhaps would
> > not be so bad; but there would also have to be barriers at the readers'
> > side, which from a performance perspective might be bad.
> >
> > Now maybe this analysis is wrong and it *is* safe for some reason, but
> > proof of that is not trivial.
>
> I just noticed that this commit (dcfff74fb16) didn't revert the change of lock
> level in ReplicationSlotRelease(). Was that intentional?
Hmm, no, that seems to have been a mistake. I'll restore it.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"El miedo atento y previsor es la madre de la seguridad" (E. Burke)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | vignesh C | 2021-11-11 12:47:13 | Re: Failed transaction statistics to measure the logical replication progress |
| Previous Message | Alvaro Herrera | 2021-11-11 12:37:41 | Re: add recovery, backup, archive, streaming etc. activity messages to server logs along with ps display |