| From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Streaming replication status |
| Date: | 2010-01-12 10:15:21 |
| Message-ID: | 3f0b79eb1001120215j1beba61cy6d00a81617128f8c@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jan 12, 2010 at 4:22 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> It would be more straightforward to have a function in the standby to
> return the current replay location. It feels more logical to poll the
> standby to get the status of the standby, instead of indirectly from the
> master. Besides, the master won't know how far the standby is if the
> connection to the standby is broken.
>
> Maybe we should just change the existing pg_current_xlog_location()
> function to return that when recovery is in progress. It currently
> throws an error during hot standby.
Sounds good.
I'd like to hear from someone which location should be returned by
that function (WAL receive/write/flush/replay location?). I vote for
WAL flush location because it's important for me to know how far the
standby can replay the WAL, i.e., how much transactions might be lost
at failover. And, it's also OK to provide the dedicated function for
WAL replay location. Thought?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Magnus Hagander | 2010-01-12 10:18:45 | Re: Streaming replication status |
| Previous Message | Pavel Stehule | 2010-01-12 10:10:41 | bug in integration SQL parser to plpgsq |