Hi,
for the archives: the root cause is locale. Both linux/debian servers
were set to the same locale (cs_CZ.UTF-8) but there is slightly
different definition of this locale on those systems - once numbers are
before letters and another time numbers are after letters. Then the
index appears t
Hi Robert,
> If there hasn't been a system crash on the standby, then it's harder
> to explain. It'd be interesting to compare the disk blocks in the
> index on the standby with the disk blocks in the index on the master
> and figure out which ones are different and in what way. pg_filedump
> m
Hi,
Do you still have the WAL files?
what do you mean exactly? We don't have full history of WAL files from
creation of hot streaming standby. They are recycled. We have set of WAL
files from the point we discovered the corrupted index and stopped the
cluster. But it was probably days after
Hi,
we've found that we have corrupted index on 9.0.3 streaming hot standby.
Master works ok. There is one more non-streaming standby which is ok as
well. Platform is 64bit Linux.
Database cluster and this database were created on 9.0.2 and than
upgraded to 9.0.3. We are not aware of any cra
> The auto-reconnect behavior is long-established and desirable. What's
> not desirable is continuing with any statements remaining on the same
> line, I think. We need to flush the input buffer on reconnect.
So if I understand it correctly, if I need correct transaction behaviour
in psql even
Tom:
> Looks like the disconnect was because pgbouncer restarted. If that
> wasn't supposed to happen then you should take it up with the
> pgbouncer folk.
The restart of pgbouncer was intentional, although made by someone else,
so the disconnect is ok. What's not ok is the "UPDATE 153" messag
> hmm yeah that is indeed a tad weird - are you actually using as
> pool_mode and server_reset_query?
pool_mode = session
server_reset_query = RESET ALL; SET SESSION AUTHORIZATION DEFAULT;
UNLISTEN *;
Kuba
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to you
brunner napsal(a):
On 05/21/2010 11:19 AM, Jakub Ouhrabka wrote:
Hi,
can anyone tell me how this could happen, please?
database=# begin; update table set col = 100;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while pr
2010-05-21 16:00:17.286 32227 LOG S-0xa6799e0:
database/u...@x.x.x.x:5432 new connection to server
Dne 21.5.2010 17:28, Tom Lane napsal(a):
Jakub Ouhrabka writes:
can anyone tell me how this could happen, please?
database=# begin; update table set col = 100;
server closed the connection
Hi,
can anyone tell me how this could happen, please?
database=# begin; update table set col = 100;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempti
By "last patch" you mean
http://archives.postgresql.org/pgsql-committers/2007-10/msg00409.php
?
Sorry for confusion, I meant this one:
http://archives.postgresql.org/pgsql-bugs/2007-10/msg00217.php
Is it the same as the commited one?
If so that's about as fast as it's likely to get. 22
Hi Tom,
...probably have some cases like that in your real application. But I'd
expect 8.2.4 to be equally slow because it also contains the code that
is slow in that scenario. I'm hoping to get some time today to think
about how that could be fixed.
Please try the attached patch (in additio
Hi Tom,
Hmm. I think there are two different bugs involved here. One is fixed
by the attached patch, and it masks the performance problem on your test
case, but I wonder whether it will be enough for your real application.
Can you try this and see if it fixes 8.2.5 for you?
many thanks for t
Hi Tom,
> Either poke into the code yourself, or submit a self-contained test
> case (the query alone does not a test case make). I can't offhand
> think of a reason for 8.2.5 to be slower than 8.2.4 ...
preparing the test case was easier than I expected. It's attached. Fast
planning on 8.2.4,
Hi Tom,
I tried to simplify the query even more and now I have query which on
8.2.4 is planned instantly and on 8.2.5 takes cca 8 seconds.
Are you sure you were using the same planner parameters (particularly
join_collapse_limit and the geqo threshold) in both cases?
thanks for the reply.
Y
Hi,
we switched from 8.2.4 to 8.2.5 and were forced to switch back. Our main
goal was to improve planner perfomance with outer joins per this change
from release notes:
Fix some planner problems with outer joins, notably poor size estimation
for t1 LEFT JOIN t2 WHERE t2.col IS NULL (Tom)
B
16 matches
Mail list logo
