Re: [PATCH] Transaction traceability - txid_status(bigint)

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Craig Ringer <craig(at)2ndquadrant(dot)com>
Cc: Petr Jelinek <petr(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Subject: Re: [PATCH] Transaction traceability - txid_status(bigint)
Date: 2016-09-20 14:46:39
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On Mon, Sep 19, 2016 at 9:54 PM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
>> You appear to have attached the wrong patch set.
> Whoops, multitasking fail.
> Sorry for the late response, hospitals are "fun".

I did some cleanup of 0001 (see attached) and was all set to commit it
when I realized what I think is a problem: holding XidGenLock doesn't
seem to help with the race condition between this function and CLOG
truncation, because vac_truncate_clog() updates the shared memory
limits AFTER performing the truncation. If the order of those
operations were reversed, we'd be fine, because it would get stuck
trying to update the shared memory limits and wouldn't be able to
truncate until it did - and conversely, if it updated the shared
memory limits before we examined them, that would be OK, too, because
we'd be sure not to consult the pages that are about to be truncated.
As it is, though, I don't see that there's any real interlock here.

(BTW, the stuff you moved from clog.c to clog.h doesn't actually need
to be moved; one of the changes I made here was to undo that.)

Robert Haas
The Enterprise PostgreSQL Company

Attachment Content-Type Size
txid-status-rmh.patch invalid/octet-stream 11.3 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-09-20 14:58:11 Re: [RFC] Should we fix postmaster to avoid slow shutdown?
Previous Message Stas Kelvich 2016-09-20 14:13:19 Re: Speedup twophase transactions