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/
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 |