Andras Kadinger wrote:
> On Mon, 11 Apr 2005, Andras Kadinger wrote:
>
>>I am unclear as to how to handle possible protocol errors (e.g. when what
>>we end up reading from the connection is not an 'A'sync Notify).
>>Theoretically, in a working connection this should not happen though.
>
> Yes, it could: reading the PostgreSQL protocol documentation, it says
> "frontends should always be prepared to accept and display NoticeResponse
> messages, even when the connection is nominally idle".
>
> So I now added code to process Error 'N'otifications as well.
You also need to handle errors ('E'). Try shutting down a postmaster (-m
fast) while idle connections are around -- they'll get spontaneous FATAL
errors.
> + try {
> + executor.processNotifies();
> + } catch (SQLException e) {};
Don't eat the exceptions, let them propagate.
(ugh, getNotifications() does not throw SQLException. We should probably
change that..)
> + while (protoConnection.getTransactionState() == ProtocolConnection.TRANSACTION_IDLE &&
pgStream.getSocket().getInputStream().available()>0){
Can you move that reference following into a method on PGStream?
(hasMessagePending() or something)
The test on transaction state is a bit misleading since the connection's
transaction state should never change inside the loop. Perhaps making
that a separate test would be clearer.
I'm not sure if available() is guaranteed to work on a socket stream
everywhere (it works fine here, though), but I suppose that at worst you
get the existing behaviour where you need to send a query.
Otherwise, seems fine!
-O