| From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
|---|---|
| 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-23 07:07:31 |
| Message-ID: | CAMsr+YEW+VLWkBhQpv33yhbAjcQnF8KFMhjSbgJBXOh_ebqx-w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 23 October 2017 at 05:44, Eric Ridge <eebbrr(at)gmail(dot)com> wrote:
>> On Oct 22, 2017, at 3:24 PM, Peter Geoghegan <pg(at)bowt(dot)ie> 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 Peter is asking "why?".
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Langote | 2017-10-23 07:42:44 | Re: path toward faster partition pruning |
| Previous Message | Rajkumar Raghuwanshi | 2017-10-23 06:58:44 | Re: path toward faster partition pruning |