Re: pgsql: Harmonize reorderbuffer parameter names.

don't see any evidence of that so far, barring this issue with unnamed parameter checking. -- Peter Geoghegan

Re: pgsql: Harmonize reorderbuffer parameter names.

On Sun, Sep 18, 2022 at 2:14 PM Peter Geoghegan wrote: > One further caveat here is that I seem to need to set "IgnoreMacros: > false" to get perfect results for the "inconsistent" check when the C > preprocessor is involved, as it often is (e.g., with Trans

pgsql: Harmonize parameter names in contrib code.

. Author: Peter Geoghegan Discussion: https://postgr.es/m/cah2-wznjt9cmm9kjtmjjh_zbl5hd9ox44qdj4aqztjfi-za...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0faf7d933f625eb1668dcaa518b472f722b53a55 Modified Files -- contrib/amcheck

pgsql: Harmonize more lexer function parameter names.

Harmonize more lexer function parameter names. Make sure that function declarations use names that exactly match the corresponding names from function definitions for several "lexer adjacent" backend functions. These were missed by commit aab06442. Author: Peter Geoghegan Discussi

pgsql: Harmonize parameter names in ecpg code.

was written with help from clang-tidy. Author: Peter Geoghegan Reviewed-By: David Rowley Discussion: https://postgr.es/m/cah2-wznjt9cmm9kjtmjjh_zbl5hd9ox44qdj4aqztjfi-za...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff

pgsql: Harmonize parameter names in storage and AM code.

other recent commits that cleaned up function parameter names, this commit was written with help from clang-tidy. Later commits will do the same for other parts of the codebase. Author: Peter Geoghegan Reviewed-By: David Rowley Discussion: https://postgr.es/m/cah2

pgsql: Harmonize more parameter names in bulk.

de related to frontend programs (with the exception of pg_dump/pg_dumpall related code). Like other recent commits that cleaned up function parameter names, this commit was written with help from clang-tidy. Later commits will handle ecpg and pg_dump/pg_dumpall. Author: Peter Geoghegan Reviewed-By: Da

Re: pgsql: Harmonize more parameter names in bulk.

On Tue, Sep 20, 2022 at 1:47 PM Andres Freund wrote: > This seems to have broken cpluspluscheck: > > https://cirrus-ci.com/task/5694996828389376 Oops. Will fix that now. -- Peter Geoghegan

pgsql: Harmonize parameter names in pg_dump/pg_dumpall.

recent commits that cleaned up function parameter names, this commit was written with help from clang-tidy. Author: Peter Geoghegan Reviewed-By: Tom Lane Discussion: https://postgr.es/m/cah2-wzmma+vzco6gr5nydz+sx0g14au-urzfutt2foraisv...@mail.gmail.com Branch -- master Details --- https

Re: pgsql: Avoid improbable PANIC during heap_update.

e) into it. It literally took weeks of adversarial stress-testing to find the bug. It's entirely possible and perhaps likely that this isn't representative of real world conditions in some crucial way. -- Peter Geoghegan

Re: pgsql: Avoid improbable PANIC during heap_update.

rotective about how the loop would work in heap_update(), but perhaps that's not true. It might just be that heap_update() does lots of stuff in between, so it's less likely to be affected by this particular race (the race which seems to be present in all versions). -- Peter Geoghegan

Re: pgsql: Avoid improbable PANIC during heap_update.

On Fri, Sep 30, 2022 at 6:29 PM Peter Geoghegan wrote: > I talked to Robins about this privately. I was wrong; there isn't a > simple or boring explanation. I think that I figured it out. With or without bugfix commit 163b0993, we do these steps early in heap_delete() (this is 1

Re: pgsql: Avoid improbable PANIC during heap_update.

to be *some* reason why the bug could repro on 13. -- Peter Geoghegan

Re: pgsql: Avoid improbable PANIC during heap_update.

n v13 be a mystery at all? Why wouldn't a simple grep get to the bottom of it? I have to imagine that the true explanation is very simple and boring. -- Peter Geoghegan

Re: pgsql: Avoid improbable PANIC during heap_update.

