Re: XLog changes for 9.3

On Thursday, June 07, 2012 07:03:32 PM Simon Riggs wrote:
> On 7 June 2012 17:12, Heikki Linnakangas
>
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> > On 07.06.2012 18:51, Simon Riggs wrote:
> >> On 7 June 2012 14:50, Heikki Linnakangas
> >>
> >> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> >>> These changes will help the XLogInsert scaling patch
> >>
> >> ...and as I'm sure you're aware will junk much of the replication code
> >> and almost certainly set back the other work that we have brewing for
> >> 9.3. So this is a very large curve ball you're throwing there.
> >
> > I don't think this has much impact on what you're doing (although it's a
> > bit hard to tell without more details). The way WAL records work is the
> > same, it's just the code that lays them out on a page, and reads back
> > from a page, that's changed. And that's fairly isolated in xlog.c.
> I wasn't worried about the code overlap, but the subsidiary breakage
> looks pretty enormous to me.
The xlog arithmetic will still be encapsulated, so not much difference there.
Removing reading of XLogContRecord isn't complicated and would result in less
code. Shouldn't be much more than that.

> Anything changing filenames will break every HA config anybody has
> anywhere. So you can pretty much kiss goodbye to the idea of
> pg_upgrade. For me, this one thing alone is sufficient to force next
> release to be 10.0.
Hm? Wal isn't relevant for pg_upgrade. And the HA setups should rely on
archive_command and such and not do computation of the next/last name. I would
guess removing that corner-case actually fixes more tools than it breaks.

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