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
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 |