Thread: incorrect checksum detected on "global/pg_filenode.map" when VACUUM FULL is executed
Michael,
I have read the comment in relmapper.c.
===
Therefore mapped catalogs can only be relocated by operations such as VACUUM FULL
and CLUSTER, which make no transactionally-significant changes: it must be
safe for the new file to replace the old, even if the transaction itself aborts.
===Does this mean it's a kind of expected to face checksum error when the mapping file is relocated by VACUUM FULL?
I faced the checksum error exactly when VACUUM FULL was running and it has never been detected until now.
Aug 16 20:51:19 postgres[22329]: [2-1] FATAL: relation mapping file "global/pg_filenode.map" contains incorrect checksum |
Aug 16 20:51:19 postgres[22329]: [2-2] STATEMENT: SELECT id,readbm,writebm,survbm,timeout FROM Users WHERE username='packetlogicd' AND password=md5('xxxxx') |
Regards,
Tatsuki
From: Kevin Grittner <kgrittn@gmail.com>
Sent: Tuesday, August 23, 2016 3:07:03 AM
To: Michael Paquier
Cc: Tatsuki Kadomoto; John R Pierce; PostgreSQL mailing lists
Subject: Re: [GENERAL] incorrect checksum detected on "global/pg_filenode.map" when VACUUM FULL is executed
Sent: Tuesday, August 23, 2016 3:07:03 AM
To: Michael Paquier
Cc: Tatsuki Kadomoto; John R Pierce; PostgreSQL mailing lists
Subject: Re: [GENERAL] incorrect checksum detected on "global/pg_filenode.map" when VACUUM FULL is executed
On Mon, Aug 22, 2016 at 3:02 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Mon, Aug 22, 2016 at 4:45 PM, Tatsuki Kadomoto
> <tatsuki.kadomoto@proceranetworks.com> wrote:
>> Thanks for suggestion for upgrade. I know that's the way to go, but it's not
>> so easy due to circumstances on my side.
>
> Well, I guess it depends on how much you care about your data.
Right. Make sure that whoever is responsible for this decision
knows that until they upgrade they are running with known bugs
which could render the database unusable without warning. It
should at least be an informed decision so that the decision-maker
can stand behind it and feel as good as possible about
circumstances should that happen.
You might want to keep a copy of the email or memo in which you
point this out, in case anyone's memory gets foggy during such a
crisis.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
<michael.paquier@gmail.com> wrote:
> On Mon, Aug 22, 2016 at 4:45 PM, Tatsuki Kadomoto
> <tatsuki.kadomoto@proceranetworks.com> wrote:
>> Thanks for suggestion for upgrade. I know that's the way to go, but it's not
>> so easy due to circumstances on my side.
>
> Well, I guess it depends on how much you care about your data.
Right. Make sure that whoever is responsible for this decision
knows that until they upgrade they are running with known bugs
which could render the database unusable without warning. It
should at least be an informed decision so that the decision-maker
can stand behind it and feel as good as possible about
circumstances should that happen.
You might want to keep a copy of the email or memo in which you
point this out, in case anyone's memory gets foggy during such a
crisis.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
 | www.enterprisedb.com A relational database management system based on PostgreSQL that adds Oracle compatibility feature, performance and management features. | |
The Enterprise PostgreSQL Company