[COMMITTERS] pgsql: Fix potential data corruption during freeze
Fix potential data corruption during freeze Fix oversight in 3b97e6823b94 bug fix. Bitwise AND is used instead of OR and it cleans all bits in t_infomask heap tuple field. Backpatch to 9.3 Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f371cc9e9fffc79ab68185e07013d50147ed2bc9 Modified Files -- src/backend/access/heap/heapam.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix potential data corruption during freeze
Fix potential data corruption during freeze Fix oversight in 3b97e6823b94 bug fix. Bitwise AND is used instead of OR and it cleans all bits in t_infomask heap tuple field. Backpatch to 9.3 Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b90e4ca3edfd60309e4bc4fcb96e658826a7e20d Modified Files -- src/backend/access/heap/heapam.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix potential data corruption during freeze
Fix potential data corruption during freeze Fix oversight in 3b97e6823b94 bug fix. Bitwise AND is used instead of OR and it cleans all bits in t_infomask heap tuple field. Backpatch to 9.3 Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/fb2d385e6521c221f2d6681125e6e42ff8b28440 Modified Files -- src/backend/access/heap/heapam.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix potential data corruption during freeze
Fix potential data corruption during freeze Fix oversight in 3b97e6823b94 bug fix. Bitwise AND is used instead of OR and it cleans all bits in t_infomask heap tuple field. Backpatch to 9.3 Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/42f62e4c976e1cf90f5e5a6381c4ee656260f230 Modified Files -- src/backend/access/heap/heapam.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix potential data corruption during freeze
Fix potential data corruption during freeze Fix oversight in 3b97e6823b94 bug fix. Bitwise AND is used instead of OR and it cleans all bits in t_infomask heap tuple field. Backpatch to 9.3 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/31b8db8e6c1fa4436116f4be5ca789f3a01b9ebf Modified Files -- src/backend/access/heap/heapam.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Clarify the contract of partition_rbound_cmp().
Clarify the contract of partition_rbound_cmp(). partition_rbound_cmp() is intended to compare range partition bounds in a way such that if all the bound values are equal but one is an upper bound and one is a lower bound, the upper bound is treated as smaller than the lower bound. This particular ordering is required by RelationBuildPartitionDesc() when building the PartitionBoundInfoData, so that it can consistently keep only the upper bounds when upper and lower bounds coincide. Update the function comment to make that clearer. Also, fix a (currently unreachable) corner-case bug -- if the bound values coincide and they contain unbounded values, fall through to the lower-vs-upper comparison code, rather than immediately returning 0. Currently it is not possible to define coincident upper and lower bounds containing unbounded columns, but that may change in the future, so code defensively. Discussion: https://postgr.es/m/CAAJ_b947mowpLdxL3jo3YLKngRjrq9+Ej4ymduQTfYR+8=y...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f1dae097f2945ffcb59a9f236843e0e0bbf0920d Modified Files -- src/backend/catalog/partition.c | 44 - 1 file changed, 30 insertions(+), 14 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Simplify the logic checking new range partition bounds.
Simplify the logic checking new range partition bounds. The previous logic, whilst not actually wrong, was overly complex and involved doing two binary searches, where only one was really necessary. This simplifies that logic and improves the comments. One visible change is that if the new partition overlaps multiple existing partitions, the error message now always reports the overlap with the first existing partition (the one with the lowest bounds). The old code would sometimes report the clash with the first partition and sometimes with the last one. Original patch idea from Amit Langote, substantially rewritten by me. Discussion: https://postgr.es/m/CAAJ_b947mowpLdxL3jo3YLKngRjrq9+Ej4ymduQTfYR+8=y...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c03911d9454a0cf5d88910ad46b433ab342c39e0 Modified Files -- src/backend/catalog/partition.c| 92 +- src/test/regress/expected/create_table.out | 2 +- 2 files changed, 40 insertions(+), 54 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
