Re: vacuum freeze performance, wraparound issues - Mailing list pgsql-admin

From Natalie Wenz
Subject Re: vacuum freeze performance, wraparound issues
Date
Msg-id 55CAE74F-D466-40B9-A4EA-7326778E3783@ebureau.com
Whole thread Raw
In response to Re: vacuum freeze performance, wraparound issues  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-admin
Yes, absolutely! We would dump and reload all of our large databases in a heartbeat if there were an option for a
64-bitxid!  

Another quick question: When this database took itself offline to avoid transaction id wraparound, we opted for a
vacuumfreeze in single-user mode. Was that the right choice? In other words, what is the fastest way to get a database
backonline when this occurs? Maybe a plain vacuum would have been better?  

Thanks!
Natalie


On Aug 12, 2013, at 11:15 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Natalie Wenz <nataliewenz@ebureau.com> writes:
>> ... With the speed postgres is capable of, and the ever-falling prices
>> of storage making larger, faster databases possible, has the possibility
>> of changing the transaction id to a 64-bit (or even 128-bit!) value been
>> considered?
>
> Not terribly seriously --- the penalties from making row headers 8 bytes
> bigger have always seemed to outweigh the advantages.  (128 bits is right
> out; we don't even have 128-bit LSNs.)
>
> We'd probably take a patch to make 64-bit XIDs available as a compile-time
> option, if someone wanted to do the legwork to write and test it.  But
> let me ask you this: if such an option existed, would you be willing to
> dump and reload your database to take advantage of it?  The conversion
> costs of changing row header format seem like they'd discourage exactly
> those people whom such a feature could help.
>
>             regards, tom lane
>
>
> --
> Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-admin



pgsql-admin by date:

Previous
From: Eduardo Morras
Date:
Subject: Re: WTF? 9.2.4 Logs have the wrong day of the week?
Next
From: Tung Thanh
Date:
Subject: global/pg_filenode.map errrors