By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,492 Members | 1,210 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,492 IT Pros & Developers. It's quick & easy.

Vacuumdb Errors --Any ideas?

P: n/a
I received the following errors from an automated full vacuum:

vacuumdb: vacuuming of database "milemgr" failed: ERROR: tuple concurrently
updated
ERROR: Vacuum command failed: Inappropriate ioctl for device

I can't find any information on these errors. Does anyone have an idea what
they mean and indicate?

[PG v7.4.2, RH 2.4.21-4.ELsmp]

TIA,

Keary Suska
Esoteritech, Inc.
"Leveraging Open Source for a better Internet"
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Nov 23 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Keary Suska <hi********@pcisys.net> writes:
I received the following errors from an automated full vacuum:
vacuumdb: vacuuming of database "milemgr" failed: ERROR: tuple concurrently
updated
Hm, could you have had more than one of these beasts running? It's
possible to get such an error from concurrent ANALYZE operations on
the same table. (This happens if the second ANALYZE tries to update the
pg_statistic rows before the first one is able to commit. It's a pretty
narrow window, and there's no real harm involved, so we haven't tried
hard to get rid of the race condition.)
ERROR: Vacuum command failed: Inappropriate ioctl for device


I have no idea where that came from --- I can't find "vacuum command
failed" anywhere in current sources. I suspect the second part of the
message just comes from someone printing strerror(errno) in a context
where errno isn't meaningful.

Bottom line: don't panic. If you can find where the second message came
from, though, I'd like to know.

regards, tom lane

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

Nov 23 '05 #2

P: n/a
Keary Suska <hi********@pcisys.net> writes:
I received the following errors from an automated full vacuum:
vacuumdb: vacuuming of database "milemgr" failed: ERROR: tuple concurrently
updated
Hm, could you have had more than one of these beasts running? It's
possible to get such an error from concurrent ANALYZE operations on
the same table. (This happens if the second ANALYZE tries to update the
pg_statistic rows before the first one is able to commit. It's a pretty
narrow window, and there's no real harm involved, so we haven't tried
hard to get rid of the race condition.)
ERROR: Vacuum command failed: Inappropriate ioctl for device


I have no idea where that came from --- I can't find "vacuum command
failed" anywhere in current sources. I suspect the second part of the
message just comes from someone printing strerror(errno) in a context
where errno isn't meaningful.

Bottom line: don't panic. If you can find where the second message came
from, though, I'd like to know.

regards, tom lane

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

Nov 23 '05 #3

P: n/a
on 5/1/04 3:11 PM, tg*@sss.pgh.pa.us purportedly said:
Keary Suska <hi********@pcisys.net> writes:
I received the following errors from an automated full vacuum:
vacuumdb: vacuuming of database "milemgr" failed: ERROR: tuple concurrently
updated


Hm, could you have had more than one of these beasts running? It's
possible to get such an error from concurrent ANALYZE operations on
the same table.


That is likely the issue--I forgot that I have a regular vacuum analyze that
may run at the same time.
ERROR: Vacuum command failed: Inappropriate ioctl for device


I have no idea where that came from --- I can't find "vacuum command
failed" anywhere in current sources. I suspect the second part of the
message just comes from someone printing strerror(errno) in a context
where errno isn't meaningful.


Probably is--in this case vacuumdb is called form a Perl script that
reports errors itself as well if the command failed. That error part,
"Inappropriate ioctl for device", is probably just Perl not knowing how to
intrerpret vacuumdb return codes. Sorry for having you look this up. I
should have reviewed my script to see what it carps on its own.

Thanks for your help,

Keary Suska
Esoteritech, Inc.
"Leveraging Open Source for a better Internet"
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Nov 23 '05 #4

P: n/a
on 5/1/04 3:11 PM, tg*@sss.pgh.pa.us purportedly said:
Keary Suska <hi********@pcisys.net> writes:
I received the following errors from an automated full vacuum:
vacuumdb: vacuuming of database "milemgr" failed: ERROR: tuple concurrently
updated


Hm, could you have had more than one of these beasts running? It's
possible to get such an error from concurrent ANALYZE operations on
the same table.


That is likely the issue--I forgot that I have a regular vacuum analyze that
may run at the same time.
ERROR: Vacuum command failed: Inappropriate ioctl for device


I have no idea where that came from --- I can't find "vacuum command
failed" anywhere in current sources. I suspect the second part of the
message just comes from someone printing strerror(errno) in a context
where errno isn't meaningful.


Probably is--in this case vacuumdb is called form a Perl script that
reports errors itself as well if the command failed. That error part,
"Inappropriate ioctl for device", is probably just Perl not knowing how to
intrerpret vacuumdb return codes. Sorry for having you look this up. I
should have reviewed my script to see what it carps on its own.

Thanks for your help,

Keary Suska
Esoteritech, Inc.
"Leveraging Open Source for a better Internet"
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Nov 23 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.