Hi, On 2020-04-15 18:11:40 -0700, Peter Geoghegan wrote: > On Wed, Apr 15, 2020 at 4:57 PM Robert Haas <robertmh...@gmail.com> wrote: > > I seem to recall Simon raising this issue at the time that the patch > > was being discussed, and I thought that we had eventually decided that > > it was OK for some reason. But I don't remember the details, and it is > > possible that we got it wrong. :-( > > It must be unreliable because it's based on something that is known to > be unreliable: > > https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/access/nbtree/README;h=c5b0a30e4ebd4fe3bd4a6f8192284c452d1170b9;hb=refs/heads/REL_12_STABLE#l331
Sure, there is some pre-existing wraparound danger for individual pages. But it's a pretty narrow corner case before INDEX_CLEANUP off. That comment says something about "shared-memory free space map", making it sound like any crash would loose the page. But it's a normal FSM these days. Vacuum will insert the deleted page into the free space map. So either the FSM would need to be corrupted to not find the inserted page anymore, or the index would need to grow slow enough to not use a page before the wraparound. And then such wrapped around xids would exist on individual pages. Not on all deleted pages, like with INDEX_CLEANUP false. And, what's worse, in the INDEX_CLEANUP off case, future VACUUMs with INDEX_CLEANUP on might not even visit the index. As there very well might not be many dead heap tuples around anymore (previous vacuums with cleanup off will have removed them), the vacuum_cleanup_index_scale_factor logic may prevent index vacuums. In contrast to the normal situations where the btm_oldest_btpo_xact check will prevent that from becoming a problem. Peter, as far as I can tell, with INDEX_CLEANUP off, nbtree will never be able to recycle half-dead pages? And thus would effectively never recycle any dead space? Is that correct? Greetings, Andres Freund
