FAQ
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

Search Discussions

  • Tom Lane at Jul 10, 2002 at 4:01 am

    Barry Lind 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
  • Barry Lind at Jul 10, 2002 at 4:09 am
    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

  • Tom Lane at Jul 10, 2002 at 4:14 am

    Barry Lind 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
  • Barry Lind at Jul 10, 2002 at 4:28 am
    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

  • Tom Lane at Jul 10, 2002 at 4:41 am

    Barry Lind 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
  • Barry Lind at Jul 10, 2002 at 4:49 am
    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

  • Tom Lane at Jul 10, 2002 at 4:55 am

    Barry Lind 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
  • Barry Lind at Jul 10, 2002 at 5:10 am
    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

  • Mario Weilguni at Jul 10, 2002 at 6:27 am

    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedJul 10, '02 at 3:40a
activeJul 10, '02 at 6:27a
posts10
users3
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase