I am using VPN (Endpoint Security, Check Point) to establish connection to the Firebird 2.1 database from IBExpert on my computer. Sometimes I just forget disconnect from database and I cancel/disonnect VPN session only.
When I am connectiong once more to the VPN and database I can see in the mon$attachments that the previous connection/attachment is still existing and its unresolved transactions are causing deadlock errors (that belong to the previous attachment - this can be verified exactly by the transaction number that is reported in the error message of deadlock error).
So - VPN sometimes retains sessions and those VPN sessions keeps the Firebird attachments in existences.
Is there way how can I (using SYSDBA connection) end those other Firebird attachments from my current Firebird session?
I have contacted the VPN administrator to cancel VPN sessions, but it takes time. Database shutdown is out of the question - DB is in production mode. So, ending Firebird attachments using SQL is the only option left for me - if such option exists at all?
In Firebird 2.5 and later, you can delete a connection from MON$ATTACHMENTS to kill a connection. This is not supported with the monitoring tables in Firebird 2.1 as far as I'm aware.
Given even Firebird 2.5 is end-of-life, and Firebird 2.1 has been end-of-life since 2014, you should really consider updating.
Normally, Firebird uses the SO_KEEPALIVE socket option to detect dead connections, but this can take a long time (depending on your OS configuration). An alternative might be to configure dummy_packet_interval in firebird.conf to a non-zero value (the value is seconds, so set it to a reasonable (read, not too low) value).
Related
I have a client app using Entity Framework Core 5 with Npgsql to access PostgreSQL. The client app may make multiple connections to the database.
The problem is, after we killed the client app and shutdown the client machine, we can still see the connections from pgAdmin dashboard on the server.
We should not see these connection in pgAdmin as the client app is totally shutdown, does anyone know what is happening?
Is it because we kill the client app during a transaction or during a query wait?
If we inspect the connection query then we can see that it is performing a select statement. We suspect that it is waiting for another transaction to complete before returning the data but the client was killed and it didn't know about that. Would this be a right assumption?
i connect to Postgresql via JDBC through pgbouncer with transaction pooling mode enabled. As far as I know in this mode pgbouncer can share same connection for several client without breaking session. So several clients may work within a single session sequentially, one by another. The question is does pgbouncer care about reseting session parameters when it detach one client from a connection and attach another client to this connection?
In particular, my app get connection and then issues something like this:
executeQuery(connection,"select set_config('myapp.user','fonar101',false)");
..../*other actions*/
commit(connection);
After commit pgbouncer can detach my app from connection and get it back to its pool, right? So,
if I issue another statements after commit they will probably be
executed within another session with incorrect values of session
parameters
pgbouncer can attach another client to that connection
and that client will proceed with again incorrect session settings
How does pgbouncer care about this things?
I'd say the opposite:
https://pgbouncer.github.io/config.html
transaction
Server is released back to pool after transaction finishes.
Which means that when you SET SESSION (default for SET), without specifying SET LOCAL, you change settings for all transactions that share the session in the pool...
According pgbouncer docs it doesnt support SET/RESET and ON COMMIT DROP for temp tables in transaction pooling mode.
This question already has answers here:
Is there a timeout for idle PostgreSQL connections?
(7 answers)
Closed 8 years ago.
I had a user who was having a crashing issue with our app and was not closing his connection to the database properly - eventually reaching his connection limit and was unable to log back in.
That's ok. The problem was eventually fixed and the app is closing the connection properly now.
I was wondering, if a user reaches his connection limit, and without me doing anything, what is the default setting for Postgres 9.1 to drop the connection on its own?
Well, for your actual question:
if a user reaches his connection limit, and without me doing anything, what is the default setting for Postgres 9.1 to drop the connection on its own?
If the connections you are talking about are active connections to real clients (i.e. the client is still around, not crashed and exited, and can read and write to its connection socket), Postgres will not "drop the connection on its own". See this question if you're interested in ways to prune such idle clients.
On the other hand, it is possible for a Postgres backend to be nominally connected to a client which has really crashed or otherwise exited, as you alluded to earlier. In that case, Postgres may not notice the client is gone and not just in an idle state for some time. I believe the exact time would be controlled by a "TCP keepalive time" OS setting, or you could even fiddle with this setting in your client via connection parameters: see the various keepalives-related settings.
I was using MySQL Workbench and I am not able to figure out the difference between the following:
1. Server instance
2. Connection to server
In general I want to know if we can use Open Connection to start querying without creating
a server instance of the connection we are trying to connect. Are these two things independent?
You need one or two connections depending on what you wanna do with your server. For MySQL work (i.e. running queries) you need a MySQL connection. For server work (e.g. shutting the MySQL server down or manage other aspects that require shell access) you need a second connection (which is called a Server Instance).
Beginning with MySQL Workbench 6.0 we merged both connection settings into one interface.
I've set up PGBouncer and configured it to connect to my postgres DB and it all connects just fine, however I'm not sure if its actually working.
I have a php script that runs as a daemon and picks up beanstalk jobs. The problem is for every distinct user/action on the system it opens a new connection to postgres and then leaves that connection idling because the daemon doesn't actually stop running so the connection is never terminated (a quick fix for this was to reset the connection at the end of the script loop, but that is going to be inefficient with many connects).
Anyway, this caused postgres to eventually run out of connections and lock up...
So PGBouncer seems like the answer.
But now when I run it, I see the same db connection multiple times when i do ps ax | grep postgres.
Isn't PGBouncer supposed to only ever have 1 connection open to the DB and route all traffic through that connection? Then open a new connection if that one is full?
At present I have 3 for one db connection (my access control system) and 2 for the other database (my client specific data).
To me, it feels like if I roll out these changes then I will just be faced with the same problem that the connections will just get eaten up again because they're not being released.
I hope that explains enough for someone to offer any advice.
It sounds like an important step here is to fix the scripts so they release the connections when they're done. Once you do that, PgBouncer will help reduce the connection setup/teardown overhead, but in connection pooling mode it won't give you the ability to maintain more connections to Pg than you otherwise could.
However, you can also use PgBouncer in transaction-pooling mode. When used for transaction pooling, PgBouncer keeps a pool of idle backend transactions and only assigns them when a client does a BEGIN. Connections are returned to the pool after the client does a COMMIT or ROLLBACK. That means that in transaction pooling mode you can have large numbers of open connections to PgBouncer; they don't each need a corresponding connection to a PostgreSQL backend, so long as most of them are idle at any point in time and don't have any transaction open.
The only real downside of transaction pooling mode is that it breaks applications that expect to SET session-level variables, keep prepared statements across transactions, etc. Applications may need modification, e.g. to use SET LOCAL.