Re: [ADMIN] Still a bug in the VACUUM ??? !!!
On Monday 17 February 2003 19:56, Tom Lane wrote: Andreas Schmitz [EMAIL PROTECTED] writes: I think it is not the same. When I ran the vaccum when no other clients whe= re=20 connected to the database. The vacuum that reports the NOTICEs is not the one that created the problem. The scenario I was talking about requires concurrent clients during the preceding vacuum. regards, tom lane Hi, ok. I got that one. I was able to reproduce it. but it still doesn't solve the problem. fact is that I loose data and that is a big problem. regards -andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [ADMIN] Still a bug in the VACUUM ??? !!!
The last lines of output were: NOTICE: Rel pg_class: Uninitialized page 3344 - fixing [...] NOTICE: Rel pg_class: Uninitialized page 3355 - fixing NOTICE: Rel pg_class: Uninitialized page 3356 - fixing batch/nachts.sh: line 3: 30855 Segmentation fault /usr/bin/php -q /usr/local/httpd/htdocs/kunden/web41/html/wcopy/batch/vacuum.php Running VACUUM FULL ANALYZE another time there were no errors. Hi, I think it is not the same. When I ran the vaccum when no other clients where connected to the database. I did the update dpa_text set titleidx=txt2txtidx(volltext); When I ran vacuumdb --full --verbose --analyze -d newsdb2 /tmp/vacuum.log 21 Maybe the log will provide some information. I noticed a few messages like this in the database log while running the vacuum: Feb 17 11:19:36 postgres2 postgres[1803]: [ID 553393 local0.info] [5] LOG: pq_flush: send() failed: Broken pipe regards -andreas -- Andreas Schmitz - Phone +49 201 8501 318 Cityweb-Technik-Service-Gesellschaft mbH Friedrichstr. 12 - Fax +49 201 8501 104 45128 Essen - email [EMAIL PROTECTED] INFO: --Relation pg_catalog.pg_conversion-- INFO: Pages 2: Changed 0, reaped 0, Empty 0, New 0; Tup 114: Vac 0, Keep/VTL 0/0, UnUsed 0, MinLen 117, MaxLen 117; Re-using: Free/Avail. Space 2208/2096; EndEmpty/Avail. Pages 0/1. CPU 0.01s/0.00u sec elapsed 0.00 sec. INFO: Index pg_conversion_default_index: Pages 2; Tuples 114. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: Index pg_conversion_name_nsp_index: Pages 4; Tuples 114. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: Index pg_conversion_oid_index: Pages 2; Tuples 114. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: Rel pg_conversion: Pages: 2 -- 2; Tuple(s) moved: 0. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: Analyzing pg_catalog.pg_conversion INFO: --Relation pg_catalog.pg_depend-- INFO: Pages 26: Changed 0, reaped 1, Empty 0, New 0; Tup 3471: Vac 0, Keep/VTL 0/0, UnUsed 65, MinLen 49, MaxLen 49; Re-using: Free/Avail. Space 3952/3652; EndEmpty/Avail. Pages 0/1. CPU 0.00s/0.01u sec elapsed 0.01 sec. INFO: Index pg_depend_depender_index: Pages 21; Tuples 3471: Deleted 0. CPU 0.01s/0.00u sec elapsed 0.01 sec. INFO: Index pg_depend_reference_index: Pages 24; Tuples 3471: Deleted 0. CPU 0.00s/0.01u sec elapsed 0.01 sec. INFO: Rel pg_depend: Pages: 26 -- 26; Tuple(s) moved: 0. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: Analyzing pg_catalog.pg_depend INFO: --Relation pg_catalog.pg_attrdef-- INFO: Pages 2: Changed 0, reaped 1, Empty 0, New 0; Tup 34: Vac 0, Keep/VTL 0/0, UnUsed 10, MinLen 159, MaxLen 411; Re-using: Free/Avail. Space 3776/3776; EndEmpty/Avail. Pages 0/2. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: Index pg_attrdef_adrelid_adnum_index: Pages 2; Tuples 34: Deleted 0. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: Index pg_attrdef_oid_index: Pages 2; Tuples 34: Deleted 0. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: Rel pg_attrdef: Pages: 2 -- 2; Tuple(s) moved: 0. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: --Relation pg_toast.pg_toast_16384-- INFO: Pages 0: Changed 0, reaped 0, Empty 0, New 0; Tup 0: Vac 0, Keep/VTL 0/0, UnUsed 0, MinLen 0, MaxLen 0; Re-using: Free/Avail. Space 0/0; EndEmpty/Avail. Pages 0/0. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: Index pg_toast_16384_index: Pages 1; Tuples 0. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: Analyzing pg_catalog.pg_attrdef INFO: --Relation pg_catalog.pg_constraint-- INFO: Pages 1: Changed 0, reaped 0, Empty 0, New 0; Tup 29: Vac 0, Keep/VTL 0/0, UnUsed 0, MinLen 146, MaxLen 146; Re-using: Free/Avail. Space 3648/3648; EndEmpty/Avail. Pages 0/1. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: Index pg_constraint_conname_nsp_index: Pages 2; Tuples 29. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: Index pg_constraint_conrelid_index: Pages 2; Tuples 29. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: Index pg_constraint_oid_index: Pages 2; Tuples 29. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: Rel pg_constraint: Pages: 1 -- 1; Tuple(s) moved: 0. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: --Relation pg_toast.pg_toast_16386-- INFO: Pages 0: Changed 0, reaped 0, Empty 0, New 0; Tup 0: Vac 0, Keep/VTL 0/0, UnUsed 0, MinLen 0, MaxLen 0; Re-using: Free/Avail. Space 0/0; EndEmpty/Avail. Pages 0/0. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: Index pg_toast_16386_index: Pages 1; Tuples 0. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: Analyzing pg_catalog.pg_constraint INFO: --Relation pg_catalog.pg_database-- INFO: Pages 1: Changed 0, reaped 1, Empty 0, New 0; Tup 5: Vac 2, Keep/VTL 0/0, UnUsed 7, MinLen 124, MaxLen 220; Re-using: Free/Avail. Space 7300/7300; EndEmpty/Avail. Pages 0/1. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: Index pg_database_datname_index: Pages 2; Tuples 5: Deleted 2. CPU 0.00s/0.01u sec elapsed 0.00 sec. INFO: Index pg_database_oid_index: Pages 2; Tuples 5: Deleted 2. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: Rel pg_database: Pages: 1 -- 1; Tuple(s) moved: 0.
Re: [ADMIN] Still a bug in the VACUUM ??? !!!
Andreas Schmitz [EMAIL PROTECTED] writes: I think it is not the same. When I ran the vaccum when no other clients whe= re=20 connected to the database. The vacuum that reports the NOTICEs is not the one that created the problem. The scenario I was talking about requires concurrent clients during the preceding vacuum. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [ADMIN] Still a bug in the VACUUM ??? !!!
On Friday 14 February 2003 17:55, Tom Lane wrote: Andreas Schmitz [EMAIL PROTECTED] writes: I have a problem with the vacuum full. every time I run the vacuum command I loose data from the parent tables. maybe also from the subtables (haven't checked yet). I tried it a few times up to now an I can reproduce the phenomena. That sounds ugly ... but are you sure you don't have a hardware problem? I don't think anyone's ever reported such behavior before. If it is a Postgres bug, we can't do much to help you without a lot more detail. regards, tom lane hi, it does sound ugly. I checked the hardware. I can't see any problems with it. I know, somestimes you need a lot of luck to see a CPU problem under solaris. But I think the hardware is ok. however, what kind of details do you need to qualify if it's a postgres problem or not ? regards -andreas schmitz ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [ADMIN] Still a bug in the VACUUM ??? !!!
I have a problem with the vacuum full. every time I run the vacuum command I loose data from the parent tables. maybe also from the subtables (haven't checked yet). I tried it a few times up to now an I can reproduce the phenomena. That sounds ugly ... but are you sure you don't have a hardware problem? I don't think anyone's ever reported such behavior before. If it is a Postgres bug, we can't do much to help you without a lot more detail. regards, tom lane I have a similiar problem with VACUUM FULL ANALYZE. I do not loose any data, but get hundreds of uninitialized pages and a segmentation fault. Processing is very slow (twenty minutes). The only thing unusual about my configuration is that system indices are bloated. I expect the hardwhere to be ok, but I can not verify it because the sever is hosted elsewhere. The last lines of output were: NOTICE: Rel pg_class: Uninitialized page 3344 - fixing NOTICE: Rel pg_class: Uninitialized page 3345 - fixing NOTICE: Rel pg_class: Uninitialized page 3346 - fixing NOTICE: Rel pg_class: Uninitialized page 3347 - fixing NOTICE: Rel pg_class: Uninitialized page 3348 - fixing NOTICE: Rel pg_class: Uninitialized page 3349 - fixing NOTICE: Rel pg_class: Uninitialized page 3350 - fixing NOTICE: Rel pg_class: Uninitialized page 3351 - fixing NOTICE: Rel pg_class: Uninitialized page 3352 - fixing NOTICE: Rel pg_class: Uninitialized page 3353 - fixing NOTICE: Rel pg_class: Uninitialized page 3354 - fixing NOTICE: Rel pg_class: Uninitialized page 3355 - fixing NOTICE: Rel pg_class: Uninitialized page 3356 - fixing batch/nachts.sh: line 3: 30855 Segmentation fault /usr/bin/php -q /usr/local/httpd/htdocs/kunden/web41/html/wcopy/batch/vacuum.php Running VACUUM FULL ANALYZE another time there were no errors. hi, it does sound ugly. I checked the hardware. I can't see any problems with i t. I know, somestimes you need a lot of luck to see a CPU problem under solari s. But I think the hardware is ok. however, what kind of details do you need t o qualify if it's a postgres problem or not ? regards -andreas schmitz -- +++ GMX - Mail, Messaging more http://www.gmx.net +++ Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage! ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [ADMIN] Still a bug in the VACUUM ??? !!!
Andreas Schmitz [EMAIL PROTECTED] writes: however, what kind of details do you need to qualify if it's a postgres problem or not ? Ultimately, we need a way to reproduce the problem for debugging. If it is a Postgres bug, it should be possible to reproduce it. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [ADMIN] Still a bug in the VACUUM ??? !!!
daniel alvarez [EMAIL PROTECTED] writes: NOTICE: Rel pg_class: Uninitialized page 3344 - fixing NOTICE: Rel pg_class: Uninitialized page 3345 - fixing NOTICE: Rel pg_class: Uninitialized page 3346 - fixing NOTICE: Rel pg_class: Uninitialized page 3347 - fixing NOTICE: Rel pg_class: Uninitialized page 3348 - fixing NOTICE: Rel pg_class: Uninitialized page 3349 - fixing [etc] This is a known and not very serious problem --- see http://archives.postgresql.org/pgsql-hackers/2002-11/msg00486.php batch/nachts.sh: line 3: 30855 Segmentation fault /usr/bin/php -q /usr/local/httpd/htdocs/kunden/web41/html/wcopy/batch/vacuum.php As best I can tell, that's your own client code crashing, not Postgres. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [ADMIN] Still a bug in the VACUUM ??? !!!
Andreas Schmitz [EMAIL PROTECTED] writes: I have a problem with the vacuum full. every time I run the vacuum command I loose data from the parent tables. maybe also from the subtables (haven't checked yet). I tried it a few times up to now an I can reproduce the phenomena. That sounds ugly ... but are you sure you don't have a hardware problem? I don't think anyone's ever reported such behavior before. If it is a Postgres bug, we can't do much to help you without a lot more detail. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[ADMIN] Still a bug in the VACUUM ??? !!!
Hello *, I have a problem with the vacuum full. every time I run the vacuum command I loose data from the parent tables. maybe also from the subtables (haven't checked yet). I tried it a few times up to now an I can reproduce the phenomena. I am running postgresql 7.3.2 on solaris 8 (E450 4x 400 sun4u 1.5 GB) regards -Andreas -- Andreas Schmitz - Phone +49 201 8501 318 Cityweb-Technik-Service-Gesellschaft mbH Friedrichstr. 12 - Fax +49 201 8501 104 45128 Essen - email [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
