Обсуждение: error during vacuum full
When trying to perform a full vacuum I am getting the following error: ERROR: No one parent tuple was found Plain vacuum works fine. Thinking it might be a problem with the indexes I have rebuilt them but still get the error. What does this error indicate and what are my options to solve the problem? I am running: PostgreSQL 7.2.1 on i686-pc-linux-gnu, compiled by GCC 2.96 on a RedHat 7.3 system. thanks, --Barry
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: > > >>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 > >---------------------------(end of broadcast)--------------------------- >TIP 4: Don't 'kill -9' the postmaster > > >
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: > > >>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 > >---------------------------(end of broadcast)--------------------------- >TIP 5: Have you checked our extensive FAQ? > >http://www.postgresql.org/users-lounge/docs/faq.html > > >
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: > > >>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 > >---------------------------(end of broadcast)--------------------------- >TIP 5: Have you checked our extensive FAQ? > >http://www.postgresql.org/users-lounge/docs/faq.html > > >
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: >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 > >---------------------------(end of broadcast)--------------------------- >TIP 6: Have you searched our list archives? > >http://archives.postgresql.org > > >
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 forsure 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 runningevery minute or so and checks some conditions, and I guess it is called while vacuum full is running too. Best regards,Mario Weilguni