Re: snapshot too old issues, first around wraparound and then more.

From: Kevin Grittner <kgrittn(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Peter Geoghegan <pg(at)bowt(dot)ie>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: snapshot too old issues, first around wraparound and then more.
Date: 2020-04-02 16:36:32
Message-ID: CACjxUsOOMAsAkYy8EEQQNcfzj=VZqJEYwevoP_CD8OofG++kSg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 1, 2020 at 7:17 PM Andres Freund <andres(at)anarazel(dot)de> wrote:

> FWIW, with autovacuum=off the query does not get killed until a manual
> vacuum, nor if fewer rows are deleted and the table has previously been
> vacuumed.
>
> The vacuum in the second session isn't required. There just needs to be
> something consuming an xid, so that oldSnapshotControl->latest_xmin is
> increased. A single SELECT txid_current(); or such in a separate session
> is sufficient.
>

Agreed. I don't see that part as a problem; if no xids are being consumed,
it's hard to see how we could be heading into debilitating levels of bloat,
so there is no need to perform the early pruning. It would not be worth
consuming any cycles to ensure that pruning happens sooner than it does in
this case. It's OK for it to happen any time past the moment that the
snapshot hits the threshold, but it's also OK for it to wait until a vacuum
of the table or until some activity consumes an xid.

--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2020-04-02 16:40:15 Re: snapshot too old issues, first around wraparound and then more.
Previous Message Tom Lane 2020-04-02 16:16:03 Re: Ltree syntax improvement