Re: pg_sequence_last_value() for unlogged sequences on standbys
От | Tom Lane |
---|---|
Тема | Re: pg_sequence_last_value() for unlogged sequences on standbys |
Дата | |
Msg-id | 1846474.1714525564@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | pg_sequence_last_value() for unlogged sequences on standbys (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: pg_sequence_last_value() for unlogged sequences on standbys
|
Список | pgsql-hackers |
Nathan Bossart <nathandbossart@gmail.com> writes: > If you create an unlogged sequence on a primary, pg_sequence_last_value() > for that sequence on a standby will error like so: > postgres=# select pg_sequence_last_value('test'::regclass); > ERROR: could not open file "base/5/16388": No such file or directory > As pointed out a few years ago [0], this function is undocumented, so > there's no stated contract to uphold. I lean towards just returning NULL > because that's what we'll have to put in the relevant pg_sequences field > anyway, but I can see an argument for fixing the ERROR to align with what > you see when you try to access unlogged relations on a standby (i.e., > "cannot access temporary or unlogged relations during recovery"). Yeah, I agree with putting that logic into the function. Putting such conditions into the SQL of a system view is risky because it is really, really painful to adjust the SQL in a released version. You could back-patch a fix for this if done at the C level, but I doubt we'd go to the trouble if it's done in the view. regards, tom lane
В списке pgsql-hackers по дате отправления: