Thread: A strange Vacuum error ...

A strange Vacuum error ...

From
Dave Smith
Date:
I am running 7.2.4 and when running a vacuum on my database I get

NOTICE:  Child itemid in update-chain marked as unused - can't continue
repair_frag
ERROR:  No one parent tuple was found
vacuumdb: vacuum  import failed

How do I fix this?

--
Dave Smith
CANdata Systems Ltd
416-493-9020


PQtrace doesn't work

From
"W. van den Akker"
Date:
Hello,

I have a little test program (see at the end of the message). The program
crashes when PQTrace is called (instruction xxxx referenced memory at
"0x00000010", the
memory could not be written" (obvious ... )
I use the library libpqdll.lib and postgresql v7.3.4. When I comment the
line the program runs fine.

Any ideas?

gr,

Willem.


#include <stdio.h>
#include <stdlib.h>
#include <libpq-fe.h>
#include <winsock.h>

void main ()
{
    int  nFields;
    int     i, j;

    PGconn    *conn;
    PGresult *res;

    char *pghost = "linux";
    char *dbName = "some_db";

    FILE *debug;

    WSADATA  wsadata;
    WSAStartup(0x0101, &wsadata);

    conn = PQsetdbLogin (pghost, NULL, NULL, NULL, dbName, "user","");

    if (PQstatus(conn) == CONNECTION_BAD)
    {
        printf ("Connection to database %s is failed\n", dbName);
        printf ("%s", PQerrorMessage (conn));
        PQfinish (conn);
        exit (1);
    }

    debug = fopen ("trace.out", "w");
  --->>  PQtrace (conn, debug);

    res = PQexec (conn, "BEGIN");
    if (!res || PQresultStatus (res) != PGRES_COMMAND_OK)
    {
        printf ("BEGIN command failed\n");
        PQclear (res);
        PQfinish (conn);
        exit (1);
    }

    PQclear (res);

    res = PQexec (conn, "DECLARE mycursor CURSOR FOR select sum(id) from
relaties");
    if (!res || PQresultStatus (res) != PGRES_COMMAND_OK)
    {
        printf ("DECLARE CURSOR command failed\n");
        PQclear (res);
        PQfinish (conn);
        exit (1);
    }

    PQclear (res);
    res = PQexec (conn, "FETCH ALL in mycursor");
    if (!res || PQresultStatus (res) != PGRES_TUPLES_OK)
    {
        printf ("FETCH ALL command didn't return tuples properly\n");
        PQclear (res);
        PQfinish (conn);
        exit (1);
    }

    nFields = PQnfields (res);
    for (i = 0; i < nFields; i++)
        printf ("%-15s", PQfname (res, i));

    printf ("\n\n");

    for (i = 0; i < PQntuples (res); i++)
    {
        for (j = 0; j < nFields; j++)
            printf ("%-15s", PQgetvalue (res, i, j));
        printf ("\n");
    }

    PQclear (res);

    res = PQexec (conn, "CLOSE mycursor");
    PQclear (res);

    res = PQexec (conn, "COMMIT");
    PQclear (res);

    PQfinish (conn);

    fclose (debug);

    WSACleanup();
}



Re: A strange Vacuum error ...

From
Tom Lane
Date:
Dave Smith <dave.smith@candata.com> writes:
> I am running 7.2.4 and when running a vacuum on my database I get
> NOTICE:  Child itemid in update-chain marked as unused - can't continue
> repair_frag
> ERROR:  No one parent tuple was found
> vacuumdb: vacuum  import failed

> How do I fix this?

I believe this error will go away once the problematic tuple is older
than the oldest running transaction.  Find which client is sitting on a
longstanding open transaction and kill it ...

We later realized that this shouldn't be an error condition at all,
since it can happen in corner cases like the one you have.  But the fix
was not back-patched as far as 7.2.*.  If you can't move to 7.3 or 7.4
soon, you might consider trying to back-patch it yourself:

2002-08-13 16:14  tgl

    * src/backend/commands/vacuum.c: Fix tuple-chain-moving tests to
    handle marked-for-update tuples correctly (they are not part of a
    chain).  When failing to find a parent tuple in an update chain,
    emit a warning and abandon repair_frag, but do not give an error as
    before.  This should eliminate the infamous 'No one parent tuple
    was found' failure, which we now realize is not a can't-happen
    condition but a perfectly valid database state.  Per recent
    pghackers discussion.

            regards, tom lane

Re: PQtrace doesn't work

From
Tom Lane
Date:
"W. van den Akker" <listsrv@wilsoft.nl> writes:
> I have a little test program (see at the end of the message). The program
> crashes when PQTrace is called (instruction xxxx referenced memory at
> "0x00000010", the
> memory could not be written" (obvious ... )
> I use the library libpqdll.lib and postgresql v7.3.4. When I comment the
> line the program runs fine.

Your test program works fine for me, after removal of the WSA-related
lines (I'm not using Windows).  I suspect some Windows-specific issue,
but hard to say what.

            regards, tom lane

PQtrace doesn't work

From
"W. van den Akker"
Date:
Hello,

I've send this message also on 29-1-2004 and have since no solution for
this problem .. >:o .
I have a little test program (see at the end of the message).
The program crashes when PQTrace is called (instruction xxxx referenced
memory at "0x00000010", the
memory could not be written" (obvious ... ). I use the library
libpqdll.lib and postgresql v8.0.1, but also happens
in 7.4.9.
Running under W2000 sp4, VC++ 6 SP5. If compiling under Linux then there
is no problem. Obvious there is
something wrong with the use under windows

If I comment traceoption all works fine.

Any ideas?

gr,

Willem.

#include <stdio.h>
#include <stdlib.h>
#include <libpq-fe.h>
#include <winsock.h>

void main ()
{
    int  nFields;
    int     i, j;

    PGconn    *conn;
    PGresult *res;

    char *pghost = "linux";
    char *dbName = "some_db";

    FILE *debug;

    WSADATA  wsadata;
    WSAStartup(0x0101, &wsadata);


   conn = PQsetdbLogin (pghost, NULL, NULL, NULL, dbName, "user","");

   if (PQstatus(conn) == CONNECTION_BAD)
   {
       printf ("Connection to database %s is failed\n", dbName);
       printf ("%s", PQerrorMessage (conn));
       PQfinish (conn);
       exit (1);
   }

   debug = fopen ("trace.out", "w");
 --->>  PQtrace (conn, debug);

   res = PQexec (conn, "BEGIN");
   if (!res || PQresultStatus (res) != PGRES_COMMAND_OK)
   {
       printf ("BEGIN command failed\n");
       PQclear (res);
       PQfinish (conn);
       exit (1);
   }

   PQclear (res);

   res = PQexec (conn, "DECLARE mycursor CURSOR FOR select sum(id) from
relaties");
   if (!res || PQresultStatus (res) != PGRES_COMMAND_OK)
   {
       printf ("DECLARE CURSOR command failed\n");
       PQclear (res);
       PQfinish (conn);
       exit (1);
   }

   PQclear (res);
   res = PQexec (conn, "FETCH ALL in mycursor");
   if (!res || PQresultStatus (res) != PGRES_TUPLES_OK)
   {
       printf ("FETCH ALL command didn't return tuples properly\n");
       PQclear (res);
       PQfinish (conn);
       exit (1);
   }

   nFields = PQnfields (res);
   for (i = 0; i < nFields; i++)
       printf ("%-15s", PQfname (res, i));

   printf ("\n\n");

   for (i = 0; i < PQntuples (res); i++)
   {
       for (j = 0; j < nFields; j++)
           printf ("%-15s", PQgetvalue (res, i, j));
       printf ("\n");
   }

   PQclear (res);

   res = PQexec (conn, "CLOSE mycursor");
   PQclear (res);

   res = PQexec (conn, "COMMIT");
   PQclear (res);
     PQfinish (conn);

   fclose (debug);

   WSACleanup();
}


Re: PQtrace doesn't work

From
Bruce Momjian
Date:
W. van den Akker wrote:
> Hello,
>
> I've send this message also on 29-1-2004 and have since no solution for
> this problem .. >:o .
> I have a little test program (see at the end of the message).
> The program crashes when PQTrace is called (instruction xxxx referenced
> memory at "0x00000010", the
> memory could not be written" (obvious ... ). I use the library
> libpqdll.lib and postgresql v8.0.1, but also happens
> in 7.4.9.
> Running under W2000 sp4, VC++ 6 SP5. If compiling under Linux then there
> is no problem. Obvious there is
> something wrong with the use under windows
>
> If I comment traceoption all works fine.

Looking at the code, the only thing I see done by PQtrace are some calls
to fprintf to that file descriptor, like this:

    fe-misc.c:  fprintf(conn->Pfdebug, libpq_gettext("To backend> Msg %c\n"),

Hard to imagine what would fail there, unless libpq_gettext() doesn't
work, but you are probably not use NLS, so it would be a noop:

    #define libpq_gettext(x) (x)

Can you send us a backtrace of the failure from VC++?  We don't have too
many internals guys using that setup, but the backtrace should suggest a
cause.

---------------------------------------------------------------------------


>
> Any ideas?
>
> gr,
>
> Willem.
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <libpq-fe.h>
> #include <winsock.h>
>
> void main ()
> {
>     int  nFields;
>     int     i, j;
>
>     PGconn    *conn;
>     PGresult *res;
>
>     char *pghost = "linux";
>     char *dbName = "some_db";
>
>     FILE *debug;
>
>     WSADATA  wsadata;
>     WSAStartup(0x0101, &wsadata);
>
>
>    conn = PQsetdbLogin (pghost, NULL, NULL, NULL, dbName, "user","");
>
>    if (PQstatus(conn) == CONNECTION_BAD)
>    {
>        printf ("Connection to database %s is failed\n", dbName);
>        printf ("%s", PQerrorMessage (conn));
>        PQfinish (conn);
>        exit (1);
>    }
>
>    debug = fopen ("trace.out", "w");
>  --->>  PQtrace (conn, debug);
>
>    res = PQexec (conn, "BEGIN");
>    if (!res || PQresultStatus (res) != PGRES_COMMAND_OK)
>    {
>        printf ("BEGIN command failed\n");
>        PQclear (res);
>        PQfinish (conn);
>        exit (1);
>    }
>
>    PQclear (res);
>
>    res = PQexec (conn, "DECLARE mycursor CURSOR FOR select sum(id) from
> relaties");
>    if (!res || PQresultStatus (res) != PGRES_COMMAND_OK)
>    {
>        printf ("DECLARE CURSOR command failed\n");
>        PQclear (res);
>        PQfinish (conn);
>        exit (1);
>    }
>
>    PQclear (res);
>    res = PQexec (conn, "FETCH ALL in mycursor");
>    if (!res || PQresultStatus (res) != PGRES_TUPLES_OK)
>    {
>        printf ("FETCH ALL command didn't return tuples properly\n");
>        PQclear (res);
>        PQfinish (conn);
>        exit (1);
>    }
>
>    nFields = PQnfields (res);
>    for (i = 0; i < nFields; i++)
>        printf ("%-15s", PQfname (res, i));
>
>    printf ("\n\n");
>
>    for (i = 0; i < PQntuples (res); i++)
>    {
>        for (j = 0; j < nFields; j++)
>            printf ("%-15s", PQgetvalue (res, i, j));
>        printf ("\n");
>    }
>
>    PQclear (res);
>
>    res = PQexec (conn, "CLOSE mycursor");
>    PQclear (res);
>
>    res = PQexec (conn, "COMMIT");
>    PQclear (res);
>      PQfinish (conn);
>
>    fclose (debug);
>
>    WSACleanup();
> }
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to majordomo@postgresql.org so that your
>        message can get through to the mailing list cleanly
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: PQtrace doesn't work

From
"Daniel Verite"
Date:
    Bruce Momjian wrote:

> Looking at the code, the only thing I see done by PQtrace are some calls
> to fprintf to that file descriptor, like this:
>
>     fe-misc.c:  fprintf(conn->Pfdebug, libpq_gettext("To backend> Msg %c\n"),
>
> Hard to imagine what would fail there, unless libpq_gettext() doesn't
> work, but you are probably not use NLS, so it would be a noop:
>
>     #define libpq_gettext(x) (x)
>
> Can you send us a backtrace of the failure from VC++?  We don't have too
> many internals guys using that setup, but the backtrace should suggest a
> cause.

Having a similar setup, I've tried enabling PQtrace and it also crashes
for me, apparently as soon as libpq tries to write into the stream.

In the hope of debugging at the point of the fprintf call,
I've built a libpq.lib to link with, as opposed to libpqdll.lib,
but the statically-linked version doesn't crash, it works as
expected.

So it looks like the problem would be DLL-related?

--
 Daniel
 PostgreSQL-powered mail user agent and storage: http://www.manitou-mail.org


Re: PQtrace doesn't work

From
Bruce Momjian
Date:
Daniel Verite wrote:
>     Bruce Momjian wrote:
>
> > Looking at the code, the only thing I see done by PQtrace are some calls
> > to fprintf to that file descriptor, like this:
> >
> >     fe-misc.c:  fprintf(conn->Pfdebug, libpq_gettext("To backend> Msg %c\n"),
> >
> > Hard to imagine what would fail there, unless libpq_gettext() doesn't
> > work, but you are probably not use NLS, so it would be a noop:
> >
> >     #define libpq_gettext(x) (x)
> >
> > Can you send us a backtrace of the failure from VC++?  We don't have too
> > many internals guys using that setup, but the backtrace should suggest a
> > cause.
>
> Having a similar setup, I've tried enabling PQtrace and it also crashes
> for me, apparently as soon as libpq tries to write into the stream.
>
> In the hope of debugging at the point of the fprintf call,
> I've built a libpq.lib to link with, as opposed to libpqdll.lib,
> but the statically-linked version doesn't crash, it works as
> expected.
>
> So it looks like the problem would be DLL-related?

Is there a problem with a DLL writing to a file descriptor opened by
application code?  I would think not, but perhaps.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: PQtrace doesn't work

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Daniel Verite wrote:
>> So it looks like the problem would be DLL-related?

> Is there a problem with a DLL writing to a file descriptor opened by
> application code?  I would think not, but perhaps.

Hmm .... malloc/free are broken in exactly that way in Windows DLLs,
maybe stdio has the same kind of issue?  I'd think this would be pretty
well known if true, though.

            regards, tom lane

Re: PQtrace doesn't work

From
Bruce Momjian
Date:
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Daniel Verite wrote:
> >> So it looks like the problem would be DLL-related?
>
> > Is there a problem with a DLL writing to a file descriptor opened by
> > application code?  I would think not, but perhaps.
>
> Hmm .... malloc/free are broken in exactly that way in Windows DLLs,
> maybe stdio has the same kind of issue?  I'd think this would be pretty
> well known if true, though.

Ah, I have found the cause of the crash, and added documentation about
the cause:

        On Win32, if the <application>libpq</> and the application are
        compiled with different flags, this function call will crash the
        application because the internal representation of the <literal>FILE</>
        pointers differ.

While such a mismatch is a problem on all platforms, it is more common
on Win32 where the FILE structure changes for debug, for example.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: PQtrace doesn't work

From
"Daniel Verite"
Date:
    Bruce Momjian wrote:

> Is there a problem with a DLL writing to a file descriptor opened by
> application code?  I would think not, but perhaps.

After some more testing, I've found out that it works only if the
application code uses the shared version of the C library
(msvcrt.dll)
That means compiling with the /MD or /MDd options, or in
the GUI, selecting in the project settings,
C/C++ -> Code Generation -> Use runtime library -> Multithread DLL
(or Debug Multithreaded DLL)
That's apparently not the default when creating a new application
with Visual Studio.

libpq.dll must also having been compiled with /MD as well, but
that should be the case unless the OP changed that himself
in libpq/win32.mak

--
 Daniel
 PostgreSQL-powered mail user agent and storage: http://www.manitou-mail.org


Re: PQtrace doesn't work

From
Bruce Momjian
Date:
Daniel Verite wrote:
>     Bruce Momjian wrote:
>
> > Is there a problem with a DLL writing to a file descriptor opened by
> > application code?  I would think not, but perhaps.
>
> After some more testing, I've found out that it works only if the
> application code uses the shared version of the C library
> (msvcrt.dll)
> That means compiling with the /MD or /MDd options, or in
> the GUI, selecting in the project settings,
> C/C++ -> Code Generation -> Use runtime library -> Multithread DLL
> (or Debug Multithreaded DLL)
> That's apparently not the default when creating a new application
> with Visual Studio.
>
> libpq.dll must also having been compiled with /MD as well, but
> that should be the case unless the OP changed that himself
> in libpq/win32.mak

Yep, library version mismatch --- now documented.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073