Re: [GENERAL] [HACKERS] getting status transaction error

2007-02-06 Thread Alvaro Herrera
Merlin Moncure wrote:

 ya, it doesn't seem to match, as this seems to be repeating quite
 regularly.  interesting that my 'clog' files start at 06B6 and count
 up. 0207 is way off the charts.
 
 a lot of applications are hitting this database, and so far everything
 seems to be running ok (i found this log msg by accident), but I am
 now officially very nervous.

I don't think there's much cause for concern here.  If my theory is
correct, this is an autovacuum bug which was fixed in 8.1.7.

What I'd do is create a 0207 clog file, fill it with 0x55 (which is
transactions committed for all transactions in that interval), and do
a VACUUM FREEZE on that database.  You'll need to set
pg_database.datallowconn=true beforehand.

Of course, I'd copy the files somewhere else and experiment on a scratch
postmaster, running on a different port, just to be sure ...

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [GENERAL] [HACKERS] getting status transaction error

2007-02-06 Thread Merlin Moncure

n 2/6/07, Alvaro Herrera [EMAIL PROTECTED] wrote:

Merlin Moncure wrote:

 ya, it doesn't seem to match, as this seems to be repeating quite
 regularly.  interesting that my 'clog' files start at 06B6 and count
 up. 0207 is way off the charts.

 a lot of applications are hitting this database, and so far everything
 seems to be running ok (i found this log msg by accident), but I am
 now officially very nervous.

I don't think there's much cause for concern here.  If my theory is
correct, this is an autovacuum bug which was fixed in 8.1.7.

What I'd do is create a 0207 clog file, fill it with 0x55 (which is
transactions committed for all transactions in that interval), and do
a VACUUM FREEZE on that database.  You'll need to set
pg_database.datallowconn=true beforehand.

Of course, I'd copy the files somewhere else and experiment on a scratch
postmaster, running on a different port, just to be sure ...


thats a big help, database is actually fairly huge, so I may have to
just go ahead and do it.   I'm off to a meeting, but I'll check back
when I'm done and assuming nobody else says 'don't do that', I'll try
the fix and post back with the result.

thanks all,
merlin

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [GENERAL] [HACKERS] getting status transaction error

2007-02-06 Thread Alvaro Herrera
Merlin Moncure wrote:
 n 2/6/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
 Merlin Moncure wrote:
 
  ya, it doesn't seem to match, as this seems to be repeating quite
  regularly.  interesting that my 'clog' files start at 06B6 and count
  up. 0207 is way off the charts.
 
  a lot of applications are hitting this database, and so far everything
  seems to be running ok (i found this log msg by accident), but I am
  now officially very nervous.
 
 I don't think there's much cause for concern here.  If my theory is
 correct, this is an autovacuum bug which was fixed in 8.1.7.
 
 What I'd do is create a 0207 clog file, fill it with 0x55 (which is
 transactions committed for all transactions in that interval), and do
 a VACUUM FREEZE on that database.  You'll need to set
 pg_database.datallowconn=true beforehand.
 
 Of course, I'd copy the files somewhere else and experiment on a scratch
 postmaster, running on a different port, just to be sure ...
 
 thats a big help, database is actually fairly huge, so I may have to
 just go ahead and do it.   I'm off to a meeting, but I'll check back
 when I'm done and assuming nobody else says 'don't do that', I'll try
 the fix and post back with the result.

Well, you don't need to copy all databases for the test area, just the
base/oid dir for template0 (along with all pg_xlog and pg_clog files,
etc, but these shouldn't be as big as all the other stuff in base/).

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match