I'm wondering if it's possible to have psql start a transaction automatically when I open a psql session on the command line. I know I can start a transaction manually using 'BEGIN;' but I'm wondering if that can be done automatically without me typing in 'BEGIN;' manually on the command line.
Thanks!
I did a google search but that didn't come up with any good results.
You cannot have psql start a transaction when you login, but you can have it start a transaction with the first SQL statement you enter. For that, put a .psqlrc file into your home directory and give it the following content:
\set AUTOCOMMIT off
Note that that is a very bad idea (in my personal opinion). You are running the risk to inadvertently start a transaction that holds locks and blocks the progress of autovacuum. I have seen more than one PostgreSQL instance that suffered serious damage because of administrators who disabled autocommit in their interactive clients and kept transactions open. At the very least, add the following to your .psqlrc:
SET idle_in_transaction_session_timeout = '1min';
Related
Original aim: rename a database using ALTER DATABASE via psql.
Problem: rename fails due to other sessions accessing target database. ・All terminals/applications I am aware of have been closed.
・querying pg_stat_activity shows that there are 10 processes(=sessions?) accessing the db.・The username for each session is the same user I have been using for psql and for some local phoenix and django apps. The client_addr is also local host for all of them.
・When I use pg_terminate_backend, on any of the pids, another process gets immediately spawned.
・After restarting my pc, 10 processes are again spawned.
Concern: As I can't account for these 10 processes that I can't get rid of, I think I'm misunderstanding how postgres works somewhere.
Question: Why do 10 session/processes connected to a particular one of my databases, and why can't I terminate them using pg_terminate_backend?
Note: In the phoenix project I set up recently, I set the and set the pool_size of the Repo config to 10 - which makes me think it's related...but I'm pretty sure that project isn't running in any way.
Update - Solved
As a_horse_with_no_name suggested, the by doing the following I was able to put a stop to the 10 mystery sessions.
(1) prevent login of user responsible for the sessions (identifiable by querying `pg_stat_activity`), by doing `alter user .... with nologin`
(2)-running pg_terminate_backend on each of the session's pids.
After those steps I was able to change the table name.
The remaining puzzle is, how did those sessions get in that status in the first place... from the contents of pg_stat_activity, the wait_event value for each was clientRead.
From this post, it seems that the application may have been forcibly stopped halfway through a transaction or something, leaving postgres hanging.
Is there a way to submit a command in datagrip to a database without keeping the connection open / asynchronously? I'm attempting to create indexes concurrently, but I'd also like to close my laptop.
My datagrip workflow:
Select column in a database, click 'modify column', and eventually run code such as:
create index concurrently batchdisbursements_updated_index
on de_testing.batchdisbursements (updated);
However, these run as background tasks and cancel if I exit datagrip.
However, these run as background tasks and cancel if I exit datagrip.
What if you close your laptop without exiting datagrip? Datagrip is probably actively sending a cancellation message to PostgreSQL when you exit it. If you just close the laptop, I doubt it will do that. In that case, PostgreSQL won't notice the client has gone away until it tries to send a message, at which point the index creation should already be done and committed.
But this is a fragile plan. I would ssh to the server, run screen (or one of the fancier variants), run psql in that, and create the indexes from there.
I am using postgres client to invoke postgres on the command line:
./bin/postgres -U user db_name
This prompts user to enter the password.
How can I set a timeout to the user's session?
There is no session timeout feature in psql, nor in the server-side postgres server. It's a good idea, and you should feel free to suggest adding it on pgsql-general and ask if someone wants to add it to the TODO list. Or try your hand at implementing it.
If you're on PostgreSQL 9.3 or newer so you have the state_change field in the pg_stat_activity system view, you could fairly easily implement a cron job, server-side, that scans for idle connections and calls pg_terminate_backend on them. Note that this would terminate any running transaction and would clear any user SET variables, WITH HOLD cursors, advisory locks, etc, because it force-disconnects the user.
When PgAdmin III displays a list of databases, a database in the middle of restoring looks just like any other one. How can I determine if the restore has completed or not?
If by restore you mean pg_restore command in progress you cannot see that directly from pgAdmin. What pg_restore does in fact is execute simple CREATE TABLE, INSERT or COPY commands that differ in no way from normal commands. What you can do is you can open the Server status window. If you know where the command is executed (IP address) or if there is nothing else connecting to the database you can check if there are open connections to the database. If there are no open connections the restore has finished. If you can't deduce the info from connections you could look if there are any transactions (no transactions for some time = restore finished).
It would be simpler to get this information if you had access to the place where the command is executed.
What can be done to prevent having to restart a PC after a program (C++Builder) terminated abnormaly without closing the database using firebird 2?
What I am looking for: I would like to be able to just restart the program without any other intervention. (I could have the user call a batch file executing some cleanup or add some lines of code to the program to disconnect everything.)
If your database is firebird 2.1+, there are monitoring tables that show the active connections, and the sysdba can manually delete any left-over connnections.
If you look in your release notes, the syntax details should be there.