Обсуждение: VACUUM warning message.
I get the following messages while vacuuming is there anything alarming? regds mallah. On Saturday 25 January 2003 07:11 am, you wrote: > SET autocommit TO 'on';VACUUM ANALYZE > WARNING: Rel site_search: Uninitialized page 1 - fixing > WARNING: Rel site_search: Uninitialized page 2 - fixing > WARNING: Rel site_search: Uninitialized page 3 - fixing > WARNING: Rel site_search: Uninitialized page 4 - fixing > WARNING: Rel site_search: Uninitialized page 5 - fixing > WARNING: Rel site_search: Uninitialized page 6 - fixing > WARNING: Rel site_search: Uninitialized page 7 - fixing > WARNING: Rel site_search: Uninitialized page 8 - fixing > WARNING: Rel site_search: Uninitialized page 9 - fixing > WARNING: Rel site_search: Uninitialized page 10 - fixing > WARNING: Rel site_search: Uninitialized page 11 - fixing > WARNING: Rel site_search: Uninitialized page 12 - fixing > WARNING: Rel site_search: Uninitialized page 13 - fixing > WARNING: Rel site_search: Uninitialized page 14 - fixing > WARNING: Rel site_search: Uninitialized page 15 - fixing -- Rajesh Kumar Mallah, Project Manager (Development) Infocom Network Limited, New Delhi phone: +91(11)6152172 (221) (L) ,9811255597 (M) Visit http://www.trade-india.com , India's Leading B2B eMarketplace.
I assume this is 7.2.X. I know this is fixed in 7.3.1 but I am not sure what release we fixed it in. The HISTORY file doesn't have a specific mention of the fix. It is not something to be worried about, as I remember. --------------------------------------------------------------------------- Rajesh Kumar Mallah. wrote: > > I get the following messages while vacuuming > is there anything alarming? > > regds > mallah. > > On Saturday 25 January 2003 07:11 am, you wrote: > > SET autocommit TO 'on';VACUUM ANALYZE > > WARNING: Rel site_search: Uninitialized page 1 - fixing > > WARNING: Rel site_search: Uninitialized page 2 - fixing > > WARNING: Rel site_search: Uninitialized page 3 - fixing > > WARNING: Rel site_search: Uninitialized page 4 - fixing > > WARNING: Rel site_search: Uninitialized page 5 - fixing > > WARNING: Rel site_search: Uninitialized page 6 - fixing > > WARNING: Rel site_search: Uninitialized page 7 - fixing > > WARNING: Rel site_search: Uninitialized page 8 - fixing > > WARNING: Rel site_search: Uninitialized page 9 - fixing > > WARNING: Rel site_search: Uninitialized page 10 - fixing > > WARNING: Rel site_search: Uninitialized page 11 - fixing > > WARNING: Rel site_search: Uninitialized page 12 - fixing > > WARNING: Rel site_search: Uninitialized page 13 - fixing > > WARNING: Rel site_search: Uninitialized page 14 - fixing > > WARNING: Rel site_search: Uninitialized page 15 - fixing > > -- > Rajesh Kumar Mallah, > Project Manager (Development) > Infocom Network Limited, New Delhi > phone: +91(11)6152172 (221) (L) ,9811255597 (M) > > Visit http://www.trade-india.com , > India's Leading B2B eMarketplace. > > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes: > I assume this is 7.2.X. I know this is fixed in 7.3.1 but I am not sure > what release we fixed it in. The HISTORY file doesn't have a specific > mention of the fix. It is not something to be worried about, as I > remember. Mmm, I'm not sure. The known variant of this problem only affects certain system tables (the nailed-in-cache ones): http://archives.postgresql.org/pgsql-hackers/2002-11/msg00486.php This is evidently a user table: > WARNING: Rel site_search: Uninitialized page 1 - fixing I'd wonder about hardware failures, myself. Does the table appear to have lost a lot of rows that should have been there? Other interesting questions are whether the table has recently undergone a TRUNCATE, or deletion of a large fraction of its rows followed by VACUUM (probably VACUUM FULL). regards, tom lane
Hmm i do the below daily to this table. And this is pgsql 7.3 ~~~~~~~~~~~~~~~~~~~~~~~ BEGIN WORK; INSERT INTO archives.site_search SELECT * from public.site_search; COMMIT; TRUNCATE TABLE public.site_search; ~~~~~~~~~~~~~~~~~~~~~~ and then it is VACUMMED within 24 hrs. The table public.site_search only under goes INSERTS thruout the day and no updates and archives.site_search only undergoes a bulk insert once in 24 hrs and "SELECTS" most of the time. public.site_search starts from 0 records and ends up to 4000-5000 records before the truncate. archives.site_search contains 6,50,000 apprx. Related Problem [ OT ] : this approach was taken because i was getting very poor performance when i was inserting and reading data from the same table within a transaction. only one table used to exists containg apprx .6 million records. I feel there was some kind of locking going on using this approach inserts and reads are from different table and perforamance is much better. Regds Mallah. > Bruce Momjian <pgman@candle.pha.pa.us> writes: >> I assume this is 7.2.X. I know this is fixed in 7.3.1 but I am not sure what release we fixed >> it in. The HISTORY file doesn't have a specific mention of the fix. It is not something to >> be worried about, as I remember. > > Mmm, I'm not sure. The known variant of this problem only affects certain system tables (the > nailed-in-cache ones): > http://archives.postgresql.org/pgsql-hackers/2002-11/msg00486.php > > This is evidently a user table: > >> WARNING: Rel site_search: Uninitialized page 1 - fixing > > I'd wonder about hardware failures, myself. Does the table appear to have lost a lot of rows > that should have been there? > > Other interesting questions are whether the table has recently undergone a TRUNCATE, or > deletion of a large fraction of its rows followed by VACUUM (probably VACUUM FULL). > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- TIP 6: Have you > searched our list archives? > > http://archives.postgresql.org ----------------------------------------- Get your free web based email at trade-india.com. "India's Leading B2B eMarketplace.!" http://www.trade-india.com/
<mallah@trade-india.com> writes:
> Hmm i do the below daily to this table. And this is pgsql 7.3
> TRUNCATE TABLE public.site_search;
Drat. Now that I look at it, 7.3 TRUNCATE doesn't send any kind of
relcache inval message, so it's got the same kind of problem that the
nailed-in-cache catalogs do: other backends don't reset their
which-page-to-insert-on pointer.
This is already fixed for 7.4, because in 7.4 TRUNCATE updates the
pg_class entry.
We decided not to backpatch any fix for the system-catalog version
of the problem, because it is purely cosmetic (there is no problem
other than the warning messages). So I guess I think the same about
this version of the problem.
regards, tom lane