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
> 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,
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
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
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.
-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 p
"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 lik
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).
>
> N
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,
"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 schem
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
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 cha
"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
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.jun
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.
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
"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 t
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 mai
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 inv
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;'
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()
"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
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:5
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 subscripti
24 matches
Mail list logo
