Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id 71C372E0037 for ; Sat, 21 Jun 2008 12:25:29 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 54235-06 for ; Sat, 21 Jun 2008 12:25:26 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by developer.postgresql.org (Postfix) with ESMTP id 439D12E0030 for ; Sat, 21 Jun 2008 12:25:26 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id m5LFPPmM018779; Sat, 21 Jun 2008 11:25:25 -0400 (EDT) To: "Bill Bartlett" cc: pgsql-admin@postgresql.org Subject: Re: PG 8.0.4 - Does Dump + drop_db + reload reset XID to prevent wraparound? In-reply-to: <001401c8d388$4b5d0720$e2171560$@com> References: <001401c8d388$4b5d0720$e2171560$@com> Comments: In-reply-to "Bill Bartlett" message dated "Sat, 21 Jun 2008 06:19:30 -0400" Date: Sat, 21 Jun 2008 11:25:25 -0400 Message-ID: <18778.1214061925@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200806/190 X-Sequence-Number: 29528 "Bill Bartlett" writes: > In a PostgreSQL 8.0.4 environment, does dropping the database and > reloading it completely reset the XID information that causes > transaction ID wraparound? I gather from the reference to "d:" that you're running on Windows. You really, really, really need to put an urgent priority on getting off 8.0.x. (Or get off Windows, but I suppose I'm wasting my breath suggesting that.) The rename problem that you're hitting is fixed in 8.2 and up, as are a bunch of other Windows-specific problems that will never be fixed in pre-8.2 branches, because we have abandoned support for those branches on Windows. As for the specific question, I think it'd work as long as template0 has never been unfrozen, but an initdb would be a lot more certain --- and since you apparently have only one user database, there's no difference in how much reload work you'd have to do. Lastly, there is no need to use VACUUM FULL for wraparound protection; plain VACUUM is sufficient. The critical point though is that it has to be a database-wide VACUUM (and done by a superuser); 8.0 doesn't track this at a per-table grain, only per-database. regards, tom lane