Joachim Wieland <j...@mcknight.de> writes: > One question regarding #2: Is a client application able to tell > whether or not it has received all notifications from one batch? i.e. > does PQnotifies() return NULL only when the backend has sent over the > complete batch of notifications or could it also return NULL while a > batch is still being transmitted but the client-side buffer just > happens to be empty?
That's true, it's difficult for the client to be sure whether it's gotten all the available notifications. It could wait a little bit to see if more arrive but there's no sure upper bound for how long is enough. If you really need it, though, you could send a query (perhaps just a dummy empty-string query). In the old implementation, the query response would mark a point of guaranteed consistency in the notification responses: you would have gotten all or none of the messages from any particular sending transaction, and furthermore there could not be any missing messages from transactions that committed before one that you saw a message from. The latter property is probably the bigger issue really, and I'm afraid that even with contiguous queuing we'd not be able to guarantee it, so maybe we have a problem even with my proposed #2 fix. Maybe we should go back to the existing scheme whereby a writer takes a lock it holds through commit, so that entries in the queue are guaranteed to be in commit order. It wouldn't lock out readers just other writers. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers