Re: [BUGS] BUG #4027: backslash escaping not disabled in plpgsql

2008-03-12 Thread Tom Lane
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I believe the reason for 
>> not changing it was that it seemed too likely to break existing
>> functions, with potentially nasty consequences if they chanced to be
>> security definers.

> Is this actually true or did we just forget it? :-)

I recall thinking about the point.  The decision could've been wrong ...

regards, tom lane

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs


Re: [BUGS] BUG #4025: wsock32.dll not found

2008-03-12 Thread Magnus Hagander

> The following bug has been logged online:
> 
> Bug reference:  4025
> Logged by:  James
> Email address:  [EMAIL PROTECTED]
> PostgreSQL version: 8.3.0.1
> Operating system:   winXP
> Description:wsock32.dll not found
> Details: 
> 
> when installation reach initdb stage, it shows can not init the database , '
> WSOCK32.DLL' not found, reinstall the application might fix the problem. '

This is a windows error, and not a postgresql one. We just ask for it, even the 
error message is from windows.

If wsock32 can't be loaded, you have a big problem on your system. It could be 
many thingt - permissions, antivirus, firewall, etc.

You will have tol investigate that at the OS level, and contact your support 
there if you can't find it yourself.
 
/Magnus

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs


Re: [BUGS] BUG #3681: fillers are NULL in pgbench

2008-03-12 Thread Bruce Momjian

This was applied by Tom.  Thanks.

---

ITAGAKI Takahiro wrote:
> 
> Tom Lane <[EMAIL PROTECTED]> wrote:
> 
> > "ITAGAKI Takahiro" <[EMAIL PROTECTED]> writes:
> > > All of filler fields in branches, tellers and history is NULL. It is
> > > probabbly a mistake because there are fields of char(22-88) in the table
> > > definitions.
> > > TPC-B requires at least 100 bytes per row for all tables used in it.
> > 
> > I'm not in favor of changing this.  pgbench has never pretended to be
> > "really" TPC-B, nor has anyone ever tried to compare its numbers against
> > other TPC-B numbers.  On the other hand, people *do* compare pgbench
> > numbers to itself over time, and if we make a change like this it will
> > break comparability of the results.
> 
> Ok, I feel it reasonable.
> The attached is a patch to mention it in the source code.
> 
> Regards,
> ---
> ITAGAKI Takahiro
> NTT Open Source Software Center
> 

[ Attachment, skipping... ]

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

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>http://momjian.us
  EnterpriseDB http://postgres.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs


Re: [BUGS] BUG #4027: backslash escaping not disabled in plpgsql

2008-03-12 Thread Bruce Momjian
Peter Eisentraut wrote:
> Tom Lane wrote:
> > plpgsql does not consider standard_conforming_strings --- it still uses
> > backslash escaping in its function bodies regardless.  Since the
> > language itself is not standardized, I see no particular reason that
> > standard_conforming_strings should govern it.
> 
> I think plpgsql should behave either consistently with the rest of PostgreSQL 
> or with Oracle, which it is copied from.

Agreed. standard_conforming_strings should affect _all_ strings.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>http://momjian.us
  EnterpriseDB http://postgres.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs


Re: [BUGS] LISTEN/NOTIFY race condition?

2008-03-12 Thread Laurent Birtz

Tom Lane wrote:

This patch will apply against HEAD and 8.3, but not cleanly against
prior versions.  Since this code hasn't changed materially (except for
additions of subtransaction and 2PC support) for a long time,
back-patching should be straightforward, but I haven't actually done
that yet.

Comments?
  


I've reviewed the patch briefly and tested it against my version
of Postgres (8.3/Debian) and the test program I wrote to
reproduce the bug. I confirm the test program works fine.

Thanks for the quick fix!
Laurent Birtz


--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs


Re: [BUGS] 8.3.0 backend segfaults

2008-03-12 Thread Greg Sabino Mullane

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160


> Work load is a web application where each page beings a transaction;
> creates a temp table, does a few selects, inserts and updates and the
> commits.

