From: Tom Lane on
Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> writes:
> Tom Lane wrote:
>> Isn't the above statement complete nonsense? There's nothing to stop
>> the DBA from issuing pg_stop_backup() after he restarts the master.

> pg_stop_backup() can't be called if there's no backup in progress.
> Restart cancels it.

Doh, right (not enough caffeine yet).

Given that, I concur this change is a good idea.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Simon Riggs on
On Tue, 2010-04-27 at 18:13 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > If pg_stop_backup() is run it creates the .backup file in the archive.
> > In the absence of that file, we should be able to work out that
> > pg_stop_backup() was not run.
>
> It's just as likely that the file is there even though the backup didn't
> finish, though.

It's possible, but not likely. It would need to break at a very specific
place for that to be the case. Whereas the test I explained would work
for about 99% of the time between start and stop backup, except for the
caveat I explained also. I'm not sure that pointing out a minor hole
stops it being a worthwhile test? Surely if you care to fix the problem
then a better test can only be a good thing?

--
Simon Riggs www.2ndQuadrant.com


--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Heikki Linnakangas on
Simon Riggs wrote:
> On Tue, 2010-04-27 at 18:13 +0300, Heikki Linnakangas wrote:
>> Simon Riggs wrote:
>>> If pg_stop_backup() is run it creates the .backup file in the archive.
>>> In the absence of that file, we should be able to work out that
>>> pg_stop_backup() was not run.
>> It's just as likely that the file is there even though the backup didn't
>> finish, though.
>
> It's possible, but not likely. It would need to break at a very specific
> place for that to be the case. Whereas the test I explained would work
> for about 99% of the time between start and stop backup, except for the
> caveat I explained also.

I don't understand how you arrived at that figure. Roughly speaking,
there's two possibilities: backup_label is backed up before the bulk of
the data in base-directory or tablespaces, in which case it will almost
certainly be included in the backup, or it will be backed up after the
bulk of the data, in which case it will almost certainly not be included
if the backup is stopped prematurely. I don't know which is more common,
but both seem plausible.

> I'm not sure that pointing out a minor hole
> stops it being a worthwhile test? Surely if you care to fix the problem
> then a better test can only be a good thing?

Yeah, it might be worthwhile if it's not a lot of code.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Simon Riggs on
On Tue, 2010-04-27 at 20:14 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Tue, 2010-04-27 at 18:13 +0300, Heikki Linnakangas wrote:
> >> Simon Riggs wrote:
> >>> If pg_stop_backup() is run it creates the .backup file in the archive.
> >>> In the absence of that file, we should be able to work out that
> >>> pg_stop_backup() was not run.
> >> It's just as likely that the file is there even though the backup didn't
> >> finish, though.
> >
> > It's possible, but not likely. It would need to break at a very specific
> > place for that to be the case. Whereas the test I explained would work
> > for about 99% of the time between start and stop backup, except for the
> > caveat I explained also.
>
> I don't understand how you arrived at that figure.

You're talking about the backup_label file, I'm talking about
the .backup file in the archive.

--
Simon Riggs www.2ndQuadrant.com


--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Heikki Linnakangas on
Simon Riggs wrote:
> On Tue, 2010-04-27 at 20:14 +0300, Heikki Linnakangas wrote:
>> Simon Riggs wrote:
>>> On Tue, 2010-04-27 at 18:13 +0300, Heikki Linnakangas wrote:
>>>> Simon Riggs wrote:
>>>>> If pg_stop_backup() is run it creates the .backup file in the archive.
>>>>> In the absence of that file, we should be able to work out that
>>>>> pg_stop_backup() was not run.
>>>> It's just as likely that the file is there even though the backup didn't
>>>> finish, though.
>>> It's possible, but not likely. It would need to break at a very specific
>>> place for that to be the case. Whereas the test I explained would work
>>> for about 99% of the time between start and stop backup, except for the
>>> caveat I explained also.
>> I don't understand how you arrived at that figure.
>
> You're talking about the backup_label file, I'm talking about
> the .backup file in the archive.

Oh, the backup history file. We stopped relying on that with the
introduction of the end-of-backup record, to make life easier for
streaming replication, and because it's simpler anyway. I don't think we
should go back to it.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: pg_migrator
Next: [HACKERS] CP949 for EUC-KR?