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.

pgAdmin FAQ

Can't edit table data
A property is disabled on an object I want to edit
User privileges
Foreign key constraints not shown
Problem after changing column type
Can't restore backup file created with pgAdmin
ERROR: column "datpath" does not exist
Win9x problems
Query tool hangs on Win9x
Query tool columns truncated
Server log: unsupported protocol
Font problem: too big
Font problem: SQL shows weird characters
Crash on Linux: QPixmap: Invalid pixmap parameters
Connection to database dropped
Encoding Problem: My data is not shown

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]

A property is disabled on an object I want to edit

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]

User Privileges

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.
If you need this nevertheless, you can switch on the option "Show users for privileges" on the General tab of the Options dialogue. [AP]

Foreign key constraints not shown

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 CONSTRAINT command.
pgAdmin considers constraint triggers as an internal implementation detail, not interesting for the common administrator. In fact, CREATE CONSTRAINT TRIGGER is for backward compatibility only, and shouldn't be used in newer scripts any more. Some tools (e.g. pgAdmin II) imply this, by showing a ADD CONSTRAINT when reverse engineering, while actually the constraint information in the database is missing.
Run the adddepend script, which can be found in the backend's sources contrib/adddepend directory. [AP]

Problem after changing column type

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.

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.

Can't restore backup file created with pgAdmin

I created a backup file using pgAdmin, but when I try to restore it using pgAdmin the OK button will stay grayed.

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.

ERROR: column "datpath" does not exist

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]

Win9x problems

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.
One example:

Query tool hangs on Win9x

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).
We don't provide fixes for Win9x components (M$ doesn't either). There's no known workaround.[AP]

Query tool columns truncated

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.
In pgAdmin V1.1 and up, we provide the function "execute to file", which has no column restrictions. [AP]

Server log: unsupported protocol

Every time I connect to my PostgreSQL 7.3.x server with pgAdmin, I get the following message in the serverlog:
FATAL: unsupported frontend protocol

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.
This behaviour is by design, and there's no problem to be expected from this. [AP]

Font problem: too big

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.
Try to put something like this in your ~/.gtkrc-2.0 file:
<---------cut here------------------->
style "defaultfont"
{
font_name = "Arial 8"
}
widget_class "*" style "defaultfont"
<---------cut here------------------->
pgAdmin V1.1 and up solves this by resizing the dialogues according to the font in use. In addition, you may select you preferred application font in the options dialogue. [RE]

Font problem: SQL shows weird characters

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.
On the Query tab of the Options dialogue, you may select your preferred font to have a correct display. [AP]

Crash on Linux: Qpixmap: Invalid pixmap parameters

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".

Connection to database dropped

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.
The PostgreSQL interface uses the TCP/IP protocol stack, that by definition should provide a reliable connection between the two end points of the connection. If interrupted, the protocol stack would notice this and notify the interface. In contrast, a firewall configured to interrupt by not forwarding any packet belonging to the connection after some arbitrary timeout, violates basic TCP/IP principles.
While this might be perfectly reasonable for browser connections to a web servers that are aware of possible non-detectable interruptions, this is not acceptable for database connections carrying sensitive data. Unfortunately, many network administrators don't understand the vital difference, others can't change the firewall configuration for some hardware/software/policy restricting reasons.

Encoding Problem: My data is not shown

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.
Later versions of pgAdmin (1.0.1 and up) will use SQL_ASCII client encoding, if it detects a server encoding of SQL_ASCII. If a different encoding is present, UNICODE is used. [AP]