Re: pgsql: Avoid tricky race condition recording XLOG_HINT - Mailing list pgsql-committers

From Andres Freund
Subject Re: pgsql: Avoid tricky race condition recording XLOG_HINT
Date
Msg-id 20130408145403.GA29465@awork2.anarazel.de
Whole thread Raw
In response to Re: pgsql: Avoid tricky race condition recording XLOG_HINT  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-committers
On 2013-04-08 10:47:50 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > On 8 April 2013 15:29, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> Just for the record, the right way to handle that kind of change is to
> >> change XLOG_PAGE_MAGIC, not catversion.  A database's catalog version
> >> might not be available to code that is inspecting WAL files and would
> >> like to know what format it should expect.
>
> > I was so happy Andres had remembered to bump the catversion like I often
> > do, it didn't occur to me it was the wrong one. My bad, sorry.

Sorry for that.

> No problem.  XLOG_PAGE_MAGIC is already different from what it was in
> 9.2, so it's mostly academic whether or not we bump it again during
> the devel cycle.

I just didn't want anybodys devel instance crashing because it accessed
record data that previously didn't exist. XLOG_PAGE_MAGIC space looks so
much more sparse than catversion's ;)

Greetings,

Andres Freund

--
 Andres Freund                       http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgsql: Avoid tricky race condition recording XLOG_HINT
Next
From: Alvaro Herrera
Date:
Subject: Re: pgsql: README comments on checksums on page holes.