pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Noah Misch <noah@leadboat.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Melanie Plageman <melanieplageman@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Cc: Andres Freund <andres@anarazel.de>
Subject: Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin
Date: Mon, 24 Jun 2024 19:09:52 -0700
Message-ID: <20240625020952.9f.nmisch@google.com> (raw)
In-Reply-To: <CAH2-Wzn7EqLndKP4pVtxd8QHvTa_Ev_gU=tELz-aaC3Q0yGuTA@mail.gmail.com>
References: <CAAKRu_bDD7oq9ZwB2OJqub5BovMG6UjEYsoK2LVttadjEqyRGg@mail.gmail.com>
	<CA+TgmoZiArAXM7KwitYWkCmeUQ76Sfg=mgq4_oFo2awWDFdePw@mail.gmail.com>
	<CAH2-Wz=irYFYP5YP2-TajwO3B1maqSSoH-7Ps1aaRv6BHXD7pg@mail.gmail.com>
	<CA+Tgmob4m4TjFCqKFvdR9=Y71fGoH_C-nfPgni6Trt8t3AKOLA@mail.gmail.com>
	<CAAKRu_Y2oTSvhY16EZbLQ6nL3qQXydsfKMXiiCH07KC_GYoRuA@mail.gmail.com>
	<CA+TgmoYzS_bkt_MrNxr5QrXDKfedmh4tStn8UBTTBXqv=3JTew@mail.gmail.com>
	<CAH2-Wzk_nFJOcC6s004bAYGLQ41tPSesTqyBAHcVGxRM97H0Xg@mail.gmail.com>
	<20240625013004.a8.nmisch@google.com>
	<CAH2-Wzn7EqLndKP4pVtxd8QHvTa_Ev_gU=tELz-aaC3Q0yGuTA@mail.gmail.com>

On Mon, Jun 24, 2024 at 09:49:53PM -0400, Peter Geoghegan wrote:
> On Mon, Jun 24, 2024 at 9:30 PM Noah Misch <noah@leadboat.com> wrote:
> > On Mon, Jun 24, 2024 at 03:23:39PM -0400, Melanie Plageman wrote:
> > > Right now, in master, we do use a single horizon when determining what
> > > is pruned -- that from GlobalVisState. OldestXmin is only used for
> > > freezing and full page visibility determinations. Using a different
> > > horizon for pruning by vacuum than freezing is what is causing the
> > > error on master.
> >
> > Agreed, and I think using different sources for pruning and freezing is a
> > recipe for future bugs.  Fundamentally, both are about answering "is
> > snapshot_considers_xid_in_progress(snapshot, xid) false for every snapshot?"
> > That's not to say this thread shall unify the two, but I suspect that's the
> > right long-term direction.
> 
> What does it really mean to unify the two, though?
> 
> If the OldestXmin field was located in struct GlobalVisState (next to
> definitely_needed and maybe_needed), but everything worked in
> essentially the same way as it will with Melanie's patch in place,
> would that count as unifying the two? Why or why not?

To me, no, unification would mean removing the data redundancy.  Relocating
the redundant field and/or code that updates the redundant field certainly
could reduce the risk of bugs, so I'm not opposing everything short of
removing the data redundancy.  I'm just agreeing with the "prefer" from
https://postgr.es/m/CA+TgmoYzS_bkt_MrNxr5QrXDKfedmh4tStn8UBTTBXqv=3JTew@mail.gmail.com





view thread (92+ messages)  latest in thread

Message-ID: <20240625020952.9f.nmisch@google.com>
Permalink:  ../20240625020952.9f.nmisch@google.com/
Also on:    postgresql.org/message-id/20240625020952.9f.nmisch@google.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: noah@leadboat.com, pg@bowt.ie, melanieplageman@gmail.com, robertmhaas@gmail.com, andres@anarazel.de
  Subject: Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin
  In-Reply-To: <20240625020952.9f.nmisch@google.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox