Re: sequences vs. synchronous replication
От | Fujii Masao |
---|---|
Тема | Re: sequences vs. synchronous replication |
Дата | |
Msg-id | 685b21d3-254d-48a7-8a26-e6e182b5e193@oss.nttdata.com обсуждение исходный текст |
Ответ на | sequences vs. synchronous replication (Tomas Vondra <tomas.vondra@enterprisedb.com>) |
Ответы |
Re: sequences vs. synchronous replication
|
Список | pgsql-hackers |
On 2021/12/23 3:49, Tomas Vondra wrote: > Attached is a patch tweaking WAL logging - in wal_level=minimal we do the same thing as now, in higher levels we log everysequence fetch. Thanks for the patch! With the patch, I found that the regression test for sequences failed. + fetch = log = fetch; This should be "log = fetch"? On second thought, originally a sequence doesn't guarantee that the value already returned by nextval() will never be returnedby subsequent nextval() after the server crash recovery. That is, nextval() may return the same value across crashrecovery. Is this understanding right? For example, this case can happen if the server crashes after nextval() returnedthe value but before WAL for the sequence was flushed to the permanent storage. So it's not a bug that sync standbymay return the same value as already returned in the primary because the corresponding WAL has not been replicatedyet, isn't it? BTW, if the returned value is stored in database, the same value is guaranteed not to be returned again after the servercrash or by sync standby. Because in that case the WAL of the transaction storing that value is flushed and replicated. > So I think this makes it acceptable / manageable. Of course, this means the values are much less monotonous (across backends),but I don't think we really promised that. And I doubt anyone is really using sequences like this (just nextval)in performance critical use cases. I think that this approach is not acceptable to some users. So, if we actually adopt WAL-logging every sequence fetch, alsohow about exposing SEQ_LOG_VALS as reloption for a sequence? If so, those who want to log every sequence fetch can setthis SEQ_LOG_VALS reloption to 0. OTOH, those who prefer the current behavior in spite of the risk we're discussing atthis thread can set the reloption to 32 like it is for now, for example. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
В списке pgsql-hackers по дате отправления: