I'll let you in on a secret: NOTIFY is actually a before-commit
operation. This is good enough because it never, or hardly ever,
fails. I would argue that anything you want to do in an AFTER COMMIT
trigger could just as well be done in a BEFORE COMMIT trigger; if
that's
not reliable enough th
Not sure if I follow why this is a problem. Seems like it would be
beneficial to have both BEFORE and AFTER COMMIT triggers.
With the BEFORE COMMIT trigger you would have the ability to 'un-
commit' (rollback) the transaction. With
the AFTER COMMIT trigger you wouldn't have that option because
PFC <[EMAIL PROTECTED]> writes:
> I guess AFTER COMMIT triggers would be like a NOTIFY, but more
> powerful.
I'll let you in on a secret: NOTIFY is actually a before-commit
operation. This is good enough because it never, or hardly ever,
fails. I would argue that anything you want to do
Tom Lane <[EMAIL PROTECTED]> writes:
> Christian Storm <[EMAIL PROTECTED]> writes:
> > Not sure if I follow why this is a problem. Seems like it would be
> > beneficial to have both BEFORE and AFTER COMMIT triggers.
> > With the BEFORE COMMIT trigger you would have the ability to 'un-
> > comm
An AFTER COMMIT trigger would have to be in a separate transaction.
I guess AFTER COMMIT triggers would be like a NOTIFY, but more powerful.
While NOTIFY can't transmit information to another process, this trigger
could, and the other process could then view the results of the commited
On Apr 13, 2006, at 12:38 PM, Tom Lane wrote:
Christian Storm <[EMAIL PROTECTED]> writes:
Not sure if I follow why this is a problem. Seems like it would be
beneficial to have both BEFORE and AFTER COMMIT triggers.
With the BEFORE COMMIT trigger you would have the ability to 'un-
commit' (roll
Christian Storm <[EMAIL PROTECTED]> writes:
> Not sure if I follow why this is a problem. Seems like it would be
> beneficial to have both BEFORE and AFTER COMMIT triggers.
> With the BEFORE COMMIT trigger you would have the ability to 'un-
> commit' (rollback) the transaction. With
> the AFTE
Hi, Tom,
Tom Lane wrote:
>>Why are AFTER COMMIT triggers impossible?
>
> What happens if such a trigger gets an error? You can't un-commit.
Then it must be specified that those triggers are in their own
transaction, and cannot abort the transaction.
Or use the 2-phase-commit infrastructure fo
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Why are AFTER COMMIT triggers impossible?
What happens if such a trigger gets an error? You can't un-commit.
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the
On Wed, Apr 12, 2006 at 04:03:43PM -0700, Josh Berkus wrote:
> PFC,
>
> > It would be nice to have ON COMMIT triggers for this use.
> >
> > However you can emulate ON COMMIT triggers with a modification of the
> > memcache update process :
>
> Well, I'm back in touch with the GORDA projec
PFC,
> It would be nice to have ON COMMIT triggers for this use.
>
> However you can emulate ON COMMIT triggers with a modification of the
> memcache update process :
Well, I'm back in touch with the GORDA project so possibly we can have
BEFORE COMMIT triggers after all.
BTW, it's i
It would be nice to have ON COMMIT triggers for this use.
However you can emulate ON COMMIT triggers with a modification of the
memcache update process :
- A standard trigger sends the data to update to memcache
- The trigger also sends the PID
- Instead of b
On Tue, Apr 04, 2006 at 12:24:42AM -0700, C Storm wrote:
> I was wondering if anyone on the list has a successful installation of
> pgmemcache running
> that uses LISTEN/NOTIFY to signal a successfully completed transaction,
> i.e., to get around the fact
> that TRIGGERS are transaction unaware. O
I was wondering if anyone on the list has a successful installation of
pgmemcache running
that uses LISTEN/NOTIFY to signal a successfully completed transaction,
i.e., to get around the fact
that TRIGGERS are transaction unaware. Or perhaps any other
information regarding a successful
deployment o
14 matches
Mail list logo
