From: | Michael Fuhr <mike(at)fuhr(dot)org> |
---|---|
To: | Kevin McArthur <postgresql-list(at)stormtide(dot)ca> |
Cc: | Neil Conway <neilc(at)samurai(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: RESULT_OID Bug |
Date: | 2005-07-27 13:36:38 |
Message-ID: | 20050727133638.GA18851@winnie.fuhr.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jul 27, 2005 at 12:19:51AM -0700, Kevin McArthur wrote:
> This error has come up in the last week or so, and my suspicion remains
> that its caused by something to do with roles but that could be way wrong.
>
> The FreeBSD machines were confirmed to work as of about a week ago ( i
> reinstalled for a timezone patch and I'm pretty sure it was working then )
Have you tried using CVS to check out and test older code? I'll
do that myself when I get a chance. If the developers can't reproduce
the problem, then at least maybe we can narrow down which commit
is responsible so they'll have something to look at.
> I can note that the \set for lastoid is properly updated when I insert into
> a table. Thus the problem has to be somewhere between plpgsql and that data
> via the get diagnostics interface (under the assumption that the lastoid
> structure is consistent for all inserts and psql having lastoid working at
> all eliminates that part of the equation).
So far the problem does seem to be specific to whatever PL/pgSQL's
is doing, and it affects ROW_COUNT as well as RESULT_OID. I haven't
been able to reproduce the problem with PL/Tcl or with C and SPI.
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2005-07-27 13:38:52 | Re: [HACKERS] O_DIRECT for WAL writes |
Previous Message | Larry Rosenman | 2005-07-27 13:36:11 | Re: regression failure on latest CVS |