Re: Detecting if current transaction is modifying the database

From: Christian Ohler <ohler(at)shift(dot)com>
To: Kevin Grittner <kgrittn(at)gmail(dot)com>
Cc: Rob Sargent <robjsargent(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Detecting if current transaction is modifying the database
Date: 2016-08-10 01:02:01
Message-ID: CAOsiKE+6dJDeOKtAVft8Nu3CKPYJm6hYY_y0Av3mLK6kTkXceQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, Aug 8, 2016 at 8:23 AM, Kevin Grittner <kgrittn(at)gmail(dot)com> wrote:
> Your check for a exclusive self-lock on transactionid should work.
> It may be possible to find a way to do it that is less expensive,
> so I would definitely encapsulate that in a function; but off-hand
> I'm not thinking of a better way.

Great, thanks for confirming this.

I agree that txid_current() isn't usable for this, but even a "soft"
version of it (that doesn't assign an ID) still wouldn't quite be what
I'm looking for; Tom's idea of checking for WAL records sounds more
like the "proper" solution, in that it more directly checks whether
COMMIT would do "real" work, and thus would presumably have fewer
false positives. (But that's a guess. AFAICT, creating a temp table
also produces WAL records, so perhaps checking for them is no better
than checking for a transaction ID after all.)

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2016-08-10 01:06:52 Re: Detecting if current transaction is modifying the database
Previous Message Philippe Girolami 2016-08-09 19:23:32 Re: Should a DB vacuum use up a lot of space ?