Re: extended query protcol violation?

Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> writes:
> While looking into an issue of Pgpool-II, I found an interesting
> behavior of a PostgreSQL client.
> Below is a trace from pgproto to reproduce the client's behavior.

> It starts a transacton.

> FE=> Parse(stmt="S1", query="BEGIN")
> FE=> Bind(stmt="S1", portal="")
> FE=> Execute(portal="")
> :
> Commit the transaction

> FE=> Parse(stmt="S1", query="COMMIT")
> FE=> Bind(stmt="S1", portal="")
> FE=> Execute(portal="")

Hm, I'd expect the second Parse to generate a "prepared statement already
exists" error due to reuse of the "S1" statement name. Is there more
in this trace than you're showing us?

> Send sync message.

> FE=> Sync

> Now the interesting part. After sync it a close message is sent.

> FE=> Close(stmt="S1")

That part seems fine to me.

> I thought all extended query protocol messages are finished by a sync
> message. But in the example above, a close message is issued, followed
> by a simple query without a sync message. Should PostgreSQL regard
> this as a protocol violation?

No, although it looks like buggy behavior on the client's part, because
it's unlikely to work well if there's any error in the Close operation.
The protocol definition is that an error causes the backend to discard
messages until Sync, so that if that Close fails, the following simple
Query will just be ignored. Most likely, that's not the behavior the
client wanted ... but it's not a protocol violation, IMO.

regards, tom lane