I have restored a Db2 v9.5 database on a new server with Db2 v9.7 FP11 with the same user and with the different user, but got permission error with the instance owner:
db2 -x "select os_name, host_name, total_memory
from table(sysproc.env_get_sys_info()) as systeminfo"
SQL0430N User defined function "SYSPROC.ENV_GET_SYS_INFO" (specific name "ENV_GET_SYS_INFO") has abnormally terminated. SQLSTATE=38503.
I have followed all the steps in this technote.
I have set the registry variable as well before restore:
[i] DB2_RESTORE_GRANT_ADMIN_AUTHORITIES=ON
but still I'm getting the error.
The error has nothing to do with missing authorization. Make sure you update your 9.5 database to the appropriate 9.7 fix pack by running db2updv97 -d <your db name>
Problem solved after update the instance
db2iupdt -u instance name
Related
I’m trying to CREATE TABLE command in Postgresql.
After creating a table, if I punch in TABLE table name, it works.
But I punch in \d table name, I keep getting an error below.
ERROR: column c.relhasoids does not exist
LINE 1: ...riggers, c.relrowsecurity, c.relforcerowsecurity, c.relhasoi...
I attempted DROP DATABASE table name recreated a database and recreated a table again several times. But it didn't work.
Any suggestions would be appreciated! Thank you.
I am able to reproduce your error if I am using Postgres v.12 and an older client (v.11 or earlier):
[root#def /]# psql -h 172.17.0.3
psql (11.5, server 12.0)
WARNING: psql major version 11, server major version 12.
Some psql features might not work.
Type "help" for help.
postgres=# create table mytable (id int, name text);
CREATE TABLE
postgres=# table mytable;
id | name
----+------
(0 rows)
postgres=# \d mytable;
ERROR: column c.relhasoids does not exist
LINE 1: ...riggers, c.relrowsecurity, c.relforcerowsecurity, c.relhasoi...
^
postgres=#
This is because in v. 12, table OIDs are no longer treated as special columns, and hence the relhasoids column is no longer necessary. Please make sure you're using a v. 12 psql binary so you don't encounter this error.
You may not necessarily be using psql, so the more general answer here is to make sure you’re using a compatible client.
For anyone running Postgres as a Docker container:
Instead of running psql from the host, run it from inside the container e.g.
docker exec -it postgres_container_name psql your_connection_string
The Postgres image always ships with the corresponding—and thus always updated—version of psql so you don't have to worry about having the correct version installed on the host machine.
If you're using DataGrip, there's an easy fix:
Try using "Introspect using JDBC metadata". This fixed it for me when (I think) I had a version mismatch between postgresql server and DataGrip client.
Under your connection settings -> Options tab -> check Introspect using JDBC metadata
According to https://www.jetbrains.com/help/datagrip/data-sources-and-drivers-dialog.html#optionsTab :
Switch to the JDBC-based introspector.
To retrieve information about database objects (DB metadata), DataGrip
uses the following introspectors:
A native introspector (might be unavailable for certain DBMS). The
native introspector uses DBMS-specific tables and views as a source of
metadata. It can retrieve DBMS-specific details and produce a more
precise picture of database objects.
A JDBC-based introspector (available for all the DBMS). The JDBC-based
introspector uses the metadata provided by the JDBC driver. It can
retrieve only standard information about database objects and their
properties.
Consider using the JDBC-based intorspector when the native
introspector fails or is not available.
The native introspector can fail, when your database server version is
older than the minimum version supported by DataGrip.
You can try to switch to the JDBC-based introspector to fix problems
with retrieving the database structure information from your database.
For example, when the schemas that exist in your database or database
objects below the schema level are not shown in the Database tool
window.
The issue is the client (psql) is a different version from the postgres server. I have seen this issue with psql version 11 talking to postgres version 12. To solve this issue upgrade the psql version to 12.
If you are running a docker postgres, you can exec into the container then use the psql client installed there.
# get the container id with this
docker ps
# Then exec into the container, please note the host will now be 120.0.0.1
docker exec -it c12e8c6b8eb5 /bin/bash
I had this issue because my psql was 9.2 and the server version was 12.7.
So ... clearly the psql client needs to be updated. But how?
Before you go downloading/installing anything though you may already have the right version. In my case I did.
I executed which psql which showed my version was coming from /usr/bin/psql.
I then checked /usr/pgsql-12/bin and found there was a psql in there.
So all I needed to do was ensure psql was picked up from there.
There are a number of places that could be controlling this; in my case I just added this line to my .pgsql_profile (in the postgres user's home directory):
export PATH="/usr/pgsql-12/bin:$PATH"
Logging out and back in as postgres and executing which psql showed the change had been successful:
which psql
/usr/pgsql-12/bin/psql
This answer is specific to pgcli
If you are using pgcli you may be encountering this issue. It's solved by updating the python package pgspecial.
If you installed pgcli using pip, you can simply do, depending on your python version:
pip install -U pgspecial
or
pip3 install -U pgspecial
If you are using Ubuntu and intalled pgcli using apt, you can either switch it to pip with:
sudo apt remove --purge pgcli
pip3 install pgcli
or update the distribution package python-pgspecial or python3-pgspecial from the Ubuntu packages web site. In that case you may need to update its dependencies as well.
I had this issue today, was unable to continue work due to this, strangely the application code is working fine.
Later, found this issue is only occurring if I use OmniDb client I use to connect to DB.
I have switched client to default pgAdmin 4 that comes with postgres installation & issue is not occurring anymore pgAdmin 4. Link: https://www.pgadmin.org/download/pgadmin-4-windows/
Its possible that OmniDb client might be older, but no time to troubleshoot it, using pgAdmin 4 for now.
Hope that helps.
Just update DataGrip solved this issue, Datagrip updated to version DataGrip 2019.3.3, Build #DB-193.6494.42, built on February 12, 2020, Now working :)
Just for DataGrip users!
I had the same issue today too. In my case, the problem was solved when I deleted the version 12 and installed the version 11. Seems that v12 has some features that must be create along the others columns.
I had the same problem.
But I found the solution by downloading the latest build on 14/10/2019
Follow the link:
https://postbird.paxa.kuber.host/2019_10_14.06_42-master-7a9e949
I hope it helps
To fix this, edit Postgres.php file and comment the lines from hasObjectID function as shown below.
function hasObjectID($table) {
$c_schema = $this->_schema;
$this->clean($c_schema);
$this->clean($table);
/*
$sql = "SELECT relhasoids FROM pg_catalog.pg_class WHERE relname='{$table}'
AND relnamespace = (SELECT oid FROM pg_catalog.pg_namespace WHERE nspname='{$c_schema}')";
$rs = $this->selectSet($sql);
if ($rs->recordCount() != 1) return null;
else {
$rs->fields['relhasoids'] = $this->phpBool($rs->fields['relhasoids']);
return $rs->fields['relhasoids'];
}
*/
}
I had the same issue when using PgAdmin to query the database.
Once I installed the newest version of PgAdmin the error disappeared!
You might also try restarting pgadmin.
After upgrading from postgres96 to postgres12 I had the same issue. My pgadmin was running psql v12.0 so that wasn't the issue. I restarted pgadmin for a separate issue and the relhasoids issue went away.
If anyone could explain to me why this worked that would be appreciated.
Just use version 11.
how to install version 11
https://websiteforstudents.com/how-to-install-postgresql-11-on-ubuntu-16-04-18-04-servers/
I also got same issue with my postgresql tables. I have fixed this issue by below query.
ALTER Table MyDataBase.table_name add column column_name data_type default 0 not null;
commit;
I've installed firebird 3.0 from the package provided by firebirdsql.org.
If I try to use a local connection to a database:
isql employee -user SYSDBA
it fails with:
Can not access lock files directory /tmp/firebird/
So adding read/write/execute permissions to /tmp/firebird/
sudo chmod a+rwx /tmp/firebird/
and executing the command again yields:
Statement failed, SQLSTATE = 08001
I/O error during "open" operation for file "/tmp/firebird/fb_init"
-Error while trying to open file
-Unknown error: -1
This all will work if I sudo the calls, but is this really necessary?
What is the correct way to use a local connection to firebird database on macOS?
I found CORE-3871 issue in the firebird issue tracker, which describes the problem and it's solution. The user which tries to open the local connection must be member of the firebird user group.
So a user is added to the firebird group on mac bash with the following command:
sudo dseditgroup -o edit -a myusername -t user firebird
If you try to open the sample database employee, shipped with firebird, it's also necessary to grant the group write access to the employee.fdb:
sudo chmod g+w /Library/Frameworks/Firebird.framework/Resources/examples/empbuild/employee.fdb
Now /Library/Frameworks/Firebird.framework/Resources/bin/isql employee -user SYSDBA should work
I only put -p and the password and it's just fine. It's working.
You current command creates the Firebird Embedded database engine to connect to the database. To be able to do that, your current OS user needs to have sufficient access to the database file. For details how to fix that, see the answer by jonjonas68.
An alternative to solution - if you have the Firebird server running - is to connect through the Firebird server process, for example using isql localhost:employee -user sysdba -password <sysdbapassword>. Then the file permissions of the user running the Firebird server process will be applied. However, in that situation, you will need to specify a password when connecting, as passwordless authentication is only applied for Firebird Embedded connections.
I'm unable to create a new database for the first time after installing postgres.app on my macbook pro
Anyone here can point me to the origin of the problem ?
createdb is not a SQL statement, it's program for the command line (like psql or grep).
Inside psql you need to use the SQL statement CREATE DATABASE:
http://www.postgresql.org/docs/current/static/sql-createdatabase.html
And don't forget to terminate every SQL statement with a ; (if you had done that with createdb you would have gotten an error message immediately).
https://gist.github.com/predatorian3/fbf6d34b0a9958212c3c
I recently tried to setup Razor Server using the documetnation provided here:
https://github.com/puppetlabs/razor-server/wiki/Installation
https://docs.puppetlabs.com/pe/latest/razor_prereqs.html
https://docs.puppetlabs.com/pe/latest/razor_install.html
I started with a fresh install of CentOS 6 on Vagrant, and installed PostgreSQL server, and Client. Then I installed the puppet-labs RPM from the documentation. I created the user using:
su - postgres
createuser -P razor
createdb -O razor razor_prd
Then I edited the /etc/razor/config.yml file to reflect the password of razor for the razor user in the database_url for production. Then when I execute the database migration as root, postgres and razor, I get different errors listed in the Gist at the beginning of the question.
[vagrant#centos6 ~]$ sudo su - razor -c "razor-admin --environment production migrate-database"
Sequel::DatabaseConnectionError: Java::OrgPostgresqlUtil::PSQLException: FATAL: Ident authentication failed for user "razor"
make_new at /opt/razor/vendor/bundle/jruby/1.9/gems/sequel-4.9.0/lib/sequel/connection_pool.rb:99
make_new at /opt/razor/vendor/bundle/jruby/1.9/gems/sequel-4.9.0/lib/sequel/connection_pool/threaded.rb:158
available at /opt/razor/vendor/bundle/jruby/1.9/gems/sequel-4.9.0/lib/sequel/connection_pool/threaded.rb:137
acquire at /opt/razor/vendor/bundle/jruby/1.9/gems/sequel-4.9.0/lib/sequel/connection_pool/threaded.rb:127
sync at /opt/razor/vendor/bundle/jruby/1.9/gems/sequel-4.9.0/lib/sequel/connection_pool/threaded.rb:194
synchronize at org/jruby/ext/thread/Mutex.java:149
sync at /opt/razor/vendor/bundle/jruby/1.9/gems/sequel-4.9.0/lib/sequel/connection_pool/threaded.rb:194
acquire at /opt/razor/vendor/bundle/jruby/1.9/gems/sequel-4.9.0/lib/sequel/connection_pool/threaded.rb:126
hold at /opt/razor/vendor/bundle/jruby/1.9/gems/sequel-4.9.0/lib/sequel/connection_pool/threaded.rb:94
synchronize at /opt/razor/vendor/bundle/jruby/1.9/gems/sequel-4.9.0/lib/sequel/database/connecting.rb:234
server_version at /opt/razor/vendor/bundle/jruby/1.9/gems/sequel-4.9.0/lib/sequel/adapters/shared/postgres.rb:442
supports_create_table_if_not_exists? at /opt/razor/vendor/bundle/jruby/1.9/gems/sequel-4.9.0/lib/sequel/adapters/shared/postgres.rb:458
create_table? at /opt/razor/vendor/bundle/jruby/1.9/gems/sequel-4.9.0/lib/sequel/database/schema_methods.rb:211
schema_dataset at /opt/razor/vendor/bundle/jruby/1.9/gems/sequel-4.9.0/lib/sequel/extensions/migration.rb:585
initialize at /opt/razor/vendor/bundle/jruby/1.9/gems/sequel-4.9.0/lib/sequel/extensions/migration.rb:443
initialize at /opt/razor/vendor/bundle/jruby/1.9/gems/sequel-4.9.0/lib/sequel/extensions/migration.rb:505
run at /opt/razor/vendor/bundle/jruby/1.9/gems/sequel-4.9.0/lib/sequel/extensions/migration.rb:390
apply at /opt/razor/vendor/bundle/jruby/1.9/gems/sequel-4.9.0/lib/sequel/extensions/migration.rb:361
(root) at /opt/razor/bin/razor-admin:41
call at org/jruby/RubyProc.java:271
(root) at /opt/razor/bin/razor-admin:84
However I can log in as the razor user into the database and poke around, and I have reset teh razor user's password as postgres and still can log in as the razor user. However, I keep running into the error listed above. What am I doing wrong?
--EDIT 2015-08-18 --
I added the lines above the other entries in the pg_hba.conf
# TYPE DATABASE USER ADDRESS METHOD
local all all trust
host all all 127.0.0.1/32 trust
Now, I'm getting a SQL error saying:
E, [2015-08-19T16:26:10.028000 #2203] ERROR -- razor.sequel: Java::OrgPostgresqlUtil::PSQLException: ERROR: syntax error at or near "DEFERRABLE"
Position: 95: ALTER TABLE "policies" DROP CONSTRAINT "policies_rule_number_key", ADD UNIQUE ("rule_number") DEFERRABLE INITIALLY DEFERRED
I, [2015-08-19T16:26:10.046000 #2203] INFO -- razor.sequel: (0.003000s) ROLLBACK
Sequel::DatabaseError: Java::OrgPostgresqlUtil::PSQLException: ERROR: syntax error at or near "DEFERRABLE"
Position: 95
I believe that this is something to do with the SQL in Razor.
What I had to do was update the database to the latest version. The version of PostgreSQL in CentOS default repos was 8.4 which is deprecated. Then I also had to white list the local, and host settings again for trust. Then restart PostgreSQL and the migration worked.
I'm trying to setup the pgexercises data in my local machine. When I run: psql -U <username> -f clubdata.sql -d postgres -x I get the error: psql:clubdata.sql:6: ERROR: cannot execute CREATE SCHEMA in a read-only transaction.
Why did it create a read-only database on my local machine? Can I change this?
Normally the most plausible reasons for this kind of error are :
trying create statements on a read-only replica (the entire instance is read-only).
<username> has default_transaction_read_only set to ON
the database has default_transaction_read_only set to ON
The script mentioned has in its first lines:
CREATE DATABASE exercises;
\c exercises
CREATE SCHEMA cd;
and you report that the error happens with CREATE SCHEMA at line 6, not before.
That means that the CREATE DATABASE does work, when run by <username>.
And it wouldn't work if any of the reasons above was directly applicable.
One possibility that would technically explain this would be that default_transaction_read_only would be ON in the postgresql.conf file, and set to OFF for the database postgres, the one that the invocation of psql connects to, through an ALTER DATABASE statement that supersedes the configuration file.
That would be why CREATE DATABASE works, but then as soon as it connects to a different database with \c, the default_transaction_read_only setting of the session would flip to ON.
But of course that would be a pretty weird and unusual configuration.
Reached out to pgexercises.com and they were able to help me.
I ran these commands(separately):
psql -U <username> -d postgres
begin;
set transaction read write;
alter database exercises set default_transaction_read_only = off;
commit;
\q
Then I dropped the database from the terminal dropdb exercises and ran script again psql -U <username> -f clubdata.sql -d postgres -x -q
I was having getting cannot execute CREATE TABLE in a read-only transaction, cannot execute DELETE TABLE in a read-only transaction and others.
They all followed a cannot execute INSERT in a read-only transaction. It was like the connection had switched itself over to read-only in the middle of my batch processing.
Turns out, I was running out of storage!
Write access was disabled when the database could no longer write anything. I am using Postgres on Azure. I don't know if the same effect would happen if I was on a dedicated server.
I had same issue for Postgre Update statement
SQL Error: 0, SQLState: 25006 ERROR: cannot execute UPDATE in a read-only transaction
Verified Database access by running below query and it will return either true or false
SELECT pg_is_in_recovery()
true -> Database has only Read Access
false -> Database has full Access
if returns true then check with DBA team for the full access and also try for ping in command prompt and ensure the connectivity.
ping <database hostname or dns>
Also verify if you have primary and standby node for the database
In my case I had a master and replication nodes, and the master node became replication node, which I believe switched it into hot_standby mode. So I was trying to write data into a node that was meant only for reading, therefore the "read-only" problem.
You can query the node in question with SELECT pg_is_in_recovery(), and if it returns True then it is "read-only", and I suppose you should switch to using whatever master node you have now.
I got this information from: https://serverfault.com/questions/630753/how-to-change-postgresql-database-from-read-only-to-writable.
So full credit and my thanks goes to Craig Ringer!
Dbeaver: In my case
This was on.
This doesn't quite answer the original question, but I received the same error and found this page, which ultimately led to a fix.
My issue was trying to run a function with temp tables being created and dropped. The function was created with SECURITY DEFINER privileges, and the user had access locally.
In a different environment, I received the cannot execute DROP TABLE in a read-only transaction error message. This environment was AWS Aurora, and by default, non-admin developers were given read-only privileges. Their server connections were thus set up to use the read-only node of Aurora (-ro- is in the connection url), which must put the connection in the read-only state. Running the same function with the same user against the write node worked.
Seems like a good use case for table variables like SQL Server has! Or, at least, AWS should modify their flow to allow temp tables to be created and dropped on read nodes.
This occurred when I was restoring a production database locally, the database is still doing online recovery from the WAL records.
A little bit unexpected as I assumed pgbackgrest was creating instantly recoverable restores, perhaps not.
91902 postgres 20 0 1445256 14804 13180 D 4.3 0.3 0:28.06 postgres: startup recovering 000000010000001E000000A5
If like me you are trying to create DB on heroku and are stuck as this message shows up on the dataclip tab
I did this,
Choose Resources from(Overview Resources Deploy Metrics Activity Access Settings)
Choose Settings out of (Overview, Durability, Settings, Dataclip)
Then in Administration->Database Credentials choose View Credentials...
then open terminal and fill that info here and enter
psql --host=***************.amazonaws.com --port=5432 --username=*********pubxl --password --dbname=*******lol
then it'll ask for password, copy-paste from there and you can run Postgres cmds.
I suddenly started facing this error on postgres installed on my windows machine, when I was running alter query from dbeaver, all I did was deleted the connection of postgres from dbeaver and created a new connection
If you are using Azure Database for PostgreSQL your server gets into read-only mode when the storage used is near total capacity.
The error you get is exactly:
ERROR: cannot execute XXXXXXXXX in a read-only transaction
https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-compute-storage
I just had this error. My cause was not granting permission to the SEQUENCE
GRANT ALL ON SEQUENCE word_mash_word_cube_template_description_reference_seq TO ronshome_user;
If you are facing this issue with an RDS instance cluster, please check your endpoint and use the Writer instance endpoint. Then it should work now.
Issue can be dur to Intellij config:
Go to Database view> click on Data Source Properties (Shift + enter)> (Select your data source)>
Options tab> Under Connection : uncheck Read-only
For me it was Azure PostgreSQL failing over to standby during maintaince in Azure and never failing back to master when PostgreSQL was in HA mode. You can check this event in Service Health and also check which zone you current VM is running from. If it's 2 and not 1 them most likely that's the result of events described above.