pg.ddx.io  pgsql-admin@postgresql.org mailing list archive  
help / color / mirror / Atom feed
last_autovacuum & last_autoanalyze showing NULL
5+ messages / 3 participants
[nested] [flat]

* last_autovacuum & last_autoanalyze showing NULL
@ 2010-08-25 07:30 Gnanakumar <gnanam@zoniac.com>
  2010-08-25 12:36 ` Re: last_autovacuum & last_autoanalyze showing NULL Brad Nicholson <bnichols@ca.afilias.info>
  2010-08-25 13:45 ` Re: last_autovacuum & last_autoanalyze showing NULL Gnanakumar <gnanam@zoniac.com>
  0 siblings, 2 replies; 5+ messages in thread

From: Gnanakumar @ 2010-08-25 07:30 UTC (permalink / raw)
  To: pgsql-admin

Hi,

Our production server is running PostgreSQL v8.2.3 on RHEL5.  Autovacuum
daemon is also running in the server.

A brief background on my use case:  We heavily use a table for storing of
data temporarily inside PostgreSQL functions.  Eventually, there will not be
any record in the table.  Because this table is used heavily, I usually keep
tab of this particular table in "pg_stat_user_tables", so that disk space is
within control.

Recently, I noticed that "last_autovacuum" and "last_autoanalyze" column for
this table showing a <NULL> value.  My question here is, what
condition/scenario would make this column to update to <NULL> value by
autovacuum?  I can add one more point here, which I remember, that is I
performed a TRUNCATE on this table just before.  I believe that this is not
because of TRUNCATE  TABLE?

Regards,
Gnanam




^ permalink  raw  reply  [nested|flat] 5+ messages in thread

* Re: last_autovacuum & last_autoanalyze showing NULL
  2010-08-25 07:30 last_autovacuum & last_autoanalyze showing NULL Gnanakumar <gnanam@zoniac.com>
@ 2010-08-25 12:36 ` Brad Nicholson <bnichols@ca.afilias.info>
  1 sibling, 0 replies; 5+ messages in thread

From: Brad Nicholson @ 2010-08-25 12:36 UTC (permalink / raw)
  To: pgsql-admin

  On 10-08-25 03:30 AM, Gnanakumar wrote:
> Hi,
>
> Our production server is running PostgreSQL v8.2.3 on RHEL5.  Autovacuum
> daemon is also running in the server.
>
> A brief background on my use case:  We heavily use a table for storing of
> data temporarily inside PostgreSQL functions.  Eventually, there will not be
> any record in the table.  Because this table is used heavily, I usually keep
> tab of this particular table in "pg_stat_user_tables", so that disk space is
> within control.
>
> Recently, I noticed that "last_autovacuum" and "last_autoanalyze" column for
> this table showing a<NULL>  value.  My question here is, what
> condition/scenario would make this column to update to<NULL>  value by
> autovacuum?  I can add one more point here, which I remember, that is I
> performed a TRUNCATE on this table just before.  I believe that this is not
> because of TRUNCATE  TABLE?

Truncate should not affect those values.

Has your Postgres instance crashed or been restarted with immediate mode 
since the last vacuum?  This will cause the autovacuum information to be 
null.

Also, are you sure that autovacuum has processed these tables at least once?

-- 
Brad Nicholson  416-673-4106
Database Administrator, Afilias Canada Corp.





^ permalink  raw  reply  [nested|flat] 5+ messages in thread

* Re: last_autovacuum & last_autoanalyze showing NULL
  2010-08-25 07:30 last_autovacuum & last_autoanalyze showing NULL Gnanakumar <gnanam@zoniac.com>
@ 2010-08-25 13:45 ` Gnanakumar <gnanam@zoniac.com>
  2010-08-25 14:33   ` Re: last_autovacuum & last_autoanalyze showing NULL Tom Lane <tgl@sss.pgh.pa.us>
  1 sibling, 1 reply; 5+ messages in thread

From: Gnanakumar @ 2010-08-25 13:45 UTC (permalink / raw)
  To: pgsql-admin; +Cc: bnichols@ca.afilias.info

> Truncate should not affect those values.
OK.

> Has your Postgres instance crashed or been restarted with immediate mode
since the last vacuum? This will cause the autovacuum information to be
null. 
No, it's been up and running for almost a week.  I even checked with "select
pg_postmaster_start_time()".

> Also, are you sure that autovacuum has processed these tables at least
once?
Yes, am very sure about this.  As I told earlier, I keep tab on this
particular table and even noticed last autovacuum and last autoanalyze every
15 minutes (using cron job I write it to a file) with timestamp before.




^ permalink  raw  reply  [nested|flat] 5+ messages in thread

* Re: last_autovacuum & last_autoanalyze showing NULL
  2010-08-25 07:30 last_autovacuum & last_autoanalyze showing NULL Gnanakumar <gnanam@zoniac.com>
  2010-08-25 13:45 ` Re: last_autovacuum & last_autoanalyze showing NULL Gnanakumar <gnanam@zoniac.com>
