doc: Release notes refinements
In particular, make some more precise links for some major items.
Branch
--
REL_12_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/3e3e32a1c160ec4e2342068515dfaf1dd04c6078
Modified Files
--
doc/src/sgml/ref/alter_table.sgml | 2 +-
doc: Add a link target
Forward-patched from PostgreSQL 12 release notes patch, for
consistency.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/92f1545d6ea9fbfe4b47108028ccaae351a1480c
Modified Files
--
doc/src/sgml/ref/alter_table.sgml | 2 +-
1 file ch
On Fri, Sep 27, 2019 at 6:58 PM Nikita Glukhov wrote:
> On Thu, Sep 26, 2019 at 2:57 AM Tom Lane
> wrote:
> > * More generally, it's completely unclear why some error conditions
> > are thrown as errors and others just result in returning *have_error.
> > In particular, it seems weird that some
Fix bogus order of error checks in new channel_binding code.
Coverity pointed out that it's pretty silly to check for a null pointer
after we've already dereferenced the pointer. To fix, just swap the
order of the two error checks. Oversight in commit d6e612f83.
Branch
--
master
Details
--
Jeff Davis writes:
> Add libpq parameter 'channel_binding'.
I found out the hard way that the added ssl tests fall over on a
platform that doesn't HAVE_X509_GET_SIGNATURE_NID:
# Running: psql -X -A -t -c SELECT $$connected with user=ssltestuser channel_bin
ding=require$$ -d dbname=trustdb sslmod
doc: Further clarify how recovery target parameters are applied
Recovery target parameters are all applied even in standby mode. The
previous documentation mostly wished they were not but this was never
the case.
Discussion:
https://www.postgresql.org/message-id/flat/e445616d-023e-a268-8aa1-67b
doc: Further clarify how recovery target parameters are applied
Recovery target parameters are all applied even in standby mode. The
previous documentation mostly wished they were not but this was never
the case.
Discussion:
https://www.postgresql.org/message-id/flat/e445616d-023e-a268-8aa1-67b
doc: Clarify release notes item
Reported-by: Justin Pryzby
Branch
--
REL_12_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/bba1baecb7b07dff33e4c5d32253db5f4c1a0507
Modified Files
--
doc/src/sgml/release-12.sgml | 3 ++-
1 file changed, 2 insertions(+), 1 deletio
Allow SSL TAP tests to run on Windows
Windows does not enforce key file permissions checks in libpq, and psql
can produce CRLF line endings on Windows.
Backpatch to Release 12 (CRLF) and Release 11 (permissions check)
Branch
--
REL_11_STABLE
Details
---
https://git.postgresql.org/pg/com
Allow SSL TAP tests to run on Windows
Windows does not enforce key file permissions checks in libpq, and psql
can produce CRLF line endings on Windows.
Backpatch to Release 12 (CRLF) and Release 11 (permissions check)
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff
Allow SSL TAP tests to run on Windows
Windows does not enforce key file permissions checks in libpq, and psql
can produce CRLF line endings on Windows.
Backpatch to Release 12 (CRLF) and Release 11 (permissions check)
Branch
--
REL_12_STABLE
Details
---
https://git.postgresql.org/pg/com
Translation updates
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 1d66650d203c89e3c69a18be3b4361f5a5393fcf
Branch
--
REL_12_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/3c70de2e12b9ef10925a57a350dffc01b95e067e
Modified Files
--
Update list of acknowledgments in release notes
Branch
--
REL_12_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/f0eadaa717eae75392d03479aea282bc752df276
Modified Files
--
doc/src/sgml/release-12.sgml | 3 +++
1 file changed, 3 insertions(+)
Fix determination when slot types for upper executor nodes are fixed.
For many queries the fact that the tuple descriptor from the lower
node was not taken into account when determining whether the type of a
slot is fixed, lead to tuple deforming for such upper nodes not to be
JIT accelerated.
I
Fix determination when slot types for upper executor nodes are fixed.
For many queries the fact that the tuple descriptor from the lower
node was not taken into account when determining whether the type of a
slot is fixed, lead to tuple deforming for such upper nodes not to be
JIT accelerated.
I
jit: Re-allow JIT compilation of execGrouping.c hashtable comparisons.
In the course of 5567d12ce03, 356687bd8 and 317ffdfeaac, I changed
BuildTupleHashTable[Ext]'s call to ExecBuildGroupingEqual to not pass
in the parent node, but NULL. Which in turn prevents the tuple
equality comparator from be
jit: Re-allow JIT compilation of execGrouping.c hashtable comparisons.
In the course of 5567d12ce03, 356687bd8 and 317ffdfeaac, I changed
BuildTupleHashTable[Ext]'s call to ExecBuildGroupingEqual to not pass
in the parent node, but NULL. Which in turn prevents the tuple
equality comparator from be
jit: Re-allow JIT compilation of execGrouping.c hashtable comparisons.
In the course of 5567d12ce03, 356687bd8 and 317ffdfeaac, I changed
BuildTupleHashTable[Ext]'s call to ExecBuildGroupingEqual to not pass
in the parent node, but NULL. Which in turn prevents the tuple
equality comparator from be
Andres Freund writes:
> jit: Re-allow JIT compilation of execGrouping.c hashtable comparisons.
I've got to say that I'm not very comfortable with changing stuff
when we've got less than 24 hours to the 12.0 GA wrap. At this
point you're not going to get complete buildfarm feedback (notably,
not
Hi,
On September 29, 2019 4:34:14 PM PDT, Tom Lane wrote:
>Andres Freund writes:
>> jit: Re-allow JIT compilation of execGrouping.c hashtable
>comparisons.
>
>I've got to say that I'm not very comfortable with changing stuff
>when we've got less than 24 hours to the 12.0 GA wrap.
I asked for
On Sun, Sep 29, 2019 at 12:51:31PM -0400, Tom Lane wrote:
> I found out the hard way that the added ssl tests fall over on a
> platform that doesn't HAVE_X509_GET_SIGNATURE_NID:
>
> [...]
>
> I don't think that it's acceptable for the test to fail on a platform
> that we're willing to compile on.
Andres Freund writes:
> On September 29, 2019 4:34:14 PM PDT, Tom Lane wrote:
>> I've got to say that I'm not very comfortable with changing stuff
>> when we've got less than 24 hours to the 12.0 GA wrap.
> I asked for input on hackers, nobody replied...
Yeah, that was sixty-plus hours ago. I
Make crash recovery ignore recovery target settings.
In v11 or before, recovery target settings could not take effect in
crash recovery because they are specified in recovery.conf and
crash recovery always starts without recovery.conf. But commit
2dedf4d9a8 integrated recovery.conf into postgresql
Make crash recovery ignore recovery target settings.
In v11 or before, recovery target settings could not take effect in
crash recovery because they are specified in recovery.conf and
crash recovery always starts without recovery.conf. But commit
2dedf4d9a8 integrated recovery.conf into postgresql
On Mon, Sep 30, 2019 at 08:47:33AM +0900, Michael Paquier wrote:
> Yes, it looks sensible to do that.
Tom, would you prefer taking take of both issues by yourself? Do you
mind if I handle both things? Or I could just commit my fix first,
then leave it to you for the second one. I don't mind doi
Hi Fujii-san,
On Mon, Sep 30, 2019 at 01:21:00AM +, Fujii Masao wrote:
> Make crash recovery ignore recovery target settings.
>
> In v11 or before, recovery target settings could not take effect in
> crash recovery because they are specified in recovery.conf and
> crash recovery always starts
On Mon, Sep 30, 2019 at 11:45 AM Michael Paquier wrote:
>
> Hi Fujii-san,
>
> On Mon, Sep 30, 2019 at 01:21:00AM +, Fujii Masao wrote:
> > Make crash recovery ignore recovery target settings.
> >
> > In v11 or before, recovery target settings could not take effect in
> > crash recovery because
Michael Paquier writes:
> On Mon, Sep 30, 2019 at 08:47:33AM +0900, Michael Paquier wrote:
>> Yes, it looks sensible to do that.
> Tom, would you prefer taking take of both issues by yourself? Do you
> mind if I handle both things? Or I could just commit my fix first,
> then leave it to you for
On Sun, Sep 29, 2019 at 11:39:12PM -0400, Tom Lane wrote:
> Feel free to deal with both.
Thanks. Will do so now then.
--
Michael
signature.asc
Description: PGP signature
Fix SSL test for libpq connection parameter channel_binding
When compiling Postgres with OpenSSL 1.0.1 or older versions, SCRAM's
channel binding cannot be supported as X509_get_signature_nid() is
needed, which causes a regression test with channel_binding='require' to
fail as the server cannot pu
On Mon, Sep 30, 2019 at 08:47:33AM +0900, Michael Paquier wrote:
> On Sun, Sep 29, 2019 at 12:51:31PM -0400, Tom Lane wrote:
>> Another point is that this error message is misleading --- or at least
>> would be misleading if the server had X509_get_signature_nid and the
>> client didn't.
>>
>> -#if
31 matches
Mail list logo
