Re: Weird WAL problem - 9.0.3

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Rafael Martinez <r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no>
Cc: Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Weird WAL problem - 9.0.3
Date: 2011-04-13 16:58:23
Message-ID: 7064.1302713903@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Rafael Martinez <r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no> writes:
> But this doesn't explain the WAL files not been created/recycled
> time-ordered. I wonder if this happened because the partition got full
> while the WALs were created/recycled?

When a checkpoint finishes, it scans the pg_xlog directory to find WAL
files that are no longer needed (because they're before the checkpoint's
WAL replay point). It will either rename them "forward" to become ready
for future use, or delete them if there are already enough future WAL
files present (as determined by checkpoint_segments). The order in
which old segments get renamed to be future ones is basically chance,
because it's determined by the order in which readdir() visits them.
So there's no reason to think that their file timestamps will be in
order.

I would expect WAL files that are *behind* the current write point to
have increasing write timestamps. But not those ahead.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message raghu ram 2011-04-13 17:53:24 Streaming Replication limitations
Previous Message David Johnston 2011-04-13 16:57:20 Re: updating rows which have a common value forconsecutive dates