On Mon, Aug 8, 2016 at 8:23 AM, Kevin Grittner 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.
G
On Fri, Aug 5, 2016 at 1:26 PM, Rob Sargent 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 tran
On Fri, Aug 5, 2016 at 1:24 PM, Tom Lane wrote:
> Christian Ohler 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
On Fri, Aug 5, 2016 at 12:55 PM, Rob Sargent wrote:
>
> What sort of interface are you looking for. Where/When would you grab the
> information? Do what with it? Log triggers are the typical pattern here
> (with packages just for that sort of thing).
I'm looking for a statement (or sequence o
res Professional: http://www.postgrespro.com
> Russian Postgres Company
>
>
>
>
> On Fri, Aug 5, 2016 at 10:25 PM +0300, "Christian Ohler"
> wrote:
>
> Hi,
>>
>> I'm trying to find a way to have Postgres tell me if the current
>> transaction would modif
Hi,
I'm trying to find a way to have Postgres tell me if the current
transaction would modify database if I committed it now. I can live with a
conservative approximation (sometimes – ideally, rarely – get a "yes" even
though nothing would be modified, but never get a "no" even though there
are p
Hi,
we have a use case similar to auditing packages like pgMemento or Audit
Trigger 91plus – we are looking to keep an ordered history of certain write
transactions. I'm trying to understand the trade-offs between different
ways of getting that order, i.e., assigning numbers to transactions
(idea
