Re: PostgreSQL pre-7.1 Linux/Alpha Status...

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