pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feed[PATCH] BUG FIX: inconsistent page found in BRIN_REGULAR_PAGE
10+ messages / 5 participants
[nested] [flat]
Commits from this thread:
2022-12-23 5436cb373c 6602599ce2 Fix end LSN determination in recently added test
2022-08-05 39e45d3cec e797c7a6f7 de31e6f81e 2cff302590 e44dae07f9 541f41d4fa 49b85e4812 BRIN: mask BRIN_EVACUATE_PAGE for WAL consistency checking
* [PATCH] BUG FIX: inconsistent page found in BRIN_REGULAR_PAGE
@ 2022-08-03 06:37 王海洋 <wanghaiyang.001@bytedance.com>
0 siblings, 1 reply; 10+ messages in thread
From: 王海洋 @ 2022-08-03 06:37 UTC (permalink / raw)
To: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Hi hackers,
I found that when wal_consistency_checking = brin is set, it may cause redo
abort, all the standby-nodes lost, and the primary node can not be restart.
This bug exists in all versions of PostgreSQL.
The operation steps are as follows:
1. Create a primary instance, set wal_consistency_checking = brin, and
start the primary instance.
initdb -D pg_test
echo "wal_consistency_checking = brin" >> pg_test/postgresql.conf
echo "port=53320" >> pg_test/postgresql.conf
pg_ctl start -D pg_test -l pg_test.logfile
2. Create a standby instance.
pg_basebackup -R -p 53320 -D pg_test_slave
echo "wal_consistency_checking = brin" >>
pg_test_slave/postgresql.conf
echo "port=53321" >> pg_test_slave/postgresql.conf
pg_ctl start -D pg_test_slave -l pg_test_slave.logfile
3. Execute brin_redo_abort.sql through psql, and find that the standby
machine is lost.
psql -p 53320 -f brin_redo_abort.sql
4. The standby instance is lost during redo, FATAL messages as follows:
FATAL: inconsistent page found, rel 1663/12978/16387, forknum 0,
blkno 2
5. The primary instance cannot be restarted through pg_ctl restart -mi.
pg_ctl restart -D pg_test -mi -l pg_test.logfile
6. FATAL messages when restart primary instance as follows:
FATAL: inconsistent page found, rel 1663/12978/16387, forknum 0,
blkno 2
I analyzed the reasons as follows:
1. When the revmap needs to be extended by brinRevmapExtend,
we may set BRIN_EVACUATE_PAGE flag on a REGULAR_PAGE to prevent
other concurrent backends from adding more BrinTuple to that page
in brin_start_evacuating_page.
2. But, during redo-process, it is not needed to set BRIN_EVACUATE_PAGE
flag on that REGULAR_PAGE after removing the old BrinTuple in
brin_xlog_update, since no one will add BrinTuple to that Page at
this time.
3. As a result, this will cause a FATAL message to be thrown in
CheckXLogConsistency after redo, due to inconsistency checking of
the BRIN_EVACUATE_PAGE flag, finally cause redo to abort.
4. Therefore, the BRIN_EVACUATE_PAGE flag should be cleared before
CheckXLogConsistency.
For the above reasons, the patch file, sql file, shell script file, and the
log files are given in the attachment.
Best Regards!
Haiyang Wang
Attachments:
brin_redo_abort.sh (application/octet-stream, 716B) download
0001-clear-BRIN_EVACUATE_PAGE-before-consistency-checking.patch (application/octet-stream, 2.3K) download
From ca682e94f233d48c37a244ec3d4f41b3637c33e6 Mon Sep 17 00:00:00 2001
From: "wanghaiyang.001" <wanghaiyang.001@bytedance.com>
Date: Thu, 28 Jul 2022 15:23:13 +0800
Subject: [PATCH] clear BRIN_EVACUATE_PAGE before consistency-checking to
prevent redo from aborting.
When the revmap needs to be extended by brinRevmapExtend,
we may set BRIN_EVACUATE_PAGE flag on a REGULAR_PAGE to prevent
other concurrent backends from adding more BrinTuple to that page
in brin_start_evacuating_page.
But, during redo-process, it is not needed to set BRIN_EVACUATE_PAGE
flag on that REGULAR_PAGE after removing the old BrinTuple in
brin_xlog_update, since no one will add BrinTuple to that Page at
this time.
As a result, this will cause a FATAL message to be thrown in
CheckXLogConsistency after redo, due to inconsistency checking of
the BRIN_EVACUATE_PAGE flag, finally cause redo to abort.
Therefore, the BRIN_EVACUATE_PAGE flag should be cleared before
the following consistency-checking.
---
src/backend/access/brin/brin_xlog.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/src/backend/access/brin/brin_xlog.c b/src/backend/access/brin/brin_xlog.c
index 39dc130e16..4732e86fad 100644
--- a/src/backend/access/brin/brin_xlog.c
+++ b/src/backend/access/brin/brin_xlog.c
@@ -358,4 +358,28 @@ brin_mask(char *pagedata, BlockNumber blkno)
{
mask_unused_space(page);
}
+
+ /*
+ * When the revmap needs to be extended by brinRevmapExtend,
+ * we may set BRIN_EVACUATE_PAGE flag on a REGULAR_PAGE to prevent
+ * other concurrent backends from adding more BrinTuple to that page
+ * in brin_start_evacuating_page.
+ *
+ * But, during redo-process, it is not needed to set BRIN_EVACUATE_PAGE
+ * flag on that REGULAR_PAGE after removing the old BrinTuple in
+ * brin_xlog_update, since no one will add BrinTuple to that Page at
+ * this time.
+ *
+ * As a result, this will cause a FATAL message to be thrown in
+ * CheckXLogConsistency after redo, due to inconsistency checking of
+ * the BRIN_EVACUATE_PAGE flag, finally cause redo to abort.
+ *
+ * Therefore, the BRIN_EVACUATE_PAGE flag should be cleared before
+ * the following consistency-checking.
+ */
+ if (BrinPageFlags(page) & BRIN_EVACUATE_PAGE)
+ {
+ Assert(BRIN_IS_REGULAR_PAGE(page));
+ BrinPageFlags(page) &= ~BRIN_EVACUATE_PAGE;
+ }
}
--
2.11.0
* Re: [PATCH] BUG FIX: inconsistent page found in BRIN_REGULAR_PAGE
@ 2022-08-04 07:55 Kyotaro Horiguchi <horikyota.ntt@gmail.com>
parent: 王海洋 <wanghaiyang.001@bytedance.com>
0 siblings, 1 reply; 10+ messages in thread
From: Kyotaro Horiguchi @ 2022-08-04 07:55 UTC (permalink / raw)
To: wanghaiyang.001@bytedance.com; +Cc: pgsql-bugs@lists.postgresql.org
At Wed, 3 Aug 2022 02:37:30 -0400, $B2&3$MN(B <wanghaiyang.001@bytedance.com> wrote in
> Hi hackers,
>
> I found that when wal_consistency_checking = brin is set, it may cause redo
> abort, all the standby-nodes lost, and the primary node can not be restart.
>
> This bug exists in all versions of PostgreSQL.
>
> The operation steps are as follows:
Nice reproducer!
> I analyzed the reasons as follows:
>
> 1. When the revmap needs to be extended by brinRevmapExtend,
> we may set BRIN_EVACUATE_PAGE flag on a REGULAR_PAGE to prevent
> other concurrent backends from adding more BrinTuple to that page
> in brin_start_evacuating_page.
>
> 2. But, during redo-process, it is not needed to set BRIN_EVACUATE_PAGE
> flag on that REGULAR_PAGE after removing the old BrinTuple in
> brin_xlog_update, since no one will add BrinTuple to that Page at
> this time.
>
> 3. As a result, this will cause a FATAL message to be thrown in
> CheckXLogConsistency after redo, due to inconsistency checking of
> the BRIN_EVACUATE_PAGE flag, finally cause redo to abort.
>
> 4. Therefore, the BRIN_EVACUATE_PAGE flag should be cleared before
> CheckXLogConsistency.
+1 for what the patch does. The flag is actually non-logged,
primary-only flag.
The coment looks too verbose. It looks as if saying we evading some
flaw by masking the flag. The inconsistency is caused by that the flag
is changed unlogged and not operated via wal-redo. So, I think it can
be shortened as the following example. (It is taken from btree_mask())
> BRIN_EVACUATE_PAGE is an unlogged bit, which is never set during
> recovery. See brin_start_evacuating_page() for details.
I think we need the corresponding comment that explains we don't need
to wal-log the bit in the function, too.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [PATCH] BUG FIX: inconsistent page found in BRIN_REGULAR_PAGE
@ 2022-08-04 08:12 Kyotaro Horiguchi <horikyota.ntt@gmail.com>
parent: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
0 siblings, 1 reply; 10+ messages in thread
From: Kyotaro Horiguchi @ 2022-08-04 08:12 UTC (permalink / raw)
To: wanghaiyang.001@bytedance.com; +Cc: pgsql-bugs@lists.postgresql.org
I'd like to explain a bit further.
At Thu, 04 Aug 2022 16:55:35 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in
> > BRIN_EVACUATE_PAGE is an unlogged bit, which is never set during
> > recovery. See brin_start_evacuating_page() for details.
That being said, I think that some bug could unexpectedly set the flag
during recovery. I sought for clean way to check that only while not
in evacuation, but I found none..
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [External] Re: [PATCH] BUG FIX: inconsistent page found in BRIN_REGULAR_PAGE
@ 2022-08-04 10:26 王海洋 <wanghaiyang.001@bytedance.com>
parent: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
0 siblings, 1 reply; 10+ messages in thread
From: 王海洋 @ 2022-08-04 10:26 UTC (permalink / raw)
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>; +Cc: pgsql-bugs@lists.postgresql.org
Thanks, I agree. So my new modified patch is attached.
From: "Kyotaro Horiguchi"<horikyota.ntt@gmail.com>
Date: Thu, Aug 4, 2022, 16:12
Subject: [External] Re: [PATCH] BUG FIX: inconsistent page found in
BRIN_REGULAR_PAGE
To: <wanghaiyang.001@bytedance.com>
Cc: <pgsql-bugs@lists.postgresql.org>
I'd like to explain a bit further. At Thu, 04 Aug 2022 16:55:35 +0900
(JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in > >
BRIN_EVACUATE_PAGE is an unlogged bit, which is never set during > >
recovery. See brin_start_evacuating_page() for details. That being said, I
think that some bug could unexpectedly set the flag during recovery. I
sought for clean way to check that only while not in evacuation, but I
found none.. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
Attachments:
0001-mask-un-logged-hint-bit-BRIN_EVACUATE_PAGE-before-co.patch (application/octet-stream, 1.7K) download
From 52d1fc3c9021da35bfde3864b64dbcdf3c7bc434 Mon Sep 17 00:00:00 2001
From: "wanghaiyang.001" <wanghaiyang.001@bytedance.com>
Date: Thu, 4 Aug 2022 18:19:12 +0800
Subject: [PATCH] mask un-logged hint bit BRIN_EVACUATE_PAGE before
consistency-checking
---
src/backend/access/brin/brin_pageops.c | 8 +++++++-
src/backend/access/brin/brin_xlog.c | 6 ++++++
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/src/backend/access/brin/brin_pageops.c b/src/backend/access/brin/brin_pageops.c
index df9ffc2fb8..0a4960232e 100644
--- a/src/backend/access/brin/brin_pageops.c
+++ b/src/backend/access/brin/brin_pageops.c
@@ -541,7 +541,13 @@ brin_start_evacuating_page(Relation idxRel, Buffer buf)
lp = PageGetItemId(page, off);
if (ItemIdIsUsed(lp))
{
- /* prevent other backends from adding more stuff to this page */
+ /*
+ * Prevent other backends from adding more stuff to this page.
+ *
+ * Note that BRIN_EVACUATE_PAGE is just an un-logged hint bit,
+ * which works on primary-node only. See br_page_get_freespace
+ * for details.
+ */
BrinPageFlags(page) |= BRIN_EVACUATE_PAGE;
MarkBufferDirtyHint(buf, true);
diff --git a/src/backend/access/brin/brin_xlog.c b/src/backend/access/brin/brin_xlog.c
index 39dc130e16..e88c327090 100644
--- a/src/backend/access/brin/brin_xlog.c
+++ b/src/backend/access/brin/brin_xlog.c
@@ -358,4 +358,10 @@ brin_mask(char *pagedata, BlockNumber blkno)
{
mask_unused_space(page);
}
+
+ /*
+ * BRIN_EVACUATE_PAGE is an unlogged bit, which is never set during
+ * recovery. So, mask it. See brin_start_evacuating_page() for details.
+ */
+ BrinPageFlags(page) &= ~BRIN_EVACUATE_PAGE;
}
--
2.36.0.windows.1
* Re: [External] Re: [PATCH] BUG FIX: inconsistent page found in BRIN_REGULAR_PAGE
@ 2022-08-05 13:17 Alvaro Herrera <alvherre@alvh.no-ip.org>
parent: 王海洋 <wanghaiyang.001@bytedance.com>
0 siblings, 2 replies; 10+ messages in thread
From: Alvaro Herrera @ 2022-08-05 13:17 UTC (permalink / raw)
To: 王海洋 <wanghaiyang.001@bytedance.com>; +Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>; pgsql-bugs@lists.postgresql.org
On 2022-Aug-04, 王海洋 wrote:
> Thanks, I agree. So my new modified patch is attached.
I propose the attached. This also adds a new TAP test that runs BRIN
through a revmap extension and through wal_consistency_checking. This
increases coverage, as currently there's none for brin_evacuate_page.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Every machine is a smoke machine if you operate it wrong enough."
https://twitter.com/libseybieda/status/1541673325781196801
Attachments:
v3-0001-add-test.patch (text/x-diff, 0B) download
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [External] Re: [PATCH] BUG FIX: inconsistent page found in BRIN_REGULAR_PAGE
@ 2022-08-05 14:01 王海洋 <wanghaiyang.001@bytedance.com>
parent: Alvaro Herrera <alvherre@alvh.no-ip.org>
1 sibling, 1 reply; 10+ messages in thread
From: 王海洋 @ 2022-08-05 14:01 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>; pgsql-bugs@lists.postgresql.org
Nice, benefited a lot, thanks.
Best Regards!
Haiyang Wang
From: "Alvaro Herrera"<alvherre@alvh.no-ip.org>
Date: Fri, Aug 5, 2022, 21:17
Subject: Re: [External] Re: [PATCH] BUG FIX: inconsistent page found in
BRIN_REGULAR_PAGE
To: "王海洋"<wanghaiyang.001@bytedance.com>
Cc: "Kyotaro Horiguchi"<horikyota.ntt@gmail.com>, <
pgsql-bugs@lists.postgresql.org>
On 2022-Aug-04, 王海洋 wrote: > Thanks, I agree. So my new modified patch is
attached. I propose the attached. This also adds a new TAP test that runs
BRIN through a revmap extension and through wal_consistency_checking. This
increases coverage, as currently there's none for brin_evacuate_page. --
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "Every
machine is a smoke machine if you operate it wrong enough."
https://twitter.com/libseybieda/status/1541673325781196801
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [External] Re: [PATCH] BUG FIX: inconsistent page found in BRIN_REGULAR_PAGE
@ 2022-08-05 16:05 Alvaro Herrera <alvherre@alvh.no-ip.org>
parent: 王海洋 <wanghaiyang.001@bytedance.com>
0 siblings, 0 replies; 10+ messages in thread
From: Alvaro Herrera @ 2022-08-05 16:05 UTC (permalink / raw)
To: 王海洋 <wanghaiyang.001@bytedance.com>; +Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>; pgsql-bugs@lists.postgresql.org
On 2022-Aug-05, 王海洋 wrote:
> Nice, benefited a lot, thanks.
Thanks, pushed to all branches. I ran the test individually in each
branch and they all pass locally, though I'll wait to see what does th
buildfarm have to say about it.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
^ permalink raw reply [nested|flat] 10+ messages in thread
* [PATCH] BUG FIX: inconsistent page found in BRIN_REGULAR_PAGE
@ 2022-12-23 13:54 Karina Litskevich <litskevichkarina@gmail.com>
parent: Alvaro Herrera <alvherre@alvh.no-ip.org>
1 sibling, 1 reply; 10+ messages in thread
From: Karina Litskevich @ 2022-12-23 13:54 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: 王海洋 <wanghaiyang.001@bytedance.com>; Kyotaro Horiguchi <horikyota.ntt@gmail.com>; pgsql-bugs@lists.postgresql.org
Hi Alvaro!
Is there any special reason to read WAL records until the last inserted
record?
+my $end_lsn = $whiskey->lsn('insert');
+
+my ($ret, $out, $err) = $whiskey->psql(
+ 'postgres', qq{
+ select count(*) from pg_get_wal_records_info('$start_lsn', '$end_lsn')
+ where resource_manager = 'BRIN' AND
+ record_type ILIKE '%revmap%'
+ });
+cmp_ok($out, '>=', 1);
It seems that in some rare situations on slower machines this test can
fail. If
any background process inserts a WAL record before lsn('insert') and
this record
isn't flushed before pg_get_wal_records_info('$start_lsn', '$end_lsn'),
pg_get_wal_records_info('$start_lsn', '$end_lsn') ends with ERROR
"cannot accept
future end LSN" as it works only if record with end LSN is inserted.
I attached two patches with two ways of fixing this minor issue.
Best regards,
Karina Litskevich
Postgres Professional: http://postgrespro.com/
Attachments: download all (2 files, .tar.gz)
v1-0001-prevent-test-from-failing-on-slower-machines.patch (text/x-patch, 772B) download
From 75a56e7bd5bc718481099bda3668855f9c200e98 Mon Sep 17 00:00:00 2001
From: Karina Litskevich <litskevichkarina@gmail.com>
Date: Fri, 23 Dec 2022 16:35:23 +0300
Subject: [PATCH v1] prevent test from failing on slower machines
---
src/test/modules/brin/t/02_wal_consistency.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/test/modules/brin/t/02_wal_consistency.pl b/src/test/modules/brin/t/02_wal_consistency.pl
index f7dbb0d014..cbc269b1df 100644
--- a/src/test/modules/brin/t/02_wal_consistency.pl
+++ b/src/test/modules/brin/t/02_wal_consistency.pl
@@ -60,7 +60,7 @@ begin
end
$$;
});
-my $end_lsn = $whiskey->lsn('insert');
+my $end_lsn = $whiskey->lsn('flush');
my ($ret, $out, $err) = $whiskey->psql(
'postgres', qq{
--
2.25.1
v2-0001-prevent-test-from-failing-on-slower-machines.patch (text/x-patch, 962B) download
From e4aff210c95ed548f4c54f9314c4b58580663a74 Mon Sep 17 00:00:00 2001
From: Karina Litskevich <litskevichkarina@gmail.com>
Date: Fri, 23 Dec 2022 16:41:48 +0300
Subject: [PATCH v2] prevent test from failing on slower machines
---
src/test/modules/brin/t/02_wal_consistency.pl | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/test/modules/brin/t/02_wal_consistency.pl b/src/test/modules/brin/t/02_wal_consistency.pl
index f7dbb0d014..a7aeadf4bb 100644
--- a/src/test/modules/brin/t/02_wal_consistency.pl
+++ b/src/test/modules/brin/t/02_wal_consistency.pl
@@ -60,11 +60,10 @@ begin
end
$$;
});
-my $end_lsn = $whiskey->lsn('insert');
my ($ret, $out, $err) = $whiskey->psql(
'postgres', qq{
- select count(*) from pg_get_wal_records_info('$start_lsn', '$end_lsn')
+ select count(*) from pg_get_wal_records_info_till_end_of_wal('$start_lsn')
where resource_manager = 'BRIN' AND
record_type ILIKE '%revmap%'
});
--
2.25.1
* Re: [PATCH] BUG FIX: inconsistent page found in BRIN_REGULAR_PAGE
@ 2022-12-23 16:35 Alvaro Herrera <alvherre@alvh.no-ip.org>
parent: Karina Litskevich <litskevichkarina@gmail.com>
0 siblings, 1 reply; 10+ messages in thread
From: Alvaro Herrera @ 2022-12-23 16:35 UTC (permalink / raw)
To: Karina Litskevich <litskevichkarina@gmail.com>; +Cc: 王海洋 <wanghaiyang.001@bytedance.com>; Kyotaro Horiguchi <horikyota.ntt@gmail.com>; pgsql-bugs@lists.postgresql.org
Hello,
On 2022-Dec-23, Karina Litskevich wrote:
> Is there any special reason to read WAL records until the last inserted
> record?
Hmm, no, there's no good reason to do it that way.
> It seems that in some rare situations on slower machines this test can fail.
> If any background process inserts a WAL record before lsn('insert')
> and this record isn't flushed before
> pg_get_wal_records_info('$start_lsn', '$end_lsn'),
> pg_get_wal_records_info('$start_lsn', '$end_lsn') ends with ERROR
> "cannot accept future end LSN" as it works only if record with end LSN
> is inserted.
Hmm. I've never seen that, but it sounds plausible.
> I attached two patches with two ways of fixing this minor issue.
> -my $end_lsn = $whiskey->lsn('insert');
> +my $end_lsn = $whiskey->lsn('flush');
Thank you, I used this one.
Regards
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [PATCH] BUG FIX: inconsistent page found in BRIN_REGULAR_PAGE
@ 2022-12-23 17:50 Patrick Headley <pheadley@linxco-inc.com>
parent: Alvaro Herrera <alvherre@alvh.no-ip.org>
0 siblings, 0 replies; 10+ messages in thread
From: Patrick Headley @ 2022-12-23 17:50 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; Karina Litskevich <litskevichkarina@gmail.com>; +Cc: 王海洋 <wanghaiyang.001@bytedance.com>; Kyotaro Horiguchi <horikyota.ntt@gmail.com>; pgsql-bugs@lists.postgresql.org
Evelyn,
I ran the query that runs when you click on Check Invoices that returns
the invTotal and TotDetailAmt and here's what came up. As you will see,
the invTotal amounts from your list don't match the production data and
most of the amounts in TotDetailAmt don't match production data. Where
did your list come from? Is this an old list from the other day?
I have turned on the invTotal field in both invoice forms so you can
compare the Total Invoice amount that is calculated from the line items
with the invTotal amount that is saved to the database. This will allow
you to see what is being saved at the time of creating the invoice.
*/Patrick Headley/*
Linx Consulting, Inc.
(303) 916-5522
pheadley@linxco-inc.com
www.linxco-inc.com
On 12/23/22 9:35 AM, Alvaro Herrera wrote:
> Hello,
>
> On 2022-Dec-23, Karina Litskevich wrote:
>
>> Is there any special reason to read WAL records until the last inserted
>> record?
> Hmm, no, there's no good reason to do it that way.
>
>> It seems that in some rare situations on slower machines this test can fail.
>> If any background process inserts a WAL record before lsn('insert')
>> and this record isn't flushed before
>> pg_get_wal_records_info('$start_lsn', '$end_lsn'),
>> pg_get_wal_records_info('$start_lsn', '$end_lsn') ends with ERROR
>> "cannot accept future end LSN" as it works only if record with end LSN
>> is inserted.
> Hmm. I've never seen that, but it sounds plausible.
>
>> I attached two patches with two ways of fixing this minor issue.
>> -my $end_lsn = $whiskey->lsn('insert');
>> +my $end_lsn = $whiskey->lsn('flush');
> Thank you, I used this one.
>
> Regards
>
Attachments:
ZYUgdb4r0i0b5gEE.png (image/png, 78.1K) download
view image
hP4KEeR6SL1TP0QC.png (image/png, 166.9K) download
view image
oTZIjlu0T7Y0535E.png (image/png, 13.1K) download
view image
end of thread, other threads:[~2022-12-23 17:50 UTC | newest]
Thread overview: 10+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2022-08-03 06:37 [PATCH] BUG FIX: inconsistent page found in BRIN_REGULAR_PAGE 王海洋 <wanghaiyang.001@bytedance.com>
2022-08-04 07:55 ` Kyotaro Horiguchi <horikyota.ntt@gmail.com>
2022-08-04 08:12 ` Kyotaro Horiguchi <horikyota.ntt@gmail.com>
2022-08-04 10:26 ` 王海洋 <wanghaiyang.001@bytedance.com>
2022-08-05 13:17 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2022-08-05 14:01 ` 王海洋 <wanghaiyang.001@bytedance.com>
2022-08-05 16:05 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2022-12-23 13:54 ` Karina Litskevich <litskevichkarina@gmail.com>
2022-12-23 16:35 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2022-12-23 17:50 ` Patrick Headley <pheadley@linxco-inc.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox