Here's an example:
create database users;
create table users (id int unique);
Then running these together:
insert into users values(1);
insert into users values(1);
I expected the first insert to succeed, but the second to fail. However what I am seeing is that they are run atomically, and no row is inserted. Here are the logs:
2021-11-08 23:04:37.825 UTC [181] LOG: statement: insert into users values(1);
insert into users values(1);
2021-11-08 23:04:37.825 UTC [181] ERROR: duplicate key value violates unique constraint "users_id_key"
2021-11-08 23:04:37.825 UTC [181] DETAIL: Key (id)=(1) already exists.
2021-11-08 23:04:37.825 UTC [181] STATEMENT: insert into users values(1);
insert into users values(1);
What's confusing is that there is no BEGIN; or COMMIT;. Are statements with multiple commands run atomically?
-- EDIT --
I am using Postico client to run these statements.
Related
I'm trying to create schema with query:
CREATE SCHEMA IF NOT EXISTS hdb_catalog
but following error occurred:
2019-09-10 13:47:37.025 UTC [129] ERROR: duplicate key value violates unique constraint "pg_namespace_nspname_index"
2019-09-10 13:47:37.025 UTC [129] DETAIL: Key (nspname)=(hdb_catalog) already exists.
2019-09-10 13:47:37.025 UTC [129] STATEMENT:
CREATE SCHEMA IF NOT EXISTS hdb_catalog
How it is possible with IF NOT EXISTS?
That looks like you have catalog corruption.
With some luck, only the index is affected. You can try to repair it using
REINDEX pg_catalog.pg_namespace;
Like in all cases of corruption, it is commendable to create a new cluster with initdb and use pg_dump/pg_restore to copy the database there. There might be more problems.
Also, try to find out what caused the corruption. Often it is bad hardware.
I have executed create an index on a big table from pgAdmin, and in a while, I lost connection to the server, so the execution window closed in pgAdnin. Then I reconnected to the server, and when checked pg_stat_activity, I do see that the create index statement is running (active) state, I just wondering to know whether this index being creating or stuck somewhere?
client disconnected with error,
cancelling statement due to statement timeout
when I reconnected to the server, in pg_stat_activity.
31937 "edsadmin" "09:54:44.280176" "CREATE INDEX CONCURRENTLY idx_src_record_date
ON pcd_t.l_esd_detail_report USING btree
(src_record_date COLLATE pg_catalog."default")
TABLESPACE pg_default;"
I'm really confused here wheather it is createing or not.
Late answer, but relevant none-the-less.
Based on my anecdotal experience right now, the index creation persists beyond the lifetime of the client.
I did the following:
database=> CREATE INDEX CONCURRENTLY IX_myIndex on table(column, column2);
It paused for a few minutes, then:
SSL SYSCALL error: EOF detected
The connection to the server was lost. Attempting reset: Succeeded.
psql (14.2 (Debian 14.2-1.pgdg110+1), server 10.18)
Immediately after reconnecting, I ran:
database=> \d table
Table "public.table"
Column | Type | Collation | Nullable |
Default
-----------------+-----------------------------+-----------+----------+---------
... blah blah blah ...
Indexes:
"IX_myIndex" btree (column, column2) INVALID
I waited a few more minutes, then checked again:
database=> \d table
Table "public.table"
Column | Type | Collation | Nullable |
Default
-----------------+-----------------------------+-----------+----------+---------
... blah blah blah ...
Indexes:
"IX_myIndex" btree (column, column2)
So, your index is likely fine.
I am using postgres 10.5 and liquibase 3.6.2 on a Mac.
I nuke & re-create my database, run liquibase update, and it works.
But a second liquibase update fails with an exception that the pkey already exists.
After the first liquibase update, the databasechangelog table contains 97 entries. After the second, it contains 10, and the time and deployment ids for those are different than they were after the first update!
Table foo was created in an early change.
Later it was changed to be named bar, but the pkey is still foo.pkey.
Liquibase-update should not be trying to re-create foo, but it does, and fails because foo.pkey already exists.
A) In general, how can I get liquibase to output more info about what it's doing? I tried both of the commands:
liquibase --logLevel=debug --logFile=`pwd`/foo.log update
liquibase --logLevel debug --logFile `pwd`/foo.log update
Both seem to work the same, and foo.log isn't created and there's no more output in the terminal.
B) How can I stop liquibase from trying to re-make this and nuking my databasechangelog?
I tried to make a small example that fails, but this seems to work... Others here are using it with postgres 9.5.10 with no problem...
All I see in the terminal is:
Starting Liquibase at Wed, 14 Nov 2018 13:06:44 PST (version 3.6.2 built at 2018-07-03 11:28:09)
Unexpected error running Liquibase: ERROR: relation "cant_change_pkey" already exists [Failed SQL: CREATE TABLE nuss.cant_change (message_id UUID NOT NULL, origin VARCHAR(4), type VARCHAR(12) NOT NULL, CONSTRAINT CANT_CHANGE_PKEY PRIMARY KEY (message_id), UNIQUE (message_id))]
liquibase.exception.MigrationFailedException: Migration failed for change set db/changelog/changelog-new1.xml::first-one::rstrauss:
Reason: liquibase.exception.DatabaseException: ERROR: relation "cant_change_pkey" already exists [Failed SQL: CREATE TABLE nuss.cant_change (message_id UUID NOT NULL, origin VARCHAR(4), type VARCHAR(12) NOT NULL, CONSTRAINT CANT_CHANGE_PKEY PRIMARY KEY (message_id), UNIQUE (message_id))]
at liquibase.changelog.ChangeSet.execute(ChangeSet.java:637)
at liquibase.changelog.visitor.UpdateVisitor.visit(UpdateVisitor.java:53)
at liquibase.changelog.ChangeLogIterator.run(ChangeLogIterator.java:78)
at liquibase.Liquibase.update(Liquibase.java:202)
at liquibase.Liquibase.update(Liquibase.java:179)
at liquibase.integration.commandline.Main.doMigration(Main.java:1205)
at liquibase.integration.commandline.Main.run(Main.java:191)
at liquibase.integration.commandline.Main.main(Main.java:129)
Caused by: liquibase.exception.DatabaseException: ERROR: relation "cant_change_pkey" already exists [Failed SQL: CREATE TABLE nuss.cant_change (message_id UUID NOT NULL, origin VARCHAR(4), type VARCHAR(12) NOT NULL, CONSTRAINT CANT_CHANGE_PKEY PRIMARY KEY (message_id), UNIQUE (message_id))]
at liquibase.executor.jvm.JdbcExecutor$ExecuteStatementCallback.doInStatement(JdbcExecutor.java:356)
at liquibase.executor.jvm.JdbcExecutor.execute(JdbcExecutor.java:57)
at liquibase.executor.jvm.JdbcExecutor.execute(JdbcExecutor.java:125)
at liquibase.database.AbstractJdbcDatabase.execute(AbstractJdbcDatabase.java:1229)
at liquibase.database.AbstractJdbcDatabase.executeStatements(AbstractJdbcDatabase.java:1211)
at liquibase.changelog.ChangeSet.execute(ChangeSet.java:600)
... 7 common frames omitted
Caused by: org.postgresql.util.PSQLException: ERROR: relation "cant_change_pkey" already exists
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2476)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2189)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:300)
at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:428)
at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:354)
at org.postgresql.jdbc.PgStatement.executeWithFlags(PgStatement.java:301)
at org.postgresql.jdbc.PgStatement.executeCachedSql(PgStatement.java:287)
at org.postgresql.jdbc.PgStatement.executeWithFlags(PgStatement.java:264)
at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:260)
at liquibase.executor.jvm.JdbcExecutor$ExecuteStatementCallback.doInStatement(JdbcExecutor.java:352)
... 12 common frames omitted
For more information, please use the --logLevel flag
I want only DDL statements in postgresql logs.
I have set log_statement to ddl, and changed log_min_messages to 'log',but I still got log like this:
< 2018-05-15 05:10:25.078 EDT > LOG: MultiXact member wraparound protections are now enabled
< 2018-05-15 05:10:25.079 EDT > LOG: database system is ready to accept connections
< 2018-05-15 05:10:25.085 EDT > LOG: autovacuum launcher started
I want only DDL statements because I want to generate DDL patch from log to synchronize database in production environment.
Is there any better way?
look into https://github.com/pgaudit/pgaudit
or if you ant to code it, consider using https://www.postgresql.org/docs/current/static/event-triggers.html
eg:
so=# create or replace function notice_ddl() returns event_trigger as $$
begin
raise info '%', session_user || ' ran '||tg_tag||' '||current_query();
end;
$$ language plpgsql;
CREATE FUNCTION
so=# create or replace function notice_ddl() returns event_trigger as $$
begin
raise info '%', session_user || ':: ran "'||tg_tag||'" ('||current_query()||')';
end;
$$ language plpgsql;
CREATE FUNCTION
so=# create event trigger etg on ddl_command_start execute procedure notice_ddl();
CREATE EVENT TRIGGER
so=# create table so(i int);
INFO: vao:: ran "CREATE TABLE" (create table so(i int);)
CREATE TABLE
surely you can save statement to table of notify channel instead of rasing info...
also if you want to use postgres logs, look into csv logs
When Keycloak is trying to start, it is unable to start. The Following error is thrown in the logs :
ERROR
[org.keycloak.connections.jpa.updater.liquibase.conn.DefaultLiquibaseConnectionProvider]
(ServerService Thread Pool -- 53) Change Set
META-INF/jpa-changelog-1.5.0.xml::1.5.0::bburke#redhat.com failed.
Error: Column "USER_SETUP_ALLOWED" not found; SQL statement: ALTER
TABLE PUBLIC.AUTHENTICATION_EXECUTION ALTER COLUMN USER_SETUP_ALLOWED
SET DEFAULT NULL [42122-193] [Failed SQL: ALTER TABLE
PUBLIC.AUTHENTICATION_EXECUTION ALTER COLUMN USER_SETUP_ALLOWED SET
DEFAULT NULL]: liquibase.exception.DatabaseException: Column
"USER_SETUP_ALLOWED" not found; SQL statement: ALTER TABLE
PUBLIC.AUTHENTICATION_EXECUTION ALTER COLUMN USER_SETUP_ALLOWED SET
DEFAULT NULL [42122-193] [Failed SQL: ALTER TABLE
PUBLIC.AUTHENTICATION_EXECUTION ALTER COLUMN USER_SETUP_ALLOWED SET
DEFAULT NULL]
at liquibase.executor.jvm.JdbcExecutor$ExecuteStatementCallback.doInStatement(JdbcExecutor.java:316)
at liquibase.executor.jvm.JdbcExecutor.execute(JdbcExecutor.java:55)
at liquibase.executor.jvm.JdbcExecutor.execute(JdbcExecutor.java:122)
at liquibase.database.AbstractJdbcDatabase.execute(AbstractJdbcDatabase.java:1247