Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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/   |
---------------------------------------------------------------------------





pgsql-ports by date

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

pgsql-hackers by date

Next:From: Anand RamanDate: 2000-12-21 04:54:09
Subject: Re: problems with query
Previous:From: Denis PerchineDate: 2000-12-21 04:14:01
Subject: Another vacuum problem

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group