From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Michael Ledford <mledford(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Recent vendor SSL renegotiation patches break PostgreSQL |
Date: | 2010-02-04 06:42:16 |
Message-ID: | 4B6A6C48.9080908@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>> FWIW I think there's another problem with streaming replication here,
>> which is that most data flows from client to server, so it would take
>> quite some time for the threshold to be reached. Note that there's no
>> size check in the libpq frontend code. Normally this is not an issue
>> because the bulk of data is expected to flow in the other direction.
>
> Huh? I thought the slaves connect to the master, rather than the other
> way round?
Correct, slave connects to the master.
Alvaro is pointing out that most data flows from client to server, like
in COPY FROM. But the server counts both in- and out-going data against
the renegotiation limit, so the server will initiate renegotiation just
fine in that case too.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2010-02-04 07:28:03 | Re: [BUGS] BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION |
Previous Message | Joe Conway | 2010-02-04 04:26:52 | Re: BUG #5304: psql using conninfo fails in connecting to the server |