Andrew Dunstan wrote:
Fabien COELHO wrote:
Dear Tom,
trigger on prepare, commit, rollback, savepoint,
Yup, and there won't be.
That's a definite answer!
This has been suggested and rejected before. See the archives.
I'll check into that.
This is a sufficiently
On Tue, 20 May 2008 19:51:32 +0100 Sam Mason wrote:
On Tue, May 20, 2008 at 01:20:48PM -0400, Greg Smith wrote:
On Tue, 20 May 2008, Hannu Krosing wrote:
Tell others that this trx failed, maybe log a failure ? OTOH, this can
be implemented by a daemon that sits on tail -f logfile |
On May 19, 2008, at 6:53 PM, Tom Lane wrote:
Another response I've heard is but I don't want to make
inside-the-database changes, I want to propagate the state to
someplace
external. Of course that's completely broken too, because there is
*absolutely no way* you will ever make such
On Mon, 2008-05-19 at 21:53 -0400, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
trigger on prepare, commit, rollback, savepoint,
This is a sufficiently frequently asked question that I wish someone
would add an entry to the FAQ about it, or add it to the TODO list's
Dear Tom,
trigger on prepare, commit, rollback, savepoint,
I'm sure I've ranted on this several times before, but a quick archive
search doesn't find anything. So, here are a few points to chew on:
I agree that not all of them may make sense, but some may do, and I do not
know which of
On Tue, May 20, 2008 at 06:38:17AM +0100, James Mansion wrote:
Tom Lane wrote:
Another response I've heard is but I don't want to make
inside-the-database changes, I want to propagate the state to someplace
external. Of course that's completely broken too, because there is
Some
things are
On Tue, 2008-05-20 at 12:09 +0200, Fabien COELHO wrote:
As for replication, I was naively thinking of using BEFORE PREPARE to
forward a prepare and possibly fail in the master if the slave fails, and
then an AFTER PREPARE or BEFORE COMMIT/ROLLBACK PREPARE would forward the
final
I'm not claiming this is easy, on the contrary, but ISTM that the 2PC
semantics is all what is fundamentaly needed to achieve synchroneous
replication
There are probably easier solutions for achieving this, like using two
connections at client level
Sure, but that means doing the
On Tue, 2008-05-20 at 13:36 +0200, Fabien COELHO wrote:
or running data modifications through pl/proxy functions where
partitioning function always returns two partitions
I don't think that pl/proxy takes care of 2PC semantics in any useful way.
Possibly something like pgpool could
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
trigger on prepare, commit, rollback, savepoint,
This is a sufficiently frequently asked question that I wish someone
would add an entry to the FAQ about it, or add it to the TODO list's
Features we don't want section.
OK, remind me
On Tue, 20 May 2008, Hannu Krosing wrote:
Tell others that this trx failed, maybe log a failure ? OTOH, this can
be implemented by a daemon that sits on tail -f logfile | grep
ROLLBACK
In order to follow the log files like that successfully in many
environments, you need to stay in sync as
On Tue, May 20, 2008 at 01:20:48PM -0400, Greg Smith wrote:
On Tue, 20 May 2008, Hannu Krosing wrote:
Tell others that this trx failed, maybe log a failure ? OTOH, this can
be implemented by a daemon that sits on tail -f logfile | grep
ROLLBACK
In order to follow the log files like that
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
trigger on prepare, commit, rollback, savepoint,
This is a sufficiently frequently asked question that I
wish someone
would add an entry to the FAQ about it, or add it to the
TODO list's
Features we don't want section.
Dear pgdev,
I've played with triggers a bit, and I have noticed that there seem to be
no way to add a trigger on events such as prepare, commit, rollback,
savepoint, if I'm not mistaken. Also, possible interesting events could
be create, alter and so, but it may already be possible to catch
Fabien COELHO [EMAIL PROTECTED] writes:
I've played with triggers a bit, and I have noticed that there seem to be
no way to add a trigger on events such as prepare, commit, rollback,
savepoint,
Yup, and there won't be. This has been suggested and rejected before.
See the archives.
It
Dear Tom,
trigger on prepare, commit, rollback, savepoint,
Yup, and there won't be.
That's a definite answer!
This has been suggested and rejected before. See the archives.
I'll check into that.
It seems to me that such triggers would be useful to help implement a
simple (hmmm...)
Fabien COELHO wrote:
Dear Tom,
trigger on prepare, commit, rollback, savepoint,
Yup, and there won't be.
That's a definite answer!
This has been suggested and rejected before. See the archives.
I'll check into that.
This is a sufficiently frequently asked question that I wish
Andrew Dunstan wrote:
Fabien COELHO wrote:
Dear Tom,
trigger on prepare, commit, rollback, savepoint,
Yup, and there won't be.
That's a definite answer!
This has been suggested and rejected before. See the archives.
I'll check into that.
This is a sufficiently
Bruce Momjian [EMAIL PROTECTED] writes:
trigger on prepare, commit, rollback, savepoint,
This is a sufficiently frequently asked question that I wish someone
would add an entry to the FAQ about it, or add it to the TODO list's
Features we don't want section.
OK, remind me why we don't
Tom Lane wrote:
* Trigger on rollback: what's that supposed to do? The current
transaction is already aborted, so the trigger has no hope of making any
database changes that will ever be visible to anyone.
It can however affect state in the backend doing the rollback, which can
be useful.
20 matches
Mail list logo
