On Monday, August 19, 2013, Alvaro Herrera wrote:
Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > Here's the second attachment.
>
> This looks good except that it can't tell "db_123.statfoo" isn't a match.
> The scan limit/buffer size needs to be greater than the longest string
> you care about, not only equal to. I think strcmp not strncmp would be
> better coding, too. Please fix that and commit -- I think this part
> is pretty noncontroversial.
Pushed with those fixes, thanks. I noticed we also needed to match
files global.stat and global.tmp. Also I added another conversion to
the sscanf pattern, to ignore files named "db_1234.tmp.foo" and such
(i.e. stuff after whitespace).
Thanks. I did not attack this with malice, but I did throw some casual stupidity at it (setting the temp directory to the same as the absolute path of the data directory) and it managed to go through crash recovery successfully, while HEAD^ completely destroyed itself.
One oddity I observed is that the first time I tested it (by doing kill -9 on the checkpointer) it failed to come back up automatically, claiming the start up process had been signalled with 9 during recovery. When I manually restarted, it ran through recovery again and started successfully. However I could not repeat this and can't see how this patch could possibly cause a regression of this nature, so I'm going to chalk it up to some bizarre race condition, or operator error.
Cheers,
Jeff