On Fri, Aug 5, 2016 at 1:24 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > Christian Ohler <ohler@xxxxxxxxx> writes: >> Thanks, fair point. I should have mentioned that I know about triggers but >> was hoping to find a less invasive mechanism (IIUC, I'd have to install a >> trigger on every table) – it seems to me that Postgres should just be able >> to tell me whether COMMIT will do anything, it obviously has to track that >> somehow (or some approximation of it). > > You could check to see if the current transaction has had an XID assigned, > or if it's emitted any WAL records. There are already tests for those > sorts of conditions in various places, though I do not think they're > exposed at the SQL level. Yes, checking if the current transaction has an XID assigned was the idea behind my proposed solution above: SELECT count(*) FROM pg_locks WHERE pid=pg_backend_pid() AND locktype='transactionid' AND mode='ExclusiveLock' AND granted; (See my original email for why I think this checks whether an XID is assigned.) It works in my superficial tests. Does it look like I'm checking for the right conditions? Checking for WAL records is an interesting idea, thanks – it seems like that would be an even more direct test than whether an XID has been assigned. I looked at pg_current_xlog_insert_location(), but that seems to be global, not limited to the current transaction, so doesn't seem usable for this. >> Another thing I should have mentioned is that I don't consider incrementing >> a sequence to be a modification. > > Things might not work the way you want on that... It's fine if they result in false positives (but don't seem to for my above method). Thanks, Christian. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