Are you sure you are calling DBI->connect *after* the Apache children
are created? Major problems like this can happen if not. The use of
prepare_cached() may be adding to the problem as well, especially if
you are using temp tables. In DBD::Pg, prepared statements are not
actually prepared (in most cases) until just before the first execute,
to account for late bindings and to be more efficient. Some related
DBD::Pg attribs to look at are pg_server_prepare and pg_prepare_now.


- --
Greg Sabino Mullane [EMAIL PROTECTED]
End Point Corporation
PGP Key: 0x14964AC8 200803121121
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-BEGIN PGP SIGNATURE-

iEYEAREDAAYFAkfX9Q0ACgkQvJuQZxSWSsjEjACg6QNUdPIw5gczfTtFK3aUMh39
fUYAoLwRrFZ75z2Fbq7GDRYqgTlRsR9N
=ngbh
-END PGP SIGNATURE-



-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs


Re: [BUGS] 8.3.0 backend segfaults

2008-03-12 Thread Tom Lane
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
> Are you sure you are calling DBI->connect *after* the Apache children
> are created? Major problems like this can happen if not.

Something like that might explain a crash in the Apache server, but
hardly one in the PG backend.

It looks to me like he's found a dangling-pointer problem, but we need
to reproduce it before we can determine a fix...

regards, tom lane

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs


Re: [BUGS] 8.3.0 backend segfaults

2008-03-12 Thread Alex Hunsaker
On Wed, Mar 12, 2008 at 12:44 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
>
> > the mean time here is a new backtrace I just got (lord knows how... it
>  > seems to be as soon as I stop trying to make it crash and look away,
>  > thats when it does).
>
>  Not sure that you are clear on what's happening here, but the train of
>  events is something like
> - you prepare a statement
> - somebody modifies the schema of one of the tables used in the
>   statement
> - you try to execute the statement, and updating the prepared
>   plan crashes
>
>  If you say "none of my stuff is changing any schemas", then I'd guess
>  that the triggering event is a background autovacuum, which forces
>  replan just like an intentional schema change would.  Does stopping
>  autovacuum make the problem go away?

Yep turning off autovacuum seems to have fixed it.  And once I
manually vacuum analyze workers; it blows up almost instantly.

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs


Re: [BUGS] 8.3.0 backend segfaults

2008-03-12 Thread Alex Hunsaker
On Wed, Mar 12, 2008 at 9:22 AM, Greg Sabino Mullane <[EMAIL PROTECTED]> wrote:
ommits.
>
>  Are you sure you are calling DBI->connect *after* the Apache children
>  are created?

Yes.

 Major problems like this can happen if not. The use of
>  prepare_cached() may be adding to the problem as well, especially if
>  you are using temp tables.

The tables its failing on happen to not be temp tables (I only have 1
temp table and only do 1 insert into it for the entire transaction).

>In DBD::Pg, prepared statements are not
>  actually prepared (in most cases) until just before the first execute,
>  to account for late bindings and to be more efficient. Some related
>  DBD::Pg attribs to look at are pg_server_prepare and pg_prepare_now.

Hrm, well i dont ever prepare them in mass, I only prepare them and
when im going to be calling execute right afterwords.  But ill try
turning on autovac and setting pg_prepare_now to 1 and see what
happens.

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs


Re: [BUGS] 8.3.0 backend segfaults

2008-03-12 Thread Tom Lane
"Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> On Wed, Mar 12, 2008 at 12:44 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> If you say "none of my stuff is changing any schemas", then I'd guess
>> that the triggering event is a background autovacuum, which forces
>> replan just like an intentional schema change would.  Does stopping
>> autovacuum make the problem go away?

> Yep turning off autovacuum seems to have fixed it.  And once I
> manually vacuum analyze workers; it blows up almost instantly.

Yeah, I was going to suggest that you ought to be able to extract
a test case involving doing a manual vacuum in between prepare and
execute.  I suspect it wouldn't even need to involve more than one
session.

regards, tom lane

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs


Re: [BUGS] 8.3.0 backend segfaults

2008-03-12 Thread Alex Hunsaker
On Wed, Mar 12, 2008 at 9:49 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
>  > On Wed, Mar 12, 2008 at 12:44 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> >> If you say "none of my stuff is changing any schemas", then I'd guess
>  >> that the triggering event is a background autovacuum, which forces
>  >> replan just like an intentional schema change would.  Does stopping
>  >> autovacuum make the problem go away?
>
>  > Yep turning off autovacuum seems to have fixed it.  And once I
>  > manually vacuum analyze workers; it blows up almost instantly.
>
>  Yeah, I was going to suggest that you ought to be able to extract
>  a test case involving doing a manual vacuum in between prepare and
>  execute.  I suspect it wouldn't even need to involve more than one
>  session.

Here is what im trying right now with no success:

3 clients doing this:
while(1)
{
$db->begin_work();
my $sth = $db->prepare_cached('select * from junk left join
junk as j on j.junk = junk.junk where junk.junk like ? limit 1;');
print "VAC!\n";
sleep 10;
print "EX!\n";
$sth->execute('junk') || die "failed: $!";
$sth->fetchall_arrayref();
$db->commit();
$db->{'AutoCommit'} = 0;
$db->{'AutoCommit'} = 1;
}

where when it prints VAC I :
update junk set junk = 'junkab';
VACUUM ANALYZE verbose junk;
(also tried deleting, and inserting a bunch of junk...)

3 other clients doing:
while(1)
{
$db->begin_work();
my $sth = $db->prepare_cached('select * from junk left join
junk as j on j.junk = junk.junk where junk.junk like ? limit 1;');
$sth->execute('junk') || die "failed: $!";
$sth->fetchall_arrayref();
$db->rollback();
}

\d junk
Table "public.junk"
 Column | Type | Modifiers
+--+---
 junk   | text |

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs


Re: [BUGS] 8.3.0 backend segfaults

2008-03-12 Thread Rodriguez Fernando

Alex Hunsaker wrote:

Precedence: bulk
Sender: [EMAIL PROTECTED]

On Wed, Mar 12, 2008 at 9:49 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
  

"Alex Hunsaker" <[EMAIL PROTECTED]> writes:
 > On Wed, Mar 12, 2008 at 12:44 AM, Tom Lane <[EMAIL PROTECTED]> wrote:



If you say "none of my stuff is changing any schemas", then I'd guess


 >> that the triggering event is a background autovacuum, which forces
 >> replan just like an intentional schema change would.  Does stopping
 >> autovacuum make the problem go away?

 > Yep turning off autovacuum seems to have fixed it.  And once I
 > manually vacuum analyze workers; it blows up almost instantly.

 Yeah, I was going to suggest that you ought to be able to extract
 a test case involving doing a manual vacuum in between prepare and
 execute.  I suspect it wouldn't even need to involve more than one
 session.



Here is what im trying right now with no success:

3 clients doing this:
while(1)
{
$db->begin_work();
my $sth = $db->prepare_cached('select * from junk left join
junk as j on j.junk = junk.junk where junk.junk like ? limit 1;');
print "VAC!\n";
sleep 10;
print "EX!\n";
$sth->execute('junk') || die "failed: $!";
$sth->fetchall_arrayref();
$db->commit();
$db->{'AutoCommit'} = 0;
$db->{'AutoCommit'} = 1;
}

where when it prints VAC I :
update junk set junk = 'junkab';
VACUUM ANALYZE verbose junk;
(also tried deleting, and inserting a bunch of junk...)

3 other clients doing:
while(1)
{
$db->begin_work();
my $sth = $db->prepare_cached('select * from junk left join
junk as j on j.junk = junk.junk where junk.junk like ? limit 1;');
$sth->execute('junk') || die "failed: $!";
$sth->fetchall_arrayref();
$db->rollback();
}

\d junk
Table "public.junk"
 Column | Type | Modifiers
+--+---
 junk   | text |

  
Hola, esto (like ? ) generalmente no funciona en un prepared statement, 
quizas tu problema este ahi.
proba con un =? , (se que no es lo mismo) y si funciona el problema es 
el like


Saludos Fernando

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs


Re: [BUGS] 8.3.0 backend segfaults

2008-03-12 Thread Tom Lane
"Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> Here is what im trying right now with no success:

> my $sth = $db->prepare_cached('select * from junk left join
> junk as j on j.junk = junk.junk where junk.junk like ? limit 1;');

You need to duplicate more of the original query structure to provoke
the problem, likely.  The crash appeared to involve evaluation of an
immutable SQL function ...

regards, tom lane

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs


Re: [BUGS] 8.3.0 backend segfaults

2008-03-12 Thread Alex Hunsaker
On Wed, Mar 12, 2008 at 10:31 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
>
> > Here is what im trying right now with no success:
>
>
> > my $sth = $db->prepare_cached('select * from junk left join
>  > junk as j on j.junk = junk.junk where junk.junk like ? limit 1;');
>
>  You need to duplicate more of the original query structure to provoke
>  the problem, likely.  The crash appeared to involve evaluation of an
>  immutable SQL function ...

Will do.

Just for the record its defined as
create or replace function data_class(text) returns integer as 'select
data_class from data_classes where data_id = $1 and defunct = 0'
language 'sql' stable strict;

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs


Re: [BUGS] 8.3.0 backend segfaults

2008-03-12 Thread Alex Hunsaker
Hrm still no luck.

I created a snapshot of the database, moved it onto another server so
i could play with it...

Ive tried using just prepare on the console using the query that fails:
prepare worker (bigint, bigint) as select w.worker_id, w.worker_id as
 printerid, w.worker, w.alias, coalesce(w.alias, w.worker) as name,
 w.active, w.last_active, w.last_deactive, round(extract(epoch from
 now()) - extract(epoch from w.last_deactive)) as time_off from workers
 as w left join worker_vis as wv on wv.worker_id = w.worker_id and
 wv.defunct = 0 and ( ((wv.auth_id = $1) and (wv.auth_class =
 data_class('user_id'))) or ((wv.auth_id = $2) and (wv.auth_class =
 data_class('clinic_id' where wv.worker_vis_id is not null and
 w.defunct = 0 order by coalesce(w.alias, w.worker);

update workers set last_active = now();
vacuum analyze workers;

update worker_vis set worker_id = worker_id;
vacuum analyze worker_vis;

update data_classes set defunct = 0 where defunct = 0;
vacuum analyze data_classes;

execute wrk;

That works as expected.  I also tried each of those updates/vacuums separately.

So now I'm trying the the "bad" query in the simple perl script i
posted before, Ive tried just one instance, and multiple instances...
I guess next ill try running all the sql each web session generates
before it crashes... unless anyone has any other bright ideas for me
to try.  Perhaps my simple updates are not enough for analyze to
invalidate the query plan?  Should I be doing inserts/deletes or just
more updates?

Below are the table counts and the definition of data_classes.  That
should be everything the query uses, except for the actually data.
Which I'm more than willing to provide (privately) if anyone thinks
they have a great idea on how to reproduce it.

 SELECT count(1) from workers;
 count
---
   716
 SELECT count(1) from worker_vis;
 count
---
   577

 SELECT count(1) from data_classes;
 count
---
75

 \d data_classes
 Table "public.data_classes"
Column|   Type   |
Modifiers
--+--+---
 data_class   | integer  | not null default
nextval('data_classes_data_class_seq'::regclass)
 data_id  | character varying(80)|
 data_table   | text |
 date_created | timestamp with time zone | default now()
 defunct  | smallint | default 0
 description  | character varying(80)|
Indexes:
"data_classes_pkey" PRIMARY KEY, btree (data_class)
"data_class_data_id_idx" UNIQUE, btree (data_id)
"data_class_data_idx" btree (data_id) WHERE defunct = 0

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs


Re: [BUGS] BUG #4027: backslash escaping not disabled in plpgsql

2008-03-12 Thread Bruce Momjian
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > Agreed. standard_conforming_strings should affect _all_ strings.
> 
> We might need another transition period over a few releases with a 
> separate "plpgsql_standard_conforming_strings" parameter.  Just changing it 
> immediately is perhaps a bit risky.

We haven't even enabled standard_conforming_strings by default yet.  It
was added as changeable in 8.2.  Is this never going to be enabled by
default?

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>http://momjian.us
  EnterpriseDB http://postgres.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs


Re: [BUGS] 8.3.0 backend segfaults

2008-03-12 Thread Tom Lane
"Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> Perhaps my simple updates are not enough for analyze to
> invalidate the query plan?  Should I be doing inserts/deletes or just
> more updates?

No, AFAICS the plan inval will happen after a vacuum regardless of whether
anything actually changed.  I'm thinking that there's some property
of the query or the invoked function that's relevant, but it's not
clear what.  (We'll know soon enough once we can reproduce it easily...)

regards, tom lane

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs


Re: [BUGS] BUG #4027: backslash escaping not disabled in plpgsql

2008-03-12 Thread Peter Eisentraut
Bruce Momjian wrote:
> Agreed. standard_conforming_strings should affect _all_ strings.

We might need another transition period over a few releases with a 
separate "plpgsql_standard_conforming_strings" parameter.  Just changing it 
immediately is perhaps a bit risky.


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs


Re: [BUGS] 8.3.0 backend segfaults

2008-03-12 Thread Alex Hunsaker
On Wed, Mar 12, 2008 at 1:37 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
>
> > Perhaps my simple updates are not enough for analyze to
>  > invalidate the query plan?  Should I be doing inserts/deletes or just
>  > more updates?
>
>  No, AFAICS the plan inval will happen after a vacuum regardless of whether
>  anything actually changed.  I'm thinking that there's some property
>  of the query or the invoked function that's relevant, but it's not
>  clear what.  (We'll know soon enough once we can reproduce it easily...)
>
> regards, tom lane
>

Ok I got it... have not been able to reproduce it in pure pgsql yet
so... maybe its a DBD::Pg bug? (CC'd Greg Sabino Mullane)

This crashes everytime for me. and just about every part is required. That is
If I take out the function call it works
If I take out the junk = ? it works
If I take out the nextval('junk_seq') it works
If I take out the begin_work it works



#!/usr/bin/perl
use strict;
use warnings;

use DBI();
use DBD::Pg();

my $db = DBI->connect('dbi:Pg:dbname=test;', {'pg_server_prepare'=>1,
'pg_prepare_now'=>1}) || die "could not connect: $!";

$db->do('create table junk (junk text, junk_id int);');
$db->do('create sequence junk_seq;');
$db->do("create or replace function junk_func(int) returns integer as
'select junk_id from junk where junk_id = \$1;' language 'sql' stable
strict;");

my $sth = $db->prepare('select * from junk where junk = ? and junk_id
= junk_func(1) limit 1;');

$db->do('vacuum junk;');
$db->begin_work();

$db->do('select nextval(\'junk_seq\');');

$sth->execute('test') || die "failed: $!";
$sth->fetchall_arrayref();

$db->disconnect();

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs


Re: [BUGS] 8.3.0 backend segfaults

2008-03-12 Thread Alex Hunsaker
err that should be (forgot the username, password placeholders)

> my $db = DBI->connect('dbi:Pg:dbname=test;', '', '', {'pg_server_prepare'=>1, 
> 'pg_prepare_now'=>1}) || die "could not connect: $!";
>  $db->do('create table junk (junk text, junk_id int);');
>  $db->do('create sequence junk_seq;');
>  $db->do("create or replace function junk_func(int) returns integer as
>  'select junk_id from junk where junk_id = \$1;' language 'sql' stable
>  strict;");
>
>  my $sth = $db->prepare('select * from junk where junk = ? and junk_id
>  = junk_func(1) limit 1;');
>
>  $db->do('vacuum junk;');
>  $db->begin_work();
>
>  $db->do('select nextval(\'junk_seq\');');
>
>  $sth->execute('test') || die "failed: $!";
>  $sth->fetchall_arrayref();
>
>  $db->disconnect();
>

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs


Re: [BUGS] 8.3.0 backend segfaults

2008-03-12 Thread Alex Hunsaker
On Wed, Mar 12, 2008 at 1:59 PM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
>  $db->do("create or replace function junk_func(int) returns integer as
>  'select junk_id from junk where junk_id = \$1;' language 'sql' stable
>  strict;");
>

Another oddity

works: create or replace function junk_func() returns integer as
'select 1;' language 'sql' volatile strict;
works: create or replace function junk_func() returns integer as
'select 1 limit 1;' language 'sql' stable strict;

segfaults: create or replace function junk_func() returns integer as
'select 1;' language 'sql' stable strict;

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs


Re: [BUGS] 8.3.0 backend segfaults

2008-03-12 Thread Tom Lane
"Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> Ok I got it... have not been able to reproduce it in pure pgsql yet
> so... maybe its a DBD::Pg bug? (CC'd Greg Sabino Mullane)

Great, got it --- you need a protocol-level prepare to cause it (or so
I expect) and pure psql won't do that.  I was able to reproduce it
with a quick test program using PQprepare though.  Now to dig ...

regards, tom lane

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs


Re: [BUGS] 8.3.0 backend segfaults

2008-03-12 Thread Tom Lane
This patch should fix it ...

regards, tom lane

Index: postgres.c
===
RCS file: /cvsroot/pgsql/src/backend/tcop/postgres.c,v
retrieving revision 1.544
diff -c -r1.544 postgres.c
*** postgres.c  10 Mar 2008 12:55:13 -  1.544
--- postgres.c  12 Mar 2008 23:42:32 -
***
*** 730,760 
  pg_plan_queries(List *querytrees, int cursorOptions, ParamListInfo 
boundParams,
bool needSnapshot)
  {
!   List   *stmt_list = NIL;
!   ListCell   *query_list;
  
!   foreach(query_list, querytrees)
{
!   Query  *query = (Query *) lfirst(query_list);
!   Node   *stmt;
  
!   if (query->commandType == CMD_UTILITY)
{
!   /* Utility commands have no plans. */
!   stmt = query->utilityStmt;
!   }
!   else
!   {
!   if (needSnapshot)
{
!   ActiveSnapshot = 
CopySnapshot(GetTransactionSnapshot());
!   needSnapshot = false;
}
!   stmt = (Node *) pg_plan_query(query, cursorOptions, 
boundParams);
}
  
!   stmt_list = lappend(stmt_list, stmt);
}
  
return stmt_list;
  }
--- 730,778 
  pg_plan_queries(List *querytrees, int cursorOptions, ParamListInfo 
boundParams,
bool needSnapshot)
  {
!   List   * volatile stmt_list = NIL;
!   SnapshotsaveActiveSnapshot = ActiveSnapshot;
  
!   /* PG_TRY to ensure previous ActiveSnapshot is restored on error */
!   PG_TRY();
{
!   SnapshotmySnapshot = NULL;
!   ListCell   *query_list;
  
!   foreach(query_list, querytrees)
{
!   Query  *query = (Query *) lfirst(query_list);
!   Node   *stmt;
! 
!   if (query->commandType == CMD_UTILITY)
!   {
!   /* Utility commands have no plans. */
!   stmt = query->utilityStmt;
!   }
!   else
{
!   if (needSnapshot && mySnapshot == NULL)
!   {
!   mySnapshot = 
CopySnapshot(GetTransactionSnapshot());
!   ActiveSnapshot = mySnapshot;
!   }
!   stmt = (Node *) pg_plan_query(query, 
cursorOptions,
!   
  boundParams);
}
! 
!   stmt_list = lappend(stmt_list, stmt);
}
  
!   if (mySnapshot)
!   FreeSnapshot(mySnapshot);
!   }
!   PG_CATCH();
!   {
!   ActiveSnapshot = saveActiveSnapshot;
!   PG_RE_THROW();
}
+   PG_END_TRY();
+   ActiveSnapshot = saveActiveSnapshot;
  
return stmt_list;
  }

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs


Re: [BUGS] 8.3.0 backend segfaults

2008-03-12 Thread Alex Hunsaker
On Wed, Mar 12, 2008 at 6:00 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> This patch should fix it ...
>
> regards, tom lane

Excellent seems to have fixed the problem.  Thanks!

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs