Andres Freund <andres@2ndquadrant.com> writes:
> On 2013-01-24 16:45:42 +0530, Amit Kapila wrote:
>>> * Writing the temporary file to .$pid seems like a bad idea, better use
>>> one file for that, SET PERSISTENT is protected by an exclusive lock
>>> anyway.
>> I think we can use one temporary file, infact that was one of the ways I
>> have asked in one of the previous mails.
>> However Tom and Zoltan felt this is better way to do it.
> The have? I didn't read it like that. The file can only ever written by
> a running postmaster and we already have code that ensures that. There's
> absolutely no need for the tempfile to have a nondeterministic
> name. That makes cleanup way easier as well.
Say again? Surely the temp file is being written by whichever backend
is executing SET PERSISTENT, and there could be more than one.
Or, if it isn't and you really do mean that this patch is getting the
postmaster process involved in executing SET PERSISTENT, that's going to
be sufficient grounds for rejection right there. The only way that we
have to keep the postmaster reliable is to not have it doing more than
it absolutely must.
While I have not been paying very much attention to this patch, I have
to say that every time I've looked into the thread I've gotten an
overwhelming impression of overdesign and overcomplication. This should
not be a very large or subtle patch. Write a setting into a temp file,
rename it into place, done.
regards, tom lane
