Frequently Asked Questions
The Frequently Asked Questions (FAQ) document is a list of commonly asked questions and answers on pgAdmin. Please make sure you have reviewed the FAQ before asking for help on the pgsql-support mailing list.
The list below is automatically imported from the pgAdmin online help resources and is only available in English.
Can't edit table data
When I open a table to edit, there's no empty line at the end to enter new data. I can't edit the existing data either.
In order to edit data, pgAdmin requires a primary key on the table, which is a good database design practice anyway. Alternatively, the table can be created WITH OIDS. Please note that oids are *not* guaranteed to be unique over a very long period of time, so using oids as kind-of primary key is only second choice. [AP]
I want to edit an object, but the property I'd like to edit always appears disabled.
You're probably editing an object on an older version of PostgreSQL server.
pgAdmin supports PostgreSQL server versions starting from V7.3. Naturally, constant improvements add more features. pgAdmin tries to keep up with this development. Consequently, some features that are described in the online documentation, which always covers the latest released PostgreSQL version available, are not accessible on older server versions. In this case, pgAdmin detects this and disables the option.
Hint: If you're working on older PostgreSQL servers regularly, you can change the online help site in the options dialogue. [AP]
I want to grant rights on an PostgreSQL object to an individual user, but on the security page of that object only groups are shown.
It is recommended to organize users into groups, and grant
the rights to these instead of granting rights to individual users.
My database contains foreign key constraints, but these are not visible with pgAdmin.
If you convert a database prior to 7.3 to a newer one, some dependency information isn't created
because it didn't exist in PostgreSQL 7.2 and older. When restoring such a pg_dump file, the foreign
keys are generated with CREATE CONSTRAINT TRIGGER instead of an ADD
After changing a column type in PostgreSQL 7.3 or 7.4, I get errors when executing views or triggers. I don't see this problem on 8.0 servers.PostgreSQL 7.3 and 7.4 don't support changing the column type by themselves, pgAdmin changes system tables directly instead. Under some circumstances, the query plan that was stored when a view or trigger created containing that column, have to be replanned using the new type information.
Currently, pgAdmin does not recreate depending objects automatically for 7.3 and 7.4 servers; you will have to do that manually if you encounter execution errors. This is not necessary on PostgreSQL 8.+ servers, because these versions support altering a column type instrinsically.
I created a backup file using pgAdmin, but when I try to restore it using pgAdmin the OK button will stay grayed.pgAdmin uses PostgreSQL's pg_restore tool, which supports only the COMRESS and TAR options of pg_dump which is used for backup creation. The PLAIN format can't be interpreted by pgAdmin and pg_restore (it can be edited manually, and executed with psql and pgAdmin's query tool in many cases), and thus isn't accepted as valid file.
We recommend using the COMPRESS format for daily backup tasks. The PLAIN format is for advanced manual processing before executing as SQL script, and has some restrictions (no blobs) which makes it less usable for standard backup tasks.
I'm using pgAdmin V1.0.x and try to connect to a PostgreSQL 8.0.x server. I get the message "ERROR: column "datpath" does not exist." and can't continue.
pgAdmin V1.0.x does not work on PostgreSQL 8.0.x, because some system structure changed.
Use pgAdmin V1.2.x or later instead, which supports PostgreSQL 7.3.x, 7.4.x and 8.0.x. [AP]
We're providing a stripped down pgAdmin v1.0 version without unicode support and limited functionality.
Still, Win9x imposes some other problems too. Consider using a true 32bit operating system
(Linux, W2K, XP) if these constraints hit you. We won't provide Win9x compatible pgAdmin 1.2 versions.
After running a query on Win9x that retrieves around 3000 rows or more, closing the query tool will hang the app.
Apparently this happens when Win9x cleans up the result set ListView. Win9x isn't prepared to handle large data
(it's still kind-of 16 bit in these places).
Some columns are truncated when running a query in the query tool.
You can increase the query option "max. chars per column" for this. Please note that there's another limit for this imposed by the underlying
windows control, which apparently doesn't allow more than 511 characters.
Every time I connect to my PostgreSQL 7.3.x server with pgAdmin,
I get the following message in the serverlog:
Binary distributions of pgAdmin are linked against the newest
PostgreSQL libpq 7.4/8.0 library, which implements a new frontend protocol. It
will try to connect to the backend using this protocol first, and if that fails it
uses the older one.
On my *ix system, the text is too big, and is truncated in the controls.
pgAdmin uses the system's setting for the font, which sometimes
isn't a good choice.
On my system, the reengineered SQL windows shows weird characters, while it should show non-Latin characters.
By default, pgAdmin uses a fixed pitch font, to show nicely
formatted reengineered SQL commands. This may lead to weird characters
if these are not supported by the fixed font codeset.
When running on a machine with gtk-qt-engine installed, pgAdmin will crash with a segmentation fault. A console will print "QPixmap: Invalid pixmap parameters".This is caused by a broken gtk-qt-engine; not only pgAdmin suffers from this. To fix, remove the broken gtk-qt-engine or install a fixed version if available.
I'm connecting to the database server via a firewall. After some minutes of inactivity, the connection to the database is dropped. Some admins report that bogus backend processes remain that are never terminated.
Unfortunately some network administrators or default firewall settings extend functions
meant for external web server access to cover
internal database traffic too. After some minutes of inactivity, the TCP/IP connection
is interrupted without notice to both sides of the connection. As a result, the backend
doesn't know that there's no connection to the client (in this case: pgAdmin , but any
other PostgreSQL client would be affected in the same way) any more,
but thinks it's just idle, and will continue waiting for the next query that never arrives.
If there's absolutely no way to accomplish this, you could use a SSH tunnel for PostgreSQL traffic. SSH can be configured to keep the channel open at all times, so that database traffic can be passed even after a prolonged period of inactivity. For information how to configure this, ask your SSH package's documentation for "tunneling". [AP]
Data that includes non-ascii characters (character code > 0x7f) will not be shown.
pgAdmin 1.0.0 uses the client_encoding set to UNICODE. The server will automatically convert
all data from the encoding format stored in the database to UNICODE. If the server is not able
to convert the data, it will suppress this. A common problem is using the SQL_ASCII server side
encoding, but storing non-ascii data in it. If you're using a client_encoding set to SQL_ASCII,
you won't notice a problem because the server doesn't convert the data, but when using a different
client encoding the server starts to convert, and fails.