On Fri, Sep 30, 2022 at 5:09 PM Peter Geoghegan wrote: > In any case we cannot really treat the information that we have about > that as a bug report -- not as things stand. Why should the question > of whether or not we ever set a page PD_ALL_VISIBLE without a cleanup > lock on v13

Re: pgsql: Avoid improbable PANIC during heap_update.

ersion that doesn't need a cleanup lock in either the first heap pass or the second heap pass to be able to set the heap page all-visible. That difference seems like it could be "protective" on 14, especially when vacuuming smaller tables. -- Peter Geoghegan

Re: pgsql: Avoid improbable PANIC during heap_update.

Nonetheless, > I'm inclined to backpatch to v12 as 34f581c39 was. +1 -- Peter Geoghegan

pgsql: Fix nbtree maximum item size macro.

ates to exactly the same value as before in practice. But it no longer depends on the current layout of nbtree's special area struct. No backpatch, since this isn't a live bug. Author: Peter Geoghegan Reported-By: Robert Haas Diagnosed-By: Robert Haas Discussion: https://postgr.es/m/CA+Tgmoa

pgsql: Add another old commit to git-blame-ignore-revs.

Add another old commit to git-blame-ignore-revs. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/bc76f5ac483a08fe2a699ce82d31a9a07520d502 Modified Files -- .git-blame-ignore-revs | 3 +++ 1 file changed, 3 insertions(+)

pgsql: Add missing parenthesis to max item size macro.

Add missing parenthesis to max item size macro. Oversight in commit 92f37505, per buildfarm. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b2fe783aecadb42e17868787bb45aa6328796d2a Modified Files -- src/backend/access/nbtree/nbtdedup.c | 3 +++

pgsql: Fix comments about deduplication updating page.

Fix comments about deduplication updating page. nbtree deduplication passes add tuples from the original/target page to a temp page, merging as necessary. The temp page is copied back to the target permanent page in the critical section. This is similar to the approach taken by nbtree page

pgsql: Refactor how VACUUM passes around its XID cutoffs.

ate (where heap_prepare_freeze_tuple sees a tuple that happens to contain a MultiXactId in its xmax). Author: Peter Geoghegan Reviewed-By: Jeff Davis Discussion: https://postgr.es/m/CAH2-WznS9TxXmz2_=SY+SyJyDFbiOftKofM9=ado68bbxnb...@mail.gmail.com Branch -- master Details ---

pgsql: Use scanned_pages to decide when to failsafe check.

-By: Peter Geoghegan Discussion: https://postgr.es/m/401CE010-4049-4B94-9961-0B610A5D254D%40amazon.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/07eef53955ea9885dd3e4701b7eaa34ccdf2ae02 Modified Files -- src/backend/access/heap/vacuumlazy.c | 9

pgsql: Remove overzealous MultiXact freeze assertion.

OldestMxact. Oversight in commit 4ce3af. Author: Peter Geoghegan Reported-By: Hayato Kuroda Discussion: https://postgr.es/m/tyapr01mb5866b24104fd80b5d7e65c3ef5...@tyapr01mb5866.jpnprd01.prod.outlook.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff

pgsql: Add page-level freezing to VACUUM.

page-level freezing might otherwise cause. Author: Peter Geoghegan Reviewed-By: Jeff Davis Reviewed-By: Andres Freund Discussion: https://postgr.es/m/CAH2-WzkFok_6EAHuK39GaW4FjEFQsY=3j0aad6fxk93u-xq...@mail.gmail.com Branch -- master Details --- https://git.po

pgsql: Adjust VACUUM hastup LP_REDIRECT comments.

Adjust VACUUM hastup LP_REDIRECT comments. The term "truncation" has been ambiguous since commit 10a8d13823 added line pointer array truncation during heap pruning. Clear things up by specifying that we're talking about rel truncation here, to match nearby comments that apply to tuples with

pgsql: Avoid special XID snapshotConflictHorizon values.

is interpreted as "record definitely doesn't require a recovery conflict". Author: Peter Geoghegan Discussion: https://postgr.es/m/cah2-wznungszf8v6osgjac5aysb3cz6hw6mlm30x0d65cms...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/

pgsql: Refine the definition of page-level freezing.

