From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | rbiro(at)interfacefinancial(dot)com |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #16705: Triggers deferred during commit callback are not executed |
Date: | 2020-11-06 14:49:58 |
Message-ID: | 1570376.1604674198@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> If you register a function with RegisterXactCallback that causes a trigger
> to be deferred, that trigger is never executed.
I'd say that's in the category of "conceptually ridiculous".
The PRE_COMMIT events are supposed to fire after all user-level
actions in the transaction are finished. Running a trigger that
could do arbitrary things would certainly break the assumptions of
whatever processing people might be doing in PRE_COMMIT callbacks.
Perhaps there's a use case for an even earlier callback that runs in or
before the fire-deferred-triggers loop. But you haven't made any argument
for it, so I'm loath to add more complexity and cycles to transaction
commit for this. The whole area is quite tricky --- for instance, the
interaction with cursor closing is not something that would leap to mind.
So it's not obvious that such a callback could do anything useful and
bulletproof.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-11-06 15:05:32 | Re: BUG #16703: pg-dump fails to process recursive view definition |
Previous Message | Tom Lane | 2020-11-06 14:41:36 | Re: BUG #16665: Segmentation fault |