Michael Fuhr wrote:
> Can anybody else reproduce the problem?

I couldn't repro it, on x86 / Debian unstable / gcc 3.4.4, with current
CVS sources.

-Neil

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

The target system for my reproduction is on FreeBSD.

Though I sitll cannot get the initdb started one to work the first time
around.

I cannot reproduce the bug on my linux machine, however I cannot test the
full initdb procedure until tomorrow on freebsd.

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 )

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).

Kevin McArthur

----- Original Message -----
From: "Neil Conway" <neilc@samurai.com>
To: "Michael Fuhr" <mike@fuhr.org>
Cc: "Tom Lane" <tgl@sss.pgh.pa.us>; "Kevin McArthur"
<postgresql-list@stormtide.ca>; <pgsql-hackers@postgresql.org>
Sent: Tuesday, July 26, 2005 11:34 PM
Subject: Re: [HACKERS] RESULT_OID Bug


> Michael Fuhr wrote:
>> Can anybody else reproduce the problem?
>
> I couldn't repro it, on x86 / Debian unstable / gcc 3.4.4, with current
> CVS sources.
>
> -Neil
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

On Wed, Jul 27, 2005 at 12:19:51AM -0700, Kevin McArthur wrote:
> The target system for my reproduction is on FreeBSD.

What version of FreeBSD? What compiler and version? So far I
haven't been able to reproduce the problem on FreeBSD 4.11-STABLE/
i386/gcc 2.95.4.

> Though I sitll cannot get the initdb started one to work the first time
> around.

Odd -- that one works (or rather, fails) every time for me on Solaris 9/
sparc/gcc 3.4.2.

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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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/

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

I cannot repoduce your experience with this bug. No matter what I do,
reconnect session or otherwise, it never returns a proper oid on the newer
cvs vers (I suspect it may be related to the roles update)

Kevin
----- Original Message -----
From: "Michael Fuhr" <mike@fuhr.org>
To: "Kevin McArthur" <postgresql-list@stormtide.ca>
Cc: <pgsql-hackers@postgresql.org>
Sent: Tuesday, July 26, 2005 4:19 PM
Subject: Re: [HACKERS] RESULT_OID Bug


> On Tue, Jul 26, 2005 at 03:36:26PM -0700, Kevin McArthur wrote:
>> Recent cvs versions are failing the following script;
>>
>> create table oidtest(a time default now()) with oids;
>>
>> CREATE OR REPLACE FUNCTION oidtest() RETURNS integer AS $oidtest$
>> DECLARE
>> insert_oid_var INTEGER;
>> BEGIN
>> INSERT INTO oidtest DEFAULT VALUES;
>> GET DIAGNOSTICS insert_oid_var = RESULT_OID;
>> RETURN insert_oid_var;
>> END;
>> $oidtest$ Language plpgsql;
>>
>> select oidtest();
>>
>> if its working you will see an oid, if its failing you will see 1 row
>> with blank data.
>
> The function appears to work in a session until you replace it (or
> drop and recreate it), after which you get NULL. If you exit the
> session and reconnect then it works again. I checked 8.0.3 and it
> doesn't have this problem.
>
> --
> Michael Fuhr
> http://www.fuhr.org/~mfuhr/
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

On 2005-07-27, Michael Fuhr <mike@fuhr.org> wrote:
> 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.

src/pl/plpgsql/src/pl_exec.c, function exec_stmt_getdiag, uninitialized
variable "isnull".

--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services

Andrew - Supernews wrote:

>On 2005-07-27, Michael Fuhr <mike@fuhr.org> wrote:
>
>
>>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.
>>
>>
>
>src/pl/plpgsql/src/pl_exec.c, function exec_stmt_getdiag, uninitialized
>variable "isnull".
>
>
>

nice catch. I see the "= false" removed in about 5 places in this
change:
http://developer.postgresql.org/cvsw...1.146;r2=1.147

Is this the only one that matters?

cheers

(another) andrew

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Changing just the one appears to resolve the oid bug. Should probably talk
to neilc to see why he changed it.

I will pass along a patch for this particular case to -patches shortly

Kevin McArthur
----- Original Message -----
From: "Andrew Dunstan" <andrew@dunslane.net>
To: <andrew@supernews.com>
Cc: <pgsql-hackers@postgresql.org>
Sent: Wednesday, July 27, 2005 11:57 AM
Subject: Re: [HACKERS] RESULT_OID Bug


>
>
> Andrew - Supernews wrote:
>
>>On 2005-07-27, Michael Fuhr <mike@fuhr.org> wrote:
>>
>>>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.
>>>
>>
>>src/pl/plpgsql/src/pl_exec.c, function exec_stmt_getdiag, uninitialized
>>variable "isnull".
>>
>>
>
> nice catch. I see the "= false" removed in about 5 places in this change:
> http://developer.postgresql.org/cvsw...1.146;r2=1.147
>
> Is this the only one that matters?
>
> cheers
>
> (another) andrew
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

On Wed, Jul 27, 2005 at 01:20:29PM -0700, Kevin McArthur wrote:
> Changing just the one appears to resolve the oid bug. Should probably talk
> to neilc to see why he changed it.

Initializing isnull to false in exec_stmt_getdiag() appears to fix
the bug on my Solaris 9 box as well. I'd guess the variations in
behavior were due to different platforms having different garbage
on the stack.

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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Sounds plausible.

Can anyone comment on whether the other instances of isnull=false being
removed need to be reset to =false

Kevin McArthur
----- Original Message -----
From: "Michael Fuhr" <mike@fuhr.org>
To: "Kevin McArthur" <postgresql-list@stormtide.ca>
Cc: "Andrew Dunstan" <andrew@dunslane.net>; <andrew@supernews.com>;
<pgsql-hackers@postgresql.org>
Sent: Wednesday, July 27, 2005 3:35 PM
Subject: Re: [HACKERS] RESULT_OID Bug


> On Wed, Jul 27, 2005 at 01:20:29PM -0700, Kevin McArthur wrote:
>> Changing just the one appears to resolve the oid bug. Should probably
>> talk
>> to neilc to see why he changed it.
>
> Initializing isnull to false in exec_stmt_getdiag() appears to fix
> the bug on my Solaris 9 box as well. I'd guess the variations in
> behavior were due to different platforms having different garbage
> on the stack.
>
> --
> Michael Fuhr
> http://www.fuhr.org/~mfuhr/
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend