VPOP3DB is the current name of the VPOP3 instance of PostgreSQL. Earlier versions of VPOP3 used the name 'PostgreSQL' or 'PostgreSQL-VPOP3'.
If the PostgreSQL service doesn't start, or starts and immediately stops, there are a couple of things you can do:
- Look in the Windows Application event log for entries relating to PostgreSQL. See below for possible errors in the event log
- Look in the VPOP3\pgsql\data\pg_log folder for a log file created at the time when you started VPOP3. If that is there, you can read that (using Notepad) and see if it reports any problems with files or 'relations'. If so, it might be a problem with a damaged database. See below for other possible error messages in the PostgreSQL log files.
- Check the Processes list (for all users) in Windows' Task Manager and end any 'postgres.exe' processes which are owned by 'vpop3postgres' and try again.
Event Viewer Entries
In the Windows Event Viewer, view the Application event log, then look for Error entries for the PostgreSQL source.
Depending on your installation, the events may all be displayed as something like:
The description for Event ID xxxx from source PostgreSQL cannot be found. Either the component that raises this event is not installed on your local computer....
If that's the case, don't worry, just look lower down in the event message. It will say something like
The following information was included with the event
It is that information you need to see. Some possible event messages we have seen are:
Timed out waiting for server startup
This can happen if the PC previously crashed, or there was a power failure. When the PC restarts, it can take some time for the database server to run its recovery process. This may take longer than the time allowed by the database service controller, especially if the PC is busy doing other recovery tasks.
To solve this, go to Windows TaskManager (Ctrl-Alt-Del - choose TaskManager), then go to the Processes tab and click Show processes for all users. Sort by Image Name, and End Process on all the postgres.exeprocesses. Once those are all ended, then you should be able to start the VPOP3DB service manually.
pg_ctl: this data directory appears to be running a pre-existing postmaster
If this is the case, then usually it means that a previous attempt to start PostgreSQL was made, but it timed out or something, and is now in a 'partially' running state.
To solve this, go to Windows TaskManager (Ctrl-Alt-Del - choose TaskManager), then go to the Processes tab and click Show processes for all users. Sort by Image Name, and End Process on all the postgres.exeprocesses. Once those are all ended, then you should be able to start the VPOP3DB service manually.
'Postmaster.pid exists' or 'bogus data in lock file "postmaster.pid" '
If there is an event saying FATAL: lock file “postmaster.pid” already exists or bogus data in lock file "postmaster.pid", then this means that that file exists in the VPOP3\pgsql\data folder. Usually this should be deleted when PostgreSQL closes down when the computer is shut down or restarted.
First check that the database software is not running in a partial state. Go to Windows TaskManager (Ctrl-Alt-Del - choose TaskManager), then go to the Processes tab and click Show processes for all users. Sort by Image Name, and End Process on all the postgres.exe processes. Once those are all ended, then you should be able to start the VPOP3DB service manually.
If the database software is not running, you can manually delete the VPOP3\pgsql\data\postmaster.pid file before restarting the VPOP3 service.
pg_ctl: could not find postgres program executable
We have seen this happen if a virus scanner decides to delete part of the PostgreSQL installation, or if the installation failed for some reason.
If you are using VPOP3 v5 or later, the easiest thing to do is to manually reinstall the PostgreSQL part of the installation. To do this, open a command prompt and go to the VPOP3 installation directory. Then run:
(for VPOP3 v5 or v6)
bsdtar -xvf pgsql.tbz
(for VPOP3 v7)
7z x -aoa -r pgsql95.7z
(for VPOP3 v8)
7z x -aoa -r pgsql10.7z
If you are using VPOP3 v3 or v4, it is more difficult. Possibly the best thing to do is to install a temporary copy of the same version of VPOP3 on another PC, then copy the VPOP3\pgsql\bin, VPOP3\pgsql\lib and VPOP3\pgsql\share folders from that temporary installation to your VPOP3 PC.
Could not open directory "pg_tblspc": No such file or directory
(The directory name may be different in some cases)
This can happen if some program or user has deleted empty directories. Some 'clean-up' programs will delete empty directories thinking they are unnecessary, but PostgreSQL uses directories for temporary files, so they may be empty when the clean-up program runs, but deleting them will cause PostgreSQL not to run, or to stop shortly after starting.
If this happens, you can recreate the empty directory. Other empty directories may have been deleted as well, so make sure they are all present. There is a list of required directory names below (this may not be a complete list, depending on your version of PostgreSQL). These are all directories in the pgsql\data directory:
- pg_commit_ts
- pg_dynshmem
- pg_logical
- pg_logical\mappings
- pg_logical\snapshots
- pg_replslot
- pg_serial
- pg_snapshots
- pg_stat
- pg_tblspc
- pg_twophase
(Note that there are other directories in the pgsql\data directory which contain data. If those have been deleted then you will probably need to restore from backup, and possibly reinitialise the database)
PostgreSQL Log Entries
If you get FATAL or PANIC entries in the PostgreSQL log files (in VPOP3\pgsql\data\pg_log) then they may give more information about why PostgreSQL could not start. Some log entries we have come across are below.
no pg_hba.conf entry for host "::1", user "postgres", database "postgres"
no pg_hba.conf entry for host "::1", user "vpop3", database "vpop3"
This usually happens if the PC where VPOP3 is installed used to only have IPv4 installed, and has now had IPv6 added. The PostgreSQL configuration needs altering to support IPv6.
Usually this only happens on Windows XP - earlier versions of Windows do not support IPv6, and later versions support IPv6 by default. Windows XP needs to have IPv6 manually installed
To fix this problem, go to the VPOP3\pgsql\data folder on the server and edit the pg_hba.conf file using a plain text editor such as Notepad.
Near the bottom of that file you should see a section saying
# TYPE DATABASE USER CIDR-ADDRESS METHOD # IPv4 local connections: host all all 127.0.0.1/32 md5 # IPv6 local connections: #host all all ::1/128 md5
Edit the last line to remove the # from the start, so it now says
# TYPE DATABASE USER CIDR-ADDRESS METHOD # IPv4 local connections: host all all 127.0.0.1/32 md5 # IPv6 local connections: host all all ::1/128 md5
In some cases the last two lines may not exist, in which case you can simply copy those lines from the example above and paste them into your pg_hba.conf file
You will then need to restart the VPOP3DB/PostgreSQL service in Windows. Note that sometimes PostgreSQL cannot close down properly, and there will be unwanted 'postgres.exe' processes visible in Windows TaskManager on the Processes tab. If so, then end those processes manually, before restarting the service.
FATAL: could not open directory "pg_replslot": No such file or directory
(The directory name may be different in some cases)
See the "Could not open directory "pg_tblspc": No such file or directory" entry in the event log entry section above.
Shared memory problems
The VPOP3 installer attempts to configure the database server to sensible defaults for the computer on which VPOP3 is running. Sometimes this may be wrong because of changes to the server configuration or other things. Most of the settings the installer could get wrong will not usually cause serious problems, but if the installer has overestimated the amount of memory available, then this could cause the VPOP3DB service to fail to start.
To check, this look in the VPOP3\pgsql\data\vpop3db.conf file (in older versions of VPOP3, this file may not exist - in that case, look in the VPOP3\pgsql\data\postgresql.conf file instead. There will be a line saying something like:
shared_buffers=512MB
This tells the database service how much memory it can use for its built-in cache. If this number is too high, so that Windows cannot give this amount of memory to the database server, then the VPOP3DB service will not start.
You can decrease the value, eg to shared_buffers=256MB and see if that will allow the VPOP3DB service to start correctly. If you wish, you may then increase the value gradually until it will not restart.
Since the VPOP3 installation of the PostgreSQL database server is a 32 bit version, you should not increase the value of this over 512MB, even if the computer has much more memory available. PostgreSQL takes advantage of Windows' disk caching, so the memory is not wasted.
Do not set this value below about 32MB. The bigger it is, the faster the database server will be able to run, up to a maximum of about 512MB. For computers with sufficient RAM (memory), then about 1/4 of the available RAM is a good starting point (within the above limits) - eg if the PC has 2GB of RAM, then 512MB is a sensible starting point.
Increasing this so much that other programs start paging to disk will be counter-productive, so there always needs to be sufficient free memory for Windows to be happy, and preferably to have memory available for Windows' disk caching.
Other things to try
Start service manually
You can also try starting the PostgreSQL service manually:
- For VPOP3 v3 and v4, from a command prompt, run “runas /user:postgres cmd” (password is “vla8Pi4cluwrouDiERiU”)
- For VPOP3 v5 and later, from a command prompt, run “runas /user:vpop3postgres cmd” (password is “Nc6ACboDt2jVL6”)
Then
c: cd \vpop3\pgsql\bin pg_ctl -D "C:\vpop3\pgsql\data" start
(If your VPOP3 is installed in a different directory, change the above paths as appropriate)
See what response you get to the pg_ctl command
Change Service user to 'LocalSystem'
Occasionally it won't start anyway. In this case, changing the VPOP3DB service Logon user to Local System Account will solve the problem (make sure that Allow service to interact with desktop is not checked).
It is not installed this way by default because the 'LocalSystem' user has full permissions to the PC's files, whereas the vpop3postgres user only has access to the database files, but it should not be a big security risk as long as other basic security steps are taken. The default installation of the VPOP3DB service does not allow access to the database over the network, so it is low risk.
Reinstall PostgreSQL program files
It isn't unknown for a virus scanner or Internet security program (or a 'system restore', etc) to randomly delete the PostgreSQL program files/DLLs, which will cause the service to fail to start.
In this case, in v6 or later you can manually replace all the PostgreSQL program files without having to reinstall or lose data. To do this, go to a command prompt in the VPOP3 installation directory and run:
VPOP3 v6.x
bsdtar -xvf pgsql.tbz
VPOP3 v7.x
7z x -aoa -r pgsql95.7z
VPOP3 v8.x
7z x -aoa -r pgsql10.7z
That should overwrite all the PostgreSQL program files/DLLs/etc without affecting the database.