On Tuesday 09 March 2004 17:38, Simon Riggs wrote:
> >Richard Huxton
> >
> > On Monday 08 March 2004 23:28, Simon Riggs wrote:
> > > PITR Functional Design v2 for 7.5
> > > Review of current Crash Recovery
> >
> > Is there any value in putting this section on techdocs or similar? We
>
> do
>
> > ge
>Hannu Krosing
> Josh Berkus kirjutas T, 09.03.2004 kell 19:46:
> > In my personal experience, the *primary* use of PITR is recovery
from
> User
> > Error. For example, with one SQL Server 7.0 installation for a law
> firm,
> > I've made use of PITR 4 times over the last 4 years: once was
because
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> What I think is possible is the following (continuous backup of WAL assumed):
> - disable VACUUM
> - issue CHECKPOINT "C1"
> - backup all files
> - reenable VACUUM
> - restore files
> - adapt pg_control (checkpoint "C1")
> - recover WAL unt
Josh Berkus kirjutas T, 09.03.2004 kell 19:46:
> In my personal experience, the *primary* use of PITR is recovery from User
> Error. For example, with one SQL Server 7.0 installation for a law firm,
> I've made use of PITR 4 times over the last 4 years: once was because and HDD
> failed, the
> > To clarify:
> > I'd expect a cluster to be workable, if I
> > - disable VACUUM until backup completed
> > - issue CHECKPOINT
> > - backup clog (CHECKPOINT and backup clog are the "backup checkpoint")
> > - backup all datafiles (which include at least all completed transaction
> > data at chec
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
To clarify:
I'd expect a cluster to be workable, if I
- disable VACUUM until backup completed
- issue CHECKPOINT
- backup clog (CHECKPOINT and backup clog are the "backup checkpoint")
- backup all datafiles (which include at least all co
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Why is that a useful approach? You might as well shut down the
postmaster and do a cold filesystem backup,
We're talking about *hot* backup, aren't we?
Exactly. The approach you're sketching can't wor
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Why is that a useful approach? You might as well shut down the
>> postmaster and do a cold filesystem backup,
>>
> We're talking about *hot* backup, aren't we?
Exactly. The approach you're sketching can't work for hot backup,
becau
> The only way we can support file-level hot backup is in conjunction with
> PITR-style WAL log archiving. It is okay for the data area dump to be
> inconsistent, so long as your recovery process includes replay of WAL
> starting at some checkpoint before the filesystem dump started, and
> extend
> From: Josh Berkus [mailto:[EMAIL PROTECTED]
> > SIGHUP - seems to allow different parameter settings in each backend
>
> Nope. SIGHUP means that you need to send a HUP to the postmaster,
such
> as
> you would with changes to pg_hba.conf.
>
> > SUSET - maybe what you're looking for???
>
>
>Josh Berkus [mailto:[EMAIL PROTECTED]
> > wal_archive_policy and enable/disable archiving accordingly. This
> > parameter can only be changed at server start. (This is required
because
> > the initial step of archiving each xlog is performed by the backend;
if
> > this were changeable after boot,
Andreas Pflug <[EMAIL PROTECTED]> writes:
> To clarify:
> I'd expect a cluster to be workable, if I
> - disable VACUUM until backup completed
> - issue CHECKPOINT
> - backup clog (CHECKPOINT and backup clog are the "backup checkpoint")
> - backup all datafiles (which include at least all completed
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
When I'm doing a file level hot backup, I can't be sure about the backup
order. To be sure the cluster is in a consistent state regarding
checkpoints, pg_clog must be the first directory backed up.
You are going off in the wrong d
>Josh Berkus [mailto:[EMAIL PROTECTED]
> First off, let me compliment you on such a thorough proposal. I'm
> feeling very enthusiastic about 7.5 PITR
Thank you, though please realise that I am in many ways summarising a
wide range of suggestions and earlier work into a coherent whole.
Me too! I
>Richard Huxton
> On Monday 08 March 2004 23:28, Simon Riggs wrote:
> > PITR Functional Design v2 for 7.5
> > Review of current Crash Recovery
>
> Is there any value in putting this section on techdocs or similar? We
do
> get a
> small but steady trickle of people asking for details on internals,
Simon,
> SIGHUP - seems to allow different parameter settings in each backend
Nope. SIGHUP means that you need to send a HUP to the postmaster, such as
you would with changes to pg_hba.conf.
> SUSET - maybe what you're looking for???
Yes. This means that it can be changed, at runtime,
>Andreas Pflug
>> Josh Berkus wrote:
> >Related to the above, what I don't see in your paper or the proposed
API
> is a
> >way to coordinate full back-ups and WAL archiving. Obviously, the
PITR
> >Archive is only useful in reference to an existing full backup, so it
is
> >important to be able to
Josh Berkus wrote:
5) Full back-up
Related to the above, what I don't see in your paper or the proposed API is a
way to coordinate full back-ups and WAL archiving. Obviously, the PITR
Archive is only useful in reference to an existing full backup, so it is
important to be able to associate a
Simon,
First off, let me compliment you on such a thourough proposal. I'm feeling
very enthusiastic about 7.5 PITR based on the amount of thought you've given
the project.
Based on throuroughness, I wanted to make a few comments and suggestions.
All of the below are in the category of "extr
On Monday 08 March 2004 23:28, Simon Riggs wrote:
> PITR Functional Design v2 for 7.5
Blimey - that's a long post :-) Thanks for explaining things simply enough
that a non-hacker like me can understand. Well - almost understand ;-)
> Review of current Crash Recovery
Is there any value in puttin
20 matches
Mail list logo
