On Sun, Dec 16, 2007 at 10:31:59AM +0000, Gregory Stark wrote:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>
> > Gregory Stark <stark@enterprisedb.com> writes:
> >> "Andrew Dunstan" <andrew@dunslane.net> writes:
> >>> Interesting. Maybe forever is going a bit too far, but retrying for <n>
> >>> seconds or so.
> >
> >> I think looping forever is the right thing. Having a fixed timeout just means
> >> Postgres will break sometimes instead of all the time. And it introduces
> >> non-deterministic behaviour too.
> >
> > Looping forever would be considered broken by a very large fraction of
> > the community.
>
> Really? I understood we're talking about having Postgres fail with an error if
> any of its files are opened by another program such as backup software. So
> with a 30s limit it means Postgres might or might not fail depending on how
> long this other software has the file open. That doesn't seem like an
> improvement.
If your software is locking a file for that long, that software is more
than just broken, it's horribly broken. Having a workaround against
something that might happen once or twice because of a bug in the other
software is one thing, but if it's actually *designed* to do that you
really need to get that software removed from your machine.
Having the server completely stop for 30 seconds waiting for something to
happen is bad enough, I think. Better to error out to let the user know
that there's a major configuration problem on the machine.
> > IIRC we have a 30-second timeout in rename() for Windows, and that seems
> > to be working well enough, so I'd be inclined to copy the behavior for
> > this case.
>
> I thought it was unlink, and the worst-case there is that we leak a file until
> some later time. I'm wasn't exactly following that case though.
We do it on both rename and unlink.
//Magnus
