On Tuesday 18 November 2008 16:46:23 Alvaro Herrera wrote: > Arctic Toucan wrote: > > If I "know" that there are no more inserts going into those > > partitioned tables, can I do a bulk change of their relfrozenxids > > setting them back 500million transactions without causing problems? > > This will mean that the relfrozenxid is not representative of the row > > versions, but does that matter in this case(Essentially static > > stables)? > > The safest most current value you can use is that of the oldest > transaction currently running (also known as RecentXmin in the code). > If you choose anything older than that you're safe too. > > I don't think you can obtain RecentXmin in SQL (short of writing a C > function) > Hmm, I have a very similar problem on some of our larger dbs with years of archival data. I'm of the thought that someday I will have a problem that my db would grow large enough that it takes longer to vacuum the archival data (for purposes of advancing relfrozenxid, the data is never modified) than it takes to run through 2 billion transactions. Sounds like the solution might be to write such a C function to just update this directly and run that in cron, and avoid the vacuum mess. -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
