Re: [BUG]"FailedAssertion" reported in lazy_scan_heap() when running logical replication - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: [BUG]"FailedAssertion" reported in lazy_scan_heap() when running logical replication
Date
Msg-id CAH2-WzmvKdsdfi+cfTQL6OMNNWuE+ggtHmnne4VCeboBuWGYDg@mail.gmail.com
Whole thread Raw
In response to [BUG]"FailedAssertion" reported in lazy_scan_heap() when running logical replication  ("tanghy.fnst@fujitsu.com" <tanghy.fnst@fujitsu.com>)
Responses RE: [BUG]"FailedAssertion" reported in lazy_scan_heap() when running logical replication  ("tanghy.fnst@fujitsu.com" <tanghy.fnst@fujitsu.com>)
Re: [BUG]"FailedAssertion" reported in lazy_scan_heap() when running logical replication  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
On Wed, Apr 28, 2021 at 7:34 PM tanghy.fnst@fujitsu.com
<tanghy.fnst@fujitsu.com> wrote:
> >TRAP: FailedAssertion("!all_visible_according_to_vm || prunestate.all_visible", File: "vacuumlazy.c", Line: 1347,
PID:1274675)
 
>
> BTW, in asynchronous mode, the same problem can also happen but in a low frequency.(I tried many times, but the
problemhappened only 2 times)
 
> As for synchronous mode, I found it seems easier to reproduce the problem with setting "autovacuum_naptime = 1".
> But it still can't be 100% to reproduced it. (I tested it 5 times, 3 of them reproduced it.)

Is setting all_visible_according_to_vm false as below enough to avoid
the assertion failure?

diff --git a/src/backend/access/heap/vacuumlazy.c
b/src/backend/access/heap/vacuumlazy.c
index c3fc12d76c..76c17e063e 100644
--- a/src/backend/access/heap/vacuumlazy.c
+++ b/src/backend/access/heap/vacuumlazy.c
@@ -1146,6 +1146,7 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams
*params, bool aggressive)
             {
                 ReleaseBuffer(vmbuffer);
                 vmbuffer = InvalidBuffer;
+                all_visible_according_to_vm = false;
             }

             /* Remove the collected garbage tuples from table and indexes */


-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Use simplehash.h instead of dynahash in SMgr
Next
From: Amit Kapila
Date:
Subject: Re: Replication slot stats misgivings