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