pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedpgmemcache
14+ messages / 9 participants
[nested] [flat]
* pgmemcache
@ 2006-04-04 07:24 C Storm <christian.storm@gmail.com>
2006-04-11 22:55 ` Re: pgmemcache Jim C. Nasby <jnasby@pervasive.com>
0 siblings, 1 reply; 14+ messages in thread
From: C Storm @ 2006-04-04 07:24 UTC (permalink / raw)
To: pgsql-performance
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 of pgmemcache.
The information available on the web/groups is pretty scant. Any
information would be greatly appreciated!
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: pgmemcache
2006-04-04 07:24 pgmemcache C Storm <christian.storm@gmail.com>
@ 2006-04-11 22:55 ` Jim C. Nasby <jnasby@pervasive.com>
2006-04-12 07:19 ` Re: pgmemcache PFC <lists@peufeu.com>
0 siblings, 1 reply; 14+ messages in thread
From: Jim C. Nasby @ 2006-04-11 22:55 UTC (permalink / raw)
To: C Storm <christian.storm@gmail.com>; +Cc: pgsql-performance
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. Or perhaps any other
> information regarding a successful
> deployment of pgmemcache.
The problem with attempting that is that you'd have a window between
transaction commit and when the cache was invalidated. If that's
acceptable then it shouldn't be too difficult to set something up using
LISTEN/NOTIFY like you describe.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: pgmemcache
2006-04-04 07:24 pgmemcache C Storm <christian.storm@gmail.com>
2006-04-11 22:55 ` Re: pgmemcache Jim C. Nasby <jnasby@pervasive.com>
@ 2006-04-12 07:19 ` PFC <lists@peufeu.com>
2006-04-12 23:03 ` Re: pgmemcache Josh Berkus <josh@agliodbs.com>
0 siblings, 1 reply; 14+ messages in thread
From: PFC @ 2006-04-12 07:19 UTC (permalink / raw)
To: Jim C. Nasby <jnasby@pervasive.com>; C Storm <christian.storm@gmail.com>; +Cc: pgsql-performance
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 being used immediately, this data is kept in a buffer
- Notify is issued
On commit :
- postgres sends the NOTIFY signal
- the memcache updater reads the NOTIFY (which embeds the PID I believe)
; it finds the buffered data sent above and uses it to update memcached
On rollback :
- Interesting problem ;)))
OK, it's a kludge. When can we get ON COMMIT triggers ?
> 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. Or perhaps any other
>> information regarding a successful
>> deployment of pgmemcache.
>
> The problem with attempting that is that you'd have a window between
> transaction commit and when the cache was invalidated. If that's
> acceptable then it shouldn't be too difficult to set something up using
> LISTEN/NOTIFY like you describe.
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: pgmemcache
2006-04-04 07:24 pgmemcache C Storm <christian.storm@gmail.com>
2006-04-11 22:55 ` Re: pgmemcache Jim C. Nasby <jnasby@pervasive.com>
2006-04-12 07:19 ` Re: pgmemcache PFC <lists@peufeu.com>
@ 2006-04-12 23:03 ` Josh Berkus <josh@agliodbs.com>
2006-04-13 00:10 ` Re: pgmemcache Jim C. Nasby <jnasby@pervasive.com>
0 siblings, 1 reply; 14+ messages in thread
From: Josh Berkus @ 2006-04-12 23:03 UTC (permalink / raw)
To: pgsql-performance; +Cc: PFC <lists@peufeu.com>; Jim C. Nasby <jnasby@pervasive.com>; C Storm <christian.storm@gmail.com>
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 important to note that AFTER COMMIT triggers are logically
impossible, so please use BEFORE COMMIT so that it's clear what we're
talking about.
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: pgmemcache
2006-04-04 07:24 pgmemcache C Storm <christian.storm@gmail.com>
2006-04-11 22:55 ` Re: pgmemcache Jim C. Nasby <jnasby@pervasive.com>
2006-04-12 07:19 ` Re: pgmemcache PFC <lists@peufeu.com>
2006-04-12 23:03 ` Re: pgmemcache Josh Berkus <josh@agliodbs.com>
@ 2006-04-13 00:10 ` Jim C. Nasby <jnasby@pervasive.com>
2006-04-13 00:35 ` Re: pgmemcache Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 14+ messages in thread
From: Jim C. Nasby @ 2006-04-13 00:10 UTC (permalink / raw)
To: Josh Berkus <josh@agliodbs.com>; +Cc: pgsql-performance@postgresql.org, PFC <lists@peufeu.com>; C Storm <christian.storm@gmail.com>
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 project so possibly we can have
> BEFORE COMMIT triggers after all.
>
> BTW, it's important to note that AFTER COMMIT triggers are logically
> impossible, so please use BEFORE COMMIT so that it's clear what we're
> talking about.
Why are AFTER COMMIT triggers impossible? ISTM they would be useful as a
means to indicate to some external process if a transaction succeeded or
not. And for some things you might only want to fire the trigger after
you knew that the transaction had committed.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: pgmemcache
2006-04-04 07:24 pgmemcache C Storm <christian.storm@gmail.com>
2006-04-11 22:55 ` Re: pgmemcache Jim C. Nasby <jnasby@pervasive.com>
2006-04-12 07:19 ` Re: pgmemcache PFC <lists@peufeu.com>
2006-04-12 23:03 ` Re: pgmemcache Josh Berkus <josh@agliodbs.com>
2006-04-13 00:10 ` Re: pgmemcache Jim C. Nasby <jnasby@pervasive.com>
@ 2006-04-13 00:35 ` Tom Lane <tgl@sss.pgh.pa.us>
2006-04-13 14:03 ` Re: pgmemcache Markus Schaber <schabi@logix-tt.com>
2006-04-13 17:29 ` Re: pgmemcache Christian Storm <christian.storm@gmail.com>
0 siblings, 2 replies; 14+ messages in thread
From: Tom Lane @ 2006-04-13 00:35 UTC (permalink / raw)
To: Jim C. Nasby <jnasby@pervasive.com>; +Cc: Josh Berkus <josh@agliodbs.com>; pgsql-performance@postgresql.org, PFC <lists@peufeu.com>; C Storm <christian.storm@gmail.com>
"Jim C. Nasby" <jnasby@pervasive.com> writes:
> Why are AFTER COMMIT triggers impossible?
What happens if such a trigger gets an error? You can't un-commit.
regards, tom lane
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: pgmemcache
2006-04-04 07:24 pgmemcache C Storm <christian.storm@gmail.com>
2006-04-11 22:55 ` Re: pgmemcache Jim C. Nasby <jnasby@pervasive.com>
2006-04-12 07:19 ` Re: pgmemcache PFC <lists@peufeu.com>
2006-04-12 23:03 ` Re: pgmemcache Josh Berkus <josh@agliodbs.com>
2006-04-13 00:10 ` Re: pgmemcache Jim C. Nasby <jnasby@pervasive.com>
2006-04-13 00:35 ` Re: pgmemcache Tom Lane <tgl@sss.pgh.pa.us>
@ 2006-04-13 14:03 ` Markus Schaber <schabi@logix-tt.com>
1 sibling, 0 replies; 14+ messages in thread
From: Markus Schaber @ 2006-04-13 14:03 UTC (permalink / raw)
To: pgsql-performance
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 for them.
Markus
--
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf. | Software Development GIS
Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: pgmemcache
2006-04-04 07:24 pgmemcache C Storm <christian.storm@gmail.com>
2006-04-11 22:55 ` Re: pgmemcache Jim C. Nasby <jnasby@pervasive.com>
2006-04-12 07:19 ` Re: pgmemcache PFC <lists@peufeu.com>
2006-04-12 23:03 ` Re: pgmemcache Josh Berkus <josh@agliodbs.com>
2006-04-13 00:10 ` Re: pgmemcache Jim C. Nasby <jnasby@pervasive.com>
2006-04-13 00:35 ` Re: pgmemcache Tom Lane <tgl@sss.pgh.pa.us>
@ 2006-04-13 17:29 ` Christian Storm <christian.storm@gmail.com>
2006-04-13 17:38 ` Re: pgmemcache Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 14+ messages in thread
From: Christian Storm @ 2006-04-13 17:29 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Jim C. Nasby <jnasby@pervasive.com>; Josh Berkus <josh@agliodbs.com>; pgsql-performance@postgresql.org, PFC <lists@peufeu.com>
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 the
commit has already been successful. However,
with an AFTER COMMIT you would be able to trigger other downstream
events that rely on a transaction successfully committing.
If the trigger fails it is the triggers problem, it isn't the
commit's problem, i.e., you wouldn't want to 'un-commit'. If the
trigger
gets an error it has to gracefully deal with that error programatically.
Where have I gone astray with this logic?
On Apr 12, 2006, at 5:35 PM, Tom Lane wrote:
> "Jim C. Nasby" <jnasby@pervasive.com> writes:
>> Why are AFTER COMMIT triggers impossible?
>
> What happens if such a trigger gets an error? You can't un-commit.
>
> regards, tom lane
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: pgmemcache
2006-04-04 07:24 pgmemcache C Storm <christian.storm@gmail.com>
2006-04-11 22:55 ` Re: pgmemcache Jim C. Nasby <jnasby@pervasive.com>
2006-04-12 07:19 ` Re: pgmemcache PFC <lists@peufeu.com>
2006-04-12 23:03 ` Re: pgmemcache Josh Berkus <josh@agliodbs.com>
2006-04-13 00:10 ` Re: pgmemcache Jim C. Nasby <jnasby@pervasive.com>
2006-04-13 00:35 ` Re: pgmemcache Tom Lane <tgl@sss.pgh.pa.us>
2006-04-13 17:29 ` Re: pgmemcache Christian Storm <christian.storm@gmail.com>
@ 2006-04-13 17:38 ` Tom Lane <tgl@sss.pgh.pa.us>
2006-04-13 18:29 ` Re: pgmemcache Jim Nasby <jnasby@pervasive.com>
2006-04-13 20:23 ` Re: pgmemcache PFC <lists@peufeu.com>
2006-04-13 20:52 ` Re: pgmemcache Greg Stark <gsstark@mit.edu>
0 siblings, 3 replies; 14+ messages in thread
From: Tom Lane @ 2006-04-13 17:38 UTC (permalink / raw)
To: Christian Storm <christian.storm@gmail.com>; +Cc: Jim C. Nasby <jnasby@pervasive.com>; Josh Berkus <josh@agliodbs.com>; pgsql-performance@postgresql.org, PFC <lists@peufeu.com>
Christian Storm <christian.storm@gmail.com> 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 AFTER COMMIT trigger you wouldn't have that option because the
> commit has already been successful. However,
> with an AFTER COMMIT you would be able to trigger other downstream
> events that rely on a transaction successfully committing.
An AFTER COMMIT trigger would have to be in a separate transaction.
What happens if there's more than one, and one of them fails? Even
more to the point, if it's a separate transaction, don't you have
to fire all these triggers again when you commit that transaction?
The idea seems circular.
regards, tom lane
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: pgmemcache
2006-04-04 07:24 pgmemcache C Storm <christian.storm@gmail.com>
2006-04-11 22:55 ` Re: pgmemcache Jim C. Nasby <jnasby@pervasive.com>
2006-04-12 07:19 ` Re: pgmemcache PFC <lists@peufeu.com>
2006-04-12 23:03 ` Re: pgmemcache Josh Berkus <josh@agliodbs.com>
2006-04-13 00:10 ` Re: pgmemcache Jim C. Nasby <jnasby@pervasive.com>
2006-04-13 00:35 ` Re: pgmemcache Tom Lane <tgl@sss.pgh.pa.us>
2006-04-13 17:29 ` Re: pgmemcache Christian Storm <christian.storm@gmail.com>
2006-04-13 17:38 ` Re: pgmemcache Tom Lane <tgl@sss.pgh.pa.us>
@ 2006-04-13 18:29 ` Jim Nasby <jnasby@pervasive.com>
2 siblings, 0 replies; 14+ messages in thread
From: Jim Nasby @ 2006-04-13 18:29 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Christian Storm <christian.storm@gmail.com>; Josh Berkus <josh@agliodbs.com>; pgsql-performance@postgresql.org, PFC <lists@peufeu.com>
On Apr 13, 2006, at 12:38 PM, Tom Lane wrote:
> Christian Storm <christian.storm@gmail.com> 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 AFTER COMMIT trigger you wouldn't have that option because the
>> commit has already been successful. However,
>> with an AFTER COMMIT you would be able to trigger other downstream
>> events that rely on a transaction successfully committing.
>
> An AFTER COMMIT trigger would have to be in a separate transaction.
> What happens if there's more than one, and one of them fails? Even
> more to the point, if it's a separate transaction, don't you have
> to fire all these triggers again when you commit that transaction?
> The idea seems circular.
I suspect that in reality you'd probably want each on-commit trigger
to be it's own transaction, but it depends on what you're doing.
Also, I can't see any use for them where you'd actually be
interacting with the database, only if you were calling something
externally via a function. One example would be sending an email out
when a certain table changes; in many cases it's better to let the
change happen even if the email can't be sent, and you'd rather not
send an email if the transaction just ends up rolling back for some
reason. And yes, you'd have to ensure you didn't code yourself up a
trigger loop.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: pgmemcache
2006-04-04 07:24 pgmemcache C Storm <christian.storm@gmail.com>
2006-04-11 22:55 ` Re: pgmemcache Jim C. Nasby <jnasby@pervasive.com>
2006-04-12 07:19 ` Re: pgmemcache PFC <lists@peufeu.com>
2006-04-12 23:03 ` Re: pgmemcache Josh Berkus <josh@agliodbs.com>
2006-04-13 00:10 ` Re: pgmemcache Jim C. Nasby <jnasby@pervasive.com>
2006-04-13 00:35 ` Re: pgmemcache Tom Lane <tgl@sss.pgh.pa.us>
2006-04-13 17:29 ` Re: pgmemcache Christian Storm <christian.storm@gmail.com>
2006-04-13 17:38 ` Re: pgmemcache Tom Lane <tgl@sss.pgh.pa.us>
@ 2006-04-13 20:23 ` PFC <lists@peufeu.com>
2006-04-14 00:43 ` Re: pgmemcache Tom Lane <tgl@sss.pgh.pa.us>
2 siblings, 1 reply; 14+ messages in thread
From: PFC @ 2006-04-13 20:23 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; Christian Storm <christian.storm@gmail.com>; +Cc: Jim C. Nasby <jnasby@pervasive.com>; Josh Berkus <josh@agliodbs.com>; pgsql-performance
> 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
transaction.
Also, implementing a long process (something involving network
roundtrips, for instance) in a BEFORE COMMIT trigger would delay the
transaction and any locks it holds with no benefit.
> What happens if there's more than one, and one of them fails?
Each one in its own transaction ?
> Even more to the point, if it's a separate transaction, don't you have
> to fire all these triggers again when you commit that transaction?
> The idea seems circular.
I guess AFTER COMMIT triggers are most useful when coupled to a trigger
on a modification to a table. So, the "before / after commit" could be an
attribute of an AFTER INSERT/UPDATE/DELETE trigger. If the AFTER COMMIT
trigger doesn't do any modifications to the target table, there will be no
infinite loop.
The before/after commit could also be implemented not via triggers, but
via deferred actions, by telling postgres to execute a specific query just
before/after the transaction commits. This could be used to implement the
triggers, but would also be more generic : a trigger on INSERT could then
defer a call to memcache update once the transaction is commited. It gets
lisp-ish, but it would be really cool?
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: pgmemcache
2006-04-04 07:24 pgmemcache C Storm <christian.storm@gmail.com>
2006-04-11 22:55 ` Re: pgmemcache Jim C. Nasby <jnasby@pervasive.com>
2006-04-12 07:19 ` Re: pgmemcache PFC <lists@peufeu.com>
2006-04-12 23:03 ` Re: pgmemcache Josh Berkus <josh@agliodbs.com>
2006-04-13 00:10 ` Re: pgmemcache Jim C. Nasby <jnasby@pervasive.com>
2006-04-13 00:35 ` Re: pgmemcache Tom Lane <tgl@sss.pgh.pa.us>
2006-04-13 17:29 ` Re: pgmemcache Christian Storm <christian.storm@gmail.com>
2006-04-13 17:38 ` Re: pgmemcache Tom Lane <tgl@sss.pgh.pa.us>
2006-04-13 20:23 ` Re: pgmemcache PFC <lists@peufeu.com>
@ 2006-04-14 00:43 ` Tom Lane <tgl@sss.pgh.pa.us>
2006-04-14 18:01 ` Re: pgmemcache Christian Storm <christian.storm@gmail.com>
0 siblings, 1 reply; 14+ messages in thread
From: Tom Lane @ 2006-04-14 00:43 UTC (permalink / raw)
To: PFC <lists@peufeu.com>; +Cc: Christian Storm <christian.storm@gmail.com>; Jim C. Nasby <jnasby@pervasive.com>; Josh Berkus <josh@agliodbs.com>; pgsql-performance
PFC <lists@peufeu.com> 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 in an AFTER COMMIT
trigger could just as well be done in a BEFORE COMMIT trigger; if that's
not reliable enough then you need to fix your trigger.
regards, tom lane
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: pgmemcache
2006-04-04 07:24 pgmemcache C Storm <christian.storm@gmail.com>
2006-04-11 22:55 ` Re: pgmemcache Jim C. Nasby <jnasby@pervasive.com>
2006-04-12 07:19 ` Re: pgmemcache PFC <lists@peufeu.com>
2006-04-12 23:03 ` Re: pgmemcache Josh Berkus <josh@agliodbs.com>
2006-04-13 00:10 ` Re: pgmemcache Jim C. Nasby <jnasby@pervasive.com>
2006-04-13 00:35 ` Re: pgmemcache Tom Lane <tgl@sss.pgh.pa.us>
2006-04-13 17:29 ` Re: pgmemcache Christian Storm <christian.storm@gmail.com>
2006-04-13 17:38 ` Re: pgmemcache Tom Lane <tgl@sss.pgh.pa.us>
2006-04-13 20:23 ` Re: pgmemcache PFC <lists@peufeu.com>
2006-04-14 00:43 ` Re: pgmemcache Tom Lane <tgl@sss.pgh.pa.us>
@ 2006-04-14 18:01 ` Christian Storm <christian.storm@gmail.com>
0 siblings, 0 replies; 14+ messages in thread
From: Christian Storm @ 2006-04-14 18:01 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: PFC <lists@peufeu.com>; Jim C. Nasby <jnasby@pervasive.com>; Josh Berkus <josh@agliodbs.com>; pgsql-performance
> 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 then you need to fix your trigger.
So, looping back to pgmemcache. It doesn't seem like it's about the
trigger failing; it's about
the transaction failing. How could I 'fix my trigger' so that if
the transaction fails
the cache wouldn't be updated?
> An AFTER COMMIT trigger would have to be in a separate transaction.
Agreed. Each trigger being in its own transaction.
> What happens if there's more than one, and one of them fails?
Each AFTER COMMIT trigger would be in its own transaction. So if it
fails, let it fail. It isn't the original transactions fault. If
you want it to bundled
with the original transaction then do a BEFORE COMMIT.
If there is more than one, so be it. One may fail, another may not.
If that is not okay or the intended behavior, then create a new
trigger than
combines them into one transaction so that they are coupled.
> Even
> more to the point, if it's a separate transaction, don't you have
> to fire all these triggers again when you commit that transaction?
> The idea seems circular.
Why would it have to do this? Not sure if I follow. In my mind,
the only way this would happen is if the AFTER COMMIT trigger acted
upon the very same table it is triggered off of. Then you could
have a circular reference. However, this is true for the BEFORE COMMIT
situation too. I don't see the difference. What am I missing?
Cheers,
Christian
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: pgmemcache
2006-04-04 07:24 pgmemcache C Storm <christian.storm@gmail.com>
2006-04-11 22:55 ` Re: pgmemcache Jim C. Nasby <jnasby@pervasive.com>
2006-04-12 07:19 ` Re: pgmemcache PFC <lists@peufeu.com>
2006-04-12 23:03 ` Re: pgmemcache Josh Berkus <josh@agliodbs.com>
2006-04-13 00:10 ` Re: pgmemcache Jim C. Nasby <jnasby@pervasive.com>
2006-04-13 00:35 ` Re: pgmemcache Tom Lane <tgl@sss.pgh.pa.us>
2006-04-13 17:29 ` Re: pgmemcache Christian Storm <christian.storm@gmail.com>
2006-04-13 17:38 ` Re: pgmemcache Tom Lane <tgl@sss.pgh.pa.us>
@ 2006-04-13 20:52 ` Greg Stark <gsstark@mit.edu>
2 siblings, 0 replies; 14+ messages in thread
From: Greg Stark @ 2006-04-13 20:52 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Christian Storm <christian.storm@gmail.com>; Jim C. Nasby <jnasby@pervasive.com>; Josh Berkus <josh@agliodbs.com>; pgsql-performance@postgresql.org, PFC <lists@peufeu.com>
Tom Lane <tgl@sss.pgh.pa.us> writes:
> Christian Storm <christian.storm@gmail.com> 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 AFTER COMMIT trigger you wouldn't have that option because the
> > commit has already been successful. However,
> > with an AFTER COMMIT you would be able to trigger other downstream
> > events that rely on a transaction successfully committing.
>
> An AFTER COMMIT trigger would have to be in a separate transaction.
> What happens if there's more than one, and one of them fails? Even
> more to the point, if it's a separate transaction, don't you have
> to fire all these triggers again when you commit that transaction?
> The idea seems circular.
Maybe it just means they would have to be limited to not making any database
modifications. Ie, all they can do is notify the outside world that the
transaction committed.
Presumably if you wanted to make any database modifications you would just do
it in the transaction anyways since they wouldn't show up until the
transaction commits.
--
greg
^ permalink raw reply [nested|flat] 14+ messages in thread
end of thread, other threads:[~2006-04-14 18:01 UTC | newest]
Thread overview: 14+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2006-04-04 07:24 pgmemcache C Storm <christian.storm@gmail.com>
2006-04-11 22:55 ` Jim C. Nasby <jnasby@pervasive.com>
2006-04-12 07:19 ` PFC <lists@peufeu.com>
2006-04-12 23:03 ` Josh Berkus <josh@agliodbs.com>
2006-04-13 00:10 ` Jim C. Nasby <jnasby@pervasive.com>
2006-04-13 00:35 ` Tom Lane <tgl@sss.pgh.pa.us>
2006-04-13 14:03 ` Markus Schaber <schabi@logix-tt.com>
2006-04-13 17:29 ` Christian Storm <christian.storm@gmail.com>
2006-04-13 17:38 ` Tom Lane <tgl@sss.pgh.pa.us>
2006-04-13 18:29 ` Jim Nasby <jnasby@pervasive.com>
2006-04-13 20:23 ` PFC <lists@peufeu.com>
2006-04-14 00:43 ` Tom Lane <tgl@sss.pgh.pa.us>
2006-04-14 18:01 ` Christian Storm <christian.storm@gmail.com>
2006-04-13 20:52 ` Greg Stark <gsstark@mit.edu>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox