| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Markus Wanner <markus(at)bluegap(dot)ch>, ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Synchronous Log Shipping Replication |
| Date: | 2008-09-09 15:43:18 |
| Message-ID: | 1220974998.3913.522.camel@ebony.2ndQuadrant |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 2008-09-09 at 18:26 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > Don't understand. I am referring to the logic at the top of
> > AdvanceXLInsertBuffer(). We would need to wait for all people reading
> > the contents of wal_buffers.
>
> Oh, I see.
>
> If a slave falls behind, how does it catch up?
That is the right question.
> I guess you're saying
> that it can't fall behind, because the master will block before that
> happens. Also in asynchronous replication?
Yes, it can fall behind in async mode. sysadmin must not let it.
> And what about when the slave
> is first set up, and needs to catch up with the master?
We need an initial joining mode while they "match speed". We must allow
for the case where the standby has been recycled, or the network has
been down for a medium-long period of time.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2008-09-09 16:06:53 | Re: Common Table Expressions (WITH RECURSIVE) patch |
| Previous Message | Heikki Linnakangas | 2008-09-09 15:26:26 | Re: Synchronous Log Shipping Replication |