Re: Detecting if current transaction is modifying the database - Mailing list pgsql-general

From Christian Ohler
Subject Re: Detecting if current transaction is modifying the database
Date
Msg-id CAOsiKE+6dJDeOKtAVft8Nu3CKPYJm6hYY_y0Av3mLK6kTkXceQ@mail.gmail.com
Whole thread Raw
In response to Re: Detecting if current transaction is modifying the database  (Kevin Grittner <kgrittn@gmail.com>)
Responses Re: Detecting if current transaction is modifying the database  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On Mon, Aug 8, 2016 at 8:23 AM, Kevin Grittner <kgrittn@gmail.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.)


pgsql-general by date:

Previous
From: Xtra Coder
Date:
Subject: Any reasons for 'DO' statement not returning result?
Next
From: Tom Lane
Date:
Subject: Re: Detecting if current transaction is modifying the database