| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Dan Gorman <dgorman(at)hi5(dot)com> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, "Koichi Suzuki" <suzuki(dot)koichi(at)oss(dot)ntt(dot)co(dot)jp>, "Toru SHIMOGAKI" <shimogaki(dot)toru(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: PITR Backups |
| Date: | 2007-06-25 16:34:18 |
| Message-ID: | 367.1182789258@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Dan Gorman <dgorman(at)hi5(dot)com> writes:
> Jun 21 00:39:43 sfmedstorageha001 postgres[3506]: [9-1] 2007-06-21
> 00:39:43 PDTLOG: redo done at 71/99870670
> Jun 21 00:39:43 sfmedstorageha001 postgres[3506]: [10-1] 2007-06-21
> 00:39:43 PDTWARNING: page 28905 of relation 1663/16384/76718 was
> uninitialized
> ... lots of these ...
> Jun 21 00:39:43 sfmedstorageha001 postgres[3506]: [40-1] 2007-06-21
> 00:39:43 PDTPANIC: WAL contains references to invalid pages
(BTW, you'll find putting a space at the end of log_line_prefix
does wonders for log readability.)
Reformatting and sorting, we have
WARNING: page 3535207 of relation 1663/16384/33190 was uninitialized
WARNING: page 3535208 of relation 1663/16384/33190 did not exist
WARNING: page 3535209 of relation 1663/16384/33190 did not exist
WARNING: page 800226 of relation 1663/16384/33204 did not exist
WARNING: page 17306 of relation 1663/16384/76710 did not exist
WARNING: page 13626 of relation 1663/16384/76716 did not exist
WARNING: page 28900 of relation 1663/16384/76718 was uninitialized
WARNING: page 28902 of relation 1663/16384/76718 was uninitialized
WARNING: page 28903 of relation 1663/16384/76718 was uninitialized
WARNING: page 28904 of relation 1663/16384/76718 was uninitialized
WARNING: page 28905 of relation 1663/16384/76718 was uninitialized
WARNING: page 28906 of relation 1663/16384/76718 was uninitialized
WARNING: page 28907 of relation 1663/16384/76718 was uninitialized
WARNING: page 28908 of relation 1663/16384/76718 was uninitialized
WARNING: page 28909 of relation 1663/16384/76718 was uninitialized
WARNING: page 28910 of relation 1663/16384/76718 was uninitialized
WARNING: page 28911 of relation 1663/16384/76718 was uninitialized
WARNING: page 28912 of relation 1663/16384/76718 was uninitialized
WARNING: page 28913 of relation 1663/16384/76718 was uninitialized
WARNING: page 28914 of relation 1663/16384/76718 was uninitialized
WARNING: page 28915 of relation 1663/16384/76718 was uninitialized
WARNING: page 28916 of relation 1663/16384/76718 was uninitialized
WARNING: page 28917 of relation 1663/16384/76718 was uninitialized
WARNING: page 28918 of relation 1663/16384/76718 was uninitialized
WARNING: page 26706 of relation 1663/16384/76719 was uninitialized
WARNING: page 26708 of relation 1663/16384/76719 was uninitialized
WARNING: page 26710 of relation 1663/16384/76719 was uninitialized
WARNING: page 26711 of relation 1663/16384/76719 was uninitialized
WARNING: page 26712 of relation 1663/16384/76719 was uninitialized
WARNING: page 26713 of relation 1663/16384/76719 was uninitialized
So the problems were pretty localized, probably at the ends of these
files. Can you go back to the source database and check which
tables these are --- match the last number cited in each line
against pg_class.relfilenode? Are they tables or indexes, and
about how big are they?
A possible explanation is we stopped scanning WAL before reaching
records that truncated or dropped these tables. But it's not clear why.
Could we see the last few log lines before the "redo done" one?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2007-06-25 16:56:06 | Re: PITR Backups |
| Previous Message | Simon Riggs | 2007-06-25 16:23:18 | Re: PITR Backups |