@ 2010-08-25 14:33   ` Tom Lane <tgl@sss.pgh.pa.us>
  2010-08-26 10:31     ` Re: last_autovacuum & last_autoanalyze showing NULL Gnanakumar <gnanam@zoniac.com>
  0 siblings, 1 reply; 5+ messages in thread

From: Tom Lane @ 2010-08-25 14:33 UTC (permalink / raw)
  To: gnanam@zoniac.com; +Cc: pgsql-admin; bnichols@ca.afilias.info

"Gnanakumar" <gnanam@zoniac.com> writes:
>> Has your Postgres instance crashed or been restarted with immediate mode
>> since the last vacuum? This will cause the autovacuum information to be
>> null. 

> No, it's been up and running for almost a week.  I even checked with "select
> pg_postmaster_start_time()".

I don't believe pg_postmaster_start_time() is reset by a
backend-crash-and-restart sequence ... but the stats collector data will
be.  You might want to look into the postmaster log for evidence of
such a crash.

			regards, tom lane



^ permalink  raw  reply  [nested|flat] 5+ messages in thread

* Re: last_autovacuum & last_autoanalyze showing NULL
  2010-08-25 07:30 last_autovacuum & last_autoanalyze showing NULL Gnanakumar <gnanam@zoniac.com>
  2010-08-25 13:45 ` Re: last_autovacuum & last_autoanalyze showing NULL Gnanakumar <gnanam@zoniac.com>
  2010-08-25 14:33   ` Re: last_autovacuum & last_autoanalyze showing NULL Tom Lane <tgl@sss.pgh.pa.us>
@ 2010-08-26 10:31     ` Gnanakumar <gnanam@zoniac.com>
  0 siblings, 0 replies; 5+ messages in thread

From: Gnanakumar @ 2010-08-26 10:31 UTC (permalink / raw)
  To: 'Tom Lane' <tgl@sss.pgh.pa.us>; +Cc: pgsql-admin; bnichols@ca.afilias.info

> I don't believe pg_postmaster_start_time() is reset by a
> backend-crash-and-restart sequence ... but the stats collector data will
> be.  You might want to look into the postmaster log for evidence of
> such a crash.

I'm sure that the backend has neither restarted nor crashed at that moment.
Anyway, I've also confirmed this in the server log, I don't find any
evidence or trace of this happened.

Is there any other possible reasons that could make autovacuum daemon to
update it to NULL value?

NOTE: "log_min_messages" is set to NOTICE.




^ permalink  raw  reply  [nested|flat] 5+ messages in thread


end of thread, other threads:[~2010-08-26 10:31 UTC | newest]

Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2010-08-25 07:30 last_autovacuum & last_autoanalyze showing NULL Gnanakumar <gnanam@zoniac.com>
2010-08-25 12:36 ` Brad Nicholson <bnichols@ca.afilias.info>
2010-08-25 13:45 ` Gnanakumar <gnanam@zoniac.com>
2010-08-25 14:33   ` Tom Lane <tgl@sss.pgh.pa.us>
2010-08-26 10:31     ` Gnanakumar <gnanam@zoniac.com>

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox