Re: logical decoding and replication of sequences
| От | Tomas Vondra |
|---|---|
| Тема | Re: logical decoding and replication of sequences |
| Дата | |
| Msg-id | 67acc02f-7989-0bc3-1b19-e5210b7659db@enterprisedb.com обсуждение исходный текст |
| Ответ на | Re: logical decoding and replication of sequences (Thomas Munro <thomas.munro@gmail.com>) |
| Ответы |
Re: logical decoding and replication of sequences
|
| Список | pgsql-hackers |
On 8/29/22 12:21, Thomas Munro wrote: > On Mon, Aug 8, 2022 at 8:56 PM Kyotaro Horiguchi > <horikyota.ntt@gmail.com> wrote: >> At Mon, 08 Aug 2022 17:33:22 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in >>> If WaitForWALToBecomeAvailable returned by promotion, ReadPageInteral >>> misses the chance to inavlidate reader-state. That state is not an >>> error while in StandbyMode. >> >> Mmm... Maybe I wanted to say: (Still I'm not sure the rewrite works..) >> >> If WaitForWALToBecomeAvailable returned by promotion, ReadPageInteral >> would miss the chance to invalidate reader-state. When XLogPageRead >> is called in blocking mode while in StandbyMode (that is, the >> traditional condition) , the function continues retrying until it >> succeeds, or returns XLRAD_FAIL if promote is triggered. In other >> words, it was not supposed to return non-failure while the header >> validation is failing while in standby mode. But while in nonblocking >> mode, the function can return non-failure with lastSourceFailed = >> true, which seems wrong. > > New ideas: > > 0001: Instead of figuring out when to invalidate the cache, let's > just invalidate it before every read attempt. It is only marked valid > after success (ie state->readLen > 0). No need to worry about error > cases. > Maybe I misunderstand how all this works, but won't this have a really bad performance impact. If not, why do we need the cache at all? regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: