Re: pg_sequence_last_value() for unlogged sequences on standbys
От | Nathan Bossart |
---|---|
Тема | Re: pg_sequence_last_value() for unlogged sequences on standbys |
Дата | |
Msg-id | 20240507171033.GA2524814@nathanxps13 обсуждение исходный текст |
Ответ на | Re: pg_sequence_last_value() for unlogged sequences on standbys (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: pg_sequence_last_value() for unlogged sequences on standbys
|
Список | pgsql-hackers |
On Sat, May 04, 2024 at 06:45:32PM +0900, Michael Paquier wrote: > On Fri, May 03, 2024 at 05:22:06PM -0400, Tom Lane wrote: >> Nathan Bossart <nathandbossart@gmail.com> writes: >>> IIUC this would cause other sessions' temporary sequences to appear in the >>> view. Is that desirable? >> >> I assume Michael meant to move the test into the C code, not drop >> it entirely --- I agree we don't want that. > > Yup. I meant to remove it from the script and keep only something in > the C code to avoid the duplication, but you're right that the temp > sequences would create more noise than now. > >> Moving it has some attraction, but pg_is_other_temp_schema() is also >> used in a lot of information_schema views, so we couldn't get rid of >> it without a lot of further hacking. Not sure we want to relocate >> that filter responsibility in just one view. > > Okay. Okay, so are we okay to back-patch something like v1? Or should we also return NULL for other sessions' temporary schemas on primaries? That would change the condition to something like char relpersist = seqrel->rd_rel->relpersistence; if (relpersist == RELPERSISTENCE_PERMANENT || (relpersist == RELPERSISTENCE_UNLOGGED && !RecoveryInProgress()) || !RELATION_IS_OTHER_TEMP(seqrel)) { ... } I personally think that would be fine to back-patch since pg_sequences already filters it out anyway. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: