Re: How to determine that a TransactionId is really aborted?

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Eric Ridge <eebbrr(at)gmail(dot)com>
Cc: Peter Geoghegan <pg(at)bowt(dot)ie>, Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: How to determine that a TransactionId is really aborted?
Date: 2017-10-26 13:50:58
Message-ID: 20171026135058.fov5mrnvvt3peo7v@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Eric Ridge wrote:

> > Again, you'll probably need to put this low level requirement into
> > context if you want sound advice from this list.
>
> I'm just thinking out lout here, but the context is likely something
> along the lines of externally storing all transaction ids, and
> periodically asking Postgres if they're
> known-to-be-aborted-by-all-transactions -- one at a time.

I think if you just check the global xmin, then you're going to maintain
a very long list of transactions "potentially running" whenever there
are long-lived transactions (pg_dump, for example). You could try to
add a TransactionIdIsInProgress() somewhere and discard the xact
downright (by DidCommit and DidAbort) if it returns false. A single
long-running transaction can keep the global xmin down by hundreds of
millions of Xids.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2017-10-26 14:11:43 Re: Transactions involving multiple postgres foreign servers
Previous Message Alvaro Herrera 2017-10-26 13:43:50 Re: Remove secondary checkpoint