over from commit 6daeeb1f. Author: Peter Geoghegan Reviewed-By: Jeff Davis Discussion: https://postgr.es/m/ebc857107fe3edd422ef8a65191ca4a8da568b9b.ca...@j-davis.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b37a0832396414e8469d4ee4daea33396bde39b0 Modi

pgsql: vacuumlazy.c: Save get_database_name() in vacrel.

vacuumlazy.c: Save get_database_name() in vacrel. This brings dbname strings in line with namespace and relation name strings. Author: Peter Geoghegan Discussion: https://postgr.es/m/cah2-wzkq1tku-ddnvngel870di3+cu1uto-7nw7xfdpve-x...@mail.gmail.com Branch -- master Details --- https

pgsql: Improve TransactionIdDidAbort() documentation.

in heapam_visibility.c (and a few other places) must observe. Follow-up to bugfix commit eb5ad4ff. Author: Peter Geoghegan Reviewed-By: Andres Freund Discussion: https://postgr.es/m/cah2-wzn4beeqgmauql3aj73ym9gaek-we4ngi7kjrjlztb+...@mail.gmail.com Branch -- master Details --- https

pgsql: vacuumlazy.c: Tweak local variable name.

vacuumlazy.c: Tweak local variable name. Make a local variable name consistent with the name from its WAL record. Extracted from a larger patch to deal with issues with how vacuumlazy.c sets pages all-frozen. Author: Peter Geoghegan Discussion: https://postgr.es/m/cah2

pgsql: Make lazy_vacuum_heap_rel match lazy_scan_heap.

Make lazy_vacuum_heap_rel match lazy_scan_heap. Make lazy_vacuum_heap_rel variable names match those from lazy_scan_heap where that makes sense. Extracted from a larger patch to deal with issues with how vacuumlazy.c sets pages all-frozen. Author: Peter Geoghegan Discussion: https://postgr.es

pgsql: Rename and relocate freeze plan dedup routines.

FREEZE_PAGE WAL records are built. The routines were initially placed next to (and followed the naming conventions of) conceptually related REDO routine code, but that scheme turned out to be kind of jarring when considered in a wider context. Author: Peter Geoghegan Reported-By: Andres Freund

pgsql: Delay commit status checks until freezing executes.

successive VACUUM operations scan the same pages and decide against freezing each time, which is a waste of cycles. Oversight in commit 1de58df4, which added page-level freezing. Author: Peter Geoghegan Discussion: https://postgr.es/m/cah2-wzkzpe4k6qmfet8h4qyjckc2r7tpvksbva7jc9w7igx

pgsql: Update obsolete multixact.c comments.

Update obsolete multixact.c comments. Commit 4f627f89 switched SLRU truncation for multixacts back to being a task performed during VACUUM, but missed some comments that continued to reference truncation happening as part of checkpointing. Update those comments now. Also update comments that

pgsql: Check that xmax didn't commit in freeze check.

completes. Go back to defensively verifying that xmax didn't commit instead. Oversight in commit 79d4bf4e. Author: Peter Geoghegan Reported-By: Andres Freund Discussion: https://postgr.es/m/20230104035636.hy5djyr2as4gb...@awork3.anarazel.de Branch -- master Details --- https

pgsql: Simplify vacuum_set_xid_limits() signature.

vacuumlazy.c caller. Author: Peter Geoghegan Discussion: https://postgr.es/m/CAH2-Wz=TE7gW5DgSahDkf0UEZigFGAoHNNN6EvSrdzC=kn+...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b6074846cebc33d752f1d9a66e5a9932f21ad177 Modified Files -- src

pgsql: Don't test HEAP_XMAX_INVALID when freezing xmax.

fix commit d2599ecf. There is no evidence that this ever led to incorrect behavior, so no backpatch. The worst consequence of this bug was that VACUUM could hypothetically fail to notice and report on certain kinds of corruption, which seems fairly benign. Author: Peter Geoghegan Discussi

pgsql: Use correct type name in comments about freezing.

Use correct type name in comments about freezing. Oversight in commit 9e540599, which added freeze plan deduplication. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/813492dacceecb752725b7e370ac7f5748b1edf9 Modified Files --

pgsql: Deduplicate freeze plans in freeze WAL records.

into line by later work that totally standardizes how the cutoffs are presented. Bump XLOG_PAGE_MAGIC. Author: Peter Geoghegan Reviewed-By: Masahiko Sawada Reviewed-By: Nathan Bossart Reviewed-By: Justin Pryzby Discussion: https://postgr.es/m/CAH2-Wz=xytermnb8fayfd+oqebiipb0q2fmfd

pgsql: Standardize rmgrdesc recovery conflict XID output.

. No bump in XLOG_PAGE_MAGIC, since the underlying format of affected WAL records doesn't change. Author: Peter Geoghegan Reviewed-By: Andres Freund Discussion: https://postgr.es/m/CAH2-Wzm2CQUmViUq7Opgk=mcvrehsooryaajr1zplykrn7_...@mail.gmail.com Branch -- master Details --- https

pgsql: Tighten up VACUUM's approach to setting VM bits.

int in reading the VM when it is set like this. Author: Peter Geoghegan Reviewed-By: Andres Freund Discussion: https://postgr.es/m/cah2-wznungszf8v6osgjac5aysb3cz6hw6mlm30x0d65cms...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitd

pgsql: Update more obsolete multixact.c comments.

Update more obsolete multixact.c comments. Update some remaining comments in multixact.c that still described SLRU truncation as happening in the checkpointer, rather than during VACUUM. Follow-up to commit 5212d447. Shi yu, with tweaks by me. Author: Shi yu Discussion:

pgsql: Add eager and lazy freezing strategies to VACUUM.

. This is a relatively low setting that prioritizes performance stability. It will be reviewed at the end of the Postgres 16 beta period. Author: Peter Geoghegan Reviewed-By: Jeff Davis Reviewed-By: Andres Freund Reviewed-By: Matthias van de Meent Discussion: https://postgr.es/m/CAH2

pgsql: Doc: update VACUUM VERBOSE freezing tip.

Doc: update VACUUM VERBOSE freezing tip. VACUUM VERBOSE/autovacuuming logging have reported on the number of pages frozen by VACUUM since commit d977ffd9 added that capability. This information is directly related to relfrozenxid advancement, so update an older tip from the documentation about

pgsql: Revert "Add eager and lazy freezing strategies to VACUUM."

Revert "Add eager and lazy freezing strategies to VACUUM." This reverts commit 4d417992613949af35530b4e8e83670c4e67e1b2. Broad concerns about regressions caused by eager freezing strategy have been raised. Whether or not these concerns can be worked through in any time frame is far from

pgsql: Count updates that move row to a new page.

Huinker Reviewed-By: Peter Geoghegan Reviewed-By: Andres Freund Discussion: https://postgr.es/m/CADkLM=ded21M9iZ36hHm-vj2rE2d=zckpuqmds__xm2pxlf...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ae4fdde1352fa6b2c9123e91435efafc78c370a0 Modified Files

Re: pgsql: amcheck: Fix verify_heapam for tuples where xmin or xmax is 0.

e, such a tuple can't be a heap-only tuple, and it can't have any xmax value other than InvalidTransactionId/zero. -- Peter Geoghegan

pgsql: Fix incorrect comment about nbtree WAL record.

Fix incorrect comment about nbtree WAL record. The nbtree VACUUM WAL record stores its page offset number payload in blk 0 (just like the closely related nbtree DELETE WAL record). Commit ebd551f5 fixed a similar issue with the DELETE WAL record, but missed this one. Branch -- master

pgsql: Remove useless argument from nbtree dedup function.

Remove useless argument from nbtree dedup function. _bt_dedup_pass()'s heapRel argument hasn't been needed or used since commit cf2acaf4dc made deleting any existing LP_DEAD index tuples the caller's responsibility. Branch -- master Details ---

Re: pgsql: doc: add transaction processing chapter with internals info

that VACUUM does that is (in part) needed to avoid storing an epoch inside every tuple header? The on-disk XIDs in tuple headers *don't* ever wraparound -- they get frozen (or maybe in extreme cases they prevent new XIDs from being allocated and creating confusion about the past and the future). -- Peter Geoghegan

