Re: Listen / Notify rewrite

Joachim Wieland <joe(at)mcknight(dot)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