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 documented anywhere
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 don't
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 126 get
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
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?
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 :-(),
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
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. You
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
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 could get
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
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
12 matches
Mail list logo
