error during vacuum full

Barry Lind <barry@xythos.com> writes:

When trying to perform a full vacuum I am getting the following error:
ERROR: No one parent tuple was found

Want to dig into it with gdb, or let someone else into your system to
do so?

I've suspected for awhile that there's still a lurking bug or three
in the VACUUM FULL tuple-chain-moving code, but without an example
to study it's damn hard to make any progress.

Note that restarting the postmaster will probably make the problem
go away, as tuple chains cannot exist unless there are old open
transactions. So unless your installation is already compiled
--enable-debug, there's probably not much we can learn :=(

regards, tom lane

Tom,

It was not compiled with debug. I will do that now and see if this
happens again in the future. If and when it happens again what would
you like me to do? I am willing provide you access if you need it.

thanks,
--Barry

Tom Lane wrote:

Barry Lind <barry@xythos.com> writes:

It was not compiled with debug. I will do that now and see if this
happens again in the future. If and when it happens again what would
you like me to do? I am willing provide you access if you need it.

Well, first off, please confirm that killing off open client
transactions (you shouldn't even need to do a full postmaster restart)
makes the problem go away.

Beyond that, I have no advice except to be prepared to apply a debugger
next time. I believe we could fix the problem if we could examine the
situation VACUUM is seeing --- but it's so far not been possible to
do that, because the triggering conditions are so transient.

regards, tom lane

Tom,

I am not sure exactly what you mean by 'open client transactions' but I
just killed off all client processes. The only postgres processes
running are:

[root@cvs root]# ps -ef | grep post
postgres 1004 1 0 Jul03 ? 00:00:00
/usr/local/pgsql/bin/postmaster
postgres 1069 1004 0 Jul03 ? 00:00:00 postgres: stats buffer
process
postgres 1070 1069 0 Jul03 ? 00:00:00 postgres: stats
collector proces

I then reconnected via psql and reran the vacuum full getting the same
error.

--Barry

Tom Lane wrote:

Barry Lind <barry@xythos.com> writes:

The only postgres processes running are:

[root@cvs root]# ps -ef | grep post
postgres 1004 1 0 Jul03 ? 00:00:00
/usr/local/pgsql/bin/postmaster
postgres 1069 1004 0 Jul03 ? 00:00:00 postgres: stats buffer
process
postgres 1070 1069 0 Jul03 ? 00:00:00 postgres: stats
collector proces

I then reconnected via psql and reran the vacuum full getting the same
error.

Really!? Well, does restarting the postmaster fix it?

regards, tom lane

Tom,

No. Restarting the postmaster does not resolve the problem. I am going
to put the debug build in place and see if I can still reproduce.

--Barry

Tom Lane wrote:

Barry Lind <barry@xythos.com> writes:

No. Restarting the postmaster does not resolve the problem.

Now you've got my attention ;-) ... this is completely at variance
with my theories about the cause of the problem. Destruction of
a theory is usually a sign of impending advance.

I am going
to put the debug build in place and see if I can still reproduce.

Good. I am dead tired and am about to go to bed, but if you can
reproduce with a debuggable build then I would definitely like to
crawl into it tomorrow.

At this point I do not have the faintest idea what might cause the
problem to go away, so if possible I'd urge you to do the minimum
possible work on the system overnight. Alternatively, if you can
spare the disk space, make a tarball copy of the whole $PGDATA
tree while you have the postmaster shut down. Then we can
study the problem offline without worrying about your live
application.

regards, tom lane

Tom,

Good. I am dead tired and am about to go to bed, but if you can
reproduce with a debuggable build then I would definitely like to
crawl into it tomorrow.

Good night. We can pick this up tomorrow.

At this point I do not have the faintest idea what might cause the
problem to go away, so if possible I'd urge you to do the minimum
possible work on the system overnight. Alternatively, if you can
spare the disk space, make a tarball copy of the whole $PGDATA
tree while you have the postmaster shut down. Then we can
study the problem offline without worrying about your live
application.

I need the app up and running, but I did shut it down and created a backup of the entire directory as you suggested.

thanks,
--Barry

Tom Lane wrote:

Am Mittwoch, 10. Juli 2002 06:50 schrieb Barry Lind:

Tom,

No. Restarting the postmaster does not resolve the problem. I am going
to put the debug build in place and see if I can still reproduce.

I've this problem on different machines too (on a daily basis), and restarting the database has never helped. There are for sure no open transactions when this happens, and the only way out is to regenerate all tuples:
update tablename set colname=colname; (take whatever column you like). I guess it's because I've a cron job which is running every minute or so and checks some conditions, and I guess it is called while vacuum full is running too.

Best regards,
Mario Weilguni