On 11 April 2017 at 09:05, Magnus Hagander <mag...@hagander.net> wrote: > On Tue, Apr 11, 2017 at 3:26 AM, Michael Paquier <michael.paqu...@gmail.com> > wrote: >> >> On Mon, Apr 10, 2017 at 5:47 PM, Magnus Hagander <mag...@hagander.net> >> wrote: >> > Based on that we seem to agree here, should we add this as an open item? >> > Clearly if we want to change this, we should do so before 10. >> >> This really is a new feature, so as the focus is to stabilize things I >> think that we should not make the code more complicated because... > > > The part I'm talking about is the potential adjustment of the patch that's > already committed. That's not a new feature, that's exactly the sort of > thing we'd want to adjust before we get to release. Because once released we > really can't change it.
I agree if we introduce target_session_attrs it would be better to have a complete feature in one release. It does seem quite strange to have target_session_attrs=read-write but not target_session_attrs=read-only And it would be even better to have these session attrs as well notify-on-promote - sent when standby is promoted notify-on-write - sent when an xid is assigned "notify-on-promotion" being my suggested name for the feature being discussed here. In terms of the feature as submitted, I wonder whether having a GUC parameter like this makes sense, but I think its ok for us to send a protocol message, maybe a NotificationResponse, but there isn't any material difference between those two protocol messages. Rather than the special case code in the patch, I imagine more generic code like this... if (sessionInterruptPending) ProcessSessionInterrupt(); I'm happy to work on the patch, if that's OK. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers