Skip site navigation (1) Skip section navigation (2)

Re: Minor changes to Recovery related code

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Minor changes to Recovery related code
Date: 2007-03-30 20:34:23
Message-ID: 23242.1175286863@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
"Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> I'd like to make the following changes to recovery related code over the
> next few days/weeks. If anybody insists I do this by freeze or not at
> all, then I'll submit patches for 1,3,4,5,10 before Saturday night. I'd
> rather take a bit more time and do this in one drop and there are some
> code dependencies between these changes and other patches from
> Koichi-san and myself.

Well, I've got a proposal for a pg_proc change that I haven't even started
coding yet, so personally I won't hold you to having the patch submitted
as long as the design is agreed to before feature freeze.  However:

> 2. pg_stop_backup() should wait until all archive files are safely
> archived before returning

Not sure I agree with that one.  If it fails, you can't tell whether the
action is done and it failed while waiting for the archiver, or if you
need to redo it.

> 6. refactor recovery.conf so that it uses a GUC-like parser

I would suggest that after feature freeze is not the time for code
beautification efforts like this.  (I rather doubt that it's worth doing
at all actually, but definitely not now.)

> 7. refactor all xlog _desc routines into one module, so these can be
> more easily used by xlogviewer utility

Even more so.

> 8. get xlogviewer utility a freshen-up so it can be part of main
> release, possibly including further refactoring of xlog.c

This is not happening for 8.3, either.

> 10. Changes to ensure WAL-avoiding operations and hot backups cannot be
> executed simultaneously. One of these two options, ISTM:
> b) Introduce a new parameter, archive_mode = on | off that can only be
> set at server start. If archive_mode = on then XLogArchivingActive();
> archiving only takes place when archive_command is not ''. This allows
> archive_command to be changed while server running, yet without any
> danger from WAL-avoiding operations.

I think I'd go with (b) since a lot of people felt it should've been
like that from the beginning, and found the magic "empty string"
behavior confusing.

> [7 & 8 would be complete by about 5-6 weeks from now. Others much
> earlier]

We are hoping to go beta in less time than that.  While I'm willing to
cut a little slack, anything you can't submit before about mid-April
is not going to make it into 8.3.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2007-03-30 20:35:50
Subject: Re: [PATCHES] Full page writes improvement, code update
Previous:From: David FetterDate: 2007-03-30 20:23:58
Subject: Re: Arrays of Complex Types

pgsql-patches by date

Next:From: Tom LaneDate: 2007-03-30 20:35:50
Subject: Re: [PATCHES] Full page writes improvement, code update
Previous:From: David FetterDate: 2007-03-30 20:23:58
Subject: Re: Arrays of Complex Types

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group