Repeat error (either with PT3 or postgres)

[dreamcaster]

I have had this problem a few times now and don't understand why it is coming up.

Yesterday, after a complete uninstall of PT3 and postgres (based on the fourm instructions), I manually installed postgres version 8.3.4, ran PT3 as admin and had the program working fine. Only bug was the PT3 icon on my desktop wouldn't show the standard PT3 icon

Today, after I downloaded an Adobe program for other purposes and deleted the Abode desktop icons, my PT3 icon corrected itself. I logged into PT3 and found the following message in the Texas Holdem tab;

"Unable to login to database (PT3DB). Reason: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request."

I had had this error before. The result of this error is the PT3 doesn't work. When I close it down, it will not reload up past the pokertracker logo and it blocks my computer from loading up any internet based programs (firefox, explorer, AIM, Skype, etc)

I turned UAC off again and rebooted but the message still comes up.

I would think that uninstalling PT3/postgres and reinstalling everyday is not the answer to this problem. Please help.

[WhiteRider]

Try this:

Please try starting the postgres service: Start -> Programs -> PostgreSQL -> Start Service.
If that, and a reboot doesn't work, try stopping the service (Start -> Programs -> Postgres -> Stop Service), running a search on your computer for postmaster.pid and then deleting that file, then restarting the service and see if that helps.
Note that you may need to turn on 'View hidden files and folders', and the file seems to be in the folder './Program Files/postgresql/[version]/data'.

