I have an application running on heroku that, on occasion, reports Timeout::Error and (ActiveRecord::StatementInvalid: Timeout::Error: execution expired) "execution expired".
This happens all over the website(not for any specific query).
Example -:
ActiveRecord::StatementInvalid: Timeout::Error: execution expired: SELECT "users".* FROM "users" WHERE "users"."id" = 3881 LIMIT 1
My app is on rails 3.2.11
Are you using Rack::Timeout? I've been struggling over the same issue and I think it's because my code is timing out from Rack::Timeout and ActiveRecord is wrapping the error awkwardly (see: Time out an ActiveRecord query).
Related
I am using Liquibase v3.9 with PostgreSQL v11 for the first time.
When testing out my changelog for the very first time I run updateSQL to see the output of the SQL that will be run against the database. I get this error:
Unexpected error running Liquibase: liquibase.exception.DatabaseException: org.postgresql.util.PSQLException: The database returned ROLLBACK, so the transaction cannot be committed. Transaction failure cause is <<ERROR: relation "public.databasechangeloglock" does not exist
Position: 22>>
For more information, please use the --logLevel flag
This happens because updateSQL is expecting databasechangelog table to exist, and if this is the first time you are running Liquibase against the database then those tables won't exist yet (they get created the first time you run liquibase update).
I do think this is a valid use case for running updateSQL, you can request this feature here:
https://github.com/liquibase/liquibase/issues
relation "public.databasechangeloglock" does not exist
I was with this issue using PostgreSQL in a container.
Then I realized the memory limit given to PostgreSQL was insufficient.
After Increasing PostgreSQL limit memory to 512MiB the problem was solved.
I'm reading "The Rails 5 Way", and on page 191 I see the following:
Pessimistic locking takes place at the database level. The SELECT
statement generated by Active Record will have a FOR UPDATE (or
similar) clause added to it...
The Rails docs appear to contain the same information:
Locking::Pessimistic provides support for row-level locking using
SELECT … FOR UPDATE and other lock types.
Chain ActiveRecord::Base#find to ActiveRecord::QueryMethods#lock to
obtain an exclusive lock on the selected rows:
Account.lock.find(1) # SELECT * FROM accounts WHERE id=1 FOR UPDATE
As an experiment, I wanted to reproduce this FOR UPDATE statement on my local machine. I know that the way to initiate a transaction with pessimistic locking is to call the .lock class method (the book gives the example t = Timesheet.lock.first). So I ran the following code in the REPL of a toy Rails app (v 5.1.6) which contains an Order class:
irb(main):015:0> Order.transaction do
irb(main):016:1* o1 = Order.lock.first
irb(main):017:1> o1.update_attributes(name: 'Foo Bar')
irb(main):018:1> end
This produced the following output:
(0.3ms) begin transaction
Order Load (0.2ms) SELECT "orders".* FROM "orders" ORDER BY "orders"."id" ASC LIMIT ? [["LIMIT", 1]]
SQL (1.1ms) UPDATE "orders" SET "name" = ?, "updated_at" = ? WHERE "orders"."id" = ? [["name", "Foo Bar"], ["updated_at", "2018-11-04 03:01:35.593868"], ["id", 1]]
(0.4ms) commit transaction
=> true
I don't see FOR UPDATE in either the SELECT or UPDATE statements. Am I doing something wrong when attempting to specify pessimistic locking? Or do I have an incorrect expectation of what SQL should be output?
I figured out that my toy app was using the default Rails sqlite database. I created a new toy app (rails new newbie --database=postgresql), create a new User model with several instances, and ran User.lock.first, and I saw the following:
irb(main):004:0> User.lock.first
User Load (1.7ms) SELECT "users".* FROM "users" ORDER BY "users"."id" ASC LIMIT $1 FOR UPDATE [["LIMIT", 1]]
=> #<User id: 1, name: nil, phone: nil, created_at: "2018-11-05 01:28:23", updated_at: "2018-11-05 01:28:23">
As you can see, FOR UPDATE appears in the SQL query. From this Stack Overflow answer, I see that by default SQLite doesn't support pessimistic locking:
SELECT ... FOR UPDATE OF ... is not supported. This is understandable
considering the mechanics of SQLite in that row locking is redundant
as the entire database is locked when updating any bit of it.
I get an error last night ,I get the following error message:
Executing the query "UPDATE STATISTICS [dbo].[tables] W..." failed
with the following error: "The multi-part identifier "tables.Id" could
not be bound.". Possible failure reasons: Problems with the query,
"ResultSet" property not set correctly, parameters not set correctly,
or connection not established correctly.
I am having an issue when running queries or stored procedures. Every time I run a query I get the following error:
Could not continue scan with NOLOCK due to data movement.
If I remove the WITH NOLOCK command, I get a different error:
Msg 824, Level 24, State 2, Line 1
SQL Server detected a logical consistency-based I/O error: incorrect pageid (expected 1:19818941; actual 1:19818957). It occurred during a read of page (1:19818941) in database ID 9 at offset 0x000025cd37a000 in file 'E:\SQLDATA\MSCRM.mdf'. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.
What should I do to resolve this error?
First, obviously, try DBCC CHECKDB.
If that cannot resolve the issue, you may need to restore from a backup and then manually copy over the most recent changes. Hopefully you have been doing nightly backups... ?
If the error is prefixed with any object (Proc, trigger, function), then you can just drop and create the object again or alter it if possible.
I would like the following SQL query to be executed in a migration file after adding a column (updating the new field with existing column value from the same row)
UPDATE users SET last_login=updated_at;
The SQL statements work properly when executed on the database, but in rails I tried multiple syntax using the ActiveRecord update_all method but without success
User.update_all("last_login=updated_at")
I get the following error
ActiveRecord::StatementInvalid: PGError: ERROR: current transaction is aborted, commands ignored until end of transaction block
: UPDATE "users" SET last_login=updated_at
Obviously something is missing in my syntax, but can't figure out what.
Can anyone point me to the right syntax?
Regards/J.
Syntax is indeed correct, the issue was relying in the fact that I had to rollback the previous transaction.
User.update_all("last_login=updated_at")
This statement works properly.