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 mdextend it only writes out the requested block. Any blocks between the end of the table and the requested block are *not* written out. We count on the OS to implicitly fill those blocks with zeros. 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. 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? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
