On Jun 4, 2010, at 7:05 , Gnanakumar wrote:
>> If some of those WAL segments still reside in pg_xlog, you'll either need
> to teach your restore_command to fetch them from there. Note that you cannot
> recover "in reverse".
>
> My pg_xlog/ and walarchive/ directory locations are
> "/usr/local/pgsq
g/ directory, this will
not work out in this situation? Is my understanding right?
-Original Message-
From: Florian Pflug [mailto:f...@phlo.org]
Sent: Thursday, June 03, 2010 8:50 PM
To: gna...@zoniac.com
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] PITR Recovery Question
Hi,
I&#
Hi,
I'll try to answer your questions below, but in the future please post
questions concerning the usage and administration of postgres to pgsql-general
or pgsql-admin. This list focus is the development of new features and bugfixes.
On Jun 3, 2010, at 15:37 , Gnanakumar wrote:
> PITR SETUP DE
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Yea, my question is if you choose "after", do you get everything that
> > happens until the "after" transaction commits, or just when it begins.
> > If I stop after xid 125, and xid 126 starts and stops before 125
> > commits, does 12
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yea, my question is if you choose "after", do you get everything that
> happens until the "after" transaction commits, or just when it begins.
> If I stop after xid 125, and xid 126 starts and stops before 125
> commits, does 126 get restored?
Yes. You
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > When we do a PITR recovery based on xid, does it stop recovery based on
> > the start of the xid or the commit of the xid?
>
> You can stop either "before" or "after" that commit. See
> recovery.conf.sample (I don't think it's docume
Bruce Momjian <[EMAIL PROTECTED]> writes:
> When we do a PITR recovery based on xid, does it stop recovery based on
> the start of the xid or the commit of the xid?
You can stop either "before" or "after" that commit. See
recovery.conf.sample (I don't think it's documented anywhere else
yet :-(),
When we do a PITR recovery based on xid, does it stop recovery based on
the start of the xid or the commit of the xid? And if you say
recovery_target_inclusive =true, does it recover that xid while not
recoverying other xids that are higher but committed sooner than the
target xid?
-
G u i d o B a r o s i o wrote:
8.0 || 7.5??
8.0
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Rod Taylor wrote:
> > You seem to be suggesting that using the id is less useful than the
> > time, but surely it's going to be easier to say "this disaster happened
> > in transaction 123 so lets do a PITR up to 122" than to say "this
>
> Transaction IDs are assigned at transaction start but what
> You seem to be suggesting that using the id is less useful than the
> time, but surely it's going to be easier to say "this disaster happened
> in transaction 123 so lets do a PITR up to 122" than to say "this
Transaction IDs are assigned at transaction start but what you really
want is some ind
On Wed, 2004-08-04 at 19:16, Tom Lane wrote:
> Oliver Elphick <[EMAIL PROTECTED]> writes:
> > How about adding a logging option to put the transaction id on the log
> > for every statement that modifies the database? Would that be a small
> > enough change to be allowed into 8.0?
>
> I think we c
Oliver Elphick <[EMAIL PROTECTED]> writes:
> How about adding a logging option to put the transaction id on the log
> for every statement that modifies the database? Would that be a small
> enough change to be allowed into 8.0?
I think we could get away with adding transaction ID as one of the
av
8.0 || 7.5??
g:)
> The PITR docs that have just been put up say:
>
> But if you want to recover to some previous point in time (say,
> right before the junior DBA dropped your main transaction
> table), just specify the required stopping point in
> recovery.conf.
On Thu, 2004-06-17 at 22:47, Simon Riggs wrote:
> On Wed, 2004-06-16 at 02:49, Tom Lane wrote:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> > > -finalaction refers to what to do when target is reached - the purpose
> > > of this is to allow recovery of a database to occur when we don't have
> > >
On Wed, 2004-06-16 at 02:49, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > -finalaction refers to what to do when target is reached - the purpose
> > of this is to allow recovery of a database to occur when we don't have
> > enough space for all of the xlogs at once, so we need to d
On Wed, 2004-06-16 at 23:50, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Is that something you'd be able to do as a starting point for the other
> > changes? It's easier for a committer to do this, than for me to do it
> > and then another to review it...
>
> I'm up to my eyeball
Simon Riggs <[EMAIL PROTECTED]> writes:
> Is that something you'd be able to do as a starting point for the other
> changes? It's easier for a committer to do this, than for me to do it
> and then another to review it...
I'm up to my eyeballs in tablespaces right now, but if you can wait a
couple
On Wed, 2004-06-16 at 02:49, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Implementation wise, I would expect all of this code to go in xlog.c,
> > with the recovery target code living in ReadRecord().
>
> I'd like to keep it out of there, as xlog.c is far too big and complex
> a
Simon Riggs <[EMAIL PROTECTED]> writes:
> -finalaction refers to what to do when target is reached - the purpose
> of this is to allow recovery of a database to occur when we don't have
> enough space for all of the xlogs at once, so we need to do recovery in
> batches.
It seems to me that this is
20 matches
Mail list logo
