Possible work-around for 9.1 partial vacuum bug?
If I'm understanding the vacuum truncate bug correctly, it can be avoided if every 2^31 transactions[1]Obviously open transactions mean 2^31 isn't exact. -- Jim C. Nasby, Data Architect jim@nasby.net 512.569.9461 (cell) http://jim.nasby.net you:
SET vacuum_freeze_table_age = 0;
VACUUM FREEZE;
table_age = 0 disables partial vacuum and then everything[1]Obviously open transactions mean 2^31 isn't exact. -- Jim C. Nasby, Data Architect jim@nasby.net 512.569.9461 (cell) http://jim.nasby.net gets frozen, eliminating the risk. Or am I missing something?
[1]: Obviously open transactions mean 2^31 isn't exact. -- Jim C. Nasby, Data Architect jim@nasby.net 512.569.9461 (cell) http://jim.nasby.net
--
Jim C. Nasby, Data Architect jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Dec 9, 2013 at 6:33 AM, Jim Nasby <jim@nasby.net> wrote:
If I'm understanding the vacuum truncate bug correctly, it can be avoided if
every 2^31 transactions[1] you:SET vacuum_freeze_table_age = 0;
VACUUM FREEZE;table_age = 0 disables partial vacuum and then everything[1] gets frozen,
eliminating the risk. Or am I missing something?
Yes, this will fix any latent error by forcing a freeze on all the
rows of all tables, but not the ones that already happened if your
system has already done more than 2^31 transactions. In this case take
care of any constraint violation.
Regards,
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers