Re: pgsql: Harmonize reorderbuffer parameter names.

On Sat, Sep 17, 2022 at 10:00 PM Peter Geoghegan wrote: > I actually noticed that clang-tidy missed this one myself, shortly > after commit. I still haven't figured out why, but it seems like it > might be a bug in the readability-named-parameter check. Could also > have someth

pgsql: Harmonize missed reorderbuffer parameter names.

Harmonize missed reorderbuffer parameter names. The function ReorderBufferCommitChild() was overlooked by initial work from commit 035ce1fe. Author: Peter Geoghegan Discussion: https://postgr.es/m/cah2-wzkhzfesnro+vagqyezuzc33dw09bdzbvmw896sa22c...@mail.gmail.com Branch -- master Details

Re: pgsql: Harmonize reorderbuffer parameter names.

some false negatives. I 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 Transactio

pgsql: Consistently use named parameters in regex code.

w Postgres coding standards. 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/bc2187ed63c56bb9cd99f6613f3e2b

pgsql: Consistently use named parameters in timezone code.

ollow Postgres coding standards. The value of having a consistent standard everywhere seems to outweigh the cost of keeping the function declarations in sync with future IANA releases. Author: Peter Geoghegan Reviewed-By: David Rowley Discussion: https://postgr.es/m

Re: pgsql: Consistently use named parameters in regex code.

On Mon, Sep 19, 2022 at 3:18 PM Tom Lane wrote: > Just scanning this quickly, it looks like you missed the ones > hidden behind #ifdef REG_DEBUG, eg dumpstate(). Ugh, yeah. I did manage to catch some of them -- but not all of them. Will address this with a follow-up commit shortly. --

pgsql: Consistently use named parameters in regex code consistently.

Consistently use named parameters in regex code consistently. Adjust a handful of remaining function prototypes that were overlooked by recent commit bc2187ed. This oversight wasn't caught by clang-tidy because the functions in question are only built in custom REG_DEBUG builds. Author:

pgsql: Harmonize heapam and tableam parameter names.

from the same translation unit as a module. It will also make certain refactoring tasks easier. Like 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

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.

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: Fix recent cpluspluscheck issue in selfuncs.h.

: Peter Geoghegan Reported-By: Andres Freund Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/eccb607e19993483e25966abae895277599f77a2 Modified Files -- src/backend/utils/adt/selfuncs.c | 6 +++--- src/include/utils/selfuncs.h | 4 ++-- 2 files changed, 5

pgsql: Harmonize lexer adjacent function parameter names.

, but we can at least do this much. Author: Peter Geoghegan Discussion: https://postgr.es/m/cah2-wznjt9cmm9kjtmjjh_zbl5hd9ox44qdj4aqztjfi-za...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/aab06442d488364f8861219cb8864a16b6d0d4e4 Modified Files ---

pgsql: Harmonize parameter names in ecpg code.

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 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 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 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.

So 15 is the first version 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.

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

Re: pgsql: Avoid improbable PANIC during heap_update.

LL_VISIBLE without a cleanup lock on 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.

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 13

Re: pgsql: Avoid improbable PANIC during heap_update.

achine time) 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.

ing protective 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.

ection. Still, there has to be *some* reason why the bug could repro on 13. -- Peter Geoghegan

pgsql: Deduplicate freeze plans in freeze WAL records.

pe). They can be brought 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=xyter

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 -- src/backend/access/heap/hea

pgsql: Standardize rmgrdesc recovery conflict XID output.

tyle XID cutoff. 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 D

pgsql: Don't test HEAP_XMAX_INVALID when freezing xmax.

versight in bugfix 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 Geog

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: Refactor how VACUUM passes around its XID cutoffs.

