Report success when Windows kill() emulation signals an exiting process.
This is consistent with the POSIX verdict that kill() shall not report
ESRCH for a zombie process. Back-patch to 9.0 (all supported versions).
Test code from commit d7cdf6ee36adeac9233678fb8f2a112e6678a770 depends
on it, and
Report success when Windows kill() emulation signals an exiting process.
This is consistent with the POSIX verdict that kill() shall not report
ESRCH for a zombie process. Back-patch to 9.0 (all supported versions).
Test code from commit d7cdf6ee36adeac9233678fb8f2a112e6678a770 depends
on it, and
MSVC: Substitute $(top_builddir) in REGRESS_OPTS.
Commit d7cdf6ee36adeac9233678fb8f2a112e6678a770 introduced a usage
thereof. Back-patch to 9.0, like that commit.
Branch
--
REL9_2_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/98d3a7b97e5221b6ca43cb4de07000675f207b00
Modifi
Report success when Windows kill() emulation signals an exiting process.
This is consistent with the POSIX verdict that kill() shall not report
ESRCH for a zombie process. Back-patch to 9.0 (all supported versions).
Test code from commit d7cdf6ee36adeac9233678fb8f2a112e6678a770 depends
on it, and
Report success when Windows kill() emulation signals an exiting process.
This is consistent with the POSIX verdict that kill() shall not report
ESRCH for a zombie process. Back-patch to 9.0 (all supported versions).
Test code from commit d7cdf6ee36adeac9233678fb8f2a112e6678a770 depends
on it, and
MSVC: Substitute $(top_builddir) in REGRESS_OPTS.
Commit d7cdf6ee36adeac9233678fb8f2a112e6678a770 introduced a usage
thereof. Back-patch to 9.0, like that commit.
Branch
--
REL9_1_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/48aa0032c454a73ca70f192c122508eb4ee38e28
Modifi
Report success when Windows kill() emulation signals an exiting process.
This is consistent with the POSIX verdict that kill() shall not report
ESRCH for a zombie process. Back-patch to 9.0 (all supported versions).
Test code from commit d7cdf6ee36adeac9233678fb8f2a112e6678a770 depends
on it, and
Report success when Windows kill() emulation signals an exiting process.
This is consistent with the POSIX verdict that kill() shall not report
ESRCH for a zombie process. Back-patch to 9.0 (all supported versions).
Test code from commit d7cdf6ee36adeac9233678fb8f2a112e6678a770 depends
on it, and
MSVC: Substitute $(top_builddir) in REGRESS_OPTS.
Commit d7cdf6ee36adeac9233678fb8f2a112e6678a770 introduced a usage
thereof. Back-patch to 9.0, like that commit.
Branch
--
REL9_4_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/44acd17605032b7d32575b66f4c00ee0e2a7ab5f
Modifi
MSVC: Substitute $(top_builddir) in REGRESS_OPTS.
Commit d7cdf6ee36adeac9233678fb8f2a112e6678a770 introduced a usage
thereof. Back-patch to 9.0, like that commit.
Branch
--
REL9_3_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/f12976ab8393463b2b0815e7412dba26702dd0a3
Modifi
MSVC: Substitute $(top_builddir) in REGRESS_OPTS.
Commit d7cdf6ee36adeac9233678fb8f2a112e6678a770 introduced a usage
thereof. Back-patch to 9.0, like that commit.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/31f9bbf05928ed8f20b1c371df8098d8c7dddb37
Modified File
MSVC: Substitute $(top_builddir) in REGRESS_OPTS.
Commit d7cdf6ee36adeac9233678fb8f2a112e6678a770 introduced a usage
thereof. Back-patch to 9.0, like that commit.
Branch
--
REL9_0_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/d5e70c73bfd050a21e80fc4c40823a7b75cc4f3b
Modifi
Re-enable error for "SELECT ... OFFSET -1".
The executor has thrown errors for negative OFFSET values since 8.4 (see
commit bfce56eea45b1369b7bb2150a150d1ac109f5073), but in a moment of brain
fade I taught the planner that OFFSET with a constant negative value was a
no-op (commit 1a1832eb085e5bca1
Re-enable error for "SELECT ... OFFSET -1".
The executor has thrown errors for negative OFFSET values since 8.4 (see
commit bfce56eea45b1369b7bb2150a150d1ac109f5073), but in a moment of brain
fade I taught the planner that OFFSET with a constant negative value was a
no-op (commit 1a1832eb085e5bca1
Re-enable error for "SELECT ... OFFSET -1".
The executor has thrown errors for negative OFFSET values since 8.4 (see
commit bfce56eea45b1369b7bb2150a150d1ac109f5073), but in a moment of brain
fade I taught the planner that OFFSET with a constant negative value was a
no-op (commit 1a1832eb085e5bca1
Check block number against the correct fork in get_raw_page().
get_raw_page tried to validate the supplied block number against
RelationGetNumberOfBlocks(), which of course is only right when
accessing the main fork. In most cases, the main fork is longer
than the others, so that the check was to
Check block number against the correct fork in get_raw_page().
get_raw_page tried to validate the supplied block number against
RelationGetNumberOfBlocks(), which of course is only right when
accessing the main fork. In most cases, the main fork is longer
than the others, so that the check was to
Check block number against the correct fork in get_raw_page().
get_raw_page tried to validate the supplied block number against
RelationGetNumberOfBlocks(), which of course is only right when
accessing the main fork. In most cases, the main fork is longer
than the others, so that the check was to
Check block number against the correct fork in get_raw_page().
get_raw_page tried to validate the supplied block number against
RelationGetNumberOfBlocks(), which of course is only right when
accessing the main fork. In most cases, the main fork is longer
than the others, so that the check was to
Check block number against the correct fork in get_raw_page().
get_raw_page tried to validate the supplied block number against
RelationGetNumberOfBlocks(), which of course is only right when
accessing the main fork. In most cases, the main fork is longer
than the others, so that the check was to
Check block number against the correct fork in get_raw_page().
get_raw_page tried to validate the supplied block number against
RelationGetNumberOfBlocks(), which of course is only right when
accessing the main fork. In most cases, the main fork is longer
than the others, so that the check was to
Allow empty string object keys in json_object().
This makes the behaviour consistent with the json parser, other
json-generating functions, and the JSON standards.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/4ebe3519e1c12fe02f734aa00f824833181840c7
Modified File
Allow empty string object keys in json_object().
This makes the behaviour consistent with the json parser, other
json-generating functions, and the JSON standards.
Branch
--
REL9_4_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/a61f63df7d19006b36adf7ee402999aa5243097d
Modifi
Diagnose incompatible OpenLDAP versions during build and test.
With OpenLDAP versions 2.4.24 through 2.4.31, inclusive, PostgreSQL
backends can crash at exit. Raise a warning during "configure" based on
the compile-time OpenLDAP version number, and test the crash scenario in
the dblink test suite
Diagnose incompatible OpenLDAP versions during build and test.
With OpenLDAP versions 2.4.24 through 2.4.31, inclusive, PostgreSQL
backends can crash at exit. Raise a warning during "configure" based on
the compile-time OpenLDAP version number, and test the crash scenario in
the dblink test suite
Diagnose incompatible OpenLDAP versions during build and test.
With OpenLDAP versions 2.4.24 through 2.4.31, inclusive, PostgreSQL
backends can crash at exit. Raise a warning during "configure" based on
the compile-time OpenLDAP version number, and test the crash scenario in
the dblink test suite
Diagnose incompatible OpenLDAP versions during build and test.
With OpenLDAP versions 2.4.24 through 2.4.31, inclusive, PostgreSQL
backends can crash at exit. Raise a warning during "configure" based on
the compile-time OpenLDAP version number, and test the crash scenario in
the dblink test suite
Diagnose incompatible OpenLDAP versions during build and test.
With OpenLDAP versions 2.4.24 through 2.4.31, inclusive, PostgreSQL
backends can crash at exit. Raise a warning during "configure" based on
the compile-time OpenLDAP version number, and test the crash scenario in
the dblink test suite
Diagnose incompatible OpenLDAP versions during build and test.
With OpenLDAP versions 2.4.24 through 2.4.31, inclusive, PostgreSQL
backends can crash at exit. Raise a warning during "configure" based on
the compile-time OpenLDAP version number, and test the crash scenario in
the dblink test suite
29 matches
Mail list logo
