From: | Michael Fuhr <mike(at)fuhr(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Kevin McArthur <postgresql-list(at)stormtide(dot)ca>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: RESULT_OID Bug |
Date: | 2005-07-27 06:12:41 |
Message-ID: | 20050727061241.GA99579@winnie.fuhr.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jul 27, 2005 at 12:56:15AM -0400, Tom Lane wrote:
> Michael Fuhr <mike(at)fuhr(dot)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/
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2005-07-27 06:34:31 | Re: RESULT_OID Bug |
Previous Message | ITAGAKI Takahiro | 2005-07-27 05:50:11 | Re: [HACKERS] O_DIRECT for WAL writes |