Thread: gen_random_uuid() is immutable in Pg 13devel
Hi, I noticed that get_random_uuid() from pgcrypt is marked as immutable. Up to 12.2 it was volatile, and in 13 it became immutable. This leads to "interesting" change, that: select gen_random_uuid() from generate_series(1,10); returns 10 different uuids before 13, and 10 identical ones on 13devel. It looks that commit 5925e5549890416bcf588334d9d0bc99f8ad6c7f forgot to mark the function as volatile. Not sure if it was intentional. Best regards, depesz
On 2020-Feb-18, hubert depesz lubaczewski wrote: > Hi, > I noticed that get_random_uuid() from pgcrypt is marked as immutable. > > Up to 12.2 it was volatile, and in 13 it became immutable. > > This leads to "interesting" change, that: > > select gen_random_uuid() from generate_series(1,10); > > returns 10 different uuids before 13, and 10 identical ones on 13devel. > > It looks that commit 5925e5549890416bcf588334d9d0bc99f8ad6c7f forgot to > mark the function as volatile. Not sure if it was intentional. It seems an oversight to me. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Tue, Feb 18, 2020 at 11:01 AM Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > > It looks that commit 5925e5549890416bcf588334d9d0bc99f8ad6c7f forgot to > > mark the function as volatile. Not sure if it was intentional. > > It seems an oversight to me. Maybe this happened because the default volatility for pg_proc.dat entries is not 'volatile' -- it's 'immutable'. -- Peter Geoghegan
On 2020-Feb-18, Peter Geoghegan wrote: > On Tue, Feb 18, 2020 at 11:01 AM Alvaro Herrera > <alvherre@2ndquadrant.com> wrote: > > > It looks that commit 5925e5549890416bcf588334d9d0bc99f8ad6c7f forgot to > > > mark the function as volatile. Not sure if it was intentional. > > > > It seems an oversight to me. > > Maybe this happened because the default volatility for pg_proc.dat > entries is not 'volatile' -- it's 'immutable'. That makes me wonder what should be the default --- and should there even *be* a default in the first place? Maybe it's better to make everyone *think* about it every time rather than hoping we'll all remember, and frequently having it got wrong. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Tue, Feb 18, 2020 at 12:01 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > That makes me wonder what should be the default --- and should there > even *be* a default in the first place? Maybe it's better to make > everyone *think* about it every time rather than hoping we'll all > remember, and frequently having it got wrong. I'd say that there is a good argument for that. Though note that opr_sanity.sql does a good job of detecting functions that are not marked immutable, but need to be -- things like indexable operators, pg_amproc entries, etc. -- Peter Geoghegan
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2020-Feb-18, Peter Geoghegan wrote:
>> Maybe this happened because the default volatility for pg_proc.dat
>> entries is not 'volatile' -- it's 'immutable'.
> That makes me wonder what should be the default --- and should there
> even *be* a default in the first place? Maybe it's better to make
> everyone *think* about it every time rather than hoping we'll all
> remember, and frequently having it got wrong.
Yeah. That default was chosen just to reduce the size of pg_proc.dat
(since a large majority of C functions are indeed immutable). But
it might be too error-prone this way. I remember worrying about that
when we put it in.
regards, tom lane
On 2020-02-18 19:54, hubert depesz lubaczewski wrote: > Hi, > I noticed that get_random_uuid() from pgcrypt is marked as immutable. > > Up to 12.2 it was volatile, and in 13 it became immutable. > > This leads to "interesting" change, that: > > select gen_random_uuid() from generate_series(1,10); > > returns 10 different uuids before 13, and 10 identical ones on 13devel. > > It looks that commit 5925e5549890416bcf588334d9d0bc99f8ad6c7f forgot to > mark the function as volatile. Not sure if it was intentional. Fixed, thanks. It was indeed the result of confusion about the default value. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Wed, Feb 19, 2020 at 08:19:00PM +0100, Peter Eisentraut wrote: > > It looks that commit 5925e5549890416bcf588334d9d0bc99f8ad6c7f forgot to > > mark the function as volatile. Not sure if it was intentional. > Fixed, thanks. > It was indeed the result of confusion about the default value. Thank you. Mistakes happen, no big deal :) Best regards, depesz