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 the same problem as exists today, although one transaction
> earlier.
>
> If someone listens to a bunch of events, does a commit and THEN waits
> around forever then you still have to store all the events from that point
> on.
Well no, because at the point the transaction commits, you *know* what
LISTENs they want. If another process does a NOTIFY, a signal is sent
your process, which sets a flag to sent the message to the client. So
by waiting after the listen, it'll run with the flag set until the next
command.
The difference being that what you want requires the server to store
the (notify string,backend) pairs for every transaction until commit,
whereas currently the server only has to store that for backends that
actually did a LISTEN.
> The only difference is that it would have to happen from the start of the
> transaction in stead of from the end of the transaction.
You could compromise and suggest that NOTIFY look at uncommitted
records too. That would change the window to from the moment the LISTEN
is executed, even if the transaction isn't committed. That wouldn't be
too expensive.
> > Currently NOTIFY requires no storage at all, so what you're suggesting
> > is fairly expensive, since the cost would be applied for every transaction,
> > even ones that don't use LISTEN.
>
> Well, in my experience all transactions use listen, or none of them do.
>
> You rarely have a situation where different clients access the same
> database and even more rarely different clients that use different methods
> to access it.
Really? Even pg_dump cares? Or your maintainence scripts
(VACUUM/ANALYZE)?
I'd have to disagree though. In most of the systems I've worked with
the database is in the center of the system. It'd be access by CGI
scripts, cron job, batch jobs started by a person, load triggered by
emails, etc. These may all use very different methods of accessing the
database. Even if an application used LISTEN/NOTIFY, I can't imagine
any bulk load/store being interested.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
