X-Original-To: pgsql-docs-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id D99F011F6C47 for ; Fri, 14 Apr 2006 13:07:23 -0300 (ADT) X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Score: 0.124 X-Spam-Level: X-Spam-Status: No, score=0.124 required=5 tests=[AWL=0.124] Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id GtmV0tL4kjZz for ; Fri, 14 Apr 2006 13:07:20 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 1770B11F6C3E for ; Fri, 14 Apr 2006 13:07:19 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id k3EG7G7d009933; Fri, 14 Apr 2006 12:07:16 -0400 (EDT) To: Bruce Momjian cc: Richard Huxton , pgsql-docs@postgresql.org Subject: Re: Proposed doc-patch: Identifying the Current WAL file In-reply-to: <200604141544.k3EFiuw20847@candle.pha.pa.us> References: <200604141544.k3EFiuw20847@candle.pha.pa.us> Comments: In-reply-to Bruce Momjian message dated "Fri, 14 Apr 2006 11:44:56 -0400" Date: Fri, 14 Apr 2006 12:07:15 -0400 Message-ID: <9932.1145030835@sss.pgh.pa.us> From: Tom Lane X-Archive-Number: 200604/7 X-Sequence-Number: 3506 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 ... regards, tom lane