I think I have found a bug in MySQLWorkbench (mac version). The following SQL executed on a mac creates a deadlock:
UPDATE mytable SET mycolumn1=0 WHERE mycolumn2 IN ()
Obviously, the SQL is incorrect because there should be at least one value between the parenthesis. However, MySQLWorkbench hangs forever when that statement gets executed.
Related
I just ran a script in MySQL Workbench 6.3 Community.
I've set it to 'Stop Script Execution on Errors'.
There were two queries that gave errors.
The errors say 'Error Code: 1175. You are using safe update mode and you tried to update a table without a WHERE that uses a KEY column To disable safe mode, toggle the option in Preferences -> SQL Editor and reconnect.'
Ok, so I missed that. No big deal.
But after that, the script simply continued as if there were no error at all, or as if I never set 'Stop Script Execution on Errors'.
As a consequence I've lost some data. (This was a test database, so no worries there.)
The script continues after the errors:
Any idea how to make it stop executing the script?
A colleague pointed me to Edit->Preferences, SQL Editor, SQL Execution, Continue SQL script execution on errors (by default).
Continue SQL script execution on errors (by default)
This worked after restarting Workbench.
I am using intellij with postgres, and highlight sql commands to run them.
I also have postgres running in my terminal, and I am getting different results from the same query when run in intellij vs. when run in the terminal.
Here is the command run from Intellij:
The result shows one entry present:
However, running the same command in the terminal shows no table entries present.
Intellij and the terminal are connecting to the same database and port as shown by Intellij's connection settings
and by the result of \conninfo run in the terminal.
Furthermore, the schema matches as shown by Intellij's connection settings (shown above) and by the result of the terminal's \d+ visitor_sign_in command
Why does this same command give different results when run in Intellij vs. when run in the terminal?
Based on your most recent comment ("yes running select * from pg_stat_activity; does show 'idle in transaction'."), here is what I believe is happening.
You have two connections, A and B.
A starts a transaction, inserts data, and then selects from that table. The table shows data (the data that was just inserted).
B connects, and selects from the same table. Since A has not committed, B does not see that data. In order for the data inserted by A to be visible to any other connections, you need A to commit its transaction.
Now, I don't know why IntelliJ is not offering you the opportunity to commit your transaction, but that lack of commit is the cause of your visibility problem.
I am using execute command tag from my liquibase changesets and this inturn is configured to run the sqls in oracle instant client sql plus.
when i run a liquibase update on my changelogxml everything works fine and the liquibase update is sucessfull.I can see the changes to the table also.
But when i try to fail the update process by giving a syntax error in my sql file refered in the changeset.Liquibase still returns liquibase update sucessfull.I expected it to throw sql errors.The sql when run seperately in toad throws syntax error.What should i do to get the error displayed out.?
Datical has created a custom Liquibase change tag that executes SQL using the sqlplus command line client. It was surprisingly much more complicated that you might think.
Some of the issues we had to deal with:
we had to do things to ensure that the sql files always had certain statements in place, and never had certain other statements. This might include things like setting the schema, ensuring that the only spool commands were ones we knew about, that the script had an 'EXIT' command, and ensuring that whenever there was a SQL error that the exit code was returned.
The sqlplus executable does not return an exit code (i.e. a non-zero exit code form the native process) in all cases, and instead will write errors to an error table in the database. The table where sqlplus writes errors is called sperrorlog, and this may be what you will need to look into.
I can't really go into all the details, but just know that what you are attempting to do is neither simple nor straightforward.
Using the jdbc4.2 implementation contained in postgresql-9.4.1212.jar, I generate an error when calling the java.Sql.Connection isValid() method on a connection to a postgresql 9.3 database (java8 and postgres both running on windows 7).
The path to producing the error is complicated but reproducible (will provide relevant code shortly) and involves a sequence of sql calls on a single db connection whose default schema is reconfigured prior to each use via an explicit execution of SET SEARCH_PATH='[some schema]'.
I find that the error occurs if and only if I render the SEARCH_PATH keyword using upper case (that is, the error does not occur if I execute SET search_path='[some schema]' - only when I execute SET SEARCH_PATH='[some schema]').
Note that the direct effect of executing either variant is the same -- in both cases the default schema associated with the connection is changed to [some schema]. It's just that, eventually, a downstream call to java.sql.connection.isValid() causes the database to crash if I've used SEARCH_PATH instead of search_path.
I can see that the jdbc driver's implementation of java.sql.connection.setSchema() uses the lower-case variant; something that makes me think this apparent case-sensitivity may be a known issue, but I have found no mentions of it anywhere online.
Note that the problem does not occur if I either: (1) use an older jdbc driver (postgresql-9.3.1100.jdbc4.1.jar) with my 9.3 database, or (2) use the latest jdbc driver with a postgresql 9.6 database.
I'm wondering if anyone has run into this specific problem, and also, if there are other known incompatibilities b/w the 9.3 database and the latest jdbc driver.
The driver is failing to invalidate the prepared statement cache because it only detects SET search_path=... when the config parameter is lower case.
See line 2056 of this commit.
I can't find an issue that describes this. Please have a look yourself and raise one if needed.
Using OS X & PostgreSQL 9.3, how do I enable the built in PL/SQL debugger & add the menu option for debugging functions in PG Admin?
I had no problems using Windows 8 & 7, but no luck with OS X.
I already tried adding the following entry to postgresql.conf-
shared_preload_libraries = '$libdir/postgresql/plugin_debugger'
also tried various of combinations of that with (with/out .so, /postgresql etc.)
and executed this query:
CREATE EXTENSION pldbgapi;
Apparently, The problem was that SQL functions cannot be debugged in PostgreSQL, only PLSQL, which is why the menu option was not shown. (To be able to debug, create your function using PLSQL as the selected language).
For future reference, this the correct entry in postgresql.conf:
shared_preload_libraries = '$libdir/plugin_debugger'