The following bug has been logged online:
Bug reference: 4566
Logged by: Randy Isbell
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.4
Operating system: FreeBSD 6.2
Description:pg_stop_backup() reports incorrect STOP WAL LOCATION
Details:
An inconsistency
Tom Lane <[EMAIL PROTECTED]> writes:
> BTW, the backup process is supposed to result in backup_label being
> present in the filesystem dump, so that you'd have had to go out of your
> way for it to NOT be present (which is why we didn't think it needed
> much documentation). What exactly was happ
cking this down. I believe we can safely
say this is NOT a bug, and close this thread.
Regards,
- r.
Randy Isbell
Technical Leader
Linksys One - SBSBU
2200 E Pres Geo Bush Tnpk
RCDN4/N2-115
Richardson, TX 75082
Office:972.813.1410
Cell: 817.239.3941
eMail:[EMAIL PROTECTED]
On Mar 12, 2007, at 8:08 PM, Tom Lane wrote:
Randy Isbell <[EMAIL PROTECTED]> writes:
One thing I do find interesting: while the backup created with my
"online" / Chap 23.3 processing contains 18 WAL files, only the last
3 (most recent) are used during the recovery process.
On Mar 10, 2007, at 5:02 PM, Tom Lane wrote:
"Randy Isbell \(jisbell\)" <[EMAIL PROTECTED]> writes:
I found that if I take an offline backup created around the same
time as
my online backup, roll forward the transaction log files included
in the
offline backup using a re
A bit more information.
I found that if I take an offline backup created around the same time as my
online backup, roll forward the transaction log files included in the offline
backup using a recovery.conf file, the duplicate records do NOT exist.
Therefore it seems there is no corruption in
Answers inline.
On Mar 7, 2007, at 3:54 PM, Tom Lane wrote:
Randy Isbell <[EMAIL PROTECTED]> writes:
Here you go:
SELECT
ctid,xmin,xmax,cmin,cmax,oid,*
Thanks. This is real interesting, because none of the rows have
xmax/cmax set, so it doesn't appear that they were me
> Question for Randy -- is this plain PostgreSQL, or are you using
some,
> hmmm, proprietary derivate of it?
Good question, but this is the plain vanilla version of 8.2.3.
My latest intel says the proprietary derivative in not currently
available at 8.2.3.
- r.
Randy Isbell
Tec
ar 6, 2007, at 11:43 AM, Tom Lane wrote:
"Randy Isbell" <[EMAIL PROTECTED]> writes:
When restoring the output of an online backup, many tables now have
duplicate OID values / primary keys, viz:
...
sn=# reindex table at_dns;
ERROR: could not create unique index
I'm confused
The following bug has been logged online:
Bug reference: 3110
Logged by: Randy Isbell
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.3
Operating system: FreeBSD 6.1 i386
Description:Online Backup introduces Duplicate OIDs
Details:
This issue is observed
10 matches
Mail list logo