If that doesn't work;
Please select the last few files in C:\Program Files\PostgreSQL\8.3\data\pg_log (they're dated so just pick the recent ones), right-click and choose 'Send To Compressed/zipped Folder', then attach the zip file to a ticket on the Support system, and link to this thread in the reference field of the ticket so that we can investigate.

[dreamcaster]

I deleted the postmaster file. I'm going to put the last couple of logs in this reply so others can see the error I am getting and hopefully you can reply with a solution. I found many threads with similar problems but the resolution is never posted.

Now that I have postgreSQL on my system, does it matter if UAC is on?

Here is the last working log:
2008-10-23 01:24:52 EDT LOG: loaded library "$libdir/plugins/plugin_debugger.dll"
2008-10-23 01:24:52 EDT LOG: loaded library "$libdir/plugins/plugin_debugger.dll"
2008-10-23 01:39:15 EDT LOG: received fast shutdown request
2008-10-23 01:39:15 EDT LOG: aborting any active transactions
2008-10-23 01:39:15 EDT LOG: autovacuum launcher shutting down
2008-10-23 01:39:15 EDT LOG: shutting down
2008-10-23 01:39:16 EDT LOG: database system is shut down

The one after:
2008-10-23 07:48:59 EDT LOG: database system was shut down at 2008-10-23 01:39:15 EDT
2008-10-23 07:48:59 EDT LOG: loaded library "$libdir/plugins/plugin_debugger.dll"
2008-10-23 07:48:59 EDT FATAL: the database system is starting up
2008-10-23 07:49:00 EDT LOG: loaded library "$libdir/plugins/plugin_debugger.dll"
2008-10-23 07:49:00 EDT FATAL: the database system is starting up
2008-10-23 07:49:01 EDT LOG: database system is ready to accept connections
2008-10-23 07:49:01 EDT LOG: autovacuum launcher started
2008-10-23 07:49:01 EDT LOG: loaded library "$libdir/plugins/plugin_debugger.dll"
FATAL: could not reattach to shared memory (key=460, addr=02DB0000): 487
2008-10-23 07:50:22 EDT WARNING: worker took too long to start; cancelled
<same error repeats>
2008-10-23 23:13:28 EDT WARNING: worker took too long to start; cancelled
FATAL: could not reattach to shared memory (key=460, addr=02DB0000): 487
2008-10-23 23:14:23 EDT LOG: received fast shutdown request
2008-10-23 23:14:23 EDT LOG: aborting any active transactions
2008-10-23 23:14:23 EDT LOG: autovacuum launcher shutting down
2008-10-23 23:14:23 EDT LOG: shutting down
2008-10-23 23:14:23 EDT LOG: database system is shut down

The next one:

2008-10-24 08:15:47 EDT LOG: database system was shut down at 2008-10-23 23:14:23 EDT
2008-10-24 08:15:48 EDT LOG: database system is ready to accept connections
2008-10-24 08:15:48 EDT LOG: autovacuum launcher started
2008-10-24 08:15:48 EDT LOG: loaded library "$libdir/plugins/plugin_debugger.dll"
2008-10-24 08:15:48 EDT FATAL: the database system is starting up
2008-10-24 08:15:49 EDT LOG: loaded library "$libdir/plugins/plugin_debugger.dll"
FATAL: could not reattach to shared memory (key=460, addr=02C10000): 487
2008-10-24 08:17:09 EDT WARNING: worker took too long to start; cancelled
2008-10-24 11:23:25 EDT WARNING: worker took too long to start; cancelled
2008-10-24 11:23:43 EDT LOG: received fast shutdown request
2008-10-24 11:23:43 EDT LOG: aborting any active transactions

The next one:

2008-10-24 11:24:56 EDT LOG: database system was interrupted; last known up at 2008-10-24 08:15:47 EDT
2008-10-24 11:24:56 EDT LOG: database system was not properly shut down; automatic recovery in progress
2008-10-24 11:24:56 EDT LOG: record with zero length at 0/491A308
2008-10-24 11:24:56 EDT LOG: redo is not required
2008-10-24 11:24:57 EDT LOG: loaded library "$libdir/plugins/plugin_debugger.dll"
2008-10-24 11:24:57 EDT FATAL: the database system is starting up
2008-10-24 11:24:57 EDT LOG: database system is ready to accept connections
2008-10-24 11:24:57 EDT LOG: autovacuum launcher started
2008-10-24 11:24:58 EDT LOG: loaded library "$libdir/plugins/plugin_debugger.dll"
FATAL: could not reattach to shared memory (key=460, addr=02C60000): 487
2008-10-24 12:32:52 EDT LOG: received fast shutdown request
2008-10-24 12:32:52 EDT LOG: aborting any active transactions

The last one:

2008-10-24 12:33:51 EDT LOG: database system was interrupted; last known up at 2008-10-24 11:24:56 EDT
2008-10-24 12:33:51 EDT LOG: database system was not properly shut down; automatic recovery in progress
2008-10-24 12:33:51 EDT LOG: loaded library "$libdir/plugins/plugin_debugger.dll"
2008-10-24 12:33:51 EDT FATAL: the database system is starting up
2008-10-24 12:33:51 EDT LOG: record with zero length at 0/491A350
2008-10-24 12:33:51 EDT LOG: redo is not required
2008-10-24 12:33:51 EDT LOG: database system is ready to accept connections
2008-10-24 12:33:51 EDT LOG: autovacuum launcher started
2008-10-24 12:33:52 EDT LOG: loaded library "$libdir/plugins/plugin_debugger.dll"


Actually, this message looked good. I loaded up PT# but the same error as in my OP is still showing.

This log came up:

2008-10-24 12:33:51 EDT LOG: database system was interrupted; last known up at 2008-10-24 11:24:56 EDT
2008-10-24 12:33:51 EDT LOG: database system was not properly shut down; automatic recovery in progress
2008-10-24 12:33:51 EDT LOG: loaded library "$libdir/plugins/plugin_debugger.dll"
2008-10-24 12:33:51 EDT FATAL: the database system is starting up
2008-10-24 12:33:51 EDT LOG: record with zero length at 0/491A350
2008-10-24 12:33:51 EDT LOG: redo is not required
2008-10-24 12:33:51 EDT LOG: database system is ready to accept connections
2008-10-24 12:33:51 EDT LOG: autovacuum launcher started
2008-10-24 12:33:52 EDT LOG: loaded library "$libdir/plugins/plugin_debugger.dll"
FATAL: could not reattach to shared memory (key=460, addr=02BD0000): 487

[kraada]

This error can occur for one of three reasons. The first is faulty hardware, and you should try setting PostgreSQL to use zero damaged pages by clicking Start --> Programs --> PostgreSQL --> Configuration Files --> Edit postgresql.conf. In the configuration file that appears, go to the bottom of the file and add the text "zero_damaged_pages = on" on a new line and then save and close the file. Click Start --> Programs --> PostgreSQL --> Reload Configuration and PostgreSQL will ignore the damaged data. If you continue to have problems with that hard drive, you should consider replacing it.

The second reason for this error may be a problem with the PostgreSQL autovacuuming daemon. Click Start --> Programs --> PostgreSQL --> Configuration Files --> Edit postgresql.conf and find the line that says "#autovacuum = on" and change it to "autovacuum = off" and save the file. Stop and restart PostgreSQL by clicking Start --> Programs --> PostgreSQL --> Stop Service, followed by Start --> Programs --> PostgreSQL --> Start Service and PostgreSQL should now be running properly.

The last reason for this error is a known issue with PostgreSQL and Windows. Unfortunately there is no known resolution for this cause at this time; however, the developers of PostgreSQL are still actively working for a solution when last I checked. But likely one of the first two solutions will fix this for you.

[dreamcaster]

I'll try the 2nd option considering that my hard drive is brand-spanking new from Dell. I'll post my results.

[dreamcaster]

I changed the 2nd option "autovacuum = off". PT3 looks to be working again (texas holdem tab shows the stats except for the correct results of my tourneys).

What exactly is the autovacuum function for?

What does this code mean anyway? FATAL: could not reattach to shared memory (key=460, addr=02DB0000): 487

And does it matter if I turn the UAC back on?

[dreamcaster]

PT3 works on and off. Everytime it errors up again the "postmaster.pid" file has returned. How do I delete that file perm?

[WhiteRider]

I guess that auto-vacuum will automatically vacuum the database. I'll see if Kraada can give you a more technical answer..

You can't delete the postmaster.pid file permanently - it is a lock file which is created when postgres starts, to prevent another instance starting.

I guess the FATAL error is to do with not being able to continue with the process it was doing before it was shut down.

I'm not sure about UAC - you can probably turn it back on, as long as you are running postgres and PT3 as Administrator.

[kraada]

The postmaster.pid file is a file that contains the process number of the running version of PostgreSQL. It will be recreated each time PostgreSQL restarts. The thing is, if it still exists when you try to restart PostgreSQL it will fail because it will check for that file and go "Oh! PostgreSQL was running, you didn't really mean to do that." Hence the deleting it before restarting PostgreSQL. PT3 should at this point try and start PostgreSQL properly so you shouldn't need to delete that file anymore, but it might be useful to know in the case of a crash.

For more detail on the autovacuum daemon, please see the the PostgreSQL documentation. Basically, when some conditions are achieved, it automatically vacuums and analyzes. This is useful in general if you can leave it running (then you don't really need the vacuum/analyze part of the Housekeeping . . . but it doesn't really take a lot of time so it's not a big deal either way).

The original error message has to do with the way PostgreSQL works. I'll admit I'm not 100% clear on the technical details, but the way I understand it, PostgreSQL stores a bunch of data in different files in a particularly efficient manner, and a bunch of the current data in use is stuck in RAM. Sometimes, because of the way the NTFS filesystem works (this stuff seems to happen a lot more on Windows from what my research indicated, anyway) there can be a conflict between the info in RAM, the info in the file, and the filesystem not being happy about the way it's all being passed back and forth. Then PostgreSQL craps out. Sometimes setting PostgreSQL to ignore some damaged data fixes it, sometimes the autovacuum process was causing the trouble. The third reason was a lot more complicated and had to do with the NTFS filesystem and I think that was on the list of things to get fixed in 8.3.4, but I haven't checked back recently, I do know it still existed in 8.3.3 and I haven't followed up on the PostgreSQL message boards since then.

I hope that wasn't too confusing or was semi-useful :)