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
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
"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
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()
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: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
"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
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.
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
"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
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
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" <[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: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,
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
"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
-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
"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 someth
On Wed, Mar 12, 2008 at 12:19 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Now personally, I am much more interested in *reproducing* the problem
> than merely dodging it. I can understand if you just need a workaround
> yesterday, but please see if you can get a reproducible test case ...
>
>
"Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> I can turn that off and only use DBI->prepare() as a test. Or heck
> just cut DBI->prepare() out and just quote everything and send them
> through using DBI->do() instead. That is if you think that could be
> the culprit.
The path of control that's d
Oops we actually use DBI->prepare_cached() not DBI->prepare() which to
my understanding should be roughly equivalent to (because of
Apache::DBI):
prepare query ;
begin;
execute query;
commit;
(next page load)
begin;
execute query;
commit;
I can turn that off and only use DBI->prepare() as a t
FYI right now Im trying:
Author: tgl
Date: Sat Feb 2 22:26:17 2008 +
Fix WaitOnLock() to ensure that the process's "waiting" flag is reset after
erroring out of a wait. We can use a PG_TRY block for this, but
add a comment
explaining why it'd be a bad idea to use it for any ot
On Tue, Mar 11, 2008 at 10:59 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> > Problem: Apparently random segfaults apparently query agnostic, seem
> > to be more frequent when a pg_dump is running
>
> Hmm, seems from the backtrace that we're trying to
"Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> Problem: Apparently random segfaults apparently query agnostic, seem
> to be more frequent when a pg_dump is running
Hmm, seems from the backtrace that we're trying to do a replan with an
invalid ActiveSnapshot. What sequence of operations is the co
24 matches
Mail list logo
