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
