Re: RESULT_OID Bug
| От | Michael Fuhr |
|---|---|
| Тема | Re: RESULT_OID Bug |
| Дата | |
| Msg-id | 20050727061241.GA99579@winnie.fuhr.org обсуждение исходный текст |
| Ответ на | Re: RESULT_OID Bug (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: RESULT_OID Bug
|
| Список | 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 по дате отправления: