On Thu, 2008-05-01 at 09:57 -0400, Tom Lane wrote:
> AFAICS there is no convenient way in 8.1 to examine the per-database
> last_autovac_time entries, which'd be needed to confirm this theory.
> We should check that just to be sure. Please do the following:
>
> 1. Stop the postmaster.
> 2. Move t
On Wed, 2008-04-30 at 16:43 -0400, Tom Lane wrote:
> Ian Westmacott <[EMAIL PROTECTED]> writes:
> 499 is the value that those columns would have immediately after initdb,
> in an 8.1 database. So what this says is that vacuum has never
> succeeded in updating the values at a
On Wed, 2008-04-30 at 13:07 -0400, Tom Lane wrote:
> Oh, that's really strange. Could we see
>
> select ctid,xmin,* from pg_database
itvtrackdata=> select ctid,xmin,* from pg_database;
ctid | xmin | datname | datdba | encoding | datistemplate |
datallowconn | datconnlimit | datla
On Wed, 2008-04-30 at 12:27 -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I still think that the autovac is dying before completing the task. Did
> > you investigate whether there are "ERROR" messages coming from
> > autovacuum? No PG crashes would happen.
There are no
On Tue, 2008-04-29 at 17:12 -0400, Alvaro Herrera wrote:
> Can you verify whether age(pg_database.datfrozenxid) is shrinking after
> vacuuming? If the age() of a database is higher than the applicable
> max_freeze_age, then it will always be chosen.
One of the databases is about 1.5TB, so that co
On Tue, 2008-04-29 at 16:33 -0400, Alvaro Herrera wrote:
> Is autovacuum dying before being able to finish the vacuuming of
> template1 or the other database?
Not as far as I can tell. There are no indications of any crash or
error in the log file (I just bumped the log level up to debug1). Just
I have a Postgres 8.1.8 system with three databases. Although
autovacuum is enabled (I'm using all default autovacuum configuration
settings) and pg_autovacuum is empty, the logs indicate that only
template1 and one of the three databases are being processed by
autovacuum. Are there other reasons
I just happened to be reading this page from
the 8.1 docs:
"The autovacuum daemon, when enabled, runs
every autovacuum_naptime seconds and
determines which database to process. Any database which is close to transaction
ID wraparound is immediately processed. In this case, autovacuum issue
Mauri, I'm no expert but I can tell you what I know. We
have experienced this same problem, and I asked a
similar question not too long ago.
- This is probably due to some sort of I/O problem. In
our case, it occurs very frequently on reboots, and
it appears to be related to dirty buffers
> In your previous emails, you stated that these errors were seen on
> multiple systems. Multiple systems, configured identically, with
> diverse motherboards/hardware or always identical hardware except for
> the sata/IDE drives?
>
> I ask, because I noted that you are using the Neo 2 ATX mot
Thanks for the tip. Later kernel versions have unrelated problems for
us, but we'll take a look at the filesystem mods and see if we can
backpatch them.
--Ian
> I remember a problem that was fixed in the 2.6.9 kernel concerning XFS
> corruption (shutdowns I think were the worst). Also i
Hi Chris,
> I think it is important to figure out why this is happening. I would
> not want to run any production databases on systems that were failing
> like this.
You and me both :) (in our application though, it is not a total
disaster to lose the last 5 minutes of transactions, it is a
For several weeks now we have been experiencing fairly
severe database corruption upon clean reboot. It is very
repeatable, and the corruption is of the following forms:
ERROR: could not access status of transaction foo
DETAIL: could not open file "bar": No such file or directory
ERROR: inval
On Tue, 2005-04-05 at 11:39, Jim C. Nasby wrote:
> On Tue, Apr 05, 2005 at 11:13:06AM -0400, Ian Westmacott wrote:
> > On Tue, 2005-04-05 at 00:41, Jim C. Nasby wrote:
> > > We'll only answer if you do a write-up on your database. :P
> > >
> > > Seriou
On Tue, 2005-04-05 at 11:34, Tom Lane wrote:
> Ian Westmacott <[EMAIL PROTECTED]> writes:
> > But the question is whether vacuum freezing tables will
> > help me reduce the frequency of a full vacuum, or reduce
> > its cost when we do it? That is, if more transactions
On Tue, 2005-04-05 at 02:42, Tom Lane wrote:
> "Ian Westmacott" <[EMAIL PROTECTED]> writes:
> > The problem is that we are writing rows every 1/15 second, 24x7. There
> > is no down time. I'm wondering if there is any way to avoid vacuuming
> > the ol
On Tue, 2005-04-05 at 00:41, Jim C. Nasby wrote:
> We'll only answer if you do a write-up on your database. :P
>
> Seriously, those are some seriously big numbers. What else is the
> database doing? What hardware is it running on?
We run on a dual 3.2GHz P4 with 2GB RAM, but are still
finalizing
I have a near-real-time system writing into a Postgres 7.4.2 database
on the order of 340 million rows per day in about 300 million
transactions. So we quickly bump up against the XID wrap-around
issue. To address this, we divide the tables into 24-hour periods.
Once we roll over to a new period,
18 matches
Mail list logo
