Database Reference
In-Depth Information
Other good filters might be:
F
WHERE
application_name
=
'
myappname
'
F
WHERE
waiting
F
WHERE
current_query
=
'
<IDLE>
in transaction'
F
WHERE
current_query
=
'
<IDLE>
'
How it works...
pg_terminate_backend()
sends a signal directly to the operating system process
for that session.
It's possible that the session may have closed by the time
pg_terminate_backend()
is
named. As pid numbers are assigned by the operating system, it might be possible that a
session with that pid number closed, and then a new session started with that exact same
number gets cancelled instead. So, be careful.
It's also possible that new sessions could start after we get the list of active sessions. There's
no way to prevent that other than by following the recipe
Preventing
new
connections
.
Deciding on a design for multi-tenancy
There are many reasons why we might want to split up groups of tables or applications:
security, resource control, convenience. Whatever the reason, we often need to separate
groups of tables (I avoid saying the word "database" just to avoid various confusions).
This topic is frequently referred to as multi-tenancy, though that is not a fully accepted
term as yet.
The purpose of this recipe is to discuss the options and lead into other more detailed recipes.
How to do it...
If you want to run multiple physical databases on one server, then you have four main options,
which are as follows:
1. Run multiple sets of tables in different schemas in one database of a
PostgreSQL instance
2. Run multiple databases in the same PostgreSQL instance
3. Run multiple PostgreSQL instances on the same virtual/physical system
4. Run separate PostgreSQL instances in separate virtual machines on the same
physical server
