Re: Standby trying "restore_command" before local WAL

Greetings,

* Tomas Vondra (tomas.vondra@2ndquadrant.com) wrote:
> That's how I read this part of RestoreArchivedFile:
> 
> https://github.com/postgres/postgres/blob/master/src/backend/access/transam/xlogarchive.c#L110
> 
> The very first thing it does is checking if the local file exists, and if it
> does then calling unlink().

Oh, yeah, once we've decided to go down that route we're doing that,
wasn't thinking it through completely, sorry for the noise.

> >>We'd need invoking some other command before restore_command, which would do
> >>this comparison and decide whether to use local or remote WAL.
> >
> >Ugh, that sounds like a lot of additional complication that I'm not sure
> >would be all that useful or sensible for this particular case, if that's
> >what it would require.  I'd rather we try to figure out some way to get
> >rid of restore_command entirely instead of bolting on more things around
> >it.
> 
> The simpler the better of course.
> 
> All I'm saying is that (assuming my understanding of RestoreArchivedFile is
> correct) we can't just do that in the current restore_command. We do need a
> way to ask the archive for some metadata/checksums, and restore_command is
> too late.

Yeah, I see what you mean there.  An alternative might be to *not*
unlink the file, in case the restore command wants to check if it's
valid and matches what's in the archive, and instead restore the
requested file somewhere else and then perform an unlink/mv after
the restore command has been run.

I'm still not entirely sure that this is a particularly good idea, but
it would at least avoid having another command for a user to have to
configure.

Thanks!

Stephen