On Thu, 3 Aug 2006, Martijn van Oosterhout wrote:
There is no reason to assume that there would be any overhead in storing a
list of outstanding events for your connection compared to today.
Err, yes there would. Think about it: for that example to work, the
server would have to store
On Fri, Aug 04, 2006 at 10:24:43AM +0200, Flemming Frandsen wrote:
On Thu, 3 Aug 2006, Martijn van Oosterhout wrote:
Err, yes there would. Think about it: for that example to work, the
server would have to store every notify that happened until your
transaction completed.
That's exactly
On Fri, 4 Aug 2006, Martijn van Oosterhout wrote:
Really? Even pg_dump cares? Or your maintainence scripts
(VACUUM/ANALYZE)?
Ok, those clients don't, but you rarely have many vacuum/pg_dump
processes going on at the same time, so storing the events for them and
throwing them away is not that
On Thu, Aug 03, 2006 at 12:43:47AM +0200, Flemming Frandsen wrote:
On Wed, 2 Aug 2006, Tom Lane wrote:
Flemming Frandsen [EMAIL PROTECTED] writes:
The listen should simply listen for events issued at the start of the
transaction it's executed in.
BEGIN;
SELECT
On 8/2/06, Flemming Frandsen [EMAIL PROTECTED] wrote:
Ian Harding wrote:
NOTIFY interacts with SQL transactions in some important ways.
Firstly, if a NOTIFY is executed inside a transaction, the notify
events are not delivered until and unless the transaction is
committed. This is
Martijn van Oosterhout kleptog@svana.org writes:
It's slightly surprising though. I havn't seen anyone else complain
about this before though. The only way to fix this is to make the
LISTEN completely atransactional, so NOTIFY can see uncomitted LISTENs
also.
There isn't anything very
Martijn van Oosterhout wrote:
A: BEGIN
A: SELECT * FROM foo and cache the result.
A: LISTEN foochange
B: BEGIN
B: update foo
B: NOTIFY foochange
B: COMMIT
A: COMMIT
Eh? At the point the LISTEN is run, the NOTIFY hasn't committed, so a
row is inserted. At the time the NOTIFY is
Tom Lane wrote:
However, I'm unconvinced that the OP's complaint is valid.
I'm unconvinced that I've stated the problem clearly enough.
I would still expect any
reimplementation of notify messaging to honor the principle that a
LISTEN doesn't take effect till you commit.
Naturally, the
In article [EMAIL PROTECTED],
Flemming Frandsen [EMAIL PROTECTED] writes:
I would still expect any
reimplementation of notify messaging to honor the principle that a
LISTEN doesn't take effect till you commit.
Naturally, the listen should not do anything at all when followed by a
rollback.
Flemming Frandsen [EMAIL PROTECTED] writes:
The listen should simply listen for events issued at the start of the
transaction it's executed in.
BEGIN;
SELECT sleep(10);
LISTEN foo;
No, I don't think so.
regards, tom lane
Tom Lane wrote:
Flemming Frandsen [EMAIL PROTECTED] writes:
The listen should simply listen for events issued at the start of the
transaction it's executed in.
BEGIN;
SELECT sleep(10);
LISTEN foo;
No, I don't think so.
regards,
Tom Lane [EMAIL PROTECTED] writes:
I would still expect any reimplementation of notify messaging to honor the
principle that a LISTEN doesn't take effect till you commit. Otherwise, what
of
BEGIN;
LISTEN foo;
ROLLBACK;
? If I get some events for foo after this I'd
On Wed, Aug 02, 2006 at 09:15:46AM -0400, Oisin Glynn wrote:
I was just about to say that if someone was to do the following they
would get the previously commited state of foo after the sleep not how
foo looked before the sleep otherwise every begin would need an entire
DB snapshot to be
On Aug 2, 2006, at 2:07 AM, Tom Lane wrote:
that the OP's complaint is valid. I would still expect any
reimplementation of notify messaging to honor the principle that a
LISTEN doesn't take effect till you commit. Otherwise, what of
Well, it would break our usage of LISTEN/NOTIFY if they
# [EMAIL PROTECTED] / 2006-08-02 07:57:55 +0200:
I'm bothered by listen listening from the end of the transaction in
stead of the start of the transaction.
Sorry if this isn't what you're after, instead just a question:
Why don't you issue the LISTEN in a separate transaction before
On 2 Aug 2006, Harald Fuchs wrote:
all events that have happened after the snapshot that the transaction
represents (the start of the transaction).
Here you're contradicting yourself. In your second paragraph you
state that LISTEN should get events unless later cancelled by a
ROLLBACK.
On Wed, 2 Aug 2006, Tom Lane wrote:
Flemming Frandsen [EMAIL PROTECTED] writes:
The listen should simply listen for events issued at the start of the
transaction it's executed in.
BEGIN;
SELECT sleep(10);
LISTEN foo;
No, I don't think so.
And why would that
On Wed, 2 Aug 2006, Roman Neuhauser wrote:
I'm bothered by listen listening from the end of the transaction in
stead of the start of the transaction.
Sorry if this isn't what you're after, instead just a question:
Why don't you issue the LISTEN in a separate transaction before
I have an application that does aggresive caching of data pulled from
the database, it even keeps the objects cached between transactions.
Normally this works very well and when the cache is warmed up about 90%
of the database time is saved.
However that leaves the problem of how to notice
On Tue, Aug 01, 2006 at 07:16:39PM +0200, Flemming Frandsen wrote:
This way we could even have wildcard listens, imagine doing a listen %
and getting all the generated events:)
That'd be awesome. Along with a data field in the listen
structure, please :-)
Karsten
--
GPG key ID E4071346 @
On 8/1/06, Flemming Frandsen [EMAIL PROTECTED] wrote:
I have an application that does aggresive caching of data pulled from
the database, it even keeps the objects cached between transactions.
Normally this works very well and when the cache is warmed up about 90%
of the database time is saved.
Ian Harding [EMAIL PROTECTED] writes:
However that just doesn't work, because listen is broken, allow me to
illustrate, here A and B are two clients:
A: BEGIN
A: SELECT * FROM foo and cache the result.
A: LISTEN foochange
B: BEGIN
B: update foo
B: NOTIFY foochange
B: COMMIT
On Tue, Aug 01, 2006 at 07:50:19PM -0400, Gregory Stark wrote:
However that just doesn't work, because listen is broken, allow me to
illustrate, here A and B are two clients:
A: BEGIN
A: SELECT * FROM foo and cache the result.
A: LISTEN foochange
B: BEGIN
B: update foo
Ian Harding wrote:
NOTIFY interacts with SQL transactions in some important ways.
Firstly, if a NOTIFY is executed inside a transaction, the notify
events are not delivered until and unless the transaction is
committed. This is appropriate, since if the transaction is aborted,
all the commands
24 matches
Mail list logo
