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 CAOsiKELWOmZM03w-t57ha4n94fqK0pnH8QGfbRjU7dQURHLJWw@mail.gmail.com
Whole thread Raw
In response to Re: Detecting if current transaction is modifying the database  (Rob Sargent <robjsargent@gmail.com>)
Responses Re: Detecting if current transaction is modifying the database  (Kevin Grittner <kgrittn@gmail.com>)
List pgsql-general
On Fri, Aug 5, 2016 at 1:26 PM, Rob Sargent <robjsargent@gmail.com> wrote:
> On 08/05/2016 02:15 PM, Christian Ohler wrote:
>>
>> I'm looking for a statement (or sequence of statements) that, when run
>> within a transaction, tells the client if any writes are happening in
>> that transaction – basically an interface similar to my proposed
>> solution.  I have some database wrapper code on the client that passes
>> along arbitrary statements to Postgres, and I'd like for that wrapper
>> code to be able to determine whether the current transaction is a
>> write (for various purposes including logging).  It would be nice not
>> to make the client-side wrapper code dependent on instrumentation of
>> the database schema itself.
>>
>> What can you tell me about my proposed solution?  Does it do what I
>> describe I want from it?  Are there limitations I should be aware of?
>
> At what point do you intend to inform the client that the db will be
> (significantly) altered? You're planned call is within the transaction and
> presumably late in the sequence (so the locks have been created). Not sure
> if your client can see any results until after the transaction has been
> largely executed.  Does that matter?

If I'm understanding you correctly, it does not matter – I'm looking
for a method to determine whether the current transaction includes any
writes _so far_.

Thanks,
Christian.


pgsql-general by date:

Previous
From: Christian Ohler
Date:
Subject: Re: Detecting if current transaction is modifying the database
Next
From: Pavel Suderevsky
Date:
Subject: perc 9 series fastpath feature for database data