RE: [Patch] Optimize dropping of relation buffers using dlist

From: Thomas Munro <thomas.munro@gmail.com>
> > I'm probably being silly, but can't we avoid the problem by using fstat()
> instead of lseek(SEEK_END)?  Would they return the same value from the
> i-node?
> 
> Amazingly, st_size can disagree with SEEK_END when using the Linux NFS
> client, but its behaviour is worse.  Here's a sequence from a Linux
> NFS client talking to a Linux NFS server with no free space.  This
> time, I also replaced the fsync() with sleep(60), just to make it
> clear that SEEK_END offset can move at any time due to asynchronous
> activity in kernel threads:

Thank you for experimenting.  That's surely amazing.  So, it makes sense for commercial DBMSs and MySQL to preallocate data files... (But IIRC, MySQL has provided an option to allocate a file per table like Postgres relatively recently.)

FWIW, it seems safe to use the nodelalloc mount option with ext4 to disable delayed allocation, while xfs doesn't have such an option.

> > Or, can't we just try to do BufTableLookup() one block after what
> smgrnblocks() returns?
> 
> Unfortunately the problem isn't limited to one block.

You're right.  The data file can be extended by multiple blocks between disk writes.


Regards
Takayuki Tsunakawa