pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #18088: Table Corruption Issues Arising from Abrupt Server Shutdown During PostgreSQL 10.20 to 14.7 Migratio
2+ messages / 2 participants
[nested] [flat]
* BUG #18088: Table Corruption Issues Arising from Abrupt Server Shutdown During PostgreSQL 10.20 to 14.7 Migratio
@ 2023-09-05 13:21 PG Bug reporting form <noreply@postgresql.org>
0 siblings, 1 reply; 2+ messages in thread
From: PG Bug reporting form @ 2023-09-05 13:21 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: rootcause000@gmail.com
The following bug has been logged on the website:
Bug reference: 18088
Logged by: Root Cause
Email address: rootcause000@gmail.com
PostgreSQL version: Unsupported/Unknown
Operating system: Microsoft Windows Server 2019 Standard
Description:
During the PostgreSQL migration from version 10.21 to 14.7, we encountered
an issue caused by corruption in a specific table. Upon checking the logs,
we noticed numerous instances of the server abruptly shutting down. After
each server restart, when attempting to access the table, we encountered the
following exceptions:
"unrecognized win32 error code: 1392
could not read block 2395 in file ""base/16509/3818424"": Invalid
argument"
On checking the 'relkind' for 'relfilenode,' the type appeared to be an
ordinary table. We were able to regain access to the table by truncating
it.
ProdDB=> select count(*) from prrhtab;
ERROR: could not read block 2394 in file "base/16509/3818424": read only 0
of 8192 bytes
ProdDB=> SELECT relname, relkind FROM pg_Class WHERE relfilenode=3818424;
relname | relkind
-----------------------+---------
prrhtab | r
(1 row)
ProdDB=> truncate table prrhtab;
TRUNCATE TABLE
ProdDB=> select count(*) from prrhtab;
count
-------
0
(1 row)
ProdDB=>
However, since there is no available backup, we are uncertain about the
presence of any data and whether any other recovery options are possible.
Please advise if there are alternative methods to recover the data and if
there are options to prevent this issue from occurring even in the event of
an abrupt server shutdown.
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: BUG #18088: Table Corruption Issues Arising from Abrupt Server Shutdown During PostgreSQL 10.20 to 14.7 Migratio
@ 2023-09-05 17:44 David G. Johnston <david.g.johnston@gmail.com>
parent: PG Bug reporting form <noreply@postgresql.org>
0 siblings, 0 replies; 2+ messages in thread
From: David G. Johnston @ 2023-09-05 17:44 UTC (permalink / raw)
To: rootcause000@gmail.com; pgsql-bugs@lists.postgresql.org
On Tue, Sep 5, 2023 at 7:02 AM PG Bug reporting form <noreply@postgresql.org>
wrote:
> The following bug has been logged on the website:
>
> Bug reference: 18088
> Logged by: Root Cause
> Email address: rootcause000@gmail.com
> PostgreSQL version: Unsupported/Unknown
> Operating system: Microsoft Windows Server 2019 Standard
> Description:
>
> Please advise if there are alternative methods to recover the data and if
> there are options to prevent this issue from occurring even in the event of
> an abrupt server shutdown.
>
There is likely no bug here - improper configuration or bad hardware is
about the only time an improper shutdown is going to cause data loss. The
WAL-based recovery system (which is also usable/required for backups)
accommodates abrupt server shutdowns just fine.
Please use the -general or -admin lists if you wish to further discuss how
to inspect just how your system may be misconfigured and for any guidance
on correcting your lack of backups.
David J,
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2023-09-05 17:44 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-09-05 13:21 BUG #18088: Table Corruption Issues Arising from Abrupt Server Shutdown During PostgreSQL 10.20 to 14.7 Migratio PG Bug reporting form <noreply@postgresql.org>
2023-09-05 17:44 ` David G. Johnston <david.g.johnston@gmail.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