Thread: Re: [PATCHES] Implementing RESET CONNECTION ...
(cc'ing -hackers) Karel Zak wrote: > I think command status is common and nice feedback for client. I think > it's more simple change something in JDBC than change protocol that is > shared between more tools. There is a bit of a queue of changes that would be nice to have but require a protocol version change. If we're going to change the protocol for any of those we might as well handle RESET CONNECTION cleanly too. > We need some common way how detect on client what's happen on server -- > a way that doesn't mean change protocol always when we add some > feature/command to backend. The command status is possible use for this. Command status only works if commands are directly executed. If you can execute the command indirectly, e.g. via a PL, then you'll miss the notification. Making RESET a top-level-only command isn't unreasonable, but using command status won't work as a general approach for notifying clients. We have a mechanism for GUC changes that uses a separate message (ParameterStatus). Perhaps that should be generalized to report different sorts of connection-related changes. -O
What did we decide on RESET CONNECTION. Do we want an SQL command or something only the protocol can do? --------------------------------------------------------------------------- Oliver Jowett wrote: > (cc'ing -hackers) > > Karel Zak wrote: > > > I think command status is common and nice feedback for client. I think > > it's more simple change something in JDBC than change protocol that is > > shared between more tools. > > There is a bit of a queue of changes that would be nice to have but > require a protocol version change. If we're going to change the protocol > for any of those we might as well handle RESET CONNECTION cleanly too. > > > We need some common way how detect on client what's happen on server -- > > a way that doesn't mean change protocol always when we add some > > feature/command to backend. The command status is possible use for this. > > Command status only works if commands are directly executed. If you can > execute the command indirectly, e.g. via a PL, then you'll miss the > notification. Making RESET a top-level-only command isn't unreasonable, > but using command status won't work as a general approach for notifying > clients. > > We have a mechanism for GUC changes that uses a separate message > (ParameterStatus). Perhaps that should be generalized to report > different sorts of connection-related changes. > > -O > > ---------------------------(end of broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
What would be absolutely ideal is a reset connection command, plus some way of knowing via the protocol if it's needed or not. Chris Bruce Momjian wrote: > What did we decide on RESET CONNECTION. Do we want an SQL command or > something only the protocol can do? > > --------------------------------------------------------------------------- > > Oliver Jowett wrote: > >>(cc'ing -hackers) >> >>Karel Zak wrote: >> >> >>>I think command status is common and nice feedback for client. I think >>>it's more simple change something in JDBC than change protocol that is >>>shared between more tools. >> >>There is a bit of a queue of changes that would be nice to have but >>require a protocol version change. If we're going to change the protocol >>for any of those we might as well handle RESET CONNECTION cleanly too. >> >> >>>We need some common way how detect on client what's happen on server -- >>>a way that doesn't mean change protocol always when we add some >>>feature/command to backend. The command status is possible use for this. >> >>Command status only works if commands are directly executed. If you can >>execute the command indirectly, e.g. via a PL, then you'll miss the >>notification. Making RESET a top-level-only command isn't unreasonable, >>but using command status won't work as a general approach for notifying >>clients. >> >>We have a mechanism for GUC changes that uses a separate message >>(ParameterStatus). Perhaps that should be generalized to report >>different sorts of connection-related changes. >> >>-O >> >>---------------------------(end of broadcast)--------------------------- >>TIP 7: don't forget to increase your free space map settings >> > >
Christopher Kings-Lynne wrote: > What would be absolutely ideal is a reset connection command, plus some > way of knowing via the protocol if it's needed or not. And a way of notifying the client that a reset has happened. -O