Re: broken reading on standby (PostgreSQL 16.2)

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Melanie Plageman <melanieplageman(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: broken reading on standby (PostgreSQL 16.2)
Date: 2024-04-25 11:22:01
Message-ID: CAFj8pRC2ThV84G=MA097Y2B_fuyALmaiXRFohKa1zU7Qw0OXzA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

čt 25. 4. 2024 v 12:53 odesílatel Melanie Plageman <
melanieplageman(at)gmail(dot)com> napsal:

> On Thu, Apr 25, 2024 at 2:13 AM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
> >
> > Hi
> >
> > yesterday, I had to fix strange issue on standby server
> >
> > The query to freshly updated data fails
> >
> > select * from seller_success_rate where create_time::date = '2024-04-23';
> > ERROR: 58P01: could not access status of transaction 1393466389
> > DETAIL: Could not open file "pg_xact/0530": No such file or directory.
> > LOCATION: SlruReportIOError, slru.c:947
> >
> > amcheck
> >
> > select * from verify_heapam('seller_success_rate');
> > blkno | offnum | attnum | msg
> >
> -------+--------+--------+-------------------------------------------------------------------
> > 5763 | 111 | | xmin 1393466389 precedes oldest valid
> transaction ID 3:1523885078
> > 5863 | 109 | | xmin 1393466389 precedes oldest valid
> transaction ID 3:1523885078
> > 5863 | 110 | | xmin 1393466389 precedes oldest valid
> transaction ID 3:1523885078
> > 5868 | 110 | | xmin 1393466389 precedes oldest valid
> transaction ID 3:1523885078
> > 5868 | 111 | | xmin 1393466389 precedes oldest valid
> transaction ID 3:1523885078
> > 5875 | 111 | | xmin 1393466389 precedes oldest valid
> transaction ID 3:1523885078
> > 5895 | 109 | | xmin 1393466389 precedes oldest valid
> transaction ID 3:1523885078
> > 5895 | 110 | | xmin 1439564642 precedes oldest valid
> transaction ID 3:1523885078
> > 6245 | 108 | | xmin 1393466389 precedes oldest valid
> transaction ID 3:1523885078
> > 6245 | 109 | | xmin 1393466389 precedes oldest valid
> transaction ID 3:1523885078
> > 6245 | 110 | | xmin 1439564642 precedes oldest valid
> transaction ID 3:1523885078
> > 6245 | 112 | | xmin 1424677216 precedes oldest valid
> transaction ID 3:1523885078
> > 6378 | 109 | | xmin 1393466389 precedes oldest valid
> transaction ID 3:1523885078
> > 6378 | 110 | | xmin 1393466389 precedes oldest valid
> transaction ID 3:1523885078
> > 6382 | 110 | | xmin 1393466389 precedes oldest valid
> transaction ID 3:1523885078
> > 6590 | 110 | | xmin 1393466389 precedes oldest valid
> transaction ID 3:1523885078
> > 6590 | 111 | | xmin 1393466389 precedes oldest valid
> transaction ID 3:1523885078
> > 7578 | 112 | | xmin 1393466389 precedes oldest valid
> transaction ID 3:1523885078
> > 7581 | 112 | | xmin 1393466389 precedes oldest valid
> transaction ID 3:1523885078
> > 8390 | 112 | | xmin 1393466389 precedes oldest valid
> transaction ID 3:1523885078
> > 10598 | 109 | | xmin 1393466389 precedes oldest valid
> transaction ID 3:1523885078
> > 10598 | 110 | | xmin 1393466389 precedes oldest valid
> transaction ID 3:1523885078
> >
> > I verified xmin against the primary server, and it was the same. There
> was not any replication gap.
> >
> > I checked the fields from pg_database table, and looks same too
> >
> > These rows were valid (and visible) on primary.
> >
> > On this server there was not any long session (when I was connected),
> unfortunately I cannot test restart of this server. One wal sender is
> executing on standby. Fortunately, there was a possibility to run VACUUM
> FULL, and it fixed the issue.
> >
> > The customer has archived wals.
>
> Did you mention what version of Postgres this is?
>

16.2 and related rows was today one day old

>
> - Melanie
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dagfinn Ilmari Mannsåker 2024-04-25 11:23:18 Doc anchors for COPY formats
Previous Message vignesh C 2024-04-25 11:16:37 Re: Race condition in FetchTableStates() breaks synchronization of subscription tables