Re: Where art thou pg_clog? - Mailing list pgsql-general

From Casey Duncan
Subject Re: Where art thou pg_clog?
Date
Msg-id A79B2F2F-91F2-4B60-990E-87205B84D4F7@pandora.com
Whole thread Raw
In response to Re: Where art thou pg_clog?  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Where art thou pg_clog?  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-general
On Feb 15, 2007, at 5:50 PM, Alvaro Herrera wrote:

> Casey Duncan wrote:
>>
>> On Feb 15, 2007, at 5:21 PM, Alvaro Herrera wrote:
>>
>>> Casey Duncan wrote:
>
>>> To fix the problem, set pg_database.datallowconn=true for template0,
>>> then connect to it and do a VACUUM FREEZE.  Then set
>>> datallowconn=false
>>> again.
>>
>> Do you mean to do this after upgrading to 8.1.8? If I try than in
>> 8.1.5, I get (unsurprisingly):
>>
>> % psql -U postgres template0 -c "vacuum freeze"
>> ERROR:  could not access status of transaction 2565134864
>> DETAIL:  could not open file "pg_clog/098E": No such file or
>> directory
>
> Hum, yeah, I forgot to mention that you need to create the 098E
> pg_clog
> segment for that to work at all :-)  Fill it with byte 0x55 till the
> needed position, which is the bit pattern for "all transactions
> committed".  I'd make sure to remove it manually after the freeze is
> done, just in case!  (I think the system would remove it at next
> checkpoint, but anyway.)

That seems a bit scary to do on a running production server. Could I
get away with dropping the template0 database and loading one from
another identical pg instance (or a new one) or will that freak
things out?

-Casey

pgsql-general by date:

Previous
From: Lou Duchez
Date:
Subject: Re: requests / suggestions to help with backups
Next
From: "Rafa Comino"
Date:
Subject: problems: slow queries with tsearch2