BUG #1527: select retrieves 0 rows after vacuum analyze

Started by Theo Petersenabout 21 years ago3 messagesbugs
Jump to latest
#1Theo Petersen
tpetersen@ocv.com

The following bug has been logged online:

Bug reference: 1527
Logged by: Theo Petersen
Email address: tpetersen@ocv.com
PostgreSQL version: 7.4
Operating system: Linux (Gentoo)
Description: select retrieves 0 rows after vacuum analyze
Details:

I have a database (network monitoring data created by OpenNMS) that exhibits
this behavior:

1) I restore the database from a production backup.
2) I perform a select that joins four tables, and get 9 rows of output.
3) I use the command VACUUM ANALYZE to maintain the database files.
4) I perform the same select and get 0 rows of output.

I've reduced it to those steps to verify the problem.

Regards,
..Theo

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Theo Petersen (#1)
Re: BUG #1527: select retrieves 0 rows after vacuum analyze

"Theo Petersen" <tpetersen@ocv.com> writes:

I have a database (network monitoring data created by OpenNMS) that exhibits
this behavior:

1) I restore the database from a production backup.
2) I perform a select that joins four tables, and get 9 rows of output.
3) I use the command VACUUM ANALYZE to maintain the database files.
4) I perform the same select and get 0 rows of output.

I've reduced it to those steps to verify the problem.

Perhaps you should offer some details that would allow someone else to
replicate the problem.

regards, tom lane

#3Michael Fuhr
mike@fuhr.org
In reply to: Tom Lane (#2)
Re: BUG #1527: select retrieves 0 rows after vacuum analyze

"Theo Petersen" <tpetersen@ocv.com> writes:

I have a database (network monitoring data created by OpenNMS) that exhibits
this behavior:

1) I restore the database from a production backup.
2) I perform a select that joins four tables, and get 9 rows of output.
3) I use the command VACUUM ANALYZE to maintain the database files.
4) I perform the same select and get 0 rows of output.

I've reduced it to those steps to verify the problem.

Are you perchance doing joins involving INET or CIDR types where
the old database is 7.3.x and the new database is 7.4.x? I ask
because I discovered a problem with the 7.4.x = operator when I was
(hastily) writing the prototype for the application I think you're
working on.

http://archives.postgresql.org/pgsql-general/2004-04/msg00453.php

If this is the problem you're having, then it should be mentioned
on the project Wiki that Chris F. set up, if it still exists.

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/