where appropriate (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 -- mast

pgsql: Use scanned_pages to decide when to failsafe check.

ed-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.

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.

processing of multis that 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 Detai

pgsql: Avoid special XID snapshotConflictHorizon values.

, which 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.pos

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 stora

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: Delay commit status checks until freezing executes.

r multiple 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-wzkzpe4k6qmfet8h4qyjckc2r7tpvksbv

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: 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 bec

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

overy 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 ---

pgsql: Improve TransactionIdDidAbort() documentation.

de 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 ---

pgsql: Rename and relocate freeze plan dedup routines.

when 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 F

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: Tighten up VACUUM's approach to setting VM bits.

so there is no point 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.postg

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: https://postgr.es/m/os

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

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 how

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 certain.

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.

nt that that's possible. For example, 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: 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 Mo

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 af

pgsql: Show record information in pg_get_wal_block_info.

1c0 (where 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 HORIGU

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 Me

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

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 nbtr

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 deter

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 Geog

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

Re: pgsql: Try to unbreak MSVC builds for pg_waldump

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

Re: pgsql: Try to unbreak MSVC builds for pg_waldump

e could add something 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

pgsql: Fix nbtree posting list update desc output.

less 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/commi

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 --- https://git.postgresql.org/pg/commitdiff/

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

ld to "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 Bran

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

eld. 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=pNYtxiJ2Jx

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+mr3bm

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 fixed

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 Detail

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 --- https://git.postgresql.org/pg/commitdiff/06

pgsql: Fix wal_consistency_checking enhanced desc output.

d 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 Geog

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

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

why do you need to talk about something 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: 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 pr

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 int

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 int

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 int

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 int

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 int

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

ater backpatched as commit 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

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

ater backpatched as commit 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

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

ater backpatched as commit 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

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

ater backpatched as commit 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

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

ater backpatched as commit 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

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

ater backpatched as commit 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

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: Allocate new pages in separate function.

cal. GiST 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

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: Fix btmarkpos/btrestrpos array key wraparound bug.

during mark/restore processing, but missed this subtlety. That commit was itself a bug fix for an issue in commit 9e8da0f7, which taught nbtree to handle ScalarArrayOpExpr quals natively. Author: Peter Geoghegan Discussion: https://postgr.es/m/cah2-wzkgp3ddrjxw6dgjcxo-cu-dkrvjev_arkp2ctbjatd..

pgsql: Fix btmarkpos/btrestrpos array key wraparound bug.

during mark/restore processing, but missed this subtlety. That commit was itself a bug fix for an issue in commit 9e8da0f7, which taught nbtree to handle ScalarArrayOpExpr quals natively. Author: Peter Geoghegan Discussion: https://postgr.es/m/cah2-wzkgp3ddrjxw6dgjcxo-cu-dkrvjev_arkp2ctbjatd..

pgsql: Fix btmarkpos/btrestrpos array key wraparound bug.

during mark/restore processing, but missed this subtlety. That commit was itself a bug fix for an issue in commit 9e8da0f7, which taught nbtree to handle ScalarArrayOpExpr quals natively. Author: Peter Geoghegan Discussion: https://postgr.es/m/cah2-wzkgp3ddrjxw6dgjcxo-cu-dkrvjev_arkp2ctbjatd..

pgsql: Fix btmarkpos/btrestrpos array key wraparound bug.

during mark/restore processing, but missed this subtlety. That commit was itself a bug fix for an issue in commit 9e8da0f7, which taught nbtree to handle ScalarArrayOpExpr quals natively. Author: Peter Geoghegan Discussion: https://postgr.es/m/cah2-wzkgp3ddrjxw6dgjcxo-cu-dkrvjev_arkp2ctbjatd..

pgsql: Fix btmarkpos/btrestrpos array key wraparound bug.

during mark/restore processing, but missed this subtlety. That commit was itself a bug fix for an issue in commit 9e8da0f7, which taught nbtree to handle ScalarArrayOpExpr quals natively. Author: Peter Geoghegan Discussion: https://postgr.es/m/cah2-wzkgp3ddrjxw6dgjcxo-cu-dkrvjev_arkp2ctbjatd..

<    2   3   4   5   6   7   8   9   >