Define LDAP_NO_ATTRS if necessary.
Commit 83aaac41c66959a3ebaec7daadc4885b5f98f561 introduced the use of
LDAP_NO_ATTRS to avoid requesting a dummy attribute when doing search+bind
LDAP authentication. It turns out that not all LDAP implementations define
that macro, but its value is fixed by the
Improve error message in WAL sender
The previous error message when attempting to run a general SQL command
in a physical replication WAL sender was a bit sloppy.
Reported-by: Fujii Masao
Branch
--
REL_10_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/2b0ded5060cc2e0b7d6c7
Improve error message in WAL sender
The previous error message when attempting to run a general SQL command
in a physical replication WAL sender was a bit sloppy.
Reported-by: Fujii Masao
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/61975d6c2cf5bbcf40a2e3160914
docs: improve pg_upgrade standby instructions
This makes it clear that pg_upgrade standby upgrade instructions should
only be used in link mode, adds examples, and explains how rsync works
with links.
Reported-by: Andreas Joseph Krogh
Discussion:
https://postgr.es/m/VisenaEmail.6c.c0e592c5af4e
docs: improve pg_upgrade standby instructions
This makes it clear that pg_upgrade standby upgrade instructions should
only be used in link mode, adds examples, and explains how rsync works
with links.
Reported-by: Andreas Joseph Krogh
Discussion:
https://postgr.es/m/VisenaEmail.6c.c0e592c5af4e
docs: improve pg_upgrade standby instructions
This makes it clear that pg_upgrade standby upgrade instructions should
only be used in link mode, adds examples, and explains how rsync works
with links.
Reported-by: Andreas Joseph Krogh
Discussion:
https://postgr.es/m/VisenaEmail.6c.c0e592c5af4e
docs: improve pg_upgrade standby instructions
This makes it clear that pg_upgrade standby upgrade instructions should
only be used in link mode, adds examples, and explains how rsync works
with links.
Reported-by: Andreas Joseph Krogh
Discussion:
https://postgr.es/m/VisenaEmail.6c.c0e592c5af4e
docs: adjust "link mode" mention in pg_upgrade streaming steps
Backpatch-through: 9.5
Branch
--
REL9_5_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/e1795efcbecdcb53d3910cd46a067a1e66ab0938
Modified Files
--
doc/src/sgml/ref/pgupgrade.sgml | 14 +++---
docs: adjust "link mode" mention in pg_upgrade streaming steps
Backpatch-through: 9.5
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/82e367ddbfdf798ea8a30da15db3984017277342
Modified Files
--
doc/src/sgml/ref/pgupgrade.sgml | 14 +++---
1 file
docs: adjust "link mode" mention in pg_upgrade streaming steps
Backpatch-through: 9.5
Branch
--
REL_10_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/6dffdcfeef934eb21b8a767d8be11ec33ccb56ed
Modified Files
--
doc/src/sgml/ref/pgupgrade.sgml | 14 +++---
docs: adjust "link mode" mention in pg_upgrade streaming steps
Backpatch-through: 9.5
Branch
--
REL9_6_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/e5c8d43abde8cbb4b7fbbb5a215e497f11bf6fe6
Modified Files
--
doc/src/sgml/ref/pgupgrade.sgml | 14 +++---
doc: Remove incorrect SCRAM protocol documentation
The documentation claimed that one should send
"pg_same_as_startup_message" as the user name in the SCRAM messages, but
this did not match the actual implementation, so remove it.
Branch
--
master
Details
---
https://git.postgresql.org/p
doc: Remove incorrect SCRAM protocol documentation
The documentation claimed that one should send
"pg_same_as_startup_message" as the user name in the SCRAM messages, but
this did not match the actual implementation, so remove it.
Branch
--
REL_10_STABLE
Details
---
https://git.postgresq
Distinguish selectivity of < from <= and > from >=.
Historically, the selectivity functions have simply not distinguished
< from <=, or > from >=, arguing that the fraction of the population that
satisfies the "=" aspect can be considered to be vanishingly small, if the
comparison value isn't any
Update contrib/seg for new scalarlesel/scalargesel selectivity functions.
I somehow missed this module in commit 7d08ce286.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/44ba2920644903d7dfceda810e5facdbcbab58a8
Modified Files
--
contrib/seg/Makefile
Adjust unstable regression test case.
Test queries added by commit 69835bc89 are giving unexpected results
on some smaller buildfarm critters. I think probably the seqscan
logic is kicking in to cause the scans to not start at the beginning
of the table. Add ORDER BY to make them be indexscans i
Make setlocale in ECPG test cases thread aware on Windows.
Fix threaded test cases on Windows not to crash in setlocale() which can be
global or local to a thread on Windows.
Author: Christian Ullrich
Branch
--
REL9_6_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/839ee1811
Changed order of statements and added an additiona MSVC safeguard to make ecpg
thread test cases work on Windows.
Branch
--
REL_10_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/eaf7001eb7e3eecc7e30c31956860f54f1def55f
Modified Files
--
src/interfaces/ecpg/test/e
Changed order of statements and added an additiona MSVC safeguard to make ecpg
thread test cases work on Windows.
Branch
--
REL9_6_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/407e660781b8c3866fe97fd5e326a078f549db61
Modified Files
--
src/interfaces/ecpg/test/e
Make setlocale in ECPG test cases thread aware on Windows.
Fix threaded test cases on Windows not to crash in setlocale() which can be
global or local to a thread on Windows.
Author: Christian Ullrich
Branch
--
REL_10_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/38d7cb67f
> Now that some buildfarm owners have enabled ecpg tests on their Windows
> machines, it'd be a good idea to back-patch this. I see that woodlouse
> is consistently succeeding on the master branch, but v10 not so much,
> and this commit is the only plausible reason why.
Done for 9.6 and 10. There
Fix ordering in pg_dump of GRANTs
The order in which GRANTs are output is important as GRANTs which have
been GRANT'd by individuals via WITH GRANT OPTION GRANTs have to come
after the GRANT which included the WITH GRANT OPTION. This happens
naturally in the backend during normal operation as we
Fix ordering in pg_dump of GRANTs
The order in which GRANTs are output is important as GRANTs which have
been GRANT'd by individuals via WITH GRANT OPTION GRANTs have to come
after the GRANT which included the WITH GRANT OPTION. This happens
naturally in the backend during normal operation as we
Fix ordering in pg_dump of GRANTs
The order in which GRANTs are output is important as GRANTs which have
been GRANT'd by individuals via WITH GRANT OPTION GRANTs have to come
after the GRANT which included the WITH GRANT OPTION. This happens
naturally in the backend during normal operation as we
24 matches
Mail list logo
