Neil Conway <[EMAIL PROTECTED]> writes:
> On Fri, 2007-04-20 at 02:55 -0400, Tom Lane wrote:
>> I don't think you've thought of quite all of the failure cases. One
>> that's a bit pressing is that a deadlock isn't necessarily confined to
>> objects in your own database.
> I'm not sure I follow. I
Andrew Dunstan wrote:
> Log Message:
> ---
> Add --with-libxslt configure option
It should be added to the installation documentation as well.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 7: You
Gregory Stark <[EMAIL PROTECTED]> writes:
> I think there's still a problem here with some kind of n^2 behaviour for
> appends of very wide tables but I haven't quite nailed it yet. In any case is
> there any reason not to make the following small change to move the constraint
> exclusion ahead of
Gregory Stark <[EMAIL PROTECTED]> writes:
> Following up on some complaints we've had about extremely large plan times for
> large partitioned tables I've been doing some profiling.
> % cumulative self self total
> time seconds secondscalls s/call s/c
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> The SearchCatCache here is the one in get_attavgwidth called to estimate the
>> relation width.
>
> Hmm, that information is supposed to be cached ... could you provide the
> test case?
This case caused my machi
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> The SearchCatCache here is the one in get_attavgwidth called to estimate the
>> relation width.
>
> Hmm, that information is supposed to be cached ... could you provide the
> test case?
Cached meaning it's stor
Gregory Stark <[EMAIL PROTECTED]> writes:
> The SearchCatCache here is the one in get_attavgwidth called to estimate the
> relation width.
Hmm, that information is supposed to be cached ... could you provide the
test case?
> The first thing that comes to mind is that we're doing the
> constraint_
2007/4/16, Ottó Havasvölgyi <[EMAIL PROTECTED]>:
Eliminate the table T from the query/subquery if the following requirements
are satisfied:
1. T is left joined
2. T is referenced only in the join expression where it is left joined
3. the left join's join expression is a simple equality expressio
Following up on some complaints we've had about extremely large plan times for
large partitioned tables I've been doing some profiling. I've constructed a
situation where it takes upwards of 30 seconds to plan a simple query like:
postgres=# explain select * from a where i between 999 and 1001;
On Fri, 2007-04-20 at 02:55 -0400, Tom Lane wrote:
> I don't think you've thought of quite all of the failure cases. One
> that's a bit pressing is that a deadlock isn't necessarily confined to
> objects in your own database.
I'm not sure I follow. If we conditionally acquire the locks we need an
Magnus Hagander wrote:
The effective max count on Unixen is typically in the thousands,
and I'd suggest the same on Windows unless there's some efficiency
reason to keep it small (in which case, maybe ten would do).
AFAIK there's no problem with huge numbers (it takes an int32, and the
do
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> How is it possible for a semaphore to be unlocked "too many times"?
>>> It's supposed to be a running counter of the net V's minus P's, and
>>> yes it had better be able to count higher than one. Have we chosen
>>
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> How is it possible for a semaphore to be unlocked "too many times"?
>> It's supposed to be a running counter of the net V's minus P's, and
>> yes it had better be able to count higher than one. Have we chosen
>> the wrong Windows pri
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> On Fri, Apr 20, 2007 at 09:20:05AM +0200, Marcin Waldowski wrote:
I've looked at the code there, and can't find a clear problem. One way it
could happen is if the actual PGSemaphoreUnlock() is called once more than
need
Magnus Hagander <[EMAIL PROTECTED]> writes:
> On Fri, Apr 20, 2007 at 09:20:05AM +0200, Marcin Waldowski wrote:
>>> I've looked at the code there, and can't find a clear problem. One way it
>>> could happen is if the actual PGSemaphoreUnlock() is called once more than
>>> needed.
> CC:ing to hack
On Fri, 2007-04-20 at 10:16 +0200, Zeugswetter Andreas ADI SD wrote:
> Your work in this area is extremely valuable and I hope my comments are
> not discouraging.
I think its too late in the day to make the changes suggested by
yourself and Tom. They make the patch more invasive and more likely t
Marcin Waldowski wrote:
Doesn't the postmaster restart all other backends due to the FATAL
error?
Are you saying that you can no longer make new connections to the
server,
or is the problem coming from that the aplpication doesn't like that the
server kicked out all connections?
No, we a
Here's only a part of the reply I should do, but as to I/O error
checking ...
Here's a list of system calls and other external function/library calls
used in pg_lesslog patch series, together with how current patch checks
each errors and how current postgresql source handles the similar calls:
--
Hi,
I agree that pg_compresslog should be aware of all the WAL records'
details so that it can optimize archive log safely. In my patch, I've
examined 8.2's WAL records to make pg_compresslog/pg_decompresslog safe.
Also I agree further pg_compresslog maintenance needs to examine changes
in
"Tom Lane" <[EMAIL PROTECTED]> writes:
> I don't think you've thought of quite all of the failure cases. One
> that's a bit pressing is that a deadlock isn't necessarily confined to
> objects in your own database.
We could do the syscache lookups for only the object we're waiting on and
store th
Magnus Hagander wrote:
Hmm, PGSemaphoreUnlock() actually ignore this error, only log that it
happens.
No. It does ereport(FATAL) which terminates the backend.
Oh, now I see, sorry :) Indeed on this one connection we receive
exception "FATAL: could not unlock semaphore", after that r
Andrew Dunstan írta:
Zoltan Boszormenyi wrote:
Martijn van Oosterhout írta:
On Thu, Apr 19, 2007 at 11:19:40AM +0200, Zoltan Boszormenyi wrote:
The problem comes from cases like
colname coltype DEFAULT 5! GENERATED ...
Since b_expr allows postfix operators, it takes one more token of
l
Zoltan Boszormenyi wrote:
Martijn van Oosterhout írta:
On Thu, Apr 19, 2007 at 11:19:40AM +0200, Zoltan Boszormenyi wrote:
The problem comes from cases like
colname coltype DEFAULT 5! GENERATED ...
Since b_expr allows postfix operators, it takes one more token of
lookahead than we have
> With DBT-2 benchmark, I've already compared the amount of WAL. The
> result was as follows:
>
> Amount of WAL after 60min. run of DBT-2 benchmark
> wal_add_optimization_info = off (default) 3.13GB
how about wal_fullpage_optimization = on (default)
> wal_add_optimization_info = on (new ca
On Fri, Apr 20, 2007 at 10:09:39AM +0200, Marcin Waldowski wrote:
> Magnus Hagander wrote:
> >I've looked at the code there, and can't find a clear problem. One way it
> >could happen is if the actual PGSemaphoreUnlock() is called once more than
> >needed.
> >
> >CC:ing to hackers for this questio
Magnus Hagander wrote:
I've looked at the code there, and can't find a clear problem. One way it
could happen is if the actual PGSemaphoreUnlock() is called once more than
needed.
CC:ing to hackers for this question:
Any chance that's happening? If this happens with SysV semaphores, will
they
On Fri, Apr 20, 2007 at 09:20:05AM +0200, Marcin Waldowski wrote:
> Hello.
>
> I've made some analysis of PostgreSQL code. It looks like void
> PGSemaphoreUnlock(PGSemaphore sema) from backend\port\win32_sema.c was
> executed one time more than needed.
Certainly looks that way.
I've looked at
Martijn van Oosterhout írta:
On Thu, Apr 19, 2007 at 11:19:40AM +0200, Zoltan Boszormenyi wrote:
The problem comes from cases like
colname coltype DEFAULT 5! GENERATED ...
Since b_expr allows postfix operators, it takes one more token of
lookahead than we have to tell if the default
28 matches
Mail list logo
