"Carrington, Matthew (Produban)" writes:
> Reading symbols from
> /ukmetmon/data/dataCollection/postgres_9.2.1/bin/pg_dump...(no debugging
> symbols found)...done.
... hm, not sure why that didn't work, but anyway:
> (gdb) bt
> #0 0x00010002e354 in exit_horribly ()
> #1 0x00010003243
Tom,
OK, here you go ...
Rebuild postgres with debugging ...
export OBJECT_MODE=64
export CFLAGS="-maix64"
export LDFLAGS="-maix64 -Wl,-bbigtoc"
export AR="ar -X64"
./configure --enable-debug --prefix=/opt/serviceMonitoring/postgres_9.2.1
--disable-thread-safety
make
cd contrib
make
cd ..
ma
"Carrington, Matthew (Produban)" writes:
> I've tried to explore the issue a bit more using 9.2.1. Here's a trace of the
> build and dump tests ...
As long as you're building your own copy, how about building with
--enable-debug and getting a stack trace showing where the error is
being thrown?
correction: because the single master was too BUSY
On 28 Sep 2012, at 7:48 PM, a...@hsk.hk wrote:
> Hi Jon,
>
> I have had a similar case as yours, I have one data center in Hong Kong
> another one in Tokyo, we have line between them, here are my feedback:
>
> 1) we used multiple masters at fi
Hi Jon,
I have had a similar case as yours, I have one data center in Hong Kong another
one in Tokyo, we have line between them, here are my feedback:
1) we used multiple masters at first, from time to time, some issues like that
it took time to sync between master servers which caused obvious
I've tried to explore the issue a bit more using 9.2.1. Here's a trace of the
build and dump tests ...
tar zxf postgresql-9.2.1.tar.gz
cd postgresql-9.2.1
uname -a
AIX sx1190a 1 6 000A707AD400 powerpc AIX
export OBJECT_MODE=64
export CFLAGS="-maix64"
export LDFLAGS="-maix64 -Wl,-bbigtoc"
exp
On 09/28/12 12:36 AM, Albe Laurenz wrote:
Yelai, Ramkumar wrote:
>7 base tables X 120 months = 840 child tables. As per your statement, If I
create these many table then it will affect the performance. But as per the
document (http://www.postgresql.org/docs/9.1/static/ddl-partitioning.html)
co
Yelai, Ramkumar wrote:
>> Anything exceeding a few hundred partitions is not considered a good
idea.
>> The system needs to keep track of all the tables, and query planning
for such a partitioned table
>> might be expensive.
>>
>> 1440 is probably pushing the limits, but maybe somebody with more
e
