From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Rui DeSousa <rui(at)crazybean(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Allow "snapshot too old" error, to prevent bloat |
Date: | 2015-03-16 16:28:43 |
Message-ID: | CAD5tBcLuUZq+wvv38MjFX=8a0KOEuZ3O_8M8WBbXp+_2yYJF+A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Mar 16, 2015 at 11:46 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Sun, Mar 15, 2015 at 8:04 PM, Rui DeSousa <rui(at)crazybean(dot)net> wrote:
> > Would a parameter to auto terminate long running transactions be a
> better solution? Terminating the long running transaction would allow for
> the normal vacuuming process to cleanup the deleted records thus avoiding
> database bloat without introducing new semantics to Postgres's MVCC. I
> would also recommend that the default be disabled.
>
> An advantage of Kevin's approach is that you don't have to abort *all*
> long-running transactions, only those that touch data which has been
> modified since then. If your system is read-mostly, that could
> dramatically reduce the number of aborts.
>
>
Indeed. The suggestion of auto-terminating long running transactions misses
the point, ISTM. Most of the use cases I can see for this involve vacuuming
tables that the long running transaction will have no interest in at all
(which is why I suggested being able to set it on a per table basis). I
certainly don't want to be terminating my long running report transaction
so that my queue table which is only ever touched by very short-lived
transactions can be reasonably vacuumed. But that's what we have to do now.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2015-03-16 16:29:53 | Re: Providing catalog view to pg_hba.conf file - Patch submission |
Previous Message | Alvaro Herrera | 2015-03-16 16:26:21 | Re: get_object_address support for additional object types |