Thread: Re:Could not read from file "pg_subtrans/00F5" at offset 122880: Success.

Hello,

On 11/27/23 03:50, Sri Mrudula Attili wrote:
> Hello,
> 
> Post refresh of a Delphix VDB , while trying to connect from application 
> users are getting the below error.
> 
> Could also see these errors in postgresql.log
> 
> Error Message:
> 
> < 2023-11-24 12:24:10.031 GMT >ERROR:  could not access status of 
> transaction 16087052
> < 2023-11-24 12:24:10.031 GMT >DETAIL:  Could not read from file 
> *"pg_subtrans/00F5" at offset 122880: Success.*
> < 2023-11-24 12:24:10.031 GMT >STATEMENT:  SELECT distinct
> 
> Postgresql Version:
> 
> ----------------------------------------------------------------------------------------------------------
>   PostgreSQL 11.16 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 
> 20150623 (Red Hat 4.8.5-44), 64-bit

 From this:


https://docs.delphix.com/docs537/delphix-administration/postgresql-environments-and-data-sources/provisioning-vdbs-from-postgresql-dsources/provisioning-a-postgresql-vdb

there seems to be a lot of moving parts to using Delphix VDB with a 
Postgres database.  You are going to need to provide more information 
about your setup.

> 
> 
> Thanks,
> 
> Sri Attili

-- 
Adrian Klaver
adrian.klaver@aklaver.com

On Mon, 2023-11-27 at 11:50 +0000, Sri Mrudula Attili wrote:
> ERROR:  could not access status of transaction 16087052
> DETAIL:  Could not read from file "pg_subtrans/00F5" at offset 122880: Success.
> STATEMENT:  SELECT distinct 

That's data corruption.
Time to restore your backup.

Investigate how you got there.  Did you run "pg_resetwal"?
Did you restore a database from a file system backup?
Did you remove a "backup_label" file?  Is your hardware broken?

Yours,
Laurenz Albe

At Mon, 27 Nov 2023 19:58:13 +0100, Laurenz Albe <laurenz.albe@cybertec.at> wrote in
> On Mon, 2023-11-27 at 11:50 +0000, Sri Mrudula Attili wrote:
> > ERROR:  could not access status of transaction 16087052
> > DETAIL:  Could not read from file "pg_subtrans/00F5" at offset 122880: Success.

By the way, just out of curiosity, but errno should not be zero at the
time the message above was output, yet "%m" is showing "success",
which implies errno = 0 in Linux. How can that happen?

slru.c:961
>     case SLRU_READ_FAILED:
>       if (errno)
>         ereport(ERROR,
>             (errcode_for_file_access(),
>              errmsg("could not access status of transaction %u", xid),
>              errdetail("Could not read from file \"%s\" at offset %d: %m.",

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

Hello Laurenz,


  Thanks for your response.


This error we are seeing on a delphix Virtual database that was 
refreshed using the snapshot of production standalone database.


It keeps the database in pg_start_backup and to take the snapshot.


I did check the dsource(production) database logs and it hasnt got any 
error like this.


Thanks,

Sri Attili

On 27/11/2023 18:58, Laurenz Albe wrote:
> On Mon, 2023-11-27 at 11:50 +0000, Sri Mrudula Attili wrote:
>> ERROR:  could not access status of transaction 16087052
>> DETAIL:  Could not read from file "pg_subtrans/00F5" at offset 122880: Success.
>> STATEMENT:  SELECT distinct
> That's data corruption.
> Time to restore your backup.
>
> Investigate how you got there.  Did you run "pg_resetwal"?
> Did you restore a database from a file system backup?
> Did you remove a "backup_label" file?  Is your hardware broken?
>
> Yours,
> Laurenz Albe

On 2023-Nov-28, Kyotaro Horiguchi wrote:

> By the way, just out of curiosity, but errno should not be zero at the
> time the message above was output, yet "%m" is showing "success",
> which implies errno = 0 in Linux. How can that happen?

If the file is exactly of the length given then seek will work, and read
will not set errno but return a length of 0 bytes.  So
SlruPhysicalReadPage sets SLRU_READ_FAILED and then in pg11 the %m in
SlruReportIOError expands to "Success".

The code in master is completely different (it uses pg_pread rather than
seek + read): it does test for errno and reports accordingly.

So, nothing to do here.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/

At Wed, 29 Nov 2023 18:29:15 +0100, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote in 
> The code in master is completely different (it uses pg_pread rather than
> seek + read): it does test for errno and reports accordingly.
> 
> So, nothing to do here.

Oops! Thank you and sorry for the noise.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center