From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | niranjan(dot)k(at)nsn(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Synch Replication |
Date: | 2009-02-09 08:52:48 |
Message-ID: | 3f0b79eb0902090052n1dd074d7ya4218be402c8e4a7@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Niranjan,
Thanks very much!
On Mon, Feb 9, 2009 at 3:08 PM, K, Niranjan (NSN - IN/Bangalore)
<niranjan(dot)k(at)nsn(dot)com> wrote:
> Now, the active and standby database are up & running even after the
> execution of the SQL (create table). What was the problem?
The problem is that 1-byte variable was assigned the value casted to 4-bytes,
which overwrote another variable (which lives next to the 1-byte val) wrongly.
This behavior varies based on environment (ex. memory alignment). So,
the trouble wasn't reproduced on my machine though it occurred on yours.
It's my disgraceful bug.. :(
> But when I logged in the standby instance by executing 'psql -d
> replication', I did not see the table that was created on the primary.
> I have few questions:
>
> - I'am not sure whether the replication is done but I'am not able to
> view? Will I be able to view the replication by logging inside to
> standby instance? Hotstandby patch will allow to read from standby. Is
> this patch integrated in sync replication patch?
No, hot standby and synch rep are independent patch now. So, you
cannot issue any queries to the standby server during replication.
The progress of replication can be checked via 'ps' command as follows.
This reports the LSN already the standby server has received and written
(or fsynced).
------------
[primary] $ pgrep -fl wal
1803 postgres: wal writer process
1830 postgres: wal sender process postgres 127.0.0.1(34604) replicated
to: write 0/1F74DD0, flush 0/1F68878
[standby] $ pgrep -fl wal
1828 postgres: wal receiver process replicated to: write 0/1F74DD0,
flush 0/1F68878
------------
> - I brought down the active instance by executing 'pg_ctl -D
> /home/postgres/postgresHSB/actdata stop' hoping that trigger file will
> enable failover. But I was not able to login to standby instance. Not
> sure why?
Please let me know the failover procedure which you carried out. As follows?
1) pg_ctl -D /home/postgres/postgresHSB/actdata stop
2) touch /home/postgres/postgresHSB/finish.trigger
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Mihai Criveti | 2009-02-09 09:38:47 | Re: 64 bit PostgreSQL 8.3.6 build on AIX 5300-09-02-0849 with IBM XL C/C++ 10.1.0.1 - initdb fails (could not dump unrecognized node type: 650) |
Previous Message | Tom Lane | 2009-02-09 07:40:04 | Re: 64 bit PostgreSQL 8.3.6 build on AIX 5300-09-02-0849 with IBM XL C/C++ 10.1.0.1 - initdb fails (could not dump unrecognized node type: 650) |