Christian Ohler writes:
> ... (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.)
Well, creating a temp table makes entries in the system catalogs, which
requires both an XID a
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 4:24 PM, Christian Ohler 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.
You mig
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 transaction – basically an interface sim
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 to me that Postgres should ju
On 08/05/2016 02:15 PM, Christian Ohler wrote:
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).
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 to me that Postgres should just be able
> to tell me whether COMMIT will do anyth
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
On 08/05/2016 01:48 PM, Christian Ohler wrote:
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 CO
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
Hi! Make trigger function
Alex Ignatov
Postgres 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 modify database
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
12 matches
Mail list logo
