Rudder

How can it happens, the property name has an unicity constraint on it?

I don't see any such constraint. I did this twice a few minutes ago:

rudder=# INSERT INTO rudderproperties VALUES ('reportLoggerLastId', 161072834);
INSERT 0 1

and got:

rudder=# select * from rudderproperties where name='reportLoggerLastId';
        name        |   value
--------------------+-----------
 reportLoggerLastId | 161072834
 reportLoggerLastId | 161072834
 reportLoggerLastId | 161072834
(3 rows)

Could it be a DB issue on our side?

François ARMAND wrote:

How can it happens, the property name has an unicity constraint on it?

hum.
I just checked, and there is something strange.

On a fresh installation, I have

rudder=> \d rudderproperties;
Table "public.rudderproperties" 
 Column | Type | Modifiers
--------+------+-----------
 name   | text | not null
 value  | text |
Indexes:
    "rudderproperties_pkey" PRIMARY KEY, btree (name)

And trying to insert the same properties fails on pkey violation constraint.

But on the schema definition, we do have the primary key, and we have it since the addition of the table in ca2380af1529a0a717df88c6c57de54e78f31e4e

So I don't get it. You can correct the problem with the following table alteration:

ALTER TABLE RudderProperties ADD PRIMARY KEY (name);

But I don't understand why there is no pk declaration.

For information, could you provide the result of the following query, to see if other pk constraint are missing:

select constraint_name from information_schema.table_constraints where constraint_type = 'PRIMARY KEY');

François,

It's probably a local issue, as I have 23 primary keys on the database of another Rudder instance, VS 21 pkeys on this database.

I just added the one you mentionned, as well as statusupdate_pkey.

I guess that you can now close the ticket.

Thanks a lot.

François ARMAND wrote:

hum.
I just checked, and there is something strange.

On a fresh installation, I have
[...]

And trying to insert the same properties fails on pkey violation constraint.

But on the schema definition, we do have the primary key, and we have it since the addition of the table in ca2380af1529a0a717df88c6c57de54e78f31e4e

So I don't get it. You can correct the problem with the following table alteration:

[...]

But I don't understand why there is no pk declaration.

For information, could you provide the result of the following query, to see if other pk constraint are missing:
[...]

This is weird indeed
my guess: table was restored or copied, and constraint was dropped during restore (possibly, concurrent writing of data prevented constraint to apply)

Several changes have been done when the platforms were setup, it's indeed probably something like this.

I think that Rudder is not guilty.

Nicolas CHARLES wrote:

This is weird indeed
my guess: table was restored or copied, and constraint was dropped during restore (possibly, concurrent writing of data prevented constraint to apply)

Hypothesis is that Rudder restarted during the restore (stopping rudder doesn't disable it - rudder agent check is still run every 5 minutes), causing Rudder to compute the compliance and writing in database
once data got inserted by restore, constraint is broken