| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Kamigishi Rei <iijima(dot)yun(at)koumakan(dot)jp>, David Rowley <dgrowley(at)gmail(dot)com>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #17245: Index corruption involving deduplicated entries |
| Date: | 2021-10-29 02:35:59 |
| Message-ID: | CAH2-Wz=W=osUk9ULhmELcgZkC9jb99MLp_RdoFKJNLABoQtLZw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Thu, Oct 28, 2021 at 6:43 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> heap_prepare_freeze_tuple() doesn't actually modify anything -- it
> just decides what to do later on, in the "nfrozen > 0" critical
> section back in lazy_scan_prune().
Oh, wait. heap_prepare_freeze_tuple() is advertised as not modifying
anything, but that's kind of a lie, since FreezeMultiXactId() is
called and can sometimes allocate a new MultiXactId. The comments
above heap_prepare_freeze_tuple() never got the memo about this
following one of the big MultiXact bug fixes, "Rework tuple freezing
protocol" (commit 3b97e6823b). My mistake.
Presumably this isn't very different to a hard crash that also
allocates a MultiXactId that never gets used. It should be even rarer
than that. We hardly ever hit the goto path, with or without freezing
or almost-freezing. I see that coverage.postgresql.org says we don't
hit it even once. So I think that this is fine.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Noah Misch | 2021-10-29 02:49:44 | Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data |
| Previous Message | Peter Geoghegan | 2021-10-29 01:50:04 | Re: BUG #17245: Index corruption involving deduplicated entries |