Re: gen_random_uuid key collision

2021-09-03 Thread jesusthefrog
> > Note that the parent variant takes a disruptive lock that will block > write DML. You might prefer to just use the first query if this is > running in a production environment. > Fortunately this has only been observed on the dev instance. This morning I tried just dropping and recreating the

Re: gen_random_uuid key collision

2021-09-02 Thread jesusthefrog
On Thu, Sep 2, 2021 at 8:05 PM Adrian Klaver wrote: > But only one is generating errors. Schema refers to an object's > definition as well as a namespace. So what does: > > \d > > return? > I see what you mean. I don't have access to the instance at the moment so I'd have to take a look

Re: gen_random_uuid key collision

2021-09-02 Thread jesusthefrog
On Thu, Sep 2, 2021 at 7:47 PM Tom Lane wrote: > > BTW, are you *entirely* certain that your application never inserts > non-default values into that column? > > regards, tom lane > Yes, I double checked that we never attempt to bind a value for that column. I'll have a

Re: gen_random_uuid key collision

2021-09-02 Thread jesusthefrog
On Thu, Sep 2, 2021 at 7:35 PM Adrian Klaver wrote: > What is the table schema as returned by \d in psql? > > The tables are in various schemas; that one is in one called "access_control", but we always set the search path explicitly to (in this case) "access_control, public". Anyway, if if

gen_random_uuid key collision

2021-09-02 Thread jesusthefrog
Hello, I'm hoping someone might be able to shed a little light on a strange situation I encountered recently. I work with a postgres instance which has dozens (probably hundreds) of tables which each have a column defined as "uuid primary key default gen_random_uuid()". Most of the time this is