From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Do not check unlogged indexes on standby |
Date: | 2020-02-05 21:35:46 |
Message-ID: | CAH2-WzmTVNetjXLGZ_RSKosH_tUo_pDD5R40k-mz=Pjjer26ew@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Feb 5, 2020 at 1:27 PM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> So, I'm confused. There appear to be two bugfix patches in this thread,
> with no relationship between them, and as far as I can tell only one of
> them has been addressed. What was applied (6754fe65a4c6) is
> significantly different from what Andrey submitted. Is that correct?
> If so, we still have an open bug, right?
No. We had two separate patches on this thread:
1. A bugfix patch to make amcheck not do the wrong thing with unlogged
indexes when operating on a standby.
2. An unrelated feature/enhancement that would allow amcheck to detect
more types of corruption with only an AccessShareLock on the relation.
The first item was dealt with way back in August, without controversy
-- my commit 6754fe65 was more or less Andrey's bugfix.
The second item genereated another thread a little after this thread.
Everything was handled on this other thread. Ultimately, I rejected
the enhancement on the grounds that it wasn't safe on standbys in the
face of concurrent splits and deletions [1].
I believe that all of the items discussed on this thread have been
resolved. Did I miss a CF entry or something?
[1] https://postgr.es/m/CAH2-Wzmb_QOmHX=uWjCFV4Gf1810kz-yVzK6RA=VS41EFcKh=g@mail.gmail.com
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2020-02-06 00:24:16 | Re: Expose lock group leader pid in pg_stat_activity |
Previous Message | Bossart, Nathan | 2020-02-05 21:29:27 | Re: Add MAIN_RELATION_CLEANUP and SECONDARY_RELATION_CLEANUP options to VACUUM |