[GENERAL] replication server: LOG: invalid magic number 0000 in log file 169, segment 77, offset 4325376

2013-08-11 Thread ascot.m...@gmail.com
Hi, I found 'LOG: invalid magic number in log file 169, segment 77, offset 4325376" from the replica's log: LOG: entering standby mode LOG: redo starts at A8/BE81B200 LOG: consistent recovery state reached at A9/4CF8 LOG: database system is ready to accept read only connections LOG

[GENERAL] Enable WAL Archive in Replication server

2013-08-11 Thread ascot.m...@gmail.com
Hi, I want to archive WAL log files in the replication server as well, the postgresql.conf is added with following new lines, after restarting PG, the /var/pgsql/data/archive/ is still empty after 1 hour: ### new lines added today # # to enable the replica as Hot Standby hot_standby = on # #

Re: [GENERAL] Enable WAL Archive in Replication server

2013-08-11 Thread Jov
now you can only enable WAL archive on the Master server,it will not take effect on replication server. I can't find the doc which explicit prohibit WAL archive on the replication server,and there are WAL generated in the slave pg_xlog dir with archive_status subdir,so I think this may be a bug.

Re: [GENERAL] replication server: LOG: invalid magic number 0000 in log file 169, segment 77, offset 4325376

2013-08-11 Thread Jov
This means the slave meet the end of the WAL when it replay the WAL files/records.The message level is "LOG",so it can be safely ignored. Jov blog: http:amutu.com/blog 2013/8/11 ascot.m...@gmail.com > Hi, > > I found 'LOG: invalid magic number in log file 169, seg

Re: [GENERAL] Replication delay

2013-08-11 Thread Michael Paquier
On Sun, Aug 11, 2013 at 5:51 AM, ascot.m...@gmail.com wrote: > Hi, > > I have a pair of PG servers, a master and a replica, all read-write queries > are handled by the master, read-only ones are by the replica. > > From time to time the replica itself is too busy, all read-only queries will > ge

Re: [GENERAL] incremental dumps

2013-08-11 Thread Michael Nolan
On 8/10/13, haman...@t-online.de wrote: > currently the source uses some 20 GB in a database partition and about 700 > GB > in a general data partition. For the database, a diff -e grows to about 10% > of the size > of a full dump in a week > The remote site is a raid box at a hosting center, wit

Re: [GENERAL] replication server: LOG: invalid magic number 0000 in log file 169, segment 77, offset 4325376

2013-08-11 Thread ascot.m...@gmail.com
Thanks so much. On 11 Aug 2013, at 7:36 PM, Jov wrote: > This means the slave meet the end of the WAL when it replay the WAL > files/records.The message level is "LOG",so it can be safely ignored. > > Jov > blog: http:amutu.com/blog > > > 2013/8/11 ascot.m...@gmail.com > Hi, > > I found 'LO

Re: [GENERAL] Fastest Index/Algorithm to find similar sentences

2013-08-11 Thread Sergey Konoplev
On Sun, Aug 11, 2013 at 6:20 AM, Janek Sendrowski wrote: > the ranking functions are nice, but if I search for one more word, which is > not included in the sentence I'm searchingfor , It doesn't find the sentence. I have already wrote you earlier about it. You can solve the problem by using & (

Re: [GENERAL] earthdistance

2013-08-11 Thread Bruno Wolff III
On Sat, Aug 10, 2013 at 12:18:48 +0200, Olivier Chaussavoine wrote: I did not found any geographic indexing with earthdistance, and need it. Some of the earthdistance stuff is based on cube which does have indexing. I don't know how well that indexing works and it might be pretty bad in pr

Re: [GENERAL] Replication delay

2013-08-11 Thread Tatsuo Ishii
> On Sun, Aug 11, 2013 at 5:51 AM, ascot.m...@gmail.com > wrote: >> Hi, >> >> I have a pair of PG servers, a master and a replica, all read-write queries >> are handled by the master, read-only ones are by the replica. >> >> From time to time the replica itself is too busy, all read-only queries

Re: [GENERAL] Performance of ORDER BY RANDOM to select random rows?

2013-08-11 Thread Victor Hooi
Hi, @Hubert/@Sergey - Thanks for your response. Hmm, aha, so the ORDER BY RANDOM behaviour hasn't changed - just to confirm - this means that Postgres will duplicate the table, add a new column, generate random numbers for every record, then sort by that new column, right? I've just read the abo