X-Original-To: pgsql-docs-postgresql.org@localhost.postgresql.org Received: from localhost (mx2.hub.org [200.46.204.254]) by postgresql.org (Postfix) with ESMTP id 4780F11F6258 for ; Sat, 15 Apr 2006 13:24:58 -0300 (ADT) X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 required=5 tests=[AWL=0.405, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] Received: from postgresql.org ([200.46.204.71]) by localhost (mx2.hub.org [200.46.204.254]) (amavisd-new, port 10024) with ESMTP id jKuDyzyKBTpo for ; Sat, 15 Apr 2006 13:24:55 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from candle.pha.pa.us (candle.pha.pa.us [70.90.9.53]) by postgresql.org (Postfix) with ESMTP id DFA9711F6239 for ; Sat, 15 Apr 2006 13:24:54 -0300 (ADT) Received: (from pgman@localhost) by candle.pha.pa.us (8.11.6/8.11.6) id k3FGOj525540; Sat, 15 Apr 2006 12:24:45 -0400 (EDT) From: Bruce Momjian Message-Id: <200604151624.k3FGOj525540@candle.pha.pa.us> Subject: Re: Proposed doc-patch: Identifying the Current WAL file In-Reply-To: <9932.1145030835@sss.pgh.pa.us> To: Tom Lane Date: Sat, 15 Apr 2006 12:24:45 -0400 (EDT) CC: Richard Huxton , pgsql-docs@postgresql.org X-Mailer: ELM [version 2.4ME+ PL121 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Archive-Number: 200604/8 X-Sequence-Number: 3507 Tom Lane wrote: > Bruce Momjian writes: > > Richard Huxton wrote: > >> To identify the current, partially-filled WAL segment, sort first by > >> mtime and second by file name. That is, take the latest mtime among the > >> properly-named files, breaking ties by taking the higher filename. > > > I am confused by this. Why do both mtime and file name need to be > > checked? > > Because recycled WAL segments are renamed to have higher file names than > the currently-in-use segment. So you can't depend on file name first. > However, shortly after a segment switch two WAL segments could have the > same mtime (to within whatever the mtime granularity is, typ. 1 second). > > The proposed rule should be OK as long as checkpoints (and ensuing > renames) can't occur oftener than the mtime granularity. If you're > checkpointing more than once a second, well, you need help ... I am trying to figure out how this could even be done in a shell script. 'ls -lt' is going to show: -rw-r--r-- 1 root postgres 0 Apr 15 11:56 x1 -rw-r--r-- 1 root postgres 0 Apr 15 11:56 x2 -rw-r--r-- 1 root postgres 0 Apr 15 11:56 x3 but this might be with second resolution: -rw-r--r-- 1 root postgres 0 Apr 15 11:56:47 x1 -rw-r--r-- 1 root postgres 0 Apr 15 11:56:47 x2 -rw-r--r-- 1 root postgres 0 Apr 15 11:56:34 x3 or it might be: -rw-r--r-- 1 root postgres 0 Apr 15 11:56:47 x1 -rw-r--r-- 1 root postgres 0 Apr 15 11:56:34 x2 -rw-r--r-- 1 root postgres 0 Apr 15 11:56:25 x3 In the first case, x2 is current, having be just switched to from x1, while in the second case, x1 is current. In BSD, you can use ls -ltT to see the seconds, but in Linux it is something different, and I am sure there are some operating systems that don't allow you to see the seconds at all. What general command-line solution can we propose for this process? And if we can't provide one, should we supply an SQL function to return the current WAL name? -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +