Peter Geoghegan writes:
> On Fri, May 6, 2016 at 9:12 PM, Peter Eisentraut
> wrote:
>> All committed.
> Thanks!
> This should no longer be referenced in the 9.6 release notes. It
> should just appear in the next batch of point releases. Tom has an
> sgml comment in the draft 9.6 release notes t
On Fri, May 6, 2016 at 9:12 PM, Peter Eisentraut
wrote:
> All committed.
Thanks!
This should no longer be referenced in the 9.6 release notes. It
should just appear in the next batch of point releases. Tom has an
sgml comment in the draft 9.6 release notes to that effect.
--
Peter Geoghegan
On 4/25/16 8:37 PM, Peter Geoghegan wrote:
Attached is a series of patches for each supported release branch. As
discussed, I would like to target every released version of Postgres
with this bugfix. This is causing users real pain at the moment.
All committed.
--
Peter Eisentraut
Peter Eisentraut writes:
> On 04/27/2016 11:04 PM, Tom Lane wrote:
>> Actually, git_changelog can merge identically-messaged commits despite
>> intervening commits. It's set up to not merge commits more than 24 hours
>> apart, though. We could loosen that requirement but I'm afraid it would
>> m
On 04/27/2016 11:04 PM, Tom Lane wrote:
>> There is no value in providing exact message matches when the backpatch
>> occurs even after one other commit in the master branch.
>
> Actually, git_changelog can merge identically-messaged commits despite
> intervening commits. It's set up to not merge
Alvaro Herrera writes:
> Peter Geoghegan 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.
> There is no value i
Peter Geoghegan 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.
There is no value in providing exact message match
On Mon, Apr 25, 2016 at 6:44 PM, Michael Paquier
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
On Tue, Apr 26, 2016 at 9:37 AM, Peter Geoghegan wrote:
> Only the 9.5 backpatch was a simple, conflict-free "git cherry-pick".
> Most of the effort here involved producing a clean 9.4 patch. This was
> largely mechanical, if a little tricky. In release branches for
> releases that preceded 9.4, t
On Fri, Apr 8, 2016 at 11:43 AM, Peter Geoghegan wrote:
> I'll do so soon. I was waiting on Peter E to take me up on the offer.
Attached is a series of patches for each supported release branch. As
discussed, I would like to target every released version of Postgres
with this bugfix. This is caus
On Fri, Apr 8, 2016 at 11:42 AM, Tom Lane wrote:
> Seems like a reasonable thing to do, but somebody would have to do the
> legwork to produce back-branch patches.
I'll do so soon. I was waiting on Peter E to take me up on the offer.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list
Peter Geoghegan writes:
> On Fri, Apr 8, 2016 at 11:20 AM, Peter Geoghegan wrote:
>> That seems reasonable. I'm glad we finally got this done. Thanks.
> Are we going to backpatch this?
Seems like a reasonable thing to do, but somebody would have to do the
legwork to produce back-branch patches.
On Fri, Apr 8, 2016 at 11:20 AM, Peter Geoghegan wrote:
> That seems reasonable. I'm glad we finally got this done. Thanks.
Are we going to backpatch this?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://w
On Fri, Apr 8, 2016 at 11:12 AM, Peter Eisentraut wrote:
> I have committed this so that the comments are only in the first instance in
> each file. I think that should give enough information to someone who is
> curious about the details of the error handling.
>
> Also, I have adjusted this so t
On 04/07/2016 09:36 PM, Peter Geoghegan wrote:
On Thu, Apr 7, 2016 at 6:08 PM, Peter Eisentraut wrote:
I wish we could avoid the huge, repeated comment blocks. Perhaps we could
put them at the top of the files once?
I'm fine with that. Do you want to take care of that, or should I?
I have
On Fri, Apr 8, 2016 at 10:23 AM, Peter Eisentraut wrote:
> On 04/07/2016 03:47 AM, Michael Paquier wrote:
>>
>> I have looked at this patch. Do we need to worry as well about
>> SSL_shutdown in disconnection code path? I believe that we don't care
>> much if an error happens at this point but we s
On Thu, Apr 7, 2016 at 6:08 PM, Peter Eisentraut wrote:
> I wish we could avoid the huge, repeated comment blocks. Perhaps we could
> put them at the top of the files once?
I'm fine with that. Do you want to take care of that, or should I?
> Also, why do you write 0UL instead of just 0?
Becaus
On 04/07/2016 03:47 AM, Michael Paquier wrote:
I have looked at this patch. Do we need to worry as well about
SSL_shutdown in disconnection code path? I believe that we don't care
much if an error happens at this point but we surely should consume
any error generated because the SSL context is ke
On 03/14/2016 09:44 PM, Peter Geoghegan wrote:
On Mon, Mar 14, 2016 at 4:11 PM, Peter Geoghegan wrote:
Yes, with one small difference: I wouldn't be calling ERR_get_error()
in the common case where SSL_get_error() returns SSL_ERROR_NONE, on
the theory that skipping that case represents no risk.
On Sun, Mar 27, 2016 at 9:01 AM, Tom Lane wrote:
> Peter Geoghegan writes:
>> Will this make it into the next point release? I was rather hoping it would.
>
> I dunno. I certainly haven't reviewed it carefully enough to commit it.
> Perhaps Peter has, but time grows short ...
I have looked at t
Peter Geoghegan writes:
> Will this make it into the next point release? I was rather hoping it would.
I dunno. I certainly haven't reviewed it carefully enough to commit it.
Perhaps Peter has, but time grows short ...
regards, tom lane
--
Sent via pgsql-hackers maili
On Wed, Mar 23, 2016 at 9:18 PM, Tom Lane wrote:
> in the other order, so as not to assume that ERR_clear_error doesn't
> set errno. On the other hand, if it does, things are probably hopelessly
> broken anyway; so I'm not sure there is any case where this helps.
I'm fine with that.
Will this m
Peter Geoghegan writes:
> On Mon, Mar 14, 2016 at 6:44 PM, Peter Geoghegan wrote:
>> I can produce a back-patchable variant of this if you and Peter E.
>> think this approach is okay.
> Where are we on this?
I'm generally okay with the approach used in
http://www.postgresql.org/message-id/CAM3S
On Mon, Mar 14, 2016 at 6:44 PM, Peter Geoghegan wrote:
> I can produce a back-patchable variant of this if you and Peter E.
> think this approach is okay.
Where are we on this?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your s
On Mon, Mar 14, 2016 at 4:11 PM, Peter Geoghegan wrote:
> Yes, with one small difference: I wouldn't be calling ERR_get_error()
> in the common case where SSL_get_error() returns SSL_ERROR_NONE, on
> the theory that skipping that case represents no risk. I'm making a
> concession to Peter E's view
On Mon, Mar 14, 2016 at 4:05 PM, Tom Lane wrote:
> So your proposal is basically to do #2 in all branches? I won't fight it,
> if it doesn't bloat the code much. The overhead should surely be trivial
> compared to network communication costs, and I'm afraid you might be right
> about the risk of
Peter Geoghegan writes:
> On Mon, Mar 14, 2016 at 3:06 PM, Tom Lane wrote:
>> Agreed, we need to deal with this one way or the other. My proposal
>> is:
>>
>> 1. In HEAD, do it as Peter E. suggests, ie clear error queue before calls.
>>
>> 2. In back branches, clear error queue before *and* af
On Mon, Mar 14, 2016 at 3:06 PM, Tom Lane wrote:
> Agreed, we need to deal with this one way or the other. My proposal
> is:
>
> 1. In HEAD, do it as Peter E. suggests, ie clear error queue before calls.
>
> 2. In back branches, clear error queue before *and* after calls. This
> will waste a few
Peter Geoghegan writes:
> On Thu, Mar 10, 2016 at 8:16 PM, Peter Geoghegan wrote:
>> On Thu, Mar 10, 2016 at 7:22 PM, Peter Eisentraut wrote:
>>> Arguably, if everyone followed "my" approach, this should be very easy
>>> to fix everywhere.
>> I don't think that there is any clear indication tha
On Thu, Mar 10, 2016 at 8:16 PM, Peter Geoghegan wrote:
> On Thu, Mar 10, 2016 at 7:22 PM, Peter Eisentraut wrote:
>> Arguably, if everyone followed "my" approach, this should be very easy
>> to fix everywhere.
>
> I don't think that there is any clear indication that the OpenSSL
> people would s
On Thu, Mar 10, 2016 at 7:22 PM, Peter Eisentraut wrote:
> Arguably, if everyone followed "my" approach, this should be very easy
> to fix everywhere.
I don't think that there is any clear indication that the OpenSSL
people would share that view. Or my view. Or anything that's sensible
or practic
On 3/10/16 9:38 PM, Peter Geoghegan wrote:
> Looked at your proposed patch. Will respond to your original mail on the
> matter.
>
> On Thu, Mar 3, 2016 at 4:15 PM, Peter Eisentraut wrote:
>> I think clearing the error after a call is not necessary. The API
>> clearly requires that you should cl
Looked at your proposed patch. Will respond to your original mail on the matter.
On Thu, Mar 3, 2016 at 4:15 PM, Peter Eisentraut wrote:
> I think clearing the error after a call is not necessary. The API
> clearly requires that you should clear the error queue before a call, so
> clearing it af
On 3/10/16 6:10 PM, Peter Geoghegan wrote:
> On Thu, Mar 10, 2016 at 3:09 PM, Peter Geoghegan wrote:
>> Getting to it very soon. Just really busy right this moment.
>
> That said, I agree with Peter's remarks about doing this frontend and
> backend. So, while I'm not sure, I think we're in agreem
On Thu, Mar 10, 2016 at 3:09 PM, Peter Geoghegan wrote:
> Getting to it very soon. Just really busy right this moment.
That said, I agree with Peter's remarks about doing this frontend and
backend. So, while I'm not sure, I think we're in agreement on all
issues. I would have no problem with Pete
On Thu, Mar 10, 2016 at 2:50 PM, Robert Haas wrote:
> So what's the next step here? Peter G, are you planning to update the
> patch based on this review from Peter E? If not, Peter E, do you want
> to update the patch and commit? If neither, I'm going to mark this
> Returned with Feedback in th
On Thu, Mar 3, 2016 at 7:15 PM, Peter Eisentraut wrote:
> On 2/5/16 5:04 AM, Peter Geoghegan wrote:
>> As Heikki goes into on that thread, the appropriate action seems to be
>> to constantly reset the error queue, and to make sure that we
>> ourselves clear the queue consistently. (Note that we mi
On 2/5/16 5:04 AM, Peter Geoghegan wrote:
> As Heikki goes into on that thread, the appropriate action seems to be
> to constantly reset the error queue, and to make sure that we
> ourselves clear the queue consistently. (Note that we might not have
> consistently called ERR_get_error() in the even
Attached patch fixes an issue reported by William Felipe Welter about
a year ago [1]. It is loosely based on his original patch.
As Heikki goes into on that thread, the appropriate action seems to be
to constantly reset the error queue, and to make sure that we
ourselves clear the queue consistent
39 matches
Mail list logo
