Joachim Wieland <j...@mcknight.de> writes:
> However, if for some reason we cannot write to the slru files in the
> pg_notify/
> directory we might want to roll back the current transaction but with the
> proposed patch we cannot because we have already committed...
I think this is a deal-breaker, and arguing about how the pg_notify
directory ought to be writable is not even slightly acceptable --- out
of disk space is an obvious risk. The existing implementation
guarantees that notifications obey ACID: if you commit, they are sent,
and if you don't, they aren't. You can't just put in something that
works most of the time instead.
> One possible solution would be to write to the queue before committing
> and adding the TransactionID. Then other backends can check if our
> TransactionID has successfully committed or not. Not sure if this is
> worth the overhead however...
That sounds reasonable, and it's certainly no more overhead than the
tuple visibility checks that happen in the current implementation.
> 2. The payload parameter is optional. A notifying client can either call
> "NOTIFY foo;" or "NOTIFY foo 'payload';". The length of the payload is
> currently limited to 128 characters... Not sure if we should allow longer
> payload strings...
Might be a good idea to make the max the same as the max length for
prepared transaction GUIDs? Not sure anyone would be shipping those
around, but it's a pre-existing limit of about the same size.
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
