Thread: PostgreSQL pre-7.1 Linux/Alpha Status...
I have had the time to test today's (12/19) snapshot on my
Linux/Alpha and the good news is that only two regression tests are
failing. The bad news is that these regression tests do not fail on
Linux/Intel. :( [1]
Specifically, the oid and misc regression tests failed. Here are
the gory details:
oid: Inserting a negative oid should wrap that oid around to an unsigned
value, but instead pgsql just spits it back out with an error
message. i.e.:
CREATE TABLE OID_TBL(f1 oid);
...
INSERT INTO OID_TBL(f1) VALUES ('-1040');
ERROR: oidin: error reading "-1040": value too large
Probably not a major problem (who inserts negative oids?), but I
could be wrong. Hopefully it has an easy fix.
misc: This one is nasty... Any attempts to use the '*' operator in the
context of inheritance causes pgsql to lose its mind and wander off
into the weeds never to be seen again. Example from 'misc' tests:
SELECT p.name, p.hobbies.name FROM person* p;
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
connection to server was lost
Definitely needs to be fixed, but I have a feeling it will not be
easy.
Other than those two issues, everything seems to run great. I would go
digging into the source to find the source of these problems, but I
thought I would throw it out to the list first. [2]
Therefore, if anyone has any ideas as to what is failing, how to
fix it, or at least a general direction to head in (i.e. look in these
source files...), please speak up. If you want more information on the
above problems, feel free to ask. Just tell me what you want, and if it is
not obvious, how to get it.
Looking forward to a new version pgsql that compiles out of the
box on Linux/Alpha! TTYL.
[1] For those who missed my poor attempt at a joke... I mean that the
Linux/Alpha regression failures are specific to that platform, and
therefore my problem to solve, not a more general problem I could leave to
the pg-hackers to solve....
[2] That, and I am definitely not familiar with the pgsql source, so it
would probably take me a while to make any headway if I just started
digging with out any direction...
---------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
---------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ |
---------------------------------------------------------------------------
Ryan Kirkpatrick <pgsql@rkirkpat.net> writes:
> INSERT INTO OID_TBL(f1) VALUES ('-1040');
> ERROR: oidin: error reading "-1040": value too large
That's coming from a possibly-misguided error check that I put into
oidin():
unsigned long cvt;char *endptr;
cvt = strtoul(s, &endptr, 10);
...
/* * Cope with possibility that unsigned long is wider than Oid. */result = (Oid) cvt;if ((unsigned long) result !=
cvt) elog(ERROR, "oidin: error reading \"%s\": value too large", s);
On a 32-bit machine, -1040 converts to 4294966256, but on a 64-bit
machine it converts to 2^64-1040, and the test is accordingly deciding
that that value won't fit in an Oid.
Not sure what to do about this. If you had actually typed 2^64-1040,
it would be appropriate for the code to reject it. But I hadn't
realized that the extra check would introduce a discrepancy between
32- and 64-bit machines for negative inputs. Maybe it'd be better just
to delete the check. Comments anyone?
> SELECT p.name, p.hobbies.name FROM person* p;
> pqReadData() -- backend closed the channel unexpectedly.
Backtrace please?
regards, tom lane
From: "Ryan Kirkpatrick" <pgsql@rkirkpat.net> > On Sat, 16 Dec 2000, Bruce Momjian wrote: > > > Here is the list of features in 7.1. > > One thing that I think ought to be added is that with 7.1, > PostgreSQL will compile out of the box (i.e. without any extra patches) > for Linux/Alpha. What patches do one need for compiling say 7.0.3 with alpha linux? Is it some kind of semaphore patch (i get those evil errors). Magnus Naeslund -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-Programmer/Networker [|] Magnus NaeslundPGP Key: http://www.genline.nu/mag_pgp.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Ryan Kirkpatrick <pgsql@rkirkpat.net> writes:
> > INSERT INTO OID_TBL(f1) VALUES ('-1040');
> > ERROR: oidin: error reading "-1040": value too large
>
> That's coming from a possibly-misguided error check that I put into
> oidin():
>
> unsigned long cvt;
> char *endptr;
>
> cvt = strtoul(s, &endptr, 10);
>
> ...
>
> /*
> * Cope with possibility that unsigned long is wider than Oid.
> */
> result = (Oid) cvt;
> if ((unsigned long) result != cvt)
> elog(ERROR, "oidin: error reading \"%s\": value too large", s);
>
> On a 32-bit machine, -1040 converts to 4294966256, but on a 64-bit
> machine it converts to 2^64-1040, and the test is accordingly deciding
> that that value won't fit in an Oid.
>
> Not sure what to do about this. If you had actually typed 2^64-1040,
> it would be appropriate for the code to reject it. But I hadn't
> realized that the extra check would introduce a discrepancy between
> 32- and 64-bit machines for negative inputs. Maybe it'd be better just
> to delete the check. Comments anyone?
Can't we just say out of range, rather than too large?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Wed, 20 Dec 2000, Tom Lane wrote:
> Ryan Kirkpatrick <pgsql@rkirkpat.net> writes:
> > INSERT INTO OID_TBL(f1) VALUES ('-1040');
> > ERROR: oidin: error reading "-1040": value too large
>
> That's coming from a possibly-misguided error check that I put into
> oidin():
...
> On a 32-bit machine, -1040 converts to 4294966256, but on a 64-bit
> machine it converts to 2^64-1040, and the test is accordingly deciding
> that that value won't fit in an Oid.
>
> Not sure what to do about this. If you had actually typed 2^64-1040,
> it would be appropriate for the code to reject it. But I hadn't
> realized that the extra check would introduce a discrepancy between
> 32- and 64-bit machines for negative inputs. Maybe it'd be better just
> to delete the check. Comments anyone?
I will leave it up to the decision of the list. Though in my
opinion attempting to insert a negative oid should be met with an error
outright. Otherwise you end up with a phantom error (i.e. the result is
not what you expected, but you are given any warning or notice to that
effect).
> > SELECT p.name, p.hobbies.name FROM person* p;
> > pqReadData() -- backend closed the channel unexpectedly.
>
> Backtrace please?
It appears that one has to run a decent amount of the regression
tests to get the backend to crash. There is heavy dependency between the
tests, so it is not trival to come up with a simple test case. Though I
can say simple inheritance (i.e. the inheritance example in the docs)
works fine. Apparently the more exotic and complex variety of inheritance
starts causing problems. I simply ran the regression tests in serial mode
and gathered the below data.
Here is the relevant from the postmaster logs:
...
DEBUG: Deadlock risk: raising lock level from ShareLock to ExclusiveLock
on object 401236/280863/8
DEBUG: Deadlock risk: raising lock level from ShareLock to ExclusiveLock
on object 401242/280863/1
DEBUG: Deadlock risk: raising lock level from ShareLock to ExclusiveLock
on object 401245/280863/7
Server process (pid 8468) exited with status 11 at Wed Dec 20 21:01:56
2000
Terminating any active server processes...
Server processes were terminated at Wed Dec 20 21:01:56 2000
Reinitializing shared memory and semaphores
...
And from gdb, here is the post-mortem (not for the faint of
heart):
Program received signal SIGSEGV, Segmentation fault.
0x1200bc160 in ExecEvalFieldSelect ()
#0 0x1200bc160 in ExecEvalFieldSelect ()
#1 0x1200bc6dc in ExecEvalExpr ()
#2 0x1200bb868 in ExecEvalFuncArgs ()
#3 0x1200bb964 in ExecMakeFunctionResult ()
#4 0x1200bbd18 in ExecEvalOper ()
#5 0x1200bc63c in ExecEvalExpr ()
#6 0x1200bc85c in ExecQual ()
#7 0x1200bcf7c in ExecScan ()
#8 0x1200c677c in ExecSeqScan ()
#9 0x1200b9e2c in ExecProcNode ()
#10 0x1200b8550 in ExecutePlan ()
#11 0x1200b72bc in ExecutorRun ()
#12 0x1200bee2c in postquel_getnext ()
#13 0x1200bf080 in postquel_execute ()
#14 0x1200bf298 in fmgr_sql ()
#15 0x1200bbab0 in ExecMakeFunctionResult ()
#16 0x1200bbdd8 in ExecEvalFunc ()
#17 0x1200bc64c in ExecEvalExpr ()
#18 0x1200bc14c in ExecEvalFieldSelect ()
#19 0x1200bc6dc in ExecEvalExpr ()
#20 0x1200b64dc in ExecEvalIter ()
#21 0x1200bc5d0 in ExecEvalExpr ()
#22 0x1200bcae0 in ExecTargetList ()
#23 0x1200bce20 in ExecProject ()
#24 0x1200c6330 in ExecResult ()
#25 0x1200b9dec in ExecProcNode ()
#26 0x1200b8550 in ExecutePlan ()
#27 0x1200b72bc in ExecutorRun ()
#28 0x1201319c8 in ProcessQuery ()
#29 0x12012f77c in pg_exec_query_string ()
#30 0x120131120 in PostgresMain ()
#31 0x12010ced4 in DoBackend ()
#32 0x12010c818 in BackendStartup ()
#33 0x12010b228 in ServerLoop ()
#34 0x12010a9a0 in PostmasterMain ()
#35 0x1200d48a8 in main ()
TTYL.
---------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
---------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ |
---------------------------------------------------------------------------
Tom Lane writes:
> Ryan Kirkpatrick <pgsql@rkirkpat.net> writes:
> > INSERT INTO OID_TBL(f1) VALUES ('-1040');
> > ERROR: oidin: error reading "-1040": value too large
>
> That's coming from a possibly-misguided error check that I put into
> oidin():
>
> unsigned long cvt;
> char *endptr;
>
> cvt = strtoul(s, &endptr, 10);
>
> ...
>
> /*
> * Cope with possibility that unsigned long is wider than Oid.
> */
> result = (Oid) cvt;
if (sizeof(unsigned long) > sizeof(Oid) && cvt > UINT_MAX)
> if ((unsigned long) result != cvt)
> elog(ERROR, "oidin: error reading \"%s\": value too large", s);
>
> On a 32-bit machine, -1040 converts to 4294966256, but on a 64-bit
> machine it converts to 2^64-1040, and the test is accordingly deciding
> that that value won't fit in an Oid.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
> if (sizeof(unsigned long) > sizeof(Oid) && cvt > UINT_MAX)
Hm. Each part of that will generate "expression is always false"
warnings from certain overprotective compilers. A more serious problem
is that using UINT_MAX assumes that Oid is unsigned int, which will
certainly not be true forever --- but the required change will be easily
missed when Oid changes.
Perhaps postgres_ext.h could define
#define OID_MAX UINT_MAX
right below the typedef for Oid, and then we could do this in oidin():
#if OID_MAX < ULONG_MAX if (cvt > OID_MAX) elog();#endif
I think this #if expression will work --- anyone see any portability
risk there?
regards, tom lane
Tom Lane writes: > > if (sizeof(unsigned long) > sizeof(Oid) && cvt > UINT_MAX) > > Hm. Each part of that will generate "expression is always false" > warnings from certain overprotective compilers. Any compiler that does this will certainly issue a boatload of these all over the tree. More generally, I have given up on worrying too much about the warning count on non-GCC compilers. All the ones I've seen lately generate tons already. > A more serious problem is that using UINT_MAX assumes that Oid is > unsigned int, which will certainly not be true forever --- but the > required change will be easily missed when Oid changes. > > Perhaps postgres_ext.h could define > > #define OID_MAX UINT_MAX > > right below the typedef for Oid, and then we could do this in oidin(): > > #if OID_MAX < ULONG_MAX > if (cvt > OID_MAX) > elog(); > #endif That looks fine as well. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
How are you on Alpha now?
>
> I have had the time to test today's (12/19) snapshot on my
> Linux/Alpha and the good news is that only two regression tests are
> failing. The bad news is that these regression tests do not fail on
> Linux/Intel. :( [1]
> Specifically, the oid and misc regression tests failed. Here are
> the gory details:
>
>
> oid: Inserting a negative oid should wrap that oid around to an unsigned
> value, but instead pgsql just spits it back out with an error
> message. i.e.:
>
> CREATE TABLE OID_TBL(f1 oid);
> ...
> INSERT INTO OID_TBL(f1) VALUES ('-1040');
> ERROR: oidin: error reading "-1040": value too large
>
> Probably not a major problem (who inserts negative oids?), but I
> could be wrong. Hopefully it has an easy fix.
>
>
> misc: This one is nasty... Any attempts to use the '*' operator in the
> context of inheritance causes pgsql to lose its mind and wander off
> into the weeds never to be seen again. Example from 'misc' tests:
>
> SELECT p.name, p.hobbies.name FROM person* p;
> pqReadData() -- backend closed the channel unexpectedly.
> This probably means the backend terminated abnormally
> before or while processing the request.
> connection to server was lost
>
> Definitely needs to be fixed, but I have a feeling it will not be
> easy.
>
> Other than those two issues, everything seems to run great. I would go
> digging into the source to find the source of these problems, but I
> thought I would throw it out to the list first. [2]
> Therefore, if anyone has any ideas as to what is failing, how to
> fix it, or at least a general direction to head in (i.e. look in these
> source files...), please speak up. If you want more information on the
> above problems, feel free to ask. Just tell me what you want, and if it is
> not obvious, how to get it.
> Looking forward to a new version pgsql that compiles out of the
> box on Linux/Alpha! TTYL.
>
>
> [1] For those who missed my poor attempt at a joke... I mean that the
> Linux/Alpha regression failures are specific to that platform, and
> therefore my problem to solve, not a more general problem I could leave to
> the pg-hackers to solve....
>
> [2] That, and I am definitely not familiar with the pgsql source, so it
> would probably take me a while to make any headway if I just started
> digging with out any direction...
>
> ---------------------------------------------------------------------------
> | "For to me to live is Christ, and to die is gain." |
> | --- Philippians 1:21 (KJV) |
> ---------------------------------------------------------------------------
> | Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ |
> ---------------------------------------------------------------------------
>
>
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Mon, 22 Jan 2001, Bruce Momjian wrote:
> How are you on Alpha now?
Great! Downloaded 7.1beta3, and it works fine right out of the
box. Built it in the standard way (./configure; make all), and then ran
the regression tests. All 76 of 76 tests passed on my Alpha XLT 366
w/Debian 2.2. I think we can finally say that Linux/Alpha is a viable
platform for PostgreSQL. :)
TTYL.
---------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
---------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ |
---------------------------------------------------------------------------