Re: pgsql-server/src backend/storage/buffer/bufmgr ...

On Sat, 24 Jan 2004, Tom Lane wrote:

> Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
> > So far nobody bothered to make any other proposal how to cause the
> > kernel to actually do some writing at all. A lot of people babble about
> > fsync(), fdatasync() and fadvise and whatnot. A week ago I posted the
> > proposal for this and got exactly zero response.
>
> As I've said before, I think we need to find a way to stop using sync()
> altogether --- we have to move to fsync or O_SYNC and variants. sync
> has simply got the wrong API.
>
> Let me give an example: you write a bunch of stuff and then call sync().
> Suppose the kernel is unable to write some of those blocks --- it gets
> a hard I/O error, or doesn't realize it's out of disk space until the
> write is attempted, or whatever. (I think this is what happened to
> Chris K-L last night.) Is the sync call going to tell you about the
> problem? No, it is not. If you are lucky you will get an error return
> from the next operation you try on a file descriptor associated with the
> failed blocks. But by that time you've probably already written a
> checkpoint record to WAL claiming that those writes were all done
> successfully. Finding out about the failures after the checkpoint is
> completed is too late --- you're screwed, especially if a crash happens
> before you can do anything about it.

Stupid question here, and I just checked postgresql.conf to make sure it
wasn't something I overlooked ... why don't we have a 'minfree' setting
for disk space? Its not like this is a rare occurance thing, running out
of disk space ...

Personally, what I'd expect would be that the postmaster process monitors
this, and if below a certain threshold, send out a 'close connections' to
the postgres processes and refuse future connections with an 'out of
space' warning ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664