Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 1F5482E004A for ; Thu, 27 Mar 2008 04:32:29 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 64079-06 for ; Thu, 27 Mar 2008 04:32:22 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from svr2.hagander.net (svr2.hagander.net [88.198.128.226]) by postgresql.org (Postfix) with ESMTP id 577D22E0039 for ; Thu, 27 Mar 2008 04:32:26 -0300 (ADT) Received: from dynamic.hagander.net ([127.0.0.1]) (encrypted and authenticated) by svr2.hagander.net (Postfix) with ESMTP id 2CB1DDCC9C8; Thu, 27 Mar 2008 08:32:24 +0100 (CET) Received: from mha-laptop (localhost [127.0.0.1]) by mha-laptop.hagander.net (Postfix) with ESMTP id 4AA27FF09C; Thu, 27 Mar 2008 08:33:42 +0100 (CET) Date: Thu, 27 Mar 2008 08:33:41 +0100 From: Magnus Hagander To: Tom Lane Cc: Andrew Dunstan , Alvaro Herrera , Gregory Stark , "Zubkovsky, Sergey" , pgsql-hackers@postgresql.org Subject: Re: [DOCS] pg_total_relation_size() and CHECKPOINT Message-ID: <20080327083341.260e222e@mha-laptop> In-Reply-To: <968.1206591222@sss.pgh.pa.us> References: <528853D3C5ED2C4AA8990B504BA7FB850106DF14@sol.transas.com> <21561.1205515308@sss.pgh.pa.us> <87myp1f9a7.fsf@oxford.xeocode.com> <24576.1205524921@sss.pgh.pa.us> <20080326132250.GK5895@alvh.no-ip.org> <47EA5602.6060605@dunslane.net> <21662.1206546092@sss.pgh.pa.us> <47EAE45D.8050902@dunslane.net> <21044.1206580136@sss.pgh.pa.us> <47EB13BF.8080301@dunslane.net> <968.1206591222@sss.pgh.pa.us> X-Mailer: Claws Mail 3.3.1 (GTK+ 2.12.0; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200803/1093 X-Sequence-Number: 115894 On Thu, 27 Mar 2008 00:13:42 -0400 Tom Lane wrote: > Andrew Dunstan writes: > > I suspect that the size reported by stat() is a little delayed > > here, but the file system is keeping proper track of it, so the > > lseek that tries to extend the file fails at the right spot. > > Hmm. If it really works that way, one would hope Microsoft would've > documented that someplace. Can anyone find a statement that Windows' > stat() is not current? I'm not in a position to test it myself now (doing training, and then I'll be off to pg-east...), but it'd be interesting to see if it acts the same way with GetFileSize(), or if it's just stat()... /Magnus