Table foo has a trigger that on insert raises a notice.
Process A listens for that notice, and blocks on the socket (using
kqueue).
Process B commits an insert of a row into that table, then commits an
insert
of another row immediately.
Process A wakes up and reads the notice, queries table foo for new
records,
finds only the first, processes it, checks the socket and blocks.
In other words, in the second insert transaction, pg seems to be
coalescing
the second notice after the first notice has been delivered, but before
the
second transaction is visible to other processes...
> So it is a bad idea to depend on the number of notifications received.
> Instead, use NOTIFY to wake up applications that need to pay attention
to
> something, and use a database object (such as a sequence) to keep track
of
> what happened or how many times it happened.
Uhm, yeah? 2 changes committed, 1 notice sent, 1 change visible on receipt
of notice.
Of course I can query table foo for new records twice, and that seems to
work, but it also seems like a bad idea to depend on that kind of timing
detail. (FYI, merely inserting a couple of log statements when process B
wakes up results in both changes being seen by the query.)
--
Scott Ribe
scott_ribe@[EMAIL PROTECTED]
(303) 722-0567 voice
--
Sent via pgsql-general mailing list (pgsql-general@[EMAIL PROTECTED]
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
|
