pg.ddx.io  pgsql-patches@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Heikki Linnakangas <heikki@enterprisedb.com>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Martin Zaun <Martin.Zaun@Sun.COM>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: Dave Page <dpage@pgadmin.org>
Cc: List pgsql-patches <pgsql-patches@postgresql.org>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [PATCHES] odd output in restore mode
Date: Wed, 23 Jul 2008 21:38:56 +0300
Message-ID: <48877AC0.7070603@enterprisedb.com> (raw)
In-Reply-To: <1216810783.3894.602.camel@ebony.2ndQuadrant>
References: <200807011520.m61FKhZ20311@momjian.us>
	<48867904.9090001@sun.com>
	<1216810783.3894.602.camel@ebony.2ndQuadrant>

Simon Riggs wrote:
> On Tue, 2008-07-22 at 17:19 -0700, Martin Zaun wrote:
>> 8. Unresolved question of implementing now/later a "cp" replacement
> 
> The patch implements what's been agreed. 
> 
> I'm not rewriting "cp", for reasons already discussed.
> 
> Not a comment to you Martin, but it's fairly clear that I'm not
> maintaining this correctly for Windows. I've never claimed to have
> tested this on Windows, and only included Windows related items as
> requested by others. I need to make it clear that I'm not going to
> maintain it at all, for Windows. If others wish to report Windows issues
> then they can suggest appropriate fixes and test them also.

Hmm. I just realized that replacing the "cp" command within pg_standby 
won't help at all. The problem is with the command that copies the files 
*to* the archivelocation that pg_standby polls, not with the copy 
pg_standby does from archivelocation to pg_xlog. And we don't have much 
control over that.

We really need a more reliable way of detecting that a file has been 
fully copied. One simple improvement would be to check the xlp_magic 
field of the last page, though it still wouldn't be bullet-proof.

Do the commands that preallocate the space keep the file exclusively 
locked during the copy? If they do, shouldn't we get an error in trying 
to run the restore copy command, and retry after the 1s sleep in 
RestoreWALFileForRecovery? Though if the archive location is a samba 
mount or something, I guess we can't rely on Windows-style exclusive 
locking.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com



view thread (59+ messages)  latest in thread

Message-ID: <48877AC0.7070603@enterprisedb.com>
Permalink:  ../48877AC0.7070603@enterprisedb.com/
Also on:    postgresql.org/message-id/48877AC0.7070603@enterprisedb.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-patches@postgresql.org
  Cc: heikki@enterprisedb.com, simon@2ndquadrant.com, Martin.Zaun@Sun.COM, bruce@momjian.us, andrew@dunslane.net, dpage@pgadmin.org, pgsql-hackers@postgresql.org
  Subject: Re: [PATCHES] odd output in restore mode
  In-Reply-To: <48877AC0.7070603@enterprisedb.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

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