PostgreSQL pre-7.1 Linux/Alpha Status...

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 Naeslund
PGP 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/ |
---------------------------------------------------------------------------

ListAdmin: Ignore the stalled/delayed posts from me earlier.
Accidently posted with the wrong from address.... :(

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/ |
---------------------------------------------------------------------------

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?

IIRC oid uses int4in/int4out and those should definitely be able to parse
-1040 into a 4 byte signed long without platform dependency, no ?

pg_dump with OID's dumps those negative numbers if oid > 2^32,
thus this input must imho be made to work correctly.

Andreas

IIRC oid uses int4in/int4out and those should definitely be able to parse
-1040 into a 4 byte signed long without platform dependency, no ?

Tom Lane changed this recently to have OID use its own i/o routines.

- Thomas

IIRC oid uses int4in/int4out and those should definitely be able to parse
-1040 into a 4 byte signed long without platform dependency, no ?

Tom Lane changed this recently to have OID use its own i/o routines.

Reading the code, I don't understand it. Why would strtoul return an int in the
first place ? The name seems to imply an unsigned long return type.
Seems config should check the return type of strtoul.

Andreas

Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> writes:

IIRC oid uses int4in/int4out and those should definitely be able to parse
-1040 into a 4 byte signed long without platform dependency, no ?

It has done that in past releases. I changed it to use unsigned display
for 7.1. Because of the past behavior, I think oidin had better accept
negative inputs for backwards compatibility. Besides which, strtoul()
does that naturally ...

regards, tom lane

Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> writes:

Reading the code, I don't understand it. Why would strtoul return an
int in the first place ? The name seems to imply an unsigned long
return type.

What's your point?

unsigned long cvt;

cvt = strtoul(s, &endptr, 10);

The trick is to get from unsigned long to oid (which is unsigned int)
on machines where those are different sizes.

regards, tom lane

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/ |
---------------------------------------------------------------------------