Re: Disabled features on Hot Standby
От | Simon Riggs |
---|---|
Тема | Re: Disabled features on Hot Standby |
Дата | |
Msg-id | CA+U5nMJ9zkfpgAFDG8FguHPk-eap0oM+PCEr6q75hmUeZXYwnw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Disabled features on Hot Standby (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: Disabled features on Hot Standby
|
Список | pgsql-hackers |
On Sat, Jan 14, 2012 at 1:02 AM, Noah Misch <noah@leadboat.com> wrote: >> Also, what happens if an all-visible bit gets set on the standby >> through some other mechanism - e.g. restored from an FPI or >> XLOG_HEAP_NEWPAGE? I'm not sure whether we ever do an FPI of the >> visibility map page itself, but we certainly do it for the heap pages. >> So it might be that this infrastructure would (somewhat bizarrely) >> trust the visibility map bits but not the PD_ALL_VISIBLE bits. > > Simon spoke to the FPI side of the question. For heap pages, the > XLOG_HEAP_NEWPAGE consumers are CLUSTER, VACUUM FULL and ALTER TABLE SET > TABLESPACE. For the last, we will have already logged any PD_ALL_VISIBLE bits > through normal channels. CLUSTER and VACUUM FULL never set PD_ALL_VISIBLE or > visibility map bits. When, someday, they do, we might emit a separate WAL > record to force the recovery conflict. However, CLUSTER/VACUUM FULL already > remove tuples still-visible to standby snapshots without provoking a recovery > conflict. (Again only with hot_standby_feedback=off.) If that were the case it would be a bug. CLUSTER/VACUUM FULL emit an AccessExclusiveLock record that would conflict with any current lock holders, so should be fine on that. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: