From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, David Zuelke <dz(at)heroku(dot)com> |
Subject: | Re: Fix for OpenSSL error queue bug |
Date: | 2016-04-26 02:12:28 |
Message-ID: | CAM3SWZSwnTGm9tGgK7UOXMmA_3+o9dCqoYF7ZZ1qkktAL3RGZg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Apr 25, 2016 at 6:44 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
>> I'm not sure if project policy around backpatching (that commit
>> messages and so on should match exactly) has anything to say about the
>> case where backpatching follows several weeks after commit to the
>> master branch. In the absence of any clear direction on that, I've
>> created commits that look like what Peter E might have pushed in early
>> April, had he decided to do that backpatch leg-work up front.
>
> It seems to me that we definitely want to get this stuff backpatched
> at the end. So +1 for this move.
Right. This issue has a long history of causing users significant
(though often intermittent) problems. As an example, consider this
problem report from a co-worker of mine that dates back to 2012:
https://bitbucket.org/ged/ruby-pg/issues/142/async_exec-over-ssl-connection-can-fail-on
There are numerous problem reports like this that are easily found
using Google. I think that there are probably a variety of unpleasant
interactions and symptoms. Crashes are one rarer symptom, seen in
certain scenarios only (crashes are not described in the link above).
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2016-04-26 02:24:05 | Re: how to measure pglogical replication lag |
Previous Message | Kyotaro HORIGUCHI | 2016-04-26 02:02:25 | Re: Support for N synchronous standby servers - take 2 |