At Wed, 29 Nov 2023 18:29:15 +0100, Alvaro Herrera
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
On Wed, Nov 29, 2023 at 12:20 PM Sri Mrudula Attili wrote:
> 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
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
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 +, Sri Mrudula Attili wrote:
ERROR: could not access status of transaction 16087052
DETAIL: Could not read from file "pg_subtrans/00F5" at off
At Mon, 27 Nov 2023 19:58:13 +0100, Laurenz Albe
wrote in
> On Mon, 2023-11-27 at 11:50 +, Sri Mrudula Attili wrote:
> > ERROR: could not access status of transaction 16087052
> > DETAIL: Could not read from file "pg_subtrans/00F5" at offset 122880:
> >
On Mon, 2023-11-27 at 11:50 +, 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
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
