| From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
|---|---|
| To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: xlogreader.c fails with FATAL on a cluster with 4kB block size |
| Date: | 2016-11-12 19:45:55 |
| Message-ID: | e591fd27-ac95-3f1e-51a3-e2bbe9121ed7@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Meh, ignore this report - I've just realized I've been running the
pg_xlogdump binary built for 8kB pages, so the failures are kinda
expected. Sorry about the confusion.
regards
On 11/12/2016 07:52 PM, Tomas Vondra wrote:
> Hi,
>
> I'm running some tests on a cluster with 4kB blocks, and it seems
> there's a bug in xlogreader.c, causing FATAL errors for example when
> running pg_xlogdump:
>
> pg_xlogdump: FATAL: error in WAL record at 48/63970258:
> BKPIMAGE_HAS_HOLE not set, but hole offset 0 length 4096 at 48/63970258
>
> This particular failure comes from "pg_xlogdump --stats", but my guess
> is this means recovery is broken with 4kB blocks (and possibly with some
> other non-standard block sizes).
>
> The standard 8kB blocks seem to be unaffected, as I've done the same
> test on 8kB blocks many times and it never triggered this error.
>
> FWIW the tests were done on bfcd07b4, so fairly recent code.
>
> regards
>
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Janes | 2016-11-12 19:53:25 | Re: Remove the comment on the countereffectiveness of large shared_buffers on Windows |
| Previous Message | Tom Lane | 2016-11-12 19:23:55 | More snapshot-management fun |