RE: [Patch] Optimize dropping of relation buffers using dlist
От | tsunakawa.takay@fujitsu.com |
---|---|
Тема | RE: [Patch] Optimize dropping of relation buffers using dlist |
Дата | |
Msg-id | TYAPR01MB2990C1DBBC8985E27CC28ADBFE1A0@TYAPR01MB2990.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | Re: [Patch] Optimize dropping of relation buffers using dlist (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
RE: [Patch] Optimize dropping of relation buffers using dlist
|
Список | pgsql-hackers |
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 datafiles... (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 suchan 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
В списке pgsql-hackers по дате отправления: