Re: pg_prepared_xact_status

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: konstantin knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_prepared_xact_status
Date: 2017-10-02 01:32:40
Message-ID: CAMsr+YGrAk+NuEO98ARSypjHgRzHQTkFmetZsesOQ5O3ShnECQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2 October 2017 at 08:09, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Sat, Sep 30, 2017 at 2:10 AM, konstantin knizhnik
> <k(dot)knizhnik(at)postgrespro(dot)ru> wrote:
> > txid_status() also not always be able to return status of transaction
> (if wraparound happen).
> > But it is still considered as one of the key features of 10 (transaction
> traceability...).
>
> Not by me. It's a feature, though, for sure.

Same here. It's nice, and obviously I wanted it since I submitted it, but
it's not a key feature by any stretch.

Even if Pg also reported the xid to the client when assigned it'd still be
a nice utility, not a huge headline feature.

> It's also a LOT more
> stable than what you're proposing. Even on a busy system, it takes a
> while to go through 200 million transactions; you probably can't
> realistically do that in under an hour, and you'll probably raise the
> 200 million transaction limit if you're anywhere close to that rate.
> In practice, you'll almost always be able to look up transactions for
> several days, and often weeks or months.

Not necessarily, since it doesn't hold down or delay clog truncation, so if
the system is really eagerly VACUUMed it might discard things sooner.

At the moment though we're quite lazy about clog truncation, mainly because
we're very lazy about vacuuming template1 and template0 (which we should
autofreeze, really) so they tend to hold down global datfrozenxid. If we
get better about that, then we might need some way to ask Pg to keep extra
clog. But for now it works well enough.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2017-10-02 01:38:32 Re: pg_prepared_xact_status
Previous Message Kyotaro HORIGUCHI 2017-10-02 01:28:27 Re: Bug with pg_basebackup and 'shared' tablespace