pgsql: Docs: wording improvement for compute_query_id = regress
Docs: wording improvement for compute_query_id = regress It's more accurate to say that the query identifier is not shown when compute_query_id = regress rather than to say it is hidden. This change (ebf6c5249) appeared in v14, so it makes sense to backpatch this small adjustment to keep the documents consistent between v14 and master. Author: Justin Pryzby Discussion: https://postgr.es/m/[email protected] Backpatch-through: 14, where compute_query_id = regress was added Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a59746d311264305bbe68aaf48d5b20e8fd56920 Modified Files -- doc/src/sgml/config.sgml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Docs: wording improvement for compute_query_id = regress
Docs: wording improvement for compute_query_id = regress It's more accurate to say that the query identifier is not shown when compute_query_id = regress rather than to say it is hidden. This change (ebf6c5249) appeared in v14, so it makes sense to backpatch this small adjustment to keep the documents consistent between v14 and master. Author: Justin Pryzby Discussion: https://postgr.es/m/[email protected] Backpatch-through: 14, where compute_query_id = regress was added Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ea669b8088380cc0bc7c48ab8581ea5fba1c5b4f Modified Files -- doc/src/sgml/config.sgml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix incorrect format placeholders
Fix incorrect format placeholders Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a038679cd876f63e17a08f64fafad27cd5bc23fe Modified Files -- src/backend/utils/error/jsonlog.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Fix finalization for json_objectagg and friends
Fix finalization for json_objectagg and friends Commit f4fb45d15c misguidedly tried to free some state during aggregate finalization for json_objectagg. This resulted in attempts to access freed memory, especially when the function is used as a window function. Commit 4eb9798879 attempted to ameliorate that, but in fact it should just be ripped out, which is done here. Also add some regression tests for json_objectagg in various flavors as a window function. Original report from Jaime Casanova, diagnosis by Andres Freund. Discussion: https://postgr.es/m/YkfeMNYRCGhySKyg@ahch-to Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/112fdb3528465cc14a2f1dff3dc27f100326d885 Modified Files -- src/backend/utils/adt/json.c | 12 src/test/regress/expected/sqljson.out | 35 +++ src/test/regress/sql/sqljson.sql | 18 ++ 3 files changed, 53 insertions(+), 12 deletions(-)
pgsql: Release cache tuple when no longer needed
Release cache tuple when no longer needed There was a small buglet in commit 52e4f0cd472d whereby a tuple acquired from cache was not released, giving rise to WARNING messages; fix that. While at it, restructure the code a bit on stylistic grounds. Author: Hou zj Reported-by: Peter Smith Reviewed-by: Amit Kapila Discussion: https://postgr.es/m/CAHut+PvKTyhTBtYCQsP6Ph7=o-owrsx+v+pxxlxp81-o2ba...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ed0fbc8e5ac995eada933250c1d5535336442b97 Modified Files -- src/backend/commands/publicationcmds.c| 95 --- src/test/regress/expected/publication.out | 16 -- src/test/regress/sql/publication.sql | 8 +++ 3 files changed, 68 insertions(+), 51 deletions(-)
pgsql: Remove extraneous blank lines before block-closing braces
Remove extraneous blank lines before block-closing braces These are useless and distracting. We wouldn't have written the code with them to begin with, so there's no reason to keep them. Author: Justin Pryzby Discussion: https://postgr.es/m/[email protected] Discussion: https://postgr.es/m/attachment/133167/0016-Extraneous-blank-lines.patch Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/24d2b2680a8d0e01b30ce8a41c4eb3b47aca5031 Modified Files -- contrib/btree_gist/btree_bit.c | 1 - contrib/btree_gist/btree_cash.c| 1 - contrib/btree_gist/btree_float4.c | 1 - contrib/btree_gist/btree_float8.c | 1 - contrib/btree_gist/btree_inet.c| 1 - contrib/btree_gist/btree_interval.c| 2 -- contrib/btree_gist/btree_macaddr.c | 1 - contrib/btree_gist/btree_macaddr8.c| 1 - contrib/btree_gist/btree_ts.c | 1 - contrib/dblink/dblink.c| 2 -- contrib/intarray/_int_bool.c | 1 - contrib/ltree/ltxtquery_io.c | 1 - contrib/pg_stat_statements/pg_stat_statements.c| 1 - contrib/postgres_fdw/connection.c | 1 - contrib/spi/refint.c | 2 -- src/backend/access/brin/brin_bloom.c | 1 - src/backend/access/gin/ginbtree.c | 1 - src/backend/access/heap/heapam.c | 1 - src/backend/access/heap/vacuumlazy.c | 1 - src/backend/access/nbtree/nbtsplitloc.c| 1 - src/backend/access/nbtree/nbtutils.c | 3 --- src/backend/access/rmgrdesc/gistdesc.c | 1 - src/backend/access/spgist/spgutils.c | 1 - src/backend/access/table/tableam.c | 1 - src/backend/access/transam/xlogrecovery.c | 1 - src/backend/catalog/objectaddress.c| 2 -- src/backend/catalog/pg_attrdef.c | 1 - src/backend/commands/copyto.c | 1 - src/backend/commands/subscriptioncmds.c| 1 - src/backend/commands/tablecmds.c | 3 --- src/backend/executor/execParallel.c| 1 - src/backend/executor/execReplication.c | 1 - src/backend/executor/nodeAgg.c | 1 - src/backend/executor/nodeMergejoin.c | 1 - src/backend/jit/llvm/llvmjit_deform.c | 2 -- src/backend/jit/llvm/llvmjit_expr.c| 1 - src/backend/libpq/hba.c| 1 - src/backend/optimizer/geqo/geqo_cx.c | 1 - src/backend/optimizer/geqo/geqo_erx.c | 3 --- src/backend/optimizer/geqo/geqo_ox1.c | 1 - src/backend/optimizer/geqo/geqo_ox2.c | 1 - src/backend/optimizer/geqo/geqo_pmx.c | 6 -- src/backend/optimizer/geqo/geqo_px.c | 3 --- src/backend/optimizer/plan/planner.c | 1 - src/backend/postmaster/postmaster.c| 1 - src/backend/replication/logical/origin.c | 1 - src/backend/replication/logical/snapbuild.c| 1 - src/backend/replication/logical/worker.c | 1 - src/backend/replication/pgoutput/pgoutput.c| 3 +-- src/backend/replication/walsender.c| 1 - src/backend/statistics/dependencies.c | 1 - src/backend/storage/buffer/bufmgr.c| 2 -- src/backend/storage/buffer/freelist.c | 1 - src/backend/storage/ipc/latch.c| 1 - src/backend/storage/ipc/procarray.c| 2 -- src/backend/storage/lmgr/lwlock.c | 1 - src/backend/storage/page/bufpage.c | 2 -- src/backend/storage/sync/sync.c| 1 - src/backend/tcop/postgres.c| 1 - src/backend/tcop/utility.c | 1 - src/backend/tsearch/to_tsany.c | 2 -- src/backend/tsearch/ts_parse.c | 2 -- src/backend/utils/activity/pgstat_database.c | 1 - src/backend/utils/adt/acl.c| 1 - src/backend/utils/adt/json.c
pgsql: Prevent access to no-longer-pinned buffer in heapam_tuple_lock()
Prevent access to no-longer-pinned buffer in heapam_tuple_lock(). heap_fetch() used to have a "keep_buf" parameter that told it to return ownership of the buffer pin to the caller after finding that the requested tuple TID exists but is invisible to the specified snapshot. This was thoughtlessly removed in commit 5db6df0c0, which broke heapam_tuple_lock() (formerly EvalPlanQualFetch) because that function needs to do more accesses to the tuple even if it's invisible. The net effect is that we would continue to touch the page for a microsecond or two after releasing pin on the buffer. Usually no harm would result; but if a different session decided to defragment the page concurrently, we could see garbage data and mistakenly conclude that there's no newer tuple version to chain up to. (It's hard to say whether this has happened in the field. The bug was actually found thanks to a later change that allowed valgrind to detect accesses to non-pinned buffers.) The most reasonable way to fix this is to reintroduce keep_buf, although I made it behave slightly differently: buffer ownership is passed back only if there is a valid tuple at the requested TID. In HEAD, we can just add the parameter back to heap_fetch(). To avoid an API break in the back branches, introduce an additional function heap_fetch_extended() in those branches. In HEAD there is an additional, less obvious API change: tuple->t_data will be set to NULL in all cases where buffer ownership is not returned, in particular when the tuple exists but fails the time qual (and !keep_buf). This is to defend against any other callers attempting to access non-pinned buffers. We concluded that making that change in back branches would be more likely to introduce problems than cure any. In passing, remove a comment about heap_fetch that was obsoleted by 9a8ee1dc6. Per bug #17462 from Daniil Anisimov. Back-patch to v12 where the bug was introduced. Discussion: https://postgr.es/m/[email protected] Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e0ed20d0b66ed2d1395e75dbb856d9b4cd251ad9 Modified Files -- src/backend/access/heap/heapam.c | 40 ++-- src/backend/access/heap/heapam_handler.c | 15 ++-- src/include/access/heapam.h | 3 +++ 3 files changed, 43 insertions(+), 15 deletions(-)
pgsql: Prevent access to no-longer-pinned buffer in heapam_tuple_lock()
Prevent access to no-longer-pinned buffer in heapam_tuple_lock(). heap_fetch() used to have a "keep_buf" parameter that told it to return ownership of the buffer pin to the caller after finding that the requested tuple TID exists but is invisible to the specified snapshot. This was thoughtlessly removed in commit 5db6df0c0, which broke heapam_tuple_lock() (formerly EvalPlanQualFetch) because that function needs to do more accesses to the tuple even if it's invisible. The net effect is that we would continue to touch the page for a microsecond or two after releasing pin on the buffer. Usually no harm would result; but if a different session decided to defragment the page concurrently, we could see garbage data and mistakenly conclude that there's no newer tuple version to chain up to. (It's hard to say whether this has happened in the field. The bug was actually found thanks to a later change that allowed valgrind to detect accesses to non-pinned buffers.) The most reasonable way to fix this is to reintroduce keep_buf, although I made it behave slightly differently: buffer ownership is passed back only if there is a valid tuple at the requested TID. In HEAD, we can just add the parameter back to heap_fetch(). To avoid an API break in the back branches, introduce an additional function heap_fetch_extended() in those branches. In HEAD there is an additional, less obvious API change: tuple->t_data will be set to NULL in all cases where buffer ownership is not returned, in particular when the tuple exists but fails the time qual (and !keep_buf). This is to defend against any other callers attempting to access non-pinned buffers. We concluded that making that change in back branches would be more likely to introduce problems than cure any. In passing, remove a comment about heap_fetch that was obsoleted by 9a8ee1dc6. Per bug #17462 from Daniil Anisimov. Back-patch to v12 where the bug was introduced. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7b7ed046cb2ad9f6efac90380757d5977f0f563f Modified Files -- src/backend/access/heap/heapam.c | 30 -- src/backend/access/heap/heapam_handler.c | 16 +++- src/include/access/heapam.h | 2 +- 3 files changed, 28 insertions(+), 20 deletions(-)
pgsql: Prevent access to no-longer-pinned buffer in heapam_tuple_lock()
Prevent access to no-longer-pinned buffer in heapam_tuple_lock(). heap_fetch() used to have a "keep_buf" parameter that told it to return ownership of the buffer pin to the caller after finding that the requested tuple TID exists but is invisible to the specified snapshot. This was thoughtlessly removed in commit 5db6df0c0, which broke heapam_tuple_lock() (formerly EvalPlanQualFetch) because that function needs to do more accesses to the tuple even if it's invisible. The net effect is that we would continue to touch the page for a microsecond or two after releasing pin on the buffer. Usually no harm would result; but if a different session decided to defragment the page concurrently, we could see garbage data and mistakenly conclude that there's no newer tuple version to chain up to. (It's hard to say whether this has happened in the field. The bug was actually found thanks to a later change that allowed valgrind to detect accesses to non-pinned buffers.) The most reasonable way to fix this is to reintroduce keep_buf, although I made it behave slightly differently: buffer ownership is passed back only if there is a valid tuple at the requested TID. In HEAD, we can just add the parameter back to heap_fetch(). To avoid an API break in the back branches, introduce an additional function heap_fetch_extended() in those branches. In HEAD there is an additional, less obvious API change: tuple->t_data will be set to NULL in all cases where buffer ownership is not returned, in particular when the tuple exists but fails the time qual (and !keep_buf). This is to defend against any other callers attempting to access non-pinned buffers. We concluded that making that change in back branches would be more likely to introduce problems than cure any. In passing, remove a comment about heap_fetch that was obsoleted by 9a8ee1dc6. Per bug #17462 from Daniil Anisimov. Back-patch to v12 where the bug was introduced. Discussion: https://postgr.es/m/[email protected] Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c590e514a90ddc9237a3438efb05be074d43452b Modified Files -- src/backend/access/heap/heapam.c | 40 ++-- src/backend/access/heap/heapam_handler.c | 15 ++-- src/include/access/heapam.h | 3 +++ 3 files changed, 43 insertions(+), 15 deletions(-)
pgsql: Prevent access to no-longer-pinned buffer in heapam_tuple_lock()
Prevent access to no-longer-pinned buffer in heapam_tuple_lock(). heap_fetch() used to have a "keep_buf" parameter that told it to return ownership of the buffer pin to the caller after finding that the requested tuple TID exists but is invisible to the specified snapshot. This was thoughtlessly removed in commit 5db6df0c0, which broke heapam_tuple_lock() (formerly EvalPlanQualFetch) because that function needs to do more accesses to the tuple even if it's invisible. The net effect is that we would continue to touch the page for a microsecond or two after releasing pin on the buffer. Usually no harm would result; but if a different session decided to defragment the page concurrently, we could see garbage data and mistakenly conclude that there's no newer tuple version to chain up to. (It's hard to say whether this has happened in the field. The bug was actually found thanks to a later change that allowed valgrind to detect accesses to non-pinned buffers.) The most reasonable way to fix this is to reintroduce keep_buf, although I made it behave slightly differently: buffer ownership is passed back only if there is a valid tuple at the requested TID. In HEAD, we can just add the parameter back to heap_fetch(). To avoid an API break in the back branches, introduce an additional function heap_fetch_extended() in those branches. In HEAD there is an additional, less obvious API change: tuple->t_data will be set to NULL in all cases where buffer ownership is not returned, in particular when the tuple exists but fails the time qual (and !keep_buf). This is to defend against any other callers attempting to access non-pinned buffers. We concluded that making that change in back branches would be more likely to introduce problems than cure any. In passing, remove a comment about heap_fetch that was obsoleted by 9a8ee1dc6. Per bug #17462 from Daniil Anisimov. Back-patch to v12 where the bug was introduced. Discussion: https://postgr.es/m/[email protected] Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/44096c31eaf0e9d86053434de8fdce418609c01e Modified Files -- src/backend/access/heap/heapam.c | 40 ++-- src/backend/access/heap/heapam_handler.c | 15 ++-- src/include/access/heapam.h | 3 +++ 3 files changed, 43 insertions(+), 15 deletions(-)
pgsql: Further tweak the default behavior of psql's \dconfig.
Further tweak the default behavior of psql's \dconfig. Define "parameters with non-default settings" as being those that not only have pg_settings.source different from 'default', but also have a current value different from the hard-wired boot_val. Adding the latter restriction removes a number of not-very-interesting cases where the active setting is chosen by initdb but in practice tends to be the same all the time. Per discussion with Jonathan Katz. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/139d46ee26a2c7813d02739d35fa305890643ac1 Modified Files -- src/bin/psql/describe.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Fix case sensitivity in psql's tab completion for GUC names.
Fix case sensitivity in psql's tab completion for GUC names. Input for these should be case-insensitive, but was not completely so. Comparing to the similar queries for timezone names, I realized that we'd missed forcing the comparison pattern to lower-case. With that, it behaves as I expect. While here, flatten the sub-selects in these queries; I don't find that those add any readability. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b5607b0746f40b3f5b38004c64ccc9697ee1e222 Modified Files -- src/bin/psql/tab-complete.c | 22 -- 1 file changed, 8 insertions(+), 14 deletions(-)
pgsql: Docs: fix some spelling mistakes and also do some wordsmithing
Docs: fix some spelling mistakes and also do some wordsmithing All except one of these are new to v15. Only one of the wordsmithing changes appears in older versions. The wordsmithing improvement does not seem significant enough to warrant backpatching. Author: Justin Pryzby Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ac8be0cb957811d04d7564f4d710ceb3e5f2fb9f Modified Files -- doc/src/sgml/charset.sgml| 12 ++-- doc/src/sgml/ref/initdb.sgml | 2 +- 2 files changed, 7 insertions(+), 7 deletions(-)
pgsql: Add missing spaces after single-line comments
Add missing spaces after single-line comments Only 1 of 3 of these changes appear to be handled by pgindent. That change is new to v15. The remaining two appear to be left alone by pgindent. The exact reason for that is not 100% clear to me. It seems related to the fact that it's a line that contains *only* a single line comment and no actual code. It does not seem worth investigating this in too much detail. In any case, these do not conform to our usual practices, so fix them. Author: Justin Pryzby Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a00fd066b1b632e675bae74841a87de1ffc1cd33 Modified Files -- src/backend/storage/file/fd.c | 2 +- src/include/replication/message.h | 2 +- src/include/tsearch/ts_type.h | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-)
pgsql: pageinspect: Fix handling of all-zero pages
pageinspect: Fix handling of all-zero pages Getting from get_raw_page() an all-zero page is considered as a valid case by the buffer manager and it can happen for example when finding a corrupted page with zero_damaged_pages enabled (using zero_damaged_pages to look at corrupted pages happens), or after a crash when a relation file is extended before any WAL for its new data is generated (before a vacuum or autovacuum job comes in to do some cleanup). However, all the functions of pageinspect, as of the index AMs (except hash that has its own idea of new pages), heap, the FSM or the page header have never worked with all-zero pages, causing various crashes when going through the page internals. This commit changes all the pageinspect functions to be compliant with all-zero pages, where the choice is made to return NULL or no rows for SRFs when finding a new page. get_raw_page() still works the same way, returning a batch of zeros in the bytea of the page retrieved. A hard error could be used but NULL, while more invasive, is useful when scanning relation files in full to get a batch of results for a single relation in one query. Tests are added for all the code paths impacted. Reported-by: Daria Lepikhova Author: Michael Paquier Discussion: https://postgr.es/m/[email protected] Backpatch-through: 10 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5378d55cb2f38eed4a7423cd3aa16d9de80b5313 Modified Files -- contrib/pageinspect/brinfuncs.c| 22 ++ contrib/pageinspect/btreefuncs.c | 6 ++ contrib/pageinspect/expected/brin.out | 25 + contrib/pageinspect/expected/btree.out | 6 ++ contrib/pageinspect/expected/gin.out | 14 ++ contrib/pageinspect/expected/hash.out | 12 contrib/pageinspect/expected/page.out | 20 contrib/pageinspect/fsmfuncs.c | 4 contrib/pageinspect/ginfuncs.c | 12 contrib/pageinspect/rawpage.c | 3 +++ contrib/pageinspect/sql/brin.sql | 7 +++ contrib/pageinspect/sql/btree.sql | 4 contrib/pageinspect/sql/gin.sql| 6 ++ contrib/pageinspect/sql/hash.sql | 7 +++ contrib/pageinspect/sql/page.sql | 6 ++ 15 files changed, 154 insertions(+)
pgsql: pageinspect: Fix handling of all-zero pages
pageinspect: Fix handling of all-zero pages Getting from get_raw_page() an all-zero page is considered as a valid case by the buffer manager and it can happen for example when finding a corrupted page with zero_damaged_pages enabled (using zero_damaged_pages to look at corrupted pages happens), or after a crash when a relation file is extended before any WAL for its new data is generated (before a vacuum or autovacuum job comes in to do some cleanup). However, all the functions of pageinspect, as of the index AMs (except hash that has its own idea of new pages), heap, the FSM or the page header have never worked with all-zero pages, causing various crashes when going through the page internals. This commit changes all the pageinspect functions to be compliant with all-zero pages, where the choice is made to return NULL or no rows for SRFs when finding a new page. get_raw_page() still works the same way, returning a batch of zeros in the bytea of the page retrieved. A hard error could be used but NULL, while more invasive, is useful when scanning relation files in full to get a batch of results for a single relation in one query. Tests are added for all the code paths impacted. Reported-by: Daria Lepikhova Author: Michael Paquier Discussion: https://postgr.es/m/[email protected] Backpatch-through: 10 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/cd4868a5700fadf5a840d44686658517433b338c Modified Files -- contrib/pageinspect/brinfuncs.c| 22 ++ contrib/pageinspect/btreefuncs.c | 6 ++ contrib/pageinspect/expected/brin.out | 25 + contrib/pageinspect/expected/btree.out | 6 ++ contrib/pageinspect/expected/gin.out | 14 ++ contrib/pageinspect/expected/gist.out | 18 ++ contrib/pageinspect/expected/hash.out | 12 contrib/pageinspect/expected/page.out | 20 contrib/pageinspect/fsmfuncs.c | 4 contrib/pageinspect/ginfuncs.c | 13 + contrib/pageinspect/gistfuncs.c| 12 contrib/pageinspect/rawpage.c | 3 +++ contrib/pageinspect/sql/brin.sql | 7 +++ contrib/pageinspect/sql/btree.sql | 4 contrib/pageinspect/sql/gin.sql| 6 ++ contrib/pageinspect/sql/gist.sql | 6 ++ contrib/pageinspect/sql/hash.sql | 7 +++ contrib/pageinspect/sql/page.sql | 6 ++ 18 files changed, 191 insertions(+)
pgsql: pageinspect: Fix handling of all-zero pages
pageinspect: Fix handling of all-zero pages Getting from get_raw_page() an all-zero page is considered as a valid case by the buffer manager and it can happen for example when finding a corrupted page with zero_damaged_pages enabled (using zero_damaged_pages to look at corrupted pages happens), or after a crash when a relation file is extended before any WAL for its new data is generated (before a vacuum or autovacuum job comes in to do some cleanup). However, all the functions of pageinspect, as of the index AMs (except hash that has its own idea of new pages), heap, the FSM or the page header have never worked with all-zero pages, causing various crashes when going through the page internals. This commit changes all the pageinspect functions to be compliant with all-zero pages, where the choice is made to return NULL or no rows for SRFs when finding a new page. get_raw_page() still works the same way, returning a batch of zeros in the bytea of the page retrieved. A hard error could be used but NULL, while more invasive, is useful when scanning relation files in full to get a batch of results for a single relation in one query. Tests are added for all the code paths impacted. Reported-by: Daria Lepikhova Author: Michael Paquier Discussion: https://postgr.es/m/[email protected] Backpatch-through: 10 Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/12d32b7bc15183be063516732d7458c58e2d2156 Modified Files -- contrib/pageinspect/brinfuncs.c| 22 ++ contrib/pageinspect/btreefuncs.c | 6 ++ contrib/pageinspect/expected/brin.out | 25 + contrib/pageinspect/expected/btree.out | 6 ++ contrib/pageinspect/expected/gin.out | 14 ++ contrib/pageinspect/expected/hash.out | 12 contrib/pageinspect/expected/page.out | 20 contrib/pageinspect/fsmfuncs.c | 4 contrib/pageinspect/ginfuncs.c | 12 contrib/pageinspect/rawpage.c | 3 +++ contrib/pageinspect/sql/brin.sql | 7 +++ contrib/pageinspect/sql/btree.sql | 4 contrib/pageinspect/sql/gin.sql| 6 ++ contrib/pageinspect/sql/hash.sql | 7 +++ contrib/pageinspect/sql/page.sql | 6 ++ 15 files changed, 154 insertions(+)
pgsql: pageinspect: Fix handling of all-zero pages
pageinspect: Fix handling of all-zero pages Getting from get_raw_page() an all-zero page is considered as a valid case by the buffer manager and it can happen for example when finding a corrupted page with zero_damaged_pages enabled (using zero_damaged_pages to look at corrupted pages happens), or after a crash when a relation file is extended before any WAL for its new data is generated (before a vacuum or autovacuum job comes in to do some cleanup). However, all the functions of pageinspect, as of the index AMs (except hash that has its own idea of new pages), heap, the FSM or the page header have never worked with all-zero pages, causing various crashes when going through the page internals. This commit changes all the pageinspect functions to be compliant with all-zero pages, where the choice is made to return NULL or no rows for SRFs when finding a new page. get_raw_page() still works the same way, returning a batch of zeros in the bytea of the page retrieved. A hard error could be used but NULL, while more invasive, is useful when scanning relation files in full to get a batch of results for a single relation in one query. Tests are added for all the code paths impacted. Reported-by: Daria Lepikhova Author: Michael Paquier Discussion: https://postgr.es/m/[email protected] Backpatch-through: 10 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2275d044d0849251c5e0fa10ee16c73124731f5c Modified Files -- contrib/pageinspect/brinfuncs.c| 22 ++ contrib/pageinspect/btreefuncs.c | 6 ++ contrib/pageinspect/expected/brin.out | 25 + contrib/pageinspect/expected/btree.out | 6 ++ contrib/pageinspect/expected/gin.out | 14 ++ contrib/pageinspect/expected/hash.out | 12 contrib/pageinspect/expected/page.out | 20 contrib/pageinspect/fsmfuncs.c | 4 contrib/pageinspect/ginfuncs.c | 12 contrib/pageinspect/rawpage.c | 3 +++ contrib/pageinspect/sql/brin.sql | 7 +++ contrib/pageinspect/sql/btree.sql | 4 contrib/pageinspect/sql/gin.sql| 6 ++ contrib/pageinspect/sql/hash.sql | 7 +++ contrib/pageinspect/sql/page.sql | 6 ++ 15 files changed, 154 insertions(+)
pgsql: pageinspect: Fix handling of all-zero pages
pageinspect: Fix handling of all-zero pages Getting from get_raw_page() an all-zero page is considered as a valid case by the buffer manager and it can happen for example when finding a corrupted page with zero_damaged_pages enabled (using zero_damaged_pages to look at corrupted pages happens), or after a crash when a relation file is extended before any WAL for its new data is generated (before a vacuum or autovacuum job comes in to do some cleanup). However, all the functions of pageinspect, as of the index AMs (except hash that has its own idea of new pages), heap, the FSM or the page header have never worked with all-zero pages, causing various crashes when going through the page internals. This commit changes all the pageinspect functions to be compliant with all-zero pages, where the choice is made to return NULL or no rows for SRFs when finding a new page. get_raw_page() still works the same way, returning a batch of zeros in the bytea of the page retrieved. A hard error could be used but NULL, while more invasive, is useful when scanning relation files in full to get a batch of results for a single relation in one query. Tests are added for all the code paths impacted. Reported-by: Daria Lepikhova Author: Michael Paquier Discussion: https://postgr.es/m/[email protected] Backpatch-through: 10 Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/79fed072ba5f96a8136053d20c8d74e0d59fe0e3 Modified Files -- contrib/pageinspect/brinfuncs.c| 22 ++ contrib/pageinspect/btreefuncs.c | 6 ++ contrib/pageinspect/expected/brin.out | 25 + contrib/pageinspect/expected/btree.out | 6 ++ contrib/pageinspect/expected/gin.out | 14 ++ contrib/pageinspect/expected/hash.out | 12 contrib/pageinspect/expected/page.out | 20 contrib/pageinspect/fsmfuncs.c | 4 contrib/pageinspect/ginfuncs.c | 12 contrib/pageinspect/rawpage.c | 3 +++ contrib/pageinspect/sql/brin.sql | 7 +++ contrib/pageinspect/sql/btree.sql | 4 contrib/pageinspect/sql/gin.sql| 6 ++ contrib/pageinspect/sql/hash.sql | 7 +++ contrib/pageinspect/sql/page.sql | 6 ++ 15 files changed, 154 insertions(+)
pgsql: pageinspect: Fix handling of all-zero pages
pageinspect: Fix handling of all-zero pages Getting from get_raw_page() an all-zero page is considered as a valid case by the buffer manager and it can happen for example when finding a corrupted page with zero_damaged_pages enabled (using zero_damaged_pages to look at corrupted pages happens), or after a crash when a relation file is extended before any WAL for its new data is generated (before a vacuum or autovacuum job comes in to do some cleanup). However, all the functions of pageinspect, as of the index AMs (except hash that has its own idea of new pages), heap, the FSM or the page header have never worked with all-zero pages, causing various crashes when going through the page internals. This commit changes all the pageinspect functions to be compliant with all-zero pages, where the choice is made to return NULL or no rows for SRFs when finding a new page. get_raw_page() still works the same way, returning a batch of zeros in the bytea of the page retrieved. A hard error could be used but NULL, while more invasive, is useful when scanning relation files in full to get a batch of results for a single relation in one query. Tests are added for all the code paths impacted. Reported-by: Daria Lepikhova Author: Michael Paquier Discussion: https://postgr.es/m/[email protected] Backpatch-through: 10 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/df6bbe73b86cda28472b9ecc61ac2deff5b2837b Modified Files -- contrib/pageinspect/brinfuncs.c| 22 ++ contrib/pageinspect/btreefuncs.c | 6 ++ contrib/pageinspect/expected/brin.out | 25 + contrib/pageinspect/expected/btree.out | 6 ++ contrib/pageinspect/expected/gin.out | 14 ++ contrib/pageinspect/expected/gist.out | 18 ++ contrib/pageinspect/expected/hash.out | 12 contrib/pageinspect/expected/page.out | 20 contrib/pageinspect/fsmfuncs.c | 4 contrib/pageinspect/ginfuncs.c | 12 contrib/pageinspect/gistfuncs.c| 12 contrib/pageinspect/rawpage.c | 3 +++ contrib/pageinspect/sql/brin.sql | 7 +++ contrib/pageinspect/sql/btree.sql | 4 contrib/pageinspect/sql/gin.sql| 6 ++ contrib/pageinspect/sql/gist.sql | 6 ++ contrib/pageinspect/sql/hash.sql | 7 +++ contrib/pageinspect/sql/page.sql | 6 ++ 18 files changed, 190 insertions(+)
