| From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
|---|---|
| To: | ev(dot)yanchuk(dot)s(at)gmail(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #17528: ERROR: could not access status of transaction 1997627701 |
| Date: | 2022-06-23 12:39:03 |
| Message-ID: | F6932542-979B-4607-8AF4-9FDFB0F773CF@yandex-team.ru |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
> On 22 Jun 2022, at 08:34, PG Bug reporting form <noreply(at)postgresql(dot)org> wrote:
>
> Hello.
> I've found on our server (PostgreSQL 10.19 on x86_64-pc-linux-gnu, compiled
> by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44), 64-bit)
>
It seems you have encountered data corruption. This might be a result of some different causes. Can you please describe more details and history of your installation?
Do you update your system? Was it running on versions before 10.16? Somewhat related bug was fixed, but AFAIR it was only reproducible only if the system is running near xid wraparound regularly.
Does your block storage feels OK? Are data_checksums enabled?
Can you check installation with amcheck and heapcheck?
Do you have backups? If so - can you bisect when the corruption first appeared?
You can try to fix a copy of the cluster with tools like pg_surgery or pg_dirty_hands.
Best regards, Andrey Borodin.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Wolf | 2022-06-23 15:58:42 | Re: BUG #17529: SQL Error [57P01]: FATAL: terminating connection due to administrator command |
| Previous Message | Raman Kumar | 2022-06-23 06:33:09 | Re: BUG #17524: Increase in WAL size due to logical replication with publication contain a table with low activity. |