Error: integer out of range

Getting this error a lot in Sidekiq (Retries and Dead lists):

Jobs::HandledExceptionWrapper: Wrapped ActiveRecord::RangeError: PG::NumericValueOutOfRange: ERROR: integer out of range 

The jobs I’ve noticed this identical error for are:
Jobs::PostAlert
Jobs::ProcessPost
Jobs::NotifyCategoryChange

This was discussed a bit in the past here: Feedback on the new Review Queue - #250 by markersocial

2 Likes

Can you please run:

cd /var/discourse/
./launcher enter app
su postgres
psql
\x
\connect discourse 
SELECT id FROM notifications ORDER BY 1 DESC LIMIT 1;
\q
exit
4 Likes

Thanks @Falco, I just ran it now. Here is the result:

-[ RECORD 1 ]--
id | 2147483496
4 Likes

Okay, so it’s the famous integer max problem. We need to move to bigint to fix this. I will take a look into this.

6 Likes

For now your workaround is to run:

cd /var/discourse/
./launcher enter app
su postgres
psql
\x
\connect discourse 
ALTER TABLE notifications ALTER COLUMN id SET DATA TYPE bigint
\q
exit

This is the default for new installs but old installs have the wrong data type.

Running the workaround may be hard cause it will block the table, you many need to shed your web load first.

2 Likes

Thanks @Falco & @sam - appreciate it :slight_smile:

Regarding the workaround, this should be relatively safe to do? Not worried about down time, just breaking something.

It’s using the standard app.yml single container. For shedding the web load, do you think using read-only mode and running ./launcher stop app, ./launcher start app prior to doing the workaround probably suffice?

It will not break anything, worst case is that it will just be “stuck” for a very long time.

2 Likes

Thanks Sam, I did the workaround. Though, did not get any feedback upon inputting:

ALTER TABLE notifications ALTER COLUMN id SET DATA TYPE bigint

Not sure if it’s still processing perhaps. Currently getting the same error (in the /sidekiq dead list, for last retry ‘just now’ jobs) for:

Jobs::PostAlert
Jobs::ProcessPost
Jobs::NotifyCategoryChange

Looks like you need to run in with post_id column as well

1 Like

Thanks! :slight_smile:

Just to be sure, does this look correct?

ALTER TABLE notifications ALTER COLUMN post_id SET DATA TYPE bigint

Yes that should be safe, once we add an official migration it will allow for it

1 Like

Perfect, thanks :slight_smile:

I ran that (no confirmation/feedback received, like the previous one). Forum didn’t slow down, so not sure if it worked. Getting the same errors currently.

Maybe it would be best if I wait for the official migration.

1 Like

Yeah looks like this is in the post_alerts table, we need to sweep through many tables

1 Like

Curious where you are on this issue now? Did the errors stop?

Originally we were thinking of making some official migration here, but the risk far outweighs the benefit. We find it exceedingly rare to come across DBs with more than 2,147,483,647 posts. 2.1 billion is a real big number.

The downside of increasing the sized everywhere are that storage requirements go up.

Where we are now is that we are considering adding a rake task that “makes space” if you are in an outlier case where you have tables in Discourse that containe 2 billion rows (or had 2 billion rows of churn)

1 Like

Thanks for the follow up @sam

I just upgraded to 2.8.0.beta6 and still getting the integer out of range errors.

I think that it’s just the notifications that has got to a massive number, which is a bit more realistic to reach the limit compared to number of posts. A lot of large topics with many replies, likes etc. from different users can result in quite a lot of notifications.

A rake task sounds fantastic :slight_smile: