Saurabh Agrawal wrote:
> max_standby_archive_delay = -1
>
> I noticed that whenever long running query executes on slave,
> slave starts lagging by master and as soon as query completes log
> files get applied immediately. Please help how can I avoid slave
> lag.
You can adjust max_standby_ar
Alanoly Andrews writes:
> Hello,
>
> PG version 8.4.7 on AIX 6.1.
>
> While creating a large multi-column index on a table of about 2.5 million
> rows, I got the following error:
>
>ERROR: out of memory
>
> DETAIL: Failed on request of size 50331648.
>
> I doubled the value of the sha
Hi All,
I have setup postgres 9 master slave streaming replication but
experiencing slave lagging sometimes by 50 min to 60 min. I am not
getting exact reason for slave lag delay. Below are the details:
1. Master table contains partition tables with frequent updates.
2. Slave is used for report g
Hello,
PG version 8.4.7 on AIX 6.1.
While creating a large multi-column index on a table of about 2.5 million rows,
I got the following error:
ERROR: out of memory
DETAIL: Failed on request of size 50331648.
I doubled the value of the "shared_buffers" parameter (from 512Mb to 1024Mb),
Gerhard Hintermayer wrote:
> Just checked my indices, looks like the only table in all my 5
> DB's that has a hash index is the one I ran tests on.
Well, actually that's pretty lucky. If you'd tested with other
indexes, you might have gone live with the broken index. I would
seriously consid
Just checked my indices, looks like the only table in all my 5 DB's
that has a hash index is the one I ran tests on. Should play in the
lottery this week :-) Will check this tomorrow and recreate the
affected hash indices. As the history of this db is quite long, I
really just can't remember how t
Gerhard Hintermayer wrote:
> I have e.g. a table with:
> Indexes:
> "idx_auftrag_l1" hash (a_nr)
Any *hash* index will need to be rebuilt. Like that one.
> Seeing this and reading the docs about the caveats I see no other
> solution as to REINDEX all of my DB's :-(
As the docs say,
On Mon, Apr 11, 2011 at 7:25 PM, Kevin Grittner
wrote:
> Gerhard Hintermayer wrote:
>
>> Because tests & docs say so:
>>
> http://www.postgresql.org/docs/9.0/static/continuous-archiving.html#CONTINUOUS-ARCHIVING-CAVEATS
>
> I asked because I didn't remember any mention of hashed indexes. I
> sti
Gerhard Hintermayer wrote:
> Because tests & docs say so:
>
http://www.postgresql.org/docs/9.0/static/continuous-archiving.html#CONTINUOUS-ARCHIVING-CAVEATS
I asked because I didn't remember any mention of hashed indexes. I
still don't know for sure that you have any, much less that you have
Because tests & docs say so:
http://www.postgresql.org/docs/9.0/static/continuous-archiving.html#CONTINUOUS-ARCHIVING-CAVEATS
;-) Docs say that this might be fixed sometime.
Also when I try a SELECT statement on the new primary, which makes use
of an index, I get an empty result, even though the t
On Apr 9, 2011, at 11:58 PM, Fredy Khan wrote:
> Hello,
>
> I get an unsupported header version error when I try to restore my database
> backup in another version of postgres via pgadmin. I would appreciate some
> help in this matter.
What;s error Message?
> regards,
>
> Fredy Khan
Than
Gerhard Hintermayer wrote:
> Unfortunately I had to insert 2.1 reindex database [for all
> databases] after creating the trigger file on the new dedicated
> primary
Why?
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://ww
On Thu, Apr 7, 2011 at 11:40 AM, Gerhard Hintermayer
wrote:
> Hi,
> I'm trying to set up at least 3 servers using hot standby streaming
> replication. I'd like to have one primary and 2 secondary (on 2
> different locations in case of a desaster in the server room).
> A primary
> B secondary 1
> C
Fredy Khan writes:
> Hello,
>
> I get an unsupported header version error when I try to restore my
> database backup in another version of? postgres via pgadmin. I would
> appreciate some help in this matter.
For starters...
What does your $PGDATA/PG_VERSION file contain?
2. What does pg_ctl --
"David Roland" wrote:
> changes to the data folder continue even after the PG_START_BACKUP
> command has been issued. This implies to me that the contents of
> any copy of the data folder may be unreliable. i.e. the copy may
> not reflect the state of the data folder either before the copy
> sta
Ok, so this has moved on a little from the query now...
As it stands now, without ANY data in the DB at all, taking a schema
pg_dump from the old machine and porting to the new, then run vacuum:
[root@pgsql3 build]# psql -U postgres -d hermes
Welcome to psql 8.1.9, the PostgreSQL interactive term
Hello,
I get an unsupported header version error when I try to restore my database
backup in another version of postgres via pgadmin. I would appreciate some
help in this matter.
regards,
Fredy Khan
OK - MORE development here.
If I bring down shared buffers to the equivalent of 1.7GB, it'll vacuum
without a problem.
Does anyone know why this might be?
Thanks in advance.
Cheers
-Original Message-
From: Scott Marlowe [mailto:scott.marl...@gmail.com]
Sent: 08 April 2011 08:47
To: Fr
First of all, thanks so much for the reply. To be clear, as stated in my
original post, if a user is interacting with the PostgreSQL database,
changes to the data folder continue even after the PG_START_BACKUP
command has been issued. This implies to me that the contents of any
copy of the data fol
> when i said "search for the problematic constraint" i meant to open the
file in a text editor and search for the problematic constraint.
Yes, I've even opened the dump file and analyzed those constraints. In
fact, I've already explained in detail about my observations here:
http://archives.po
20 matches
Mail list logo
