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@xxxxxxxxx> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
Attachment:
signature.asc
Description: Digital signature
