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
Hi,
My production server is running PostgreSQL v8.2.3 on CentOS release 5.2
(Final).
I've setup PITR in my production server. For some reason, after setting up
PITR, we're not able to manage and maintain it. Because of this our WAL
archive drive become full (100% use) approximately after 1 mont
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.
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. You can specify the stop point
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
...on the assumption we now have archived xlogs, how do we do recovery?
Default is to put all xlogs back into pg_xlog and then let recovery do
its work...though clearly we all want finer specification than that.
Based upon all our discussions to date...I propose to:
1. put more verbose instrument
23 matches
Mail list logo
