Date: Tue, 30 Apr 2024 20:13:17 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: pg_sequence_last_value() for unlogged sequences on standbys
Message-ID: <20240501011317.GC594666@nathanxps13>
References: <20240501005730.GA594666@nathanxps13>
 <1846474.1714525564@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1846474.1714525564@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/20240501011317.GC594666%40nathanxps13>
Precedence: bulk

On Tue, Apr 30, 2024 at 09:06:04PM -0400, Tom Lane wrote:
> 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.

Good point.  I'll work on a patch along these lines, then.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com