Gregory Stark <[EMAIL PROTECTED]> writes:
> Now this only matters if we ever call mdextend on a block which isn't the
> block immediately following the end of file. Is that true?
Only in hash indexes.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hacker
Gregory Stark wrote:
Now this only matters if we ever call mdextend on a block which isn't the
block immediately following the end of file. Is that true?
I don't think so.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hacker
Gregory Stark napsal(a):
On Unix that creates a sparse file where the intervening blocks are not
allocated. When we later write out those blocks the filesystem then has to
allocate space for them. IIRC the bug reports were from Windows. I'm not sure
what NTFS's behaviour with sparse files is.
* Gregory Stark:
> On Unix that creates a sparse file where the intervening blocks are
> not allocated. When we later write out those blocks the filesystem
> then has to allocate space for them.
This seems to happen relatively rarely. Creating temporary holes like
this usually results in heavily
Earlier we saw some bug reports from someone who had a buffer flush fail do to
ENOSPC. We asserted then that that should never happen because when we extend
the relation we write out the new blocks so any ENOSPC errors out to happen at
that point, not when a buffer is flushed.
However looking at
