pgsql: Fix overly strict Assert in jsonpath code
Fix overly strict Assert in jsonpath code
This was failing for queries which try to get the .type() of a
jpiLikeRegex. For example:
select jsonb_path_query('["string", "string"]',
'($[0] like_regex ".{7}").type()');
Reported-by: Alexander Kozhemyakin
Bug: #18035
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 12, where SQL/JSON path was added.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/deae1657ee6dd6f7b3effab3d44429d5434f5bbf
Modified Files
--
src/backend/utils/adt/jsonpath.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Fix overly strict Assert in jsonpath code
Fix overly strict Assert in jsonpath code
This was failing for queries which try to get the .type() of a
jpiLikeRegex. For example:
select jsonb_path_query('["string", "string"]',
'($[0] like_regex ".{7}").type()');
Reported-by: Alexander Kozhemyakin
Bug: #18035
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 12, where SQL/JSON path was added.
Branch
--
REL_16_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/b25acc302524cf61bee46e1aad5bebb276449270
Modified Files
--
src/backend/utils/adt/jsonpath.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Fix overly strict Assert in jsonpath code
Fix overly strict Assert in jsonpath code
This was failing for queries which try to get the .type() of a
jpiLikeRegex. For example:
select jsonb_path_query('["string", "string"]',
'($[0] like_regex ".{7}").type()');
Reported-by: Alexander Kozhemyakin
Bug: #18035
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 12, where SQL/JSON path was added.
Branch
--
REL_15_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/67f3a697ba83489fc69fefd82bc6dbc19f87ac56
Modified Files
--
src/backend/utils/adt/jsonpath.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Fix overly strict Assert in jsonpath code
Fix overly strict Assert in jsonpath code
This was failing for queries which try to get the .type() of a
jpiLikeRegex. For example:
select jsonb_path_query('["string", "string"]',
'($[0] like_regex ".{7}").type()');
Reported-by: Alexander Kozhemyakin
Bug: #18035
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 12, where SQL/JSON path was added.
Branch
--
REL_14_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/f457f2ef140a9a218ded6befed6d7dc625aac3ec
Modified Files
--
src/backend/utils/adt/jsonpath.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Fix overly strict Assert in jsonpath code
Fix overly strict Assert in jsonpath code
This was failing for queries which try to get the .type() of a
jpiLikeRegex. For example:
select jsonb_path_query('["string", "string"]',
'($[0] like_regex ".{7}").type()');
Reported-by: Alexander Kozhemyakin
Bug: #18035
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 12, where SQL/JSON path was added.
Branch
--
REL_13_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/74a5bf1b676f75f67f63e57db7e97edd8a1e923f
Modified Files
--
src/backend/utils/adt/jsonpath.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Fix overly strict Assert in jsonpath code
Fix overly strict Assert in jsonpath code
This was failing for queries which try to get the .type() of a
jpiLikeRegex. For example:
select jsonb_path_query('["string", "string"]',
'($[0] like_regex ".{7}").type()');
Reported-by: Alexander Kozhemyakin
Bug: #18035
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 12, where SQL/JSON path was added.
Branch
--
REL_12_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/668990980f15e204abad3ed015466514483ab7ab
Modified Files
--
src/backend/utils/adt/jsonpath.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Add and use symbolic constants for tar header offsets and file t
Add and use symbolic constants for tar header offsets and file types. Because symbolic constants in a header file are better than magic constants embedded in the code. Patch by me, reviewed by Tom Lane, Dagfinn Ilmari Mannsåker, and Tristan Partin. Discussion: http://postgr.es/m/ca+tgmoznblwhmcrntkjavi8flkwfdmevu3myv2hqqpa5bvb...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6050b6a92d1e6b5a234e96382ea711683e67d280 Modified Files -- src/bin/pg_basebackup/bbstreamer_tar.c | 22 +-- src/bin/pg_basebackup/walmethods.c | 7 +++--- src/bin/pg_dump/pg_backup_tar.c| 16 +++--- src/include/pgtar.h| 39 ++ src/port/tar.c | 38 - 5 files changed, 80 insertions(+), 42 deletions(-)
pgsql: Fix pg_stat_io buffer reuse test instability
Fix pg_stat_io buffer reuse test instability The stats regression test attempts to ensure that Buffer Access Strategy "reuses" are being counted in pg_stat_io by vacuuming a table which is larger than the size of the strategy ring. However, when shared buffers are in sufficiently high demand, another backend could evict one of the blocks in the strategy ring before the first backend has a chance to reuse the buffer. The backend using the strategy would then evict another shared buffer and add that buffer to the strategy ring. This counts as an eviction and not a reuse in pg_stat_io. Count both evictions and reuses in the test to ensure it does not fail incorrectly. Reported-by: Jeff Davis , Author: Melanie Plageman Reviewed-by: Alexander Lakhin Reviewed-by: Masahiko Sawada Discussion: https://postgr.es/m/CAAKRu_bNG27AxG9TdPtwsL6wg8AWbVckjmTL2t1HF=midqu...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/36ab831f9abc6f6b0ab74dd62e0faad75dbf42bf Modified Files -- src/test/regress/expected/stats.out | 30 -- src/test/regress/sql/stats.sql | 19 --- 2 files changed, 32 insertions(+), 17 deletions(-)
pgsql: Fix performance regression in pg_strtointNN_safe functions
Fix performance regression in pg_strtointNN_safe functions Between 6fcda9aba and 1b6f632a3, the pg_strtoint functions became quite a bit slower in v16, despite efforts in 6b423ec67 to speed these up. Since the majority of cases for these functions will only contain base-10 digits, perhaps prefixed by a '-', it makes sense to have a special case for this and just fall back on the more complex version which processes hex, octal, binary and underscores if the fast path version fails to parse the string. While we're here, update the header comments for these functions to mention that hex, octal and binary formats along with underscore separators are now supported. Author: Andres Freund, David Rowley Reported-by: Masahiko Sawada Reviewed-by: Dean Rasheed, John Naylor Discussion: https://postgr.es/m/CAD21AoDvDmUQeJtZrau1ovnT_smN940%3DKp6mszNGK3bq9yRN6g%40mail.gmail.com Backpatch-through: 16, where 6fcda9aba and 1b6f632a3 were added Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/3845577cb55eab3e06b3724e307ebbcac31f4841 Modified Files -- src/backend/utils/adt/numutils.c | 306 +++ 1 file changed, 279 insertions(+), 27 deletions(-)
pgsql: Fix performance regression in pg_strtointNN_safe functions
Fix performance regression in pg_strtointNN_safe functions Between 6fcda9aba and 1b6f632a3, the pg_strtoint functions became quite a bit slower in v16, despite efforts in 6b423ec67 to speed these up. Since the majority of cases for these functions will only contain base-10 digits, perhaps prefixed by a '-', it makes sense to have a special case for this and just fall back on the more complex version which processes hex, octal, binary and underscores if the fast path version fails to parse the string. While we're here, update the header comments for these functions to mention that hex, octal and binary formats along with underscore separators are now supported. Author: Andres Freund, David Rowley Reported-by: Masahiko Sawada Reviewed-by: Dean Rasheed, John Naylor Discussion: https://postgr.es/m/CAD21AoDvDmUQeJtZrau1ovnT_smN940%3DKp6mszNGK3bq9yRN6g%40mail.gmail.com Backpatch-through: 16, where 6fcda9aba and 1b6f632a3 were added Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4e2e75cd29eb7bc591afe30fd7425629fe2c5a5d Modified Files -- src/backend/utils/adt/numutils.c | 306 +++ 1 file changed, 279 insertions(+), 27 deletions(-)
pgsql: Fix pg_stat_io buffer reuse test instability
Fix pg_stat_io buffer reuse test instability The stats regression test attempts to ensure that Buffer Access Strategy "reuses" are being counted in pg_stat_io by vacuuming a table which is larger than the size of the strategy ring. However, when shared buffers are in sufficiently high demand, another backend could evict one of the blocks in the strategy ring before the first backend has a chance to reuse the buffer. The backend using the strategy would then evict another shared buffer and add that buffer to the strategy ring. This counts as an eviction and not a reuse in pg_stat_io. Count both evictions and reuses in the test to ensure it does not fail incorrectly. Reported-by: Jeff Davis , Author: Melanie Plageman Reviewed-by: Alexander Lakhin Reviewed-by: Masahiko Sawada Discussion: https://postgr.es/m/CAAKRu_bNG27AxG9TdPtwsL6wg8AWbVckjmTL2t1HF=midqu...@mail.gmail.com Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/803660ea4c5d9d2b3c7e1b0a9fc4b99359ba0a85 Modified Files -- src/test/regress/expected/stats.out | 30 -- src/test/regress/sql/stats.sql | 19 --- 2 files changed, 32 insertions(+), 17 deletions(-)
pgsql: Fix ReorderBufferCheckMemoryLimit() comment.
Fix ReorderBufferCheckMemoryLimit() comment. Commit 7259736a6 updated the comment but it was not correct since ReorderBufferLargestStreamableTopTXN() returns only top-level transactions. Reviewed-by: Amit Kapila Discussion: https://postgr.es/m/CAD21AoA9XB7OR86BqvrCe2dMYX%2BZv3-BvVmjF%3DGY2z6jN-kqjg%40mail.gmail.com Backpatch-through: 14 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2e3741fb5733201f80443ba9b4583f0e3f3df86e Modified Files -- src/backend/replication/logical/reorderbuffer.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix ReorderBufferCheckMemoryLimit() comment.
Fix ReorderBufferCheckMemoryLimit() comment. Commit 7259736a6 updated the comment but it was not correct since ReorderBufferLargestStreamableTopTXN() returns only top-level transactions. Reviewed-by: Amit Kapila Discussion: https://postgr.es/m/CAD21AoA9XB7OR86BqvrCe2dMYX%2BZv3-BvVmjF%3DGY2z6jN-kqjg%40mail.gmail.com Backpatch-through: 14 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/01357f1da94b9926336448d88ac519f20ab27cd7 Modified Files -- src/backend/replication/logical/reorderbuffer.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix ReorderBufferCheckMemoryLimit() comment.
Fix ReorderBufferCheckMemoryLimit() comment. Commit 7259736a6 updated the comment but it was not correct since ReorderBufferLargestStreamableTopTXN() returns only top-level transactions. Reviewed-by: Amit Kapila Discussion: https://postgr.es/m/CAD21AoA9XB7OR86BqvrCe2dMYX%2BZv3-BvVmjF%3DGY2z6jN-kqjg%40mail.gmail.com Backpatch-through: 14 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5c0fcef76a44bb834d4d13685b877e62409e6984 Modified Files -- src/backend/replication/logical/reorderbuffer.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix ReorderBufferCheckMemoryLimit() comment.
Fix ReorderBufferCheckMemoryLimit() comment. Commit 7259736a6 updated the comment but it was not correct since ReorderBufferLargestStreamableTopTXN() returns only top-level transactions. Reviewed-by: Amit Kapila Discussion: https://postgr.es/m/CAD21AoA9XB7OR86BqvrCe2dMYX%2BZv3-BvVmjF%3DGY2z6jN-kqjg%40mail.gmail.com Backpatch-through: 14 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0125c4e21d7e9c8b3da95ffcd3e34c0f61c9b69a Modified Files -- src/backend/replication/logical/reorderbuffer.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
