pgsql: Fix nested error handling in PG_FINALLY

Fix nested error handling in PG_FINALLY We need to pop the error stack before running the user-supplied PG_FINALLY code. Otherwise an error in the cleanup code would end up at the same sigsetjmp() invocation and result in an infinite error handling loop. Reviewed-by: Tom Lane Discussion: https

pgsql: Remove HAVE_LONG_LONG_INT

Remove HAVE_LONG_LONG_INT The presence of long long int is now implied in the requirement for C99 and the configure check for the same. We keep the define hard-coded in ecpg_config.h for backward compatibility with ecpg-using user code. Discussion: https://www.postgresql.org/message-id/flat/5cd

Re: pgsql: doc: Further clarify how recovery target parameters are applied

On 2019-11-06 10:49, Fujii Masao wrote: On Wed, Nov 6, 2019 at 4:29 PM Peter Eisentraut wrote: On 2019-11-06 05:48, Fujii Masao wrote: Patch attached. As I argued upthread, IMO it's better to remove the latter description from the doc and the patch does that. Also the patch adds "mainly" into

pgsql: Fix integer-overflow edge case detection in interval_mul and pgb

Fix integer-overflow edge case detection in interval_mul and pgbench. This patch adopts the overflow check logic introduced by commit cbdb8b4c0 into two more places. interval_mul() failed to notice if it computed a new microseconds value that was one more than INT64_MAX, and pgbench's double-to-i

pgsql: Fix integer-overflow edge case detection in interval_mul and pgb

Fix integer-overflow edge case detection in interval_mul and pgbench. This patch adopts the overflow check logic introduced by commit cbdb8b4c0 into two more places. interval_mul() failed to notice if it computed a new microseconds value that was one more than INT64_MAX, and pgbench's double-to-i

pgsql: Fix integer-overflow edge case detection in interval_mul and pgb

Fix integer-overflow edge case detection in interval_mul and pgbench. This patch adopts the overflow check logic introduced by commit cbdb8b4c0 into two more places. interval_mul() failed to notice if it computed a new microseconds value that was one more than INT64_MAX, and pgbench's double-to-i

pgsql: Fix integer-overflow edge case detection in interval_mul and pgb

Fix integer-overflow edge case detection in interval_mul and pgbench. This patch adopts the overflow check logic introduced by commit cbdb8b4c0 into two more places. interval_mul() failed to notice if it computed a new microseconds value that was one more than INT64_MAX, and pgbench's double-to-i

pgsql: Fix integer-overflow edge case detection in interval_mul and pgb

Fix integer-overflow edge case detection in interval_mul and pgbench. This patch adopts the overflow check logic introduced by commit cbdb8b4c0 into two more places. interval_mul() failed to notice if it computed a new microseconds value that was one more than INT64_MAX, and pgbench's double-to-i

pgsql: Fix integer-overflow edge case detection in interval_mul and pgb

Fix integer-overflow edge case detection in interval_mul and pgbench. This patch adopts the overflow check logic introduced by commit cbdb8b4c0 into two more places. interval_mul() failed to notice if it computed a new microseconds value that was one more than INT64_MAX, and pgbench's double-to-i

pgsql: Fix integer-overflow edge case detection in interval_mul and pgb

Fix integer-overflow edge case detection in interval_mul and pgbench. This patch adopts the overflow check logic introduced by commit cbdb8b4c0 into two more places. interval_mul() failed to notice if it computed a new microseconds value that was one more than INT64_MAX, and pgbench's double-to-i

Re: pgsql: doc: Further clarify how recovery target parameters are applied

On Fri, Nov 8, 2019 at 12:23 AM Peter Eisentraut wrote: > > On 2019-11-06 10:49, Fujii Masao wrote: > > On Wed, Nov 6, 2019 at 4:29 PM Peter Eisentraut > > wrote: > >> > >> On 2019-11-06 05:48, Fujii Masao wrote: > >>> Patch attached. As I argued upthread, IMO it's better to remove > >>> the latt

pgsql: Fix SET CONSTRAINTS .. DEFERRED on partitioned tables

Fix SET CONSTRAINTS .. DEFERRED on partitioned tables SET CONSTRAINTS ... DEFERRED failed on partitioned tables, because of a sanity check that ensures that the affected constraints have triggers. On partitioned tables, the triggers are in the leaf partitions, not in the partitioned relations them

pgsql: Fix SET CONSTRAINTS .. DEFERRED on partitioned tables

Fix SET CONSTRAINTS .. DEFERRED on partitioned tables SET CONSTRAINTS ... DEFERRED failed on partitioned tables, because of a sanity check that ensures that the affected constraints have triggers. On partitioned tables, the triggers are in the leaf partitions, not in the partitioned relations them

pgsql: Fix SET CONSTRAINTS .. DEFERRED on partitioned tables

Fix SET CONSTRAINTS .. DEFERRED on partitioned tables SET CONSTRAINTS ... DEFERRED failed on partitioned tables, because of a sanity check that ensures that the affected constraints have triggers. On partitioned tables, the triggers are in the leaf partitions, not in the partitioned relations them