pgsql: Use nbtdesc "level" field name consistently.

Use nbtdesc "level" field name consistently. The "lev" name that appeared in NEWROOT nbtree record desc output was inconsistent with the symbol name from the underlying C struct. It was also inconsistent with nbtdesc output for other nearby record types with similar level fields. Standardize on

pgsql: Fix wal_consistency_checking enhanced desc output.

for consistency checking purposes only). The presence of such an FPI was incorrectly taken to indicate the absence of block data. To fix, test DecodedBkpBlock.has_data, not !DecodedBkpBlock.has_image. This is the exact condition that we care about, not an inexact proxy. Author: Peter Geoghegan

pgsql: Fix recent pg_walinspect fpi_length bug.

Fix recent pg_walinspect fpi_length bug. Commit 0276ae42dd taught pg_walinspect's pg_get_wal_record_info() function to output NULLs rather than empty strings for its record description and block_ref output parameters. However, it inadvertently moved the function call that sets fpi_length until

pgsql: Show record information in pg_get_wal_block_info.

it first appeared under the name pg_get_wal_fpi_info). There still hasn't been a stable release since commit c31cf1c0, so no bump in the pg_walinspect extension version. Author: Bharath Rupireddy Author: Peter Geoghegan Reviewed-By: Peter Geoghegan Reviewed-By: Kyotaro HORIGUCHI Discussion

pgsql: Add show_data option to pg_get_wal_block_info.

re feasible with all queries that don't specifically require these raw binary strings. Follow-up to recent work in commit 122376f0. There still hasn't been a stable release with the pg_get_wal_block_info function, so no bump in the pg_walinspect extension version. Per suggestion from Melanie Plag

pgsql: Move heaprel struct field next to index rel field.

Move heaprel struct field next to index rel field. Commit 61b313e4 added a heaprel struct member to IndexVacuumInfo, but placed it last. Move the heaprel struct member next to the index struct member to improve the code's readability. Author: Peter Geoghegan Discussion: https://postgr.es/m

pgsql: Recycle deleted nbtree pages more aggressively.

Recycle deleted nbtree pages more aggressively. Commit 61b313e4 made nbtree consistently pass down a heaprel to low level routines like _bt_getbuf(). Although this was primarily intended as preparation for logical decoding on standbys, it also made it easy to correct an old deficiency in how

pgsql: Make SP-GiST redirect cleanup more aggressive.

Make SP-GiST redirect cleanup more aggressive. Commit 61b313e4 made VACUUM pass down a heaprel to index AM bulkdelete and vacuumcleanup routines. Although this was primarily intended as preparation for logical decoding on standbys, it also made it easy to correct an old deficiency in how we

pgsql: Show more detail in nbtree rmgr descriptions.

Show more detail in nbtree rmgr descriptions. Show a detailed description of the page offset number arrays that appear in certain nbtree WAL records. Also brings nbtree desc routines in line with the guidelines established by recent commit 7d8219a4. Author: Melanie Plageman Reviewed-By: Peter

pgsql: Show more detail in heapam rmgr descriptions.

(unless there was an FPI). Also document the conventions that desc routines should follow. Only the heapdesc routines follow the conventions for now, so they're just guidelines for the time being. Based on a suggestion from Andres Freund. Author: Melanie Plageman Reviewed-By: Peter Geoghegan

Re: pgsql: Try to unbreak MSVC builds for pg_waldump

hing akin to the existing CompilerWarnings target. Something that's purely intended to detect these kinds of oversights. Even that seems excessive to me, though. I hope that we can just get rid of the scripts before long. -- Peter Geoghegan

Re: pgsql: Try to unbreak MSVC builds for pg_waldump

ut that's no longer the case -- not since commit e6b6ea02. I'll need to remember that. -- Peter Geoghegan

pgsql: Fix nbtree posting list update desc output.

verbose. Oversight in commit 1c453cfd, which enhanced the nbtree rmgr desc routines. Author: Peter Geoghegan Discussion: https://postgr.es/m/cah2-wzkbyuvwykm-y-72qeh6spmqcao9uonv+mr3bmgcu9e...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff

