I tend to write about new features in new versions of PostgreSQL, but this patch actually fixes one of the things that annoy me a lot, so here it goes:
On 26th of January, Simon Riggs committed:
Log Message: ----------- Fix longstanding gripe that we check for 0000000001.history at start of archive recovery, even when we know it is never present.
If you've ever tried to roll your own restore_command script ( like pg_standby ) then you know that to the algorithm that's presented in docs You always had to add special case for file “0000000001.history" – which was never there, but somehow PostgreSQL always asked for it – despite the fact that it could never arrive.
Now, thanks to this small patch we will no longer need to add this “if" in any script. It's small, and it's not a new feature, but I am SO happy to see it.
A restore_command is supposed to behave gracefully when asked for a non-existent file. It *will* still be asked for a non-existent history file, regardless of this commit. This was really just a special-case to silence the useless log message about missing 0000000001.history file, it shouldn’t cause any changes in scripts.
Unless you had a special-case for 0000000001.history in your script to silence it too, which this does make unnecessary.
@Heikki:
Well, it doesn’t make much sense, does it? I mean – restore_command should usually wait for non-existing files to become existing – i.e. when given wal segment is not yet here, we should wait for it to be here. So, basically – we still need this special-case thing. 🙁
Well, it is a bit cumbersome, but that’s the way it’s designed and documented.
It makes sense when you consider the history. The original purpose of restore_command was PITR, not setting up a standby server. In PITR, restore_command doesn’t need to care what file it’s asked for, so something simple as ‘cp’ works. It’s only when it’s repurposed to implement a standby server that it gets more complicated.
The final request for a non-existent history file is the server’s way of confirming that that timeline id has never existed. We support restoring to many timelines, so incrementing the timeline id is not sufficient to guarantee uniqueness. So we loop until we find one that doesn’t exist and presume that means it is OK to use. It not being there isn’t a problem, so perhaps we shouldn’t report it as an error, which is potentially confusing.