Обсуждение: A strange Vacuum error ...
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
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();
}
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
"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
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();
}
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
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
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
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
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
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
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