Re: Allow "snapshot too old" error, to prevent bloat - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Allow "snapshot too old" error, to prevent bloat
Date
Msg-id CABUevEydGn_vsx6OBKQL7jgm9Fc28sDS5jZyXqpxCsC2ZMbxVw@mail.gmail.com
Whole thread Raw
In response to Re: Allow "snapshot too old" error, to prevent bloat  (Kevin Grittner <kgrittn@ymail.com>)
List pgsql-hackers
On Wed, Feb 18, 2015 at 10:57 PM, Kevin Grittner <kgrittn@ymail.com> wrote:
Magnus Hagander <magnus@hagander.net> wrote:
> On Feb 17, 2015 12:26 AM, "Andres Freund" <andres@2ndquadrant.com> wrote:
>> On 2015-02-16 16:35:46 -0500, Bruce Momjian wrote:
>> But max_standby_streaming_delay, max_standby_archive_delay and
>> hot_standby_feedback are among the most frequent triggers for
>> questions and complaints that I/we see.
>>
> Agreed.
> And a really bad one used to be vacuum_defer_cleanup_age, because
> of confusing units amongst other things. Which in terms seems
> fairly close to Kevins suggestions, unfortunately.

Particularly my initial suggestion, which was to base snapshot
"age" it on the number of transaction IDs assigned.  Does this look
any better to you if it is something that can be set to '20min' or
'1h'?  Just to restate, that would not automatically cancel the
snapshots past that age; it would allow vacuum of any tuples which
became "dead" that long ago, and would cause a "snapshot too old"
message for any read of a page modified more than that long ago
using a snapshot which was older than that.

Yes, it would definitely look much better. My reference per above was exactly that - having a setting in the unit "number of xids" confused a lot of users and made it really hard to tune. Having something in time units is a lot easier to understand and tune for most people.

--

pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: Odd behavior of updatable security barrier views on foreign tables
Next
From: Gavin Flower
Date:
Subject: Re: Expanding the use of FLEXIBLE_ARRAY_MEMBER for declarations like foo[1]