Re: pgsql: doc: Further clarify how recovery target parameters are applied

On 11/6/19 4:49 AM, Fujii Masao wrote: On Wed, Nov 6, 2019 at 4:29 PM Peter Eisentraut wrote: On 2019-11-06 05:48, Fujii Masao wrote: Patch attached. As I argued upthread, IMO it's better to remove the latter description from the doc and the patch does that. Also the patch adds "mainly" into

pgsql: Move declaration of ecpg_gettext() to a saner place.

Move declaration of ecpg_gettext() to a saner place. Declaring this in the client-visible header ecpglib.h was a pretty poor decision. It's not meant to be application-callable (and if it was, putting it outside the extern "C" { ... } wrapper means that C++ clients would fail to call it). And th

pgsql: Move declaration of ecpg_gettext() to a saner place.

Move declaration of ecpg_gettext() to a saner place. Declaring this in the client-visible header ecpglib.h was a pretty poor decision. It's not meant to be application-callable (and if it was, putting it outside the extern "C" { ... } wrapper means that C++ clients would fail to call it). And th

pgsql: Move declaration of ecpg_gettext() to a saner place.

Move declaration of ecpg_gettext() to a saner place. Declaring this in the client-visible header ecpglib.h was a pretty poor decision. It's not meant to be application-callable (and if it was, putting it outside the extern "C" { ... } wrapper means that C++ clients would fail to call it). And th

pgsql: Move declaration of ecpg_gettext() to a saner place.

Move declaration of ecpg_gettext() to a saner place. Declaring this in the client-visible header ecpglib.h was a pretty poor decision. It's not meant to be application-callable (and if it was, putting it outside the extern "C" { ... } wrapper means that C++ clients would fail to call it). And th

pgsql: Move declaration of ecpg_gettext() to a saner place.

Move declaration of ecpg_gettext() to a saner place. Declaring this in the client-visible header ecpglib.h was a pretty poor decision. It's not meant to be application-callable (and if it was, putting it outside the extern "C" { ... } wrapper means that C++ clients would fail to call it). And th

pgsql: Move declaration of ecpg_gettext() to a saner place.

Move declaration of ecpg_gettext() to a saner place. Declaring this in the client-visible header ecpglib.h was a pretty poor decision. It's not meant to be application-callable (and if it was, putting it outside the extern "C" { ... } wrapper means that C++ clients would fail to call it). And th

pgsql: Move declaration of ecpg_gettext() to a saner place.

Move declaration of ecpg_gettext() to a saner place. Declaring this in the client-visible header ecpglib.h was a pretty poor decision. It's not meant to be application-callable (and if it was, putting it outside the extern "C" { ... } wrapper means that C++ clients would fail to call it). And th

pgsql: docs: clarify that only INSERT and UPDATE triggers can mod. NEW

docs: clarify that only INSERT and UPDATE triggers can mod. NEW The point is that DELETE triggers cannot modify any values. Reported-by: Eugen Konkov Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.4 Branch -- master Details --- https://git.pos

pgsql: docs: clarify that only INSERT and UPDATE triggers can mod. NEW

docs: clarify that only INSERT and UPDATE triggers can mod. NEW The point is that DELETE triggers cannot modify any values. Reported-by: Eugen Konkov Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.4 Branch -- REL9_6_STABLE Details --- https://

pgsql: docs: clarify that only INSERT and UPDATE triggers can mod. NEW

docs: clarify that only INSERT and UPDATE triggers can mod. NEW The point is that DELETE triggers cannot modify any values. Reported-by: Eugen Konkov Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.4 Branch -- REL_11_STABLE Details --- https://

pgsql: docs: clarify that only INSERT and UPDATE triggers can mod. NEW

docs: clarify that only INSERT and UPDATE triggers can mod. NEW The point is that DELETE triggers cannot modify any values. Reported-by: Eugen Konkov Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.4 Branch -- REL_10_STABLE Details --- https://

pgsql: docs: clarify that only INSERT and UPDATE triggers can mod. NEW

docs: clarify that only INSERT and UPDATE triggers can mod. NEW The point is that DELETE triggers cannot modify any values. Reported-by: Eugen Konkov Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.4 Branch -- REL9_4_STABLE Details --- https://

pgsql: docs: clarify that only INSERT and UPDATE triggers can mod. NEW

docs: clarify that only INSERT and UPDATE triggers can mod. NEW The point is that DELETE triggers cannot modify any values. Reported-by: Eugen Konkov Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.4 Branch -- REL9_5_STABLE Details --- https://

pgsql: Use "low key" terminology in nbtsort.c.

Use "low key" terminology in nbtsort.c. nbtree index builds once stashed the "minimum key" for a page, which was used as the basis of the pivot tuple that gets placed in the next level up (i.e. the tuple that stores the downlink to the page in question). It doesn't quite work that way anymore, so

pgsql: More precise errors from initial pg_control check

More precise errors from initial pg_control check Use a separate error message for invalid checkpoint location and invalid state instead of just "invalid data" for both. Reviewed-by: Michael Paquier Discussion: https://www.postgresql.org/message-id/[email protected] Branch