On Sun, Aug 14, 2011 at 12:16:39AM -0400, Robert Haas wrote:
> On Fri, Aug 12, 2011 at 7:19 PM, daveg wrote:
> > This seems to be bug month for my client. Now there are seeing periods
> > where all new connections fail immediately with the error:
> >
> > FATAL: lock AccessShareLock on object 0/
On Fri, Aug 12, 2011 at 7:19 PM, daveg wrote:
> This seems to be bug month for my client. Now there are seeing periods
> where all new connections fail immediately with the error:
>
> FATAL: lock AccessShareLock on object 0/1260/0 is already held
>
> This happens on postgresql 8.4.7 on a large
On Sat, Aug 13, 2011 at 5:31 PM, Heikki Linnakangas
wrote:
> Yeah, I'm not excited about making the planner and statistics more dynamic.
> Feedback loops and plan instability are not fun. I think we should rather be
> more aggressive in setting the visibility map bits.
As far as I can see, the on
Tom Lane wrote:
> Alvaro Herrera writes:
> > Excerpts from Jeff Davis's message of mar ago 09 16:03:26 -0400 2011:
> >> I think I agree with Peter here that it's not a very good idea, and I
> >> don't see a big upside. With tablespaces it seems to make a little bit
> >> more sense, but I'd still l
On 14.08.2011 01:13, Tom Lane wrote:
On investigation, this turns out to occur when the planner is trying to
fetch the value of a toasted attribute in a cached pg_statistic tuple,
and a concurrent "vacuum full pg_statistic" has just finished. The
problem of course is that vacuum full reassigned
On Sat, Aug 13, 2011 at 4:40 PM, Greg Stark wrote:
> On Sat, Aug 13, 2011 at 8:52 PM, Robert Haas wrote:
>> and possibly we ought to put them all in a
>> linked list so that the next guy who needs a buffer can just pop one
>
> The whole point of the clock sweep algorithm is to approximate an LRU
So I've gotten things fixed to the point where the regression tests seem
to not fall over when contending with concurrent "vacuum full pg_class",
and now expanded the scope of the testing to all the system catalogs.
What's failing for me now is this chunk in opr_sanity:
*** 209,219
NOT
I realize it's a bit late to jump in here with the path already having been
committed. But I think there's a point that was missed in the discussion.
One reason to do the test as Tom recommended is that the warning probably
indicates that the test as written was just going to be optimized away as
d
On 13.08.2011 23:35, Kääriäinen Anssi wrote:
"""
Now, suppose that we know that 50% of the heap pages have their
visibility map bits set. What's the chance that this query won't need
a heap fetch? Well, the chance is 50% *if* you assume that a row
which has been quiescent for a long time is jus
On Sat, Aug 13, 2011 at 8:52 PM, Robert Haas wrote:
> and possibly we ought to put them all in a
> linked list so that the next guy who needs a buffer can just pop one
The whole point of the clock sweep algorithm is to approximate an LRU
without needing to maintain a linked list. The problem wit
"""
Now, suppose that we know that 50% of the heap pages have their
visibility map bits set. What's the chance that this query won't need
a heap fetch? Well, the chance is 50% *if* you assume that a row
which has been quiescent for a long time is just as likely to be
queried as one that has been
Robert Haas writes:
> On the other hand, I am also not entirely sure such a change in
> terminology would be a net improvement in clarity, even though it does
> seem better in some cases. For example, the CREATE TABLE command does
> not create a viewed table; nor is there any CREATE VIEWED TABLE
On Fri, Aug 12, 2011 at 10:51 PM, Greg Stark wrote:
> On Fri, Aug 12, 2011 at 5:05 AM, Robert Haas wrote:
>> Only 96 of the 14286 buffers in sample_data are in shared_buffers,
>> despite the fact that we have 37,218 *completely unused* buffers lying
>> around. That sucks, because it means that t
On Sat, Aug 13, 2011 at 1:56 PM, Peter Eisentraut wrote:
> On fre, 2011-08-12 at 16:14 -0400, Robert Haas wrote:
>> On Fri, Aug 12, 2011 at 4:11 PM, Peter Eisentraut wrote:
>> > "A table is either a base table, a derived table, a transient table, or
>> > a viewed table." (SQL/MED adds "foreign ta
On Fri, Aug 12, 2011 at 5:39 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> That's one of the points I asked for feedback on in my original
>> email. "How should the costing be done?"
>
> It seems pretty clear that there should be some cost adjustment. If
> you can't get good numbers someh
On Sat, Aug 13, 2011 at 12:18 PM, Tom Lane wrote:
> I wrote:
>> Yeah. Also, to my mind this is only a fix that will be used in 9.0 and
>> 9.1 --- now that it's occurred to me that we could use tuple xmin/xmax
>> to invalidate catcaches instead of recording individual TIDs, I'm
>> excited about do
On fre, 2011-08-12 at 16:14 -0400, Robert Haas wrote:
> On Fri, Aug 12, 2011 at 4:11 PM, Peter Eisentraut wrote:
> > "A table is either a base table, a derived table, a transient table, or
> > a viewed table." (SQL/MED adds "foreign table".)
> >
> > Just FYI.
>
> Base table seems clear enough, an
I wrote:
> Yeah. Also, to my mind this is only a fix that will be used in 9.0 and
> 9.1 --- now that it's occurred to me that we could use tuple xmin/xmax
> to invalidate catcaches instead of recording individual TIDs, I'm
> excited about doing that instead for 9.2 and beyond. I believe that
> th
Heikki Linnakangas writes:
> The patch is WIP, mainly because I didn't write the WAL replay routines
> yet, but please let me know if you see any issues.
Why do you need new WAL replay routines? Can't you just use the existing
XLOG_HEAP_NEWPAGE support?
By any large, I think we should be avoid
Simon Riggs writes:
> With HOT, there is very little need to perform a VACUUM FULL on any
> shared catalog table. Look at the indexes...
This is not really a useful argument. People do do VAC FULL on
catalogs, whether we think they should or not. Also, it's not only
"shared" catalogs that are a
On 12 August 2011 23:19, Heikki Linnakangas
wrote:
>>> Triggers complicate this. I believe it is only safe to group tuples
>>> together
>>> like this if the table has no triggers. A BEFORE ROW trigger might run a
>>> SELECT on the table being copied to, and check if some of the tuples
>>> we're
>>
On fre, 2011-08-12 at 20:09 -0700, Darren Duncan wrote:
> David E. Wheeler wrote:
> > On Aug 12, 2011, at 6:17 PM, Alex Hunsaker wrote:
> >> Anyway, the attached patch fixes it for me. That is when we don't have
> >> an array state, just return an empty array. (Also adds some
> >> additional comme
22 matches
Mail list logo
