Re: BUG #18146: Rows reappearing in Tables after Auto-Vacuum Failure in PostgreSQL on Windows

On Fri, Oct 20, 2023 at 4:38 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Fri, Oct 20, 2023 at 4:16 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> > On Fri, Oct 20, 2023 at 8:50 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > > here are some patches.
> >
> > 0001: LGTM, except in the commit message "By setting
>
> I take that back: there is a palloc() under RelationTruncate(). DNLGTM.

Ooops, I should have quoted to the 0002 patch there.

Hmm. We could teach md.c to do all its path manipulation in
MAXPGPATH-sized output buffers but that still wouldn't be enough
because it might decide to allocate more space for the array of
segments, and I'm not even sure where in PostgreSQL we guarantee that
everything that could appear here would fit in that. But that gives
me an idea. It feels like a bit of a dirty hack, which could perhaps
be made less dirty with some kind of function that includes the word
'ensure' in its name, but I think we can make md.c promise not to
allocate anything before the next CFI with something like this:

* truncate files on disk before they can get the database up
and running
* again. But forcing them to fix permissions (or whatever the
problem is)
* beats corrupting the database.
+ *
+ * First, make sure that smgr doesn't need to allocate any memory to
+ * truncate, since that wouldn't be allowed in a critical
section. We don't
+ * need to call XLogEnsureRecord() for such a small insertion.
*/
+
+ smgrnblocks(RelationGetSmgr(rel), MAIN_FORKNUM);
+ if (fsm)
+ smgrnblocks(RelationGetSmgr(rel), FSM_FORKNUM);
+
START_CRIT_SECTION();