From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | marcin mank <marcin(dot)mank(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Streaming rep - why log shipping is necessary? |
Date: | 2010-02-25 17:34:30 |
Message-ID: | 4B86B4A6.1050200@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> If you're adventurous enough, it's actually possible to set an
>> archive_command that checks the status of the standby and returns
>> failure as long as the standby still needs the given WAL segment. That
>> way the primary doesn't recycle segments that are still needed by the
>> standby, and you can get away without restore_command in the standby.
I'd prefer something a little different ... is there any way to tell
which log segments a standby still needs, *from* the standby?
Given performance considerations, I'd prefer to set up HS/SR with log
shipping because I don't want any slaves asking the master for a really
old log and interfering with its write performance. However, that
leaves the issue of "How do I decide when I can delete archived log
segments off the slave because the slave is past them?"
Currently, I'm recommending some interval of time, but that's very brute
force and error-prone. I'd prefer some elegant way to determine "log
segment contains no unapplied transactions." Is there one?
--Josh Berkus
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2010-02-25 17:45:50 | Re: tie user processes to postmaster was:(Re: [HACKERS] scheduler in core) |
Previous Message | Greg Smith | 2010-02-25 17:31:55 | Re: pg_stop_backup does not complete |