empty backup_label

From: David Kerr <dmk(at)mr-paradox(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Subject: empty backup_label
Date: 2012-06-24 21:33:41
Message-ID: 20120624213341.GA90986@mr-paradox.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Howdy,

We're using NetApp's flexclone's whenever we need to move our DB between machines.

One specific case where we do that is when we're creating a new streaming replication target.

The basic steps we're using are:
pg_start_backup();
<flex clone within the netapp>
pg_stop_backup();

The problem i'm seeing is that periodically the backup_label is empty, which means
I can't start the new standby.

I believe that since the NetApp stuff is all happening within the SAN this file hasn't been
fsynced to disk by the time we take the snapshot.

One option would be to do a "sync" prior to the clone, however that seems kind of like a
heavy operation, and it's slightly more complicated to script. (having to have a user
account on the system to sudo rather than just connecting to the db to issue the
pg_start_backup(...) )

Another option is to add pg_fsync(fileno(fp)) after the fflush() when creating the file (I'm not
sure if fsync implies fflush or not, if it does you could just replace it.)

I think this type of snapshot is fairly common, I've been doing them since 2000 with EMC,
i'm sure that most SAN vendors support it.

I also suspect that this type of problem could show up on AWS if you tried to use their EBS snapshots

Attached is a patch for the suggested change.

Dave

Attachment Content-Type Size
fsync-backup_label.patch text/x-diff 422 bytes

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2012-06-24 21:37:26 Re: Catalog/Metadata consistency during changeset extraction from wal
Previous Message Andres Freund 2012-06-24 21:11:07 Re: Catalog/Metadata consistency during changeset extraction from wal