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
(Sorry if duplicates show up this is the third time ive posted this in
the past 10 hours, Im assuming it got dropped because of the
attachments)
Problem: Apparently random segfaults apparently query agnostic, seem
to be more frequent when a pg_dump is running
The most frequent query it segfault
25 matches
Mail list logo
