[COMMITTERS] pgsql: Improve error message for incorrect number inputs in libecpg.
Improve error message for incorrect number inputs in libecpg. Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/90d61bd1d16bb51d9bbc07e2e345e49bed7310fe Modified Files -- src/interfaces/ecpg/ecpglib/data.c | 1 - 1 file changed, 1 deletion(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Improve error message for incorrect number inputs in libecpg.
Improve error message for incorrect number inputs in libecpg. Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/deb429b51ed37e5c069f5d1fd659244a29d3a769 Modified Files -- src/interfaces/ecpg/ecpglib/data.c | 1 - 1 file changed, 1 deletion(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Improve error message for incorrect number inputs in libecpg.
Improve error message for incorrect number inputs in libecpg. Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c63568b06edeece064771b8f170ef0298d8ab134 Modified Files -- src/interfaces/ecpg/ecpglib/data.c | 1 - 1 file changed, 1 deletion(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Improve error message for incorrect number inputs in libecpg.
Improve error message for incorrect number inputs in libecpg. Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/6cf68e223643203494292c2787b72a7353264c7d Modified Files -- src/interfaces/ecpg/ecpglib/data.c | 1 - 1 file changed, 1 deletion(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Improve error message for incorrect number inputs in libecpg.
Improve error message for incorrect number inputs in libecpg. Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/946f165182a2e643c18fa21b563dc3ccc0c9ada7 Modified Files -- src/interfaces/ecpg/ecpglib/data.c | 1 - 1 file changed, 1 deletion(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Improve error message for incorrect number inputs in libecpg.
Improve error message for incorrect number inputs in libecpg. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7164991caf3858cbd75e5efb7943e11a51ad04f9 Modified Files -- src/interfaces/ecpg/ecpglib/data.c | 1 - 1 file changed, 1 deletion(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Grammar typo in security warning about md5
Grammar typo in security warning about md5 Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0f6bd533341341de7007b6d5ed24742211471c68 Author: Simon Riggs Modified Files -- doc/src/sgml/client-auth.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple
On 2017-11-02 06:05:51 -0700, Andres Freund wrote: > Hi, > > On 2017-11-02 13:49:47 +0100, Alvaro Herrera wrote: > > Andres Freund wrote: > > > I think the problem is on the pruning, rather than the freezing side. We > > > can't freeze a tuple if it has an alive predecessor - rather than > > > weakining this, we should be fixing the pruning to not have the alive > > > predecessor. > > > > I gave a look at HTSV back then, but I didn't find what the right tweak > > was, but then I only tried changing the return value to DEAD and > > DELETE_IN_PROGRESS; the thought of selecting DEAD or RECENTLY_DEAD based > > on OldestXmin didn't occur to me ... I was thinking that the fact that > > there were live lockers meant that the tuple could not be removed, > > obviously failing to notice that the subsequent versions of the tuple > > would be good enough. > > I'll try to write up a commit based on that idea. I think there's some > comment work needed too, Robert and I were both confused by a few > things. > I'm unfortunately travelling atm - it's evening here, and I'll flying > back to the US all Saturday. I'm fairly sure I'll be able to come up > with a decent patch tomorrow, but I'll need review and testing by > others. Here's that patch. I've stared at this some, and Robert did too. Robert mentioned that the commit message might need some polish and I'm not 100% sure about the error message texts yet. I'm not yet convinced that the new elog in vacuumlazy can never trigger - but I also don't think we want to actually freeze the tuple in that case. Staring at the vacuumlazy hunk I think I might have found a related bug: heap_update_tuple() just copies the old xmax to the new tuple's xmax if a multixact and still running. It does so without verifying liveliness of members. Isn't that buggy? Consider what happens if we have three blocks: 1 has free space, two is being vacuumed and is locked, three is full and has a tuple that's key share locked by a live tuple and is updated by a dead xmax from before the xmin horizon. In that case afaict the multi will be copied from the third page to the first one. Which is quite bad, because vacuum already processed it, and we'll set relfrozenxid accordingly. I hope I'm missing something here? Greetings, Andres Freund >From 774376dc8f7ed76657660e6beb0f5191d1bdaae4 Mon Sep 17 00:00:00 2001 From: Andres Freund Date: Fri, 3 Nov 2017 07:52:29 -0700 Subject: [PATCH] Fix pruning of locked and updated tuples. Previously it was possible that a tuple was not pruned during vacuum, even though it's update xmax (i.e. the updating xid in a multixact with both key share lockers and an updater) was below the cutoff horizon. As the freezing code assumed, rightly so, that that's not supposed to happen, xmax would be preserved (as a member of a new multixact or xmax directly). That causes two problems: For one the tuple is below the xmin horizon, which can cause problems if the clog is truncated or once there's an xid wraparound. The bigger problem is that that will break HOT chains, leading to index lookups failing, which in turn can lead to constraints being violated. Fix the problem by recognizing that tuples can be DEAD instead of RECENTLY_DEAD, even if the multixactid has alive members, if the update_xid is below the xmin horizon. That's safe because newer versions of the tuple will contain the locking xids. As the wrong freezing of xmax can cause data corruption, extend sanity checks and promote them to elogs rather than assertions. Per-Discussion: Robert Haas and Freund Reported-By: Daniel Wood Discussion: https://postgr.es/m/[email protected] https://postgr.es/m/[email protected] --- src/backend/access/heap/heapam.c | 34 -- src/backend/commands/vacuumlazy.c | 13 + src/backend/utils/time/tqual.c| 53 +++ src/test/isolation/isolation_schedule | 1 + 4 files changed, 62 insertions(+), 39 deletions(-) diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c index 765750b8743..9b963e0cd0d 100644 --- a/src/backend/access/heap/heapam.c +++ b/src/backend/access/heap/heapam.c @@ -6412,7 +6412,8 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask, */ if (TransactionIdPrecedes(xid, cutoff_xid)) { -Assert(!TransactionIdDidCommit(xid)); +if (TransactionIdDidCommit(xid)) + elog(ERROR, "can't freeze committed xmax"); *flags |= FRM_INVALIDATE_XMAX; xid = InvalidTransactionId; /* not strictly necessary */ } @@ -6484,6 +6485,8 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask, { TransactionId xid = members[i].xid; + Assert(TransactionIdIsValid(xid)); + /* * It's an update; should we keep it? If the transaction is known * aborted or crashed then it's okay to ignore it, otherwise not. @@ -6512,18 +6515,24 @@ FreezeMultiXactId(MultiXactId multi
[COMMITTERS] pgsql: Fix BRIN summarization concurrent with extension
Fix BRIN summarization concurrent with extension If a process is extending a table concurrently with some BRIN summarization process, it is possible for the latter to miss pages added by the former because the number of pages is computed ahead of time. Fix by determining a fresh relation size after inserting the placeholder tuple: any process that further extends the table concurrently will update the placeholder tuple, while previous pages will be processed by the heap scan. Reported-by: Tomas Vondra Reviewed-by: Tom Lane Author: Álvaro Herrera Discussion: https://postgr.es/m/[email protected] Backpatch-to: 9.5 Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/bd8e2b3cf4cfe5f26ed314af662ef988b4cfad4b Modified Files -- src/backend/access/brin/brin.c | 57 -- 1 file changed, 49 insertions(+), 8 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix BRIN summarization concurrent with extension
Fix BRIN summarization concurrent with extension If a process is extending a table concurrently with some BRIN summarization process, it is possible for the latter to miss pages added by the former because the number of pages is computed ahead of time. Fix by determining a fresh relation size after inserting the placeholder tuple: any process that further extends the table concurrently will update the placeholder tuple, while previous pages will be processed by the heap scan. Reported-by: Tomas Vondra Reviewed-by: Tom Lane Author: Álvaro Herrera Discussion: https://postgr.es/m/[email protected] Backpatch-to: 9.5 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ec42a1dcb30de235b252f6d4972f2f2bdb2e47f2 Modified Files -- src/backend/access/brin/brin.c | 90 -- 1 file changed, 61 insertions(+), 29 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix BRIN summarization concurrent with extension
Fix BRIN summarization concurrent with extension If a process is extending a table concurrently with some BRIN summarization process, it is possible for the latter to miss pages added by the former because the number of pages is computed ahead of time. Fix by determining a fresh relation size after inserting the placeholder tuple: any process that further extends the table concurrently will update the placeholder tuple, while previous pages will be processed by the heap scan. Reported-by: Tomas Vondra Reviewed-by: Tom Lane Author: Álvaro Herrera Discussion: https://postgr.es/m/[email protected] Backpatch-to: 9.5 Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/cf0612aa2c8fdc54bb98a13ef839f43cef5eadc5 Modified Files -- src/backend/access/brin/brin.c | 57 -- 1 file changed, 49 insertions(+), 8 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix BRIN summarization concurrent with extension
Fix BRIN summarization concurrent with extension If a process is extending a table concurrently with some BRIN summarization process, it is possible for the latter to miss pages added by the former because the number of pages is computed ahead of time. Fix by determining a fresh relation size after inserting the placeholder tuple: any process that further extends the table concurrently will update the placeholder tuple, while previous pages will be processed by the heap scan. Reported-by: Tomas Vondra Reviewed-by: Tom Lane Author: Álvaro Herrera Discussion: https://postgr.es/m/[email protected] Backpatch-to: 9.5 Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/37a856567c04cf48d38292afc487be5f2665c2a5 Modified Files -- src/backend/access/brin/brin.c | 90 -- 1 file changed, 61 insertions(+), 29 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Don't reset additional columns on subscriber to NULL on UPDATE
Don't reset additional columns on subscriber to NULL on UPDATE When a publisher table has fewer columns than a subscriber, the update of a row on the publisher should result in updating of only the columns in common. The previous coding mistakenly reset the values of additional columns on the subscriber to NULL because it failed to skip updates of columns not found in the attribute map. Author: Petr Jelinek Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a14b52c61454e3d23f7d0ab0affa56f8abfdf505 Modified Files -- src/backend/replication/logical/worker.c | 7 ++- src/test/subscription/t/008_diff_schema.pl | 80 ++ 2 files changed, 85 insertions(+), 2 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Don't reset additional columns on subscriber to NULL on UPDATE
Don't reset additional columns on subscriber to NULL on UPDATE When a publisher table has fewer columns than a subscriber, the update of a row on the publisher should result in updating of only the columns in common. The previous coding mistakenly reset the values of additional columns on the subscriber to NULL because it failed to skip updates of columns not found in the attribute map. Author: Petr Jelinek Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a9fce66729ad5217e8219e22e595974059c21291 Modified Files -- src/backend/replication/logical/worker.c | 7 ++- src/test/subscription/t/008_diff_schema.pl | 80 ++ 2 files changed, 85 insertions(+), 2 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Fix BRIN summarization concurrent with extension
Alvaro Herrera writes: > Fix BRIN summarization concurrent with extension Buildfarm is entirely unhappy ... regards, tom lane -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: doc: Convert ids to upper case at build time
doc: Convert ids to upper case at build time This makes the produced HTML anchors upper case, making it backward compatible with the previous (9.6) build system. Reported-by: Thomas Kellerer Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5159626afbe969bdcb6623e9f75f79ecb13ec79c Modified Files -- doc/src/sgml/stylesheet-html-common.xsl | 25 + 1 file changed, 25 insertions(+) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: doc: Convert ids to upper case at build time
doc: Convert ids to upper case at build time This makes the produced HTML anchors upper case, making it backward compatible with the previous (9.6) build system. Reported-by: Thomas Kellerer Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/49df45acd8d40ee172c2f5491485de997c5f1020 Modified Files -- doc/src/sgml/stylesheet-html-common.xsl | 25 + 1 file changed, 25 insertions(+) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Fix BRIN summarization concurrent with extension
Tom Lane wrote: > Alvaro Herrera writes: > > Fix BRIN summarization concurrent with extension > > Buildfarm is entirely unhappy ... Will fix shortly. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple
Andres Freund wrote: Here's that patch. I've stared at this some, and Robert did too. Robert mentioned that the commit message might need some polish and I'm not 100% sure about the error message texts yet. The commit message should probably say that the bug involves the resurrection of previously dead tuples, which is different to there being duplicates because a constraint is not enforced because HOT chains are broken (that's a separate, arguably less serious problem). Staring at the vacuumlazy hunk I think I might have found a related bug: heap_update_tuple() just copies the old xmax to the new tuple's xmax if a multixact and still running. It does so without verifying liveliness of members. Isn't that buggy? Consider what happens if we have three blocks: 1 has free space, two is being vacuumed and is locked, three is full and has a tuple that's key share locked by a live tuple and is updated by a dead xmax from before the xmin horizon. In that case afaict the multi will be copied from the third page to the first one. Which is quite bad, because vacuum already processed it, and we'll set relfrozenxid accordingly. I hope I'm missing something here? Can you be more specific about what you mean here? I think that I understand where you're going with this, but I'm not sure. -- Peter Geoghegan -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple
Peter Geoghegan wrote: > Andres Freund wrote: > > Staring at the vacuumlazy hunk I think I might have found a related bug: > > heap_update_tuple() just copies the old xmax to the new tuple's xmax if > > a multixact and still running. It does so without verifying liveliness > > of members. Isn't that buggy? Consider what happens if we have three > > blocks: 1 has free space, two is being vacuumed and is locked, three is > > full and has a tuple that's key share locked by a live tuple and is > > updated by a dead xmax from before the xmin horizon. In that case afaict > > the multi will be copied from the third page to the first one. Which is > > quite bad, because vacuum already processed it, and we'll set > > relfrozenxid accordingly. I hope I'm missing something here? > > Can you be more specific about what you mean here? I think that I > understand where you're going with this, but I'm not sure. He means that the tuple that heap_update moves to page 1 (which will no longer be processed by vacuum) will contain a multixact that's older than relminmxid -- because it is copied unchanged by heap_update instead of properly checking against age limit. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix thinkos in BRIN summarization
Fix thinkos in BRIN summarization The previous commit contained a thinko that made a single-range summarization request process from there to end of table. Fix by setting the correct end range point. Per buildfarm. Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b17870d754665c4b431d3ce4de6676832a0b10a0 Modified Files -- src/backend/access/brin/brin.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix thinkos in BRIN summarization
Fix thinkos in BRIN summarization The previous commit contained a thinko that made a single-range summarization request process from there to end of table. Fix by setting the correct end range point. Per buildfarm. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/1b890562b8d1b44bd3ef948aeeb58dd59abd04b7 Modified Files -- src/backend/access/brin/brin.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple
Alvaro Herrera wrote: He means that the tuple that heap_update moves to page 1 (which will no longer be processed by vacuum) will contain a multixact that's older than relminmxid -- because it is copied unchanged by heap_update instead of properly checking against age limit. I see. The problem is more or less with this heap_update() code: /* * And also prepare an Xmax value for the new copy of the tuple. If there * was no xmax previously, or there was one but all lockers are now gone, * then use InvalidXid; otherwise, get the xmax from the old tuple. (In * rare cases that might also be InvalidXid and yet not have the * HEAP_XMAX_INVALID bit set; that's fine.) */ if ((oldtup.t_data->t_infomask & HEAP_XMAX_INVALID) || HEAP_LOCKED_UPGRADED(oldtup.t_data->t_infomask) || (checked_lockers && !locker_remains)) xmax_new_tuple = InvalidTransactionId; else xmax_new_tuple = HeapTupleHeaderGetRawXmax(oldtup.t_data); My naive guess is that we have to create a new MultiXactId here in at least some cases, just like FreezeMultiXactId() sometimes does. -- Peter Geoghegan -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Flag index metapages as standard-format in xlog.c calls.
Flag index metapages as standard-format in xlog.c calls. btree, hash, and bloom indexes all set up their metapages in standard format (that is, with pd_lower and pd_upper correctly delimiting the unused area); but they mostly didn't inform the xlog routines of this. When calling log_newpage[_buffer], this is bad because it loses the opportunity to compress unused data out of the WAL record. When calling XLogRegisterBuffer, it's not such a performance problem because all of these call sites also use REGBUF_WILL_INIT, preventing an FPI image from being written. But it's still a good idea to provide the flag when relevant, because that aids WAL consistency checking. This completes the project of getting all the in-core index AMs to handle their metapage WAL operations similarly. Amit Kapila, reviewed by Michael Paquier Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/4c11d2c559e76892156fd08d6a3cf5e1848a017f Modified Files -- contrib/bloom/blinsert.c | 2 +- src/backend/access/hash/hashpage.c| 7 --- src/backend/access/nbtree/nbtinsert.c | 4 ++-- src/backend/access/nbtree/nbtpage.c | 9 + src/backend/access/nbtree/nbtree.c| 2 +- src/backend/access/nbtree/nbtxlog.c | 5 +++-- 6 files changed, 16 insertions(+), 13 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple
On November 4, 2017 1:22:04 AM GMT+05:30, Alvaro Herrera wrote: >Peter Geoghegan wrote: >> Andres Freund wrote: > >> > Staring at the vacuumlazy hunk I think I might have found a related >bug: >> > heap_update_tuple() just copies the old xmax to the new tuple's >xmax if >> > a multixact and still running. It does so without verifying >liveliness >> > of members. Isn't that buggy? Consider what happens if we have >three >> > blocks: 1 has free space, two is being vacuumed and is locked, >three is >> > full and has a tuple that's key share locked by a live tuple and is >> > updated by a dead xmax from before the xmin horizon. In that case >afaict >> > the multi will be copied from the third page to the first one. >Which is >> > quite bad, because vacuum already processed it, and we'll set >> > relfrozenxid accordingly. I hope I'm missing something here? >> >> Can you be more specific about what you mean here? I think that I >> understand where you're going with this, but I'm not sure. > >He means that the tuple that heap_update moves to page 1 (which will no >longer be processed by vacuum) will contain a multixact that's older >than relminmxid -- because it is copied unchanged by heap_update >instead >of properly checking against age limit. Right. That, or a member xid below relminxid. I think both scenarios are possible. Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Avoid looping through line pointers twice in PageRepairFragmenta
Avoid looping through line pointers twice in PageRepairFragmentation(). There doesn't seem to be any good reason to do the filling of the itemidbase[] array separately from the first traversal of the pointers. It's certainly not a win if there are any line pointers with storage, and even if there aren't, this change doesn't insert code into the part of the first loop that will be traversed in that case. So let's just merge the two loops. Yura Sokolov, reviewed by Claudio Freire Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a9169f0200fc57e01cbd216bbd41c9ea3a79a7b0 Modified Files -- src/backend/storage/page/bufpage.c | 46 +- 1 file changed, 21 insertions(+), 25 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
