Re: [BUGS] BUG #3110: Online Backup introduces Duplicate OIDs
"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 recovery.conf file, the duplicate records do NOT > exist. > Therefore it seems there is no corruption in the WAL files. The problem > must be in the PITR processing of the online backup file. ... or there's something wrong with your backup procedure. I hadn't looked closely at that point before, but I see you describe it as > 3. Issue pg_start_backup() > 4. Save off the data cluster > 5. Issue pg_stop_backup() > 6. Collect the WAL files > 7. Create a big hairy tar file with the stuff from items 4 and 6. > 8. Take the big hairy tar file to another server running the same pg > 8.2.3, untar and start postgres AFAICS this procedure is *not* suggested anywhere in our documentation. What's bothering me about it is that I don't see anything guaranteeing that you have a full set of WAL files back to pg_start_backup(). If checkpoints occur during step 4, as is virtually certain given you say step 4 takes 20 minutes, then WAL files you need will get renamed/recycled. What are you doing to "collect the WAL files" exactly? Also, what do you consider to be an "offline backup", and what's different in your process for creating that? regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] BUG #3110: Online Backup introduces Duplicate OIDs
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 the WAL files. The problem must be in the PITR processing of the online backup file. - r.
Re: [BUGS] alter column type (from timestamp to date) violates not null
Michael Fuhr <[EMAIL PROTECTED]> writes: > On Fri, Mar 09, 2007 at 04:55:59AM -0800, psmith wrote: >> When change a column type from timestamp to date, the 'infinity' and '- >> infinity' values will be NULL. Even if the column has a not null >> constraint. > This appears to be fixed already: http://archives.postgresql.org/pgsql-bugs/2006-07/msg00015.php http://archives.postgresql.org/pgsql-committers/2006-07/msg00067.php regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] alter column type (from timestamp to date) violates not null
On Fri, Mar 09, 2007 at 04:55:59AM -0800, psmith wrote: > When change a column type from timestamp to date, the 'infinity' and '- > infinity' values will be NULL. Even if the column has a not null > constraint. [...] >version > -- > PostgreSQL 8.1.0 on i486-pc-linux-gnu, compiled by GCC cc (GCC) 4.0.3 > 20051023 (prerelease) (Debian 4.0.2-3) > (1 sor) This appears to be fixed already: test=> alter table a alter t type date; ERROR: column "t" contains null values test=> select version(); version --- PostgreSQL 8.1.8 on sparc-sun-solaris2.9, compiled by GCC gcc (GCC) 3.4.2 (1 row) -- Michael Fuhr ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
