Immediate problem: When I do a pgAdmin 4 restore I get "Stymied by idle_in_transaction_session_timeout" error.
I am on a MacBook Pro running macOS Mojave version 10.14.5, using Java and PostgreSQL. I use the pgAdmin 4 GUI, as I am not proficient in psql, bash, etc. I have a test database named pg2. As you can see from the attachment, PostgreSQL servers 9.4 and 10 have the identical databases. If I make a change in a database on one server, it will show also in the other server’s database. There is a third server, 11, in which there is only the postgres database.
I have tried psql and get errors (including timeout errors).
I have tried to Delete/Drop server 11, it will disappear but when I sign out of pgAdmin 4 and then go into pgAdmin 4 again the server 11 will be there again.
See the attachments for screen shots.
I expect the backup/restore to work: backup, then make a change to the database, then correctly restore to previous state.
I would like to have just one server, preferably 11 with only pg1 and the test db tempdb running in it. I thought that I could live with the three, for I am aware of my current capabilities and thus did not want to screw things up further. However, I suspect that the two servers 9.4 and 10 are the source of my current problem: receiving the idle_in_transaction_session_timeout error while doing a restore. Note: I did the backup using the server 10’s pg1 backup. Did it create 2 backups, one for 9.4 and one for 10?
I tried to attach these before. They will help make sense of my problem.
The 2 servers have the same database; is this causing the idle in transaction session timeout?
Related
I am hosting a PostgreSQL 9.5 database on a DigitalOcean Droplet. I am using pgAdmin 4 v6.14 to access the database server.
Since upgrading to Windows 11, I still can connect and manually query the databases, but if I try to open /Schemas/public/Tables, there is just an endless "Windows-Sweep-Waiting-Icon" without any result nor error message. Other subsections such as Sequences are seemingly working fine. Other stakeholders using Windows 11 are experiencing the same issue, while users using Windows 10 can still use pgAdmin to access the database tables.
Are there any experiences with this problem? Is "just upgrade your postgreSQL version" the way to go? I am unexperienced in hosting a postgreSQL server and since there are multiple projects currently running, I am afraid to mess up with the server while it is "basically" working, and Windows 11 seems to be the discriminant factor.
Best regards
I have a heroku postgres database. On pgadmin i can see over 1,700 databases since they are all on the same host. I have set the server connection settings as provided by heroku and i can see my database highlighted in yellow and can access it normally.
I tried disconnecting from the server than edit the db restriction property in the advanced tab and put in my database name(same one as the maintenance db, and without ''). I press save, i reconnect to the server but i can still see all the databases of the server and all the live data of the entire server. Am i missing something?
Don´t download the latest version of pgadmin 4(v.6.10), instead download the v.6.9
link:
https://www.postgresql.org/ftp/pgadmin/pgadmin4/v6.9/windows/
I believe that latest version is buged when we try to especify a dbname for restriction
uninstall 4(v.6.10) and replace (v.6.9)
i faced the same problem here, but installed (v.6.9) and worked great, and brings me only my database
for pgadmin4 you dont need single quotes ... just write the dbname and then tab
How to hide databases that I am not allowed to access
result-image
This question already has answers here:
Export and import table dump (.sql) using pgAdmin
(6 answers)
Closed 1 year ago.
Let I first state that I am not a DBA-guy but I do have a question regarding restoring remote databases using PG Admin.
I have this PG Admin tool (v4.27) running in a Docker container and I use this portal to maintain two separate Postgress databases, both running in a Docker container as well. I installed PG Agent in both database containers and run scheduled daily backup's, defined via PG Admin and stored in the container of each corresponding databases. So far so good.
Now I want to restore one of these databases by using the latest daily backup file (*.sql), but the Restore Dialog of PG Admin only looks for files stored locally (the PG Admin container)?
Whatever I tried or searched for on the internet, to me it seems not possible to show a list of remote backup files in PG Admin or run manually a remote SQL file. Is this even possible in PG Admin? Running psql in the query editor is not possible (duh ...) and due to not finding the remote SQL-restore file I have no clue how to run this code within PG Admin on the remote corresponding database container.
The one and only solution so far I can think of, is scheduling a restore which has no calendar and should be triggered manually when needed, but it's not the prettiest solution.
Do I miss something or did I overlook the right documentation or have I created a silly, unmaintainable solution?
Thanks in advance for thinking along and kind regards,
Aad Dijksman
You cannot restore a plain format dump (an SQL script) with pgAdmin. You will have to use psql, the command line client.
COPY statements and data are mixed in such a dump, and that would make pgAdmin choke.
The solution by #Laurenz Albe points out that it is best to use the command line psql here, and that would be my first go-to.
However, if for whatever reason you don't have access to the command line and are only able to connect to this database via pgadmin, there is another solution which you can find here:
Export and import table dump (.sql) using pgAdmin
I recommend looking at the solution by Tomas Greif.
I had Postgresql 9.6 installed (on Windows 10) and did a complete uninstall including the data directory and all old copies of PgAdmin and there are no environment variables relating to this or any other old Postgres installation either.
I recently installed Postgresql 11 and PgAdmin 4 v3.6 using EnterpriseDB installer. When I run PgAdmin 4 it aurto detects a postgresql instance called 9.6 - though the details tell me it is actually my v11 instance with the same port number and password etc. The only difference is that it is pointing to the non-existent old data directory.
I have searched for a stray postgresql.conf file (and can't find one as it was in the deleted data directory!). As there is also no environment variables, no binaries and no data I can't understand how PgAdmin is auto detecting this ghost. Any suggestions on how to correct it?
EDIT:
I have tried deleting all cookies relating to PgAdmin and Postgresql in Chrome too - this had no effect
I have also double checked that there is no postgresql 9.6 service running (but that just confirms the above where PgAdmin tells me it is called 9.6 but actually is a v11 instance)
Try deleting pgAdmin4 config file pgadmin4.db located at %APPDATA%\pgAdmin\
Restart pgAdmin4 and check.
I was trying to follow the instructions from postgresqltutorial to load a sample database into postgresql using pgadmin. But after the database was restored(since I can query data from the database), the process watcher just won't go away, and it keeps saying that the command is "running"(as of this writing, it has been running for over 400 thousands seconds, but the size of the sample database is just a few megabytes). Reboot and reinstallation couldn't fix the problem.
Here are some screen shots:
And when I click "click here for details":
I am using postgresql 9.6 with pgadmin4 on windows 10. So what's going on here? Is it a bug? How can I get rid of the process watcher?
I had the same issue with posgresql 9.5 and pgAdmin4 on Windows 7. I solved it without loosing server list by opening %APPDATA%\pgAdmin\pgadmin4.db file with SQLite Manager (Firefox Add-on) and deleting all entries from the 'process' table.
This is a bug in pgAdmin4 & reported,
https://redmine.postgresql.org/issues/1679
close pgAdmin, restart the system, open %APPDATA% and erase the folder pgAdmin and the pgAdmin is Ready to start without errors.
Greetings