pgsql: Clarify nbtree posting list update desc issue.

Clarify nbtree posting list update desc issue. Per complaint from Melanie Plageman. Follow-up to commit 5d6728e5. Reported-By: Melanie Plageman Discussion: https://postgr.es/m/20230411002315.oyaicmcqrq2hb3ek@liskov Branch -- master Details ---

pgsql: Fix Heap rmgr's desc output for infobits arrays.

. This order also matches WAL record struct order. Heap's DELETE desc output now shows the record's xmax field for the first time (just like UPDATE/HOT_UPDATE records). Author: Peter Geoghegan Reviewed-By: Melanie Plageman Discussion: https://postgr.es/m/CAH2-Wz=pNYtxiJ2Jx5Lj=fko1oez4ge0p_kct

pgsql: Fix xl_heap_lock WAL record field's data type.

;xmax" to make things consistency with related records, such as xl_heap_lock_updated. Deliberately avoid a bump in XLOG_PAGE_MAGIC. No backpatch, either. Author: Peter Geoghegan Discussion: https://postgr.es/m/CAH2-WzkCd3kOS8b7Rfxw7Mh1_6jvX=nzo-cwr1vbtiotvzk...@mail.gmail.com Branch -- maste

pgsql: Refine the guidelines for rmgrdesc authors.

with a significant amount of leeway. This even includes the leeway to invent custom conventions (in cases where it's warranted). Follow-up to commit 7d8219a4. Author: Peter Geoghegan Reviewed-By: Melanie Plageman Discussion: https://postgr.es/m/cah2-wzkbyuvwykm-y-72qeh6spmqcao9uonv+mr3bmgcu9e

pgsql: pg_walinspect: Adjust memory context name.

pg_walinspect: Adjust memory context name. Correct the name of the memory context used by the pg_get_wal_block_info() SQL-callable function. Oversight in commit 9ecb134a93. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/637dce2254245321283ade9db1b7cc8d1f8cf308

pgsql: Harmonize some more function parameter names.

Harmonize some more function parameter names. Make sure that function declarations use names that exactly match the corresponding names from function definitions in a few places. These inconsistencies were all introduced relatively recently, after the code base had parameter name mismatches

pgsql: nbtree: Allocate new pages in separate function.

already took the same approach; it has a dedicated function for allocating new pages called gistNewBuffer(). That factor allowed commit 61b313e4 to make much more targeted changes to GiST. Author: Peter Geoghegan Reviewed-By: Heikki Linnakangas Discussion: https://postgr.es/m/CAH2-Wz

pgsql: Add another old commit to git-blame-ignore-revs.

Add another old commit to git-blame-ignore-revs. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/fe879ae3a8e0735ccb12a425e1cdbcedb2f4af81 Modified Files -- .git-blame-ignore-revs | 3 +++ 1 file changed, 3 insertions(+)

pgsql: nbtree VACUUM: cope with right sibling link corruption.

t 43e409ce), which taught nbtree to press on with vacuuming an index when page deletion fails to "re-find" a downlink in the target page's parent page. The "re-find" check seems to make VACUUM bail on page deletion more often in practice, but there is no reason to take an

pgsql: nbtree VACUUM: cope with right sibling link corruption.

t 43e409ce), which taught nbtree to press on with vacuuming an index when page deletion fails to "re-find" a downlink in the target page's parent page. The "re-find" check seems to make VACUUM bail on page deletion more often in practice, but there is no reason to take an

pgsql: nbtree VACUUM: cope with right sibling link corruption.

t 43e409ce), which taught nbtree to press on with vacuuming an index when page deletion fails to "re-find" a downlink in the target page's parent page. The "re-find" check seems to make VACUUM bail on page deletion more often in practice, but there is no reason to take an

pgsql: nbtree VACUUM: cope with right sibling link corruption.

t 43e409ce), which taught nbtree to press on with vacuuming an index when page deletion fails to "re-find" a downlink in the target page's parent page. The "re-find" check seems to make VACUUM bail on page deletion more often in practice, but there is no reason to take an

pgsql: nbtree VACUUM: cope with right sibling link corruption.

t 43e409ce), which taught nbtree to press on with vacuuming an index when page deletion fails to "re-find" a downlink in the target page's parent page. The "re-find" check seems to make VACUUM bail on page deletion more often in practice, but there is no reason to take an

pgsql: nbtree VACUUM: cope with right sibling link corruption.

t 43e409ce), which taught nbtree to press on with vacuuming an index when page deletion fails to "re-find" a downlink in the target page's parent page. The "re-find" check seems to make VACUUM bail on page deletion more often in practice, but there is no reason to take an

pgsql: nbtree VACUUM: cope with topparent inconsistencies.

y after the "re-find" check, right before the critical section for the first stage of page deletion. Author: Peter Geoghegan Discussion: https://postgr.es/m/CAH2-Wz=dayg0vjs4+er84TS9ami=csdzjpuiCGbEw=idhwq...@mail.gmail.com Backpatch: 11- (all supported versions). Branch --

pgsql: nbtree VACUUM: cope with topparent inconsistencies.

y after the "re-find" check, right before the critical section for the first stage of page deletion. Author: Peter Geoghegan Discussion: https://postgr.es/m/CAH2-Wz=dayg0vjs4+er84TS9ami=csdzjpuiCGbEw=idhwq...@mail.gmail.com Backpatch: 11- (all supported versions). Branch -- REL_11

pgsql: nbtree VACUUM: cope with topparent inconsistencies.

y after the "re-find" check, right before the critical section for the first stage of page deletion. Author: Peter Geoghegan Discussion: https://postgr.es/m/CAH2-Wz=dayg0vjs4+er84TS9ami=csdzjpuiCGbEw=idhwq...@mail.gmail.com Backpatch: 11- (all supported versions). Branch -- REL_15

pgsql: nbtree VACUUM: cope with topparent inconsistencies.

y after the "re-find" check, right before the critical section for the first stage of page deletion. Author: Peter Geoghegan Discussion: https://postgr.es/m/CAH2-Wz=dayg0vjs4+er84TS9ami=csdzjpuiCGbEw=idhwq...@mail.gmail.com Backpatch: 11- (all supported versions). Branch -- REL_13

pgsql: nbtree VACUUM: cope with topparent inconsistencies.

y after the "re-find" check, right before the critical section for the first stage of page deletion. Author: Peter Geoghegan Discussion: https://postgr.es/m/CAH2-Wz=dayg0vjs4+er84TS9ami=csdzjpuiCGbEw=idhwq...@mail.gmail.com Backpatch: 11- (all supported versions). Branch -- REL_12

pgsql: nbtree VACUUM: cope with topparent inconsistencies.

y after the "re-find" check, right before the critical section for the first stage of page deletion. Author: Peter Geoghegan Discussion: https://postgr.es/m/CAH2-Wz=dayg0vjs4+er84TS9ami=csdzjpuiCGbEw=idhwq...@mail.gmail.com Backpatch: 11- (all supported versions). Branch -- REL_14

pgsql: Doc: Fix link to fillfactor reloption.

Doc: Fix link to fillfactor reloption. Fix a link from the "Heap-Only Tuples" documentation section. Previously, its "fillfactor" link pointed to the "CREATE TABLE" command's documentation. Now the link directly points to the fillfactor storage parameter documentation (which is about half way

pgsql: Doc: Fix link to fillfactor reloption.

Doc: Fix link to fillfactor reloption. Fix a link from the "Heap-Only Tuples" documentation section. Previously, its "fillfactor" link pointed to the "CREATE TABLE" command's documentation. Now the link directly points to the fillfactor storage parameter documentation (which is about half way

pgsql: Doc: Fix link to fillfactor reloption.

Doc: Fix link to fillfactor reloption. Fix a link from the "Heap-Only Tuples" documentation section. Previously, its "fillfactor" link pointed to the "CREATE TABLE" command's documentation. Now the link directly points to the fillfactor storage parameter documentation (which is about half way

pgsql: Doc: Fix link to fillfactor reloption.

Doc: Fix link to fillfactor reloption. Fix a link from the "Heap-Only Tuples" documentation section. Previously, its "fillfactor" link pointed to the "CREATE TABLE" command's documentation. Now the link directly points to the fillfactor storage parameter documentation (which is about half way

pgsql: Doc: Fix link to fillfactor reloption.

Doc: Fix link to fillfactor reloption. Fix a link from the "Heap-Only Tuples" documentation section. Previously, its "fillfactor" link pointed to the "CREATE TABLE" command's documentation. Now the link directly points to the fillfactor storage parameter documentation (which is about half way

pgsql: Doc: update VACUUM FREEZE query conflict guidance.

Doc: update VACUUM FREEZE query conflict guidance. Commit 1de58df4, which added page-level freezing, taught VACUUM to reuse each page's "set-visibility-map" snapshotConflictHorizon for freezing (at least in the vast majority of cases where freezing went ahead). This made VACUUM FREEZE much less

pgsql: Fix nbtree backward scan race condition comments.

Fix nbtree backward scan race condition comments. Remove comments that supposed that holding a pin was a useful interlock for _bt_walk_left(). There are times when _bt_walk_left() doesn't hold either a lock or a pin on any page, so clearly this can't be true. _bt_walk_left() is even prepared to

pgsql: Optimize nbtree backward scan boundary cases.

viously, this isn't strictly necessary for these new cases (unlike VACUUM, _bt_first is prepared to move the scan to the left once on the leaf level), but the underlying principle is the same. Author: Peter Geoghegan Reviewed-By: Matthias van de Meent Discussion: https://postgr.es/m/CAH2-Wz=

pgsql: Update obsolete index scan TID comments.

Update obsolete index scan TID comments. Oversight in commit c2fe139c20. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/3045324214467dd3f0bef31f6f33562b9eb93aa3 Modified Files -- src/backend/access/hash/hashsearch.c | 6 +++---

pgsql: Avoid extra lookups with nbtree array inequalities.

Avoid extra lookups with nbtree array inequalities. nbtree index scans with SAOP inequalities (but no SAOP equalities) performed extra ORDER proc lookups for any remaining equality strategy scan keys. This could waste cycles, and caused assertion failures. Keeping around a separate ORDER proc is

pgsql: Remove redundant nbtree preprocessing assertions.

Remove redundant nbtree preprocessing assertions. One of the assertions was the subject of a false positive complaint from Coverity, but none of the assertions added much, so get rid of them. Reported-By: Tom Lane Discussion: https://postgr.es/m/3000247.1712537...@sss.pgh.pa.us Branch --

pgsql: Enhance nbtree ScalarArrayOp execution.

item about the issue to the Postgres 17 release notes seems like a good idea. Author: Peter Geoghegan Author: Matthias van de Meent Reviewed-By: Heikki Linnakangas Reviewed-By: Matthias van de Meent Reviewed-By: Tomas Vondra Discussion: https://postgr.es/m/CAH2-Wz=ksvn_sjcnd1+bt-wtifr

pgsql: Fix nbtree page recycling comment.

Fix nbtree page recycling comment. Oversight in commit e5d8a99903. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/aa1def44c301ce7fae9ae33f0a95bc01efa297a3 Modified Files -- src/include/access/nbtree.h | 2 +- 1 file changed, 1 insertion(+), 1

pgsql: Fix nbtree posting list comment.

Fix nbtree posting list comment. Oversight in commit 0d861bbb70. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f6987041557f2b2b96f116c1f3150f9ed9a77c89 Modified Files -- src/include/access/nbtree.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

pgsql: Don't try to fix eliminated nbtree array scan keys.

Don't try to fix eliminated nbtree array scan keys. Preprocessing for nbtree index scans allowed array "input" scan keys already marked eliminated during array-specific preprocessing to be "fixed up" during preprocessing proper. This allowed eliminated scan keys on DESC index columns to spurious

pgsql: Remove unneeded nbtree array preprocessing assert.

Remove unneeded nbtree array preprocessing assert. Certain cases involving the use of cursors had assertion failures within _bt_preprocess_keys's recently added no-op return path. The assertion in question made the faulty assumption that a second or third call to _bt_preprocess_keys (within the

<    2   3   4   5   6   7   8   >