Re: incorrect checksum detected on "global/pg_filenode.map" when VACUUM FULL is executed

From: Tatsuki Kadomoto <tatsuki(dot)kadomoto(at)proceranetworks(dot)com>
To: Kevin Grittner <kgrittn(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: John R Pierce <pierce(at)hogranch(dot)com>, PostgreSQL mailing lists <pgsql-general(at)postgresql(dot)org>
Subject: Re: incorrect checksum detected on "global/pg_filenode.map" when VACUUM FULL is executed
Date: 2016-08-25 12:48:37
Message-ID: BN6PR08MB26580530EF99E22CE7A5183F93ED0@BN6PR08MB2658.namprd08.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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(at)gmail(dot)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

On Mon, Aug 22, 2016 at 3:02 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Mon, Aug 22, 2016 at 4:45 PM, Tatsuki Kadomoto
> <tatsuki(dot)kadomoto(at)proceranetworks(dot)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
[http://upload.wikimedia.org/wikipedia/commons/4/43/Enterprisedblogo.png]<http://www.enterprisedb.com/>

EnterpriseDB | The Postgres Database Company<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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message arnaud gaboury 2016-08-25 14:18:39 pg_hba.conf : bad entry for ADDRESS
Previous Message Sylvain Marechal 2016-08-25 10:44:29 BDR: Recover from "FATAL: mismatch in worker state" without restarting postgres