Skip site navigation (1) Skip section navigation (2)

Re: Well, we seem to be proof against cache-inval problems now

From: Alex Pilosov <alex(at)pilosoft(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Well, we seem to be proof against cache-inval problems now
Date: 2001-01-05 19:13:26
Message-ID: Pine.BSO.4.10.10101051356350.31095-100000@spider.pilosoft.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, 5 Jan 2001, Tom Lane wrote:

> I just finished running the parallel regress tests with inval.c rigged
> to flush the relcache and syscache at every available opportunity,
> that is anytime we could recognize a shared-cache-inval message from
> another backend (see diff below).  This setup gives a whole new universe
> of meaning to the word "slow" --- it took *three full days* to run the
> standard "make check" procedure, including eighteen hours just to do the
> "vacuum template1" part of initdb.  I kid you not.  But it worked.
> Looks like the unexpected-cache-entry-drop class of problems are indeed
> gone.
Tom, I'm not sure how (or whether) this relates to "alter table" happening
when someone else is doing a SELECT from table. Are you saying that it
should work without any locking or I'm completely off base?

-alex




In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2001-01-05 19:14:29
Subject: Re: Well, we seem to be proof against cache-inval problems now
Previous:From: Alex PilosovDate: 2001-01-05 18:50:18
Subject: Re: running pgsql 7 under Jail'ed virtual machine on FreeBSD 4.2

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group