[pgpool-general: 7972] Re: Hang with Skunk because Flush not honoured

[Tatsuo Ishii]

>> After all, we need to find a compromise. For me it seems Skunk is
>> minority.
> 
> Certainly. But no matter how rare or strange a client is, it should never get stuck forever, especially when it works perfectly well when connected directly to a database server without Pgpool-II in the middle.
> 
>> BTW, I don't understand why Skunk issuses flush after every message to
>> obtain response. Simple query protocol is already there for that
>> purpose.
> 
> If I understand correctly, the simple query protocol has no prepared statements/bind.

You can use SQL level PREPARE/EXECUTE.

> But yes, I agree Skunk is not doing it efficiently. From what I have seen, this has to do with implementation restrictions within Skunk itself and might be improved in the future. Still, even if it is inefficient, it is not incorrect.

It seems "flush tracking" is the only way to manage both correctness
and efficiency. Rather than playing with some quick hacks, I will try
to implement "flush tracking". If it's not too invasive, we may be
able to back patch to existing stable branches.

> So as a last resort, intermediate buffers like this tend to have a timeout after which the data is sent out even if no explicit flush has been requested: that way, there may be an inefficient delay, but at least the connection can make progress. But, of course, it still is not a desirable outcome.

I wonder why you don't use client_idle_limit instead. It's already
there.

>> Suppose Pgpool-II sends SET command to all PostgreSQL
>> servers. Then Pgpool-II must not flush the downstream buffer until all
>> backends reply with Command Complete or Error response.
> 
> Sorry if this is a dumb question (I must admit I am new to multiple-server scenarios), but why? If some of the servers have already sent some earlier response data before the SET, what is wrong with flushing it downstream? If a client had connected to the database directly and sent the same SET, it would have already received that response by now.

Earlier responses are not problems here. In general when Pgpool-II
sends a command to multiple PostgreSQL, the response from those
servers may not be identical. For example most of PostgreSQL servers
reply with Command Complete but one of them returns an error. In this
case Pgpool-II returns an error to frontend with "kind mismatch" error
so that clients can recognize there's something wrong with PostgreSQL
servers.

Also in the simple query protocol, frontend should not send next
command until PostgreSQL returns "Ready for query". So Pgpool-II needs
wait for all PostgreSQL returning the message.

Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp