On Wed, May 19, 2010 at 9:58 PM, Boszormenyi Zoltan <zb@cybertec.at> wrote:
>> In the patch, PQputCopyData() checks the newly-introduced pg_conn field
>> "duplexCopy". Instead, how about checking the existing field "replication"?
>
> I didn't see there was such a new field. (looking...) I can see now,
> it was added in the middle of the structure. Ok, we can then use it
> to allow duplex COPY instead of my new field. I suppose it's non-NULL
> if replication is on, right? Then the extra call is not needed then.
Right. Usually the first byte of the pg_conn field seems to be also
checked as follows, but I'm not sure if that is valuable for this case.
if (conn->replication && conn->replication[0])
>> Or we can just allow PQputCopyData() to go even in COPY OUT state.
>
> I think this may not be too useful for SQL clients, but who knows? :-)
> Use cases, anyone?
It's for only replication.
>> Hmm... when min_sync_replication_clients = 2 and there are three
>> "synchronous" standbys, the master waits for only two standbys?
>>
>
> Yes. This is the idea, "partially synchronous replication".
> I heard anecdotes about replication solutions where say
> ensuring that (say) if at least 50% of the machines across the
> whole cluster report back synchronously then the transaction
> is considered replicated "good enough".
Oh, I got. I heard such a use case for the first time.
We seem to have many ideas about the knobs to control synchronization
levels, and would need to clarify which ones to be implemented for 9.1.
>> I'd like to just know the use case of min_sync_replication_clients.
>> Sorry, I've not understood yet how useful this option is.
>>
>
> I hope I answered it. :-)
Yep. Thanks!
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center