contrib/sslinfo needs a fix too to make hamerkop happy.
Re-ordering the #include's is a bit problematic here because
libpq/libpq-be.h needs to include . Instead,
let's #undef the unwanted macro after all the #includes.
This is definitely uglier than the other way, but it should
work despite possi
Silence uninitialized-variable warning.
Quite a few buildfarm animals are warning about this, and lapwing
is actually failing (because -Werror). It's a false positive AFAICS,
so no need to do more than zero the variable to start with.
Discussion: https://postgr.es/m/yyxjnuxgw9dzk...@paquier.xyz
Michael Paquier writes:
> On Fri, Nov 05, 2021 at 04:55:52PM +, Robert Haas wrote:
>> Change ThisTimeLineID from a global variable to a local variable.
> lapwing looks unhappy after this commit:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lapwing&dt=2021-11-05%2022%3A40%3A10
> x
Release notes for 14.1, 13.5, 12.9, 11.14, 10.19, 9.6.24.
Branch
--
REL_13_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/5d73415d20086406f083eb0929626036e10797a1
Modified Files
--
doc/src/sgml/release-13.sgml | 1802 ++
1 f
Release notes for 14.1, 13.5, 12.9, 11.14, 10.19, 9.6.24.
Branch
--
REL_12_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/0bc98fb741f40e3f24a636afa562b8540a9f6d50
Modified Files
--
doc/src/sgml/release-12.sgml | 1523 ++
1 f
Release notes for 14.1, 13.5, 12.9, 11.14, 10.19, 9.6.24.
Branch
--
REL9_6_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/492a1a94bf59f187de2a09fe3ebfedae2bc6cff1
Modified Files
--
doc/src/sgml/release-9.6.sgml | 1014 +
1 f
Release notes for 14.1, 13.5, 12.9, 11.14, 10.19, 9.6.24.
Branch
--
REL_10_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/fdbad0043345c3a7eddda7698b52fcc7ba121500
Modified Files
--
doc/src/sgml/release-10.sgml | 1252 ++
1 f
Release notes for 14.1, 13.5, 12.9, 11.14, 10.19, 9.6.24.
Branch
--
REL_14_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/bb003edbb7b1e8fb2ce488e2f047e5e1982b95fd
Modified Files
--
doc/src/sgml/release-14.sgml | 1012 +-
1 f
Release notes for 14.1, 13.5, 12.9, 11.14, 10.19, 9.6.24.
Branch
--
REL_11_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/5fb3ee544c5ad3bb5a6f0f8fba258300995f4822
Modified Files
--
doc/src/sgml/release-11.sgml | 1419 ++
1 f
Remove tests added by bd807be6935929bdefe74d1258ca08048f0aafa3.
The buildfarm is unhappy. It's not obvious why it doesn't like
these tests, but let's remove them until we figure it out.
Discussion: http://postgr.es/m/462618.1636171...@sss.pgh.pa.us
Branch
--
master
Details
---
https://g
On Sun, Nov 7, 2021 at 12:23 PM Tom Lane wrote:
> Yeah. I've seen some older compilers complain about that code before,
> but now there are over a dozen buildfarm members warning about it.
> It's clearly a false positive, since checkPointLoc does get set in
> the read_backup_label()-failure-retur
Robert Haas writes:
> On Sun, Nov 7, 2021 at 12:23 PM Tom Lane wrote:
>> Yeah. I've seen some older compilers complain about that code before,
>> but now there are over a dozen buildfarm members warning about it.
>> It's clearly a false positive, since checkPointLoc does get set in
>> the read_b
On Sun, Nov 7, 2021 at 4:39 PM Tom Lane wrote:
> Based on this data point, we can speculate that the number of such
> variables matters, too.
Yeah, apparently. Well, at least I don't feel bad about not guessing
that that would happen. That's pretty magical.
--
Robert Haas
EDB: http://www.enterp
Fix gist_bool_ops to use gbtreekey2
Commit 57e3c5160b added a new GiST bool opclass, but it used gbtreekey4
to store the data, which left two bytes undefined, as reported by skink,
our valgrind animal. There was a bit more confusion, because the opclass
also used gbtreekey8 in the definition.
Fix
Fix incorrect hash equality operator bug in Memoize
In v14, because we don't have a field in RestrictInfo to cache both the
left and right type's hash equality operator, we just restrict the scope
of Memoize to only when the left and right types of a RestrictInfo are the
same.
In master we add an
Fix incorrect hash equality operator bug in Memoize
In v14, because we don't have a field in RestrictInfo to cache both the
left and right type's hash equality operator, we just restrict the scope
of Memoize to only when the left and right types of a RestrictInfo are the
same.
In master we add an
16 matches
Mail list logo
