Re: Recent vendor SSL renegotiation patches break PostgreSQL

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

In response to

Browse pgsql-hackers by date

  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