Re: sequences vs. synchronous replication

From: Sascha Kuhl <yogidabanli(at)gmail(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: sequences vs. synchronous replication
Date: 2021-12-28 08:53:41
Message-ID: CAPvVvKBGhL4am-KXFh=818VuO3-bhjPmZC0ma26yymZrBxjKRw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> schrieb am Di., 28. Dez. 2021,
09:51:

> Hi
>
> út 28. 12. 2021 v 9:28 odesílatel Sascha Kuhl <yogidabanli(at)gmail(dot)com>
> napsal:
>
>> Sequence validation by step, in total is great. If the sequence is
>> Familie or professional, does it make sense to a have a total validation by
>> an expert. I can only say true by chi square Networks, but would a medical
>> opinion be an improvement?
>>
>
> Is it generated by boot or by a human?
>

I validation my family and Société, only when them Show me not their
Sekret, part of their truth. Works fine by a Boot level, as far as I can
detektei, without the Boot showing up 😉

>
>
>
>> Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> schrieb am Di., 28. Dez. 2021,
>> 07:56:
>>
>>>
>>>
>>> On 2021/12/24 19:40, Tomas Vondra wrote:
>>> > Maybe, but what would such workload look like? Based on the tests I
>>> did, such workload probably can't generate any WAL. The amount of WAL added
>>> by the change is tiny, the regression is caused by having to flush WAL.
>>> >
>>> > The only plausible workload I can think of is just calling nextval,
>>> and the cache pretty much fixes that.
>>>
>>> Some users don't want to increase cache setting, do they? Because
>>>
>>> - They may expect that setval() affects all subsequent nextval(). But if
>>> cache is set to greater than one, the value set by setval() doesn't affect
>>> other backends until they consumed all the cached sequence values.
>>> - They may expect that the value returned from nextval() is basically
>>> increased monotonically. If cache is set to greater than one, subsequent
>>> nextval() can easily return smaller value than one returned by previous
>>> nextval().
>>> - They may want to avoid "hole" of a sequence as much as possible, e.g.,
>>> as far as the server is running normally. If cache is set to greater than
>>> one, such "hole" can happen even thought the server doesn't crash yet.
>>>
>>>
>>> > FWIW I plan to explore the idea of looking at sequence page LSN, and
>>> flushing up to that position.
>>>
>>> Sounds great, thanks!
>>>
>>> Regards,
>>>
>>> --
>>> Fujii Masao
>>> Advanced Computing Technology Center
>>> Research and Development Headquarters
>>> NTT DATA CORPORATION
>>>
>>>
>>>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2021-12-28 08:57:28 Re: sequences vs. synchronous replication
Previous Message Josef Šimánek 2021-12-28 08:53:06 Re: Add Boolean node