Re: Proposal: "Causal reads" mode for load balancing reads without stale data
От | Michael Paquier |
---|---|
Тема | Re: Proposal: "Causal reads" mode for load balancing reads without stale data |
Дата | |
Msg-id | CAB7nPqR-mcswK38h6ce4Ezy36VhtEDV3uix74MJf_yaMiy7UBA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Proposal: "Causal reads" mode for load balancing reads without stale data (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Thu, Mar 24, 2016 at 11:20 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Thu, Mar 24, 2016 at 2:11 AM, Michael Paquier > <michael.paquier@gmail.com> wrote: >> - SyncRepWaitForLSN(gxact->prepare_end_lsn); >> + SyncRepWaitForLSN(gxact->prepare_end_lsn, false); >> Isn't it important to ensure that a PREPARE LSN is applied as well on >> the standby with remote_apply? Say if an application prepares a >> transaction, it would commit locally but its LSN may not be applied on >> the standby with this patch. That would be a surprising behavior for >> the user. > > You need to wait for COMMIT PREPARED, but I don't see why you need to > wait for PREPARE itself. Multi-master conflict resolution. Knowing in-time that a prepared transaction has been applied is useful on another node for lock conflicts resolution. Say a PRIMARY KEY insert is prepared, and we want to know at application level that its prepared state is visible everywhere. -- Michael
В списке pgsql-hackers по дате отправления: