In mysql, one can execute the following statement:
UPDATE trx SET lock_id=somevalue WHERE lock_id is NULL order by stamp desc limit 1
I'm looking for a statement or statements run in transaction that would accomplish the same thing and would work in both MySQL 5.7 and PostgreSQL 9.4
It is important for this to be atomic, as this statement is in MySQL.
Related
I'm replicating from mysql 5.6.33 to 5.7.41. I have a table with a datetime field. If I understand correctly, between 5.6 and 5.7 the decreased the space a datetime field uses because it doesn't store timezone data. (but a timestamp does).
This query works on 5.7 (note the presence of the timezone field):
select count(*) from login_activities where date_created < '2023-01-15 04:00:15 -0800';
This delete statement does not work:
delete from login_activities where date_created < '2023-01-15 04:00:15 -0800'
ERROR:
Error 'Incorrect datetime value: '2023-01-15 04:00:15 -0800' for column 'date_created' at row 1' on query. Default database: 'sms'. Query: 'delete from login_activities where date_created < '2023-01-15 04:00:15 -0800''
How can I get the delete to work in the same way the select works? I've even removed sql_mode entries but still can't get it to work in 5.7
edit:
not sure if this matters, but the error with the delete statement is happining during replication (5.6 -> 5.7), but I'm running the select statement manually. I haven't tried running the delete statement manually because it will through off the replication.
For example this is working for MariaDB and all three queries return 1:
START TRANSACTION;
SELECT ##in_transaction;
SELECT variable_value FROM information_schema.session_variables WHERE variable_name = 'in_transaction';
SELECT session_value FROM information_schema.system_variables WHERE variable_name = 'in_transaction';
And all these queries are not working for Percona 8.0.22-13.
MySQL 5.7 and 8.0 supports this (I haven't checked 5.6 because it's past end-of-life already), and therefore Percona should too, because Percona is a branch (not a fork) of MySQL.
mysql> select * from information_schema.innodb_trx
where trx_mysql_thread_id = connection_id()\G
If it returns no result, then the thread has not started a transaction.
Note that you can use start transaction and yet the query returns no result. A transaction does not really start until you execute the first statement against a transactional table.
well i have looked for a lot of places on the internet for the cause of the mysql error #1442 which says
Can't update table 'unlucky_table' in stored function/trigger because
it is already used by statement which invoked this stored
function/trigger
some say that this is a bug in mysql or a feature that it doesnt provide.
MySQL triggers can't manipulate the table they are assigned to. All other major DBMS support this feature so hopefully MySQL will add this support soon.
Some claim that this is due to recursive behavior
when you insert a record mysql is doing some lock stuff. you can't insert/update/delete rows of the same table where you insert.. because then the trigger would called again and again.. ending up in a recursion
During the insert/update you have access to the NEW object which contains all of the fields in the table involved. If you do a before insert/update and edit the field(s) that you want to change in the new object it will become a part of the calling statement and not be executed as a separately (eliminating the recursion)
now i cant understand why this is recursive. i have a case in which i have 2 tables table1 and table2 and i run an sql query as
update table1 set avail = 0 where id in (select id from table2 where duration < now() - interval 2 hour);
now i have an after update trigger on table1 as
CREATE TRIGGER trig_table1 AFTER UPDATE ON table1
FOR EACH ROW begin
if old.avail=1 and new.avail=0 then
delete from table2 where id=new.id;
end if;
now when i execute the update query i get a 1442 error.
whats recursive in this case?
is this error a lack of feature in mysql?
OR
does this have to do with how mysql executes queries?
OR
is there something logically wrong with executing such queries?
You cannot refer to a table when updating it.
/* my sql does not support this */
UPDATE tableName WHERE 1 = (SELECT 1 FROM tableName)
From MySQL Docs:
A trigger can access both old and new data in its own table. A trigger can also affect other tables, but it is not permitted to modify a table that is already being used (for reading or writing) by the statement that invoked the function or trigger. (Before MySQL 5.0.10, a trigger cannot modify other tables.)
In sql server and mysql
I want a query to identify the tables name which are affected using INSERT or UPDATE
Additional info:
1. I have more than two tables and all tables may not have indexes.
2. If a stored procedure execute I don't know what are the tables inserted or updated. But here I want to know.
Thanks.
You can do this in SQL server
SELECT TOP 1 *
FROM sys.dm_db_index_usage_stats
WHERE database_id = DB_ID( 'AdventureWorks')
AND OBJECT_ID in (select OBJECT_ID(name) from sys.tables)
ORDER BY last_user_update DESC
not sure about MYSQL
taken from here and here
I just upgraded a MySQL 5.0 server to MySQL 5.5 and found that stored routines that worked before had broken. Difference: MySQL 5.5 seems to INSERT rows in an arbitrary order. So in the following code the ORDER BY clause has no effect. AFAIK, it used to have that in MySQL 5.0.
INSERT INTO MyTable
SELECT * FROM MyOtherTable ORDER BY Col1, Col2 DESC;
People say that, by definition, order is irrelevant in INSERTs: Just use ORDER BY when using SELECT from the table. Problem is I use a cursor to loop the table and perform complex operations. Surely I can put the ORDER BY statement on the cursor definition instead:
DECLARE cur CURSOR FOR SELECT * FROM MyTable ORDER BY Col1, Col2 DESC;
But that slows down the routine: from 10 seconds on MySQL 5.0 to over 10 minutes on MySQL 5.5.
Any ideas on how to solve problem?
Add an index on (Col1, Col2) to speed up ordering.