Re: danger of stats_temp_directory = /dev/shm

On Monday, August 19, 2013, Alvaro Herrera wrote:

> Tom Lane wrote:
> > Alvaro Herrera <alvherre(at)2ndquadrant(dot)com <javascript:;>> 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