Re: [HACKERS] PostgreSQL pre-7.1 Linux/Alpha Status... (fwd)

From: Ryan Kirkpatrick <pgsql(at)rkirkpat(dot)net>
To: pgsql-hackers(at)postgresql(dot)org, pgsql-ports(at)postgresql(dot)org
Subject: Re: [HACKERS] PostgreSQL pre-7.1 Linux/Alpha Status... (fwd)
Date: 2000-12-21 04:17:05
Message-ID: Pine.LNX.4.10.10012202116120.28246-100000@excelsior.rkirkpat.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-ports

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(at)rkirkpat(dot)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/ |
---------------------------------------------------------------------------

Browse pgsql-hackers by date

  From Date Subject
Next Message Anand Raman 2000-12-21 04:54:09 Re: problems with query
Previous Message Denis Perchine 2000-12-21 04:14:01 Another vacuum problem

Browse pgsql-ports by date

  From Date Subject
Next Message Zeugswetter Andreas SB 2000-12-21 10:53:11 AW: PostgreSQL pre-7.1 Linux/Alpha Status...
Previous Message Ryan Kirkpatrick 2000-12-21 04:11:10 Re: [HACKERS] PostgreSQL pre-7.1 Linux/Alpha Status...