Re: RESULT_OID Bug - Mailing list pgsql-hackers

From Michael Fuhr
Subject Re: RESULT_OID Bug
Date
Msg-id 20050727061241.GA99579@winnie.fuhr.org
Whole thread Raw
In response to Re: RESULT_OID Bug  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: RESULT_OID Bug
List pgsql-hackers
On Wed, Jul 27, 2005 at 12:56:15AM -0400, Tom Lane wrote:
> Michael Fuhr <mike@fuhr.org> writes:
> > Could this be platform-specific?
> 
> Seems that way.  I tried it on HPUX 10.20/HPPA/gcc 2.95.3.

No luck on FreeBSD 4.11-STABLE/i386/gcc 2.95.4.  The box that does
have a problem is Solaris 9/sparc/gcc 3.4.2.

Can anybody else reproduce the problem?

> My guess is that the behavior is related to plpgsql's caching
> of plans for functions, and as such should be driven by the
> backend's history not the whole database's history.  But it's
> just a guess.

Another test case that's been consistent for me:

Session 1: connect
Session 1: create table and function
Session 1: call function; returns oid

Session 2: connect
Session 2: call function; returns NULL

Session 1: exit

Session 3: connect
Session 3: call function; returns NULL

Session 2: exit

Session 3: exit

Session 4: connect
Session 4: call function; returns oid

Session 5: connect
Session 5: call function; returns NULL

Any suggestions?  Would it be useful to attach gdb to one of the
backends?  If so, what should I be looking for?

-- 
Michael Fuhr
http://www.fuhr.org/~mfuhr/


pgsql-hackers by date:

Previous
From:
Date:
Subject: Re: psql as an execve(2) interpreter
Next
From: Neil Conway
Date:
Subject: Re: RESULT_OID Bug