Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reserving jobs hits Postgresq Update..(subquery ..limit 1) bug #143

Open
pslavov opened this issue Aug 25, 2017 · 1 comment · May be fixed by #177
Open

Reserving jobs hits Postgresq Update..(subquery ..limit 1) bug #143

pslavov opened this issue Aug 25, 2017 · 1 comment · May be fixed by #177

Comments

@pslavov
Copy link

pslavov commented Aug 25, 2017

Hi we are using delayed_jobs_active_record 4.1.1 with PostgreSQL 9.6.
We can see that PostgreSQL is updating multiple record in some cases here: https://github.com/collectiveidea/delayed_job_active_record/blob/master/lib/delayed/backend/active_record.rb#L100. We can actually see that there are multiple records updated and returned by the UPDATE...RETURNING * query .

The problem is somewhat described here https://dba.stackexchange.com/questions/69471/postgres-update-limit-1/69497#comment321713_69497 , and basically is that the postgresql planer sometimes decides not to see the limit in the sub-query and uses JOIN which updated all the records that matches the predicates in the sub-query.

Hope this helps.

@albus522
Copy link
Member

Do you know of a reliable way to reproduce this? I can't get a test case to fail.

hardbap added a commit to AdvancedEnergyEconomy/delayed_job_active_record that referenced this issue May 25, 2022
collectiveidea#143

> The subquery returns 1 row so there is no need to use "IN" as the "=" operator will work just fine. Additionally, using "=" doesn't allow the query planner to choose a plan that can sidestep the LIMIT.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants