Thread: postgresql-8.3.7 unexpected connection closures
I posted this a while back but got no useful responses. I have the following error message: "Error connecting to the server: server closed the connection unexpectedly. This probably means that the server terminated abnormally before or while processing the request." It happens intermittently both when using pgAdminIII and when using QT so it is not a pgAdminIII issue. Often the connection seems to succeed but you get a series of error messages like the one above when attempting to open a database. It seems to be a timing issue. This is happening when using a local connection on vista, irrespective of whether the antivirus is on or off. I can't see anything to change in postgresql.conf that could alleviate this problem. This does not happen with postgresql-8.3.5 but does happen with postgresql-8.3.7. This is happening on two different machines (both Vista SP2) running different antivirus programs so I suspect there has been some change to postgres that has triggered this problem. Postgres has become unuseable on these machines. Thanks for may help Andrew -- ___________________________________________ Andrew J. P. Maclean Centre for Autonomous Systems The Rose Street Building J04 The University of Sydney 2006 NSW AUSTRALIA Ph: +61 2 9351 3283 Fax: +61 2 9351 7474 URL: http://www.acfr.usyd.edu.au/ ___________________________________________
On Fri, 2009-06-19 at 09:12 +1000, Andrew Maclean wrote: > I posted this a while back but got no useful responses. > > I have the following error message: > > "Error connecting to the server: server closed the connection unexpectedly. > This probably means that the server terminated abnormally before or > while processing the request." Look at the PostgreSQL server log to see what happened. On Windows, I think this is in your PostgreSQL data directory. (List members: This seems to confuse Windows admins a lot - they're not used to application log files, apparently. Is it worth having the win32 version of the server report sudden backend death via the Windows event logging system, with a reference to the Pg log file? I'm not sure, since it's not clear that most Windows admins look at Event Viewer either...) -- Craig Ringer
Thanks for the quick response, the log shows the following: 2009-06-19 07:51:47 EST LOG: database system was interrupted; last known up at 2009-06-18 19:14:37 EST 2009-06-19 07:51:47 EST LOG: database system was not properly shut down; automatic recovery in progress 2009-06-19 07:51:47 EST LOG: record with zero length at 0/6614E8 2009-06-19 07:51:47 EST LOG: redo is not required 2009-06-19 07:51:47 EST LOG: database system is ready to accept connections 2009-06-19 07:51:47 EST LOG: autovacuum launcher started 2009-06-19 07:54:51 EST LOG: loaded library "$libdir/plugins/plugin_debugger.dll" 2009-06-19 07:54:51 EST LOG: loaded library "$libdir/plugins/plugin_debugger.dll" 2009-06-19 07:54:51 EST LOG: could not receive data from client: Unknown winsock error 10061 2009-06-19 07:54:52 EST LOG: loaded library "$libdir/plugins/plugin_debugger.dll" FATAL: could not reattach to shared memory (key=252, addr=02080000): 487 FATAL: could not reattach to shared memory (key=252, addr=02080000): 487 FATAL: could not reattach to shared memory (key=252, addr=02080000): 487 FATAL: could not reattach to shared memory (key=252, addr=02080000): 487 FATAL: could not reattach to shared memory (key=252, addr=02080000): 487 FATAL: could not reattach to shared memory (key=252, addr=02080000): 487 FATAL: could not reattach to shared memory (key=252, addr=02080000): 487 FATAL: could not reattach to shared memory (key=252, addr=02080000): 487 FATAL: could not reattach to shared memory (key=252, addr=02080000): 487 FATAL: could not reattach to shared memory (key=252, addr=02080000): 487 FATAL: could not reattach to shared memory (key=252, addr=02080000): 487 2009-06-19 10:47:35 EST LOG: loaded library "$libdir/plugins/plugin_debugger.dll" FATAL: could not reattach to shared memory (key=252, addr=02080000): 487 FATAL: could not reattach to shared memory (key=252, addr=02080000): 487 FATAL: could not reattach to shared memory (key=252, addr=02080000): 487 2009-06-19 10:49:04 EST WARNING: worker took too long to start; cancelled FATAL: could not reattach to shared memory (key=252, addr=02080000): 487 On Fri, Jun 19, 2009 at 10:40 AM, Craig Ringer<craig@postnewspapers.com.au> wrote: > On Fri, 2009-06-19 at 09:12 +1000, Andrew Maclean wrote: >> I posted this a while back but got no useful responses. >> >> I have the following error message: >> >> "Error connecting to the server: server closed the connection unexpectedly. >> This probably means that the server terminated abnormally before or >> while processing the request." > > Look at the PostgreSQL server log to see what happened. On Windows, I > think this is in your PostgreSQL data directory. > > (List members: This seems to confuse Windows admins a lot - they're not > used to application log files, apparently. Is it worth having the win32 > version of the server report sudden backend death via the Windows event > logging system, with a reference to the Pg log file? I'm not sure, since > it's not clear that most Windows admins look at Event Viewer either...) > > -- > Craig Ringer > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general > -- ___________________________________________ Andrew J. P. Maclean Centre for Autonomous Systems The Rose Street Building J04 The University of Sydney 2006 NSW AUSTRALIA Ph: +61 2 9351 3283 Fax: +61 2 9351 7474 URL: http://www.acfr.usyd.edu.au/ ___________________________________________
On Fri, 2009-06-19 at 10:50 +1000, Andrew Maclean wrote: > 2009-06-19 07:54:51 EST LOG: could not receive data from client: > Unknown winsock error 10061 Winsock error 10061 is WSAECONNREFUSED (10061) Connection Refused. I presume that means the client has sent an RST packet, but ... wtf? Why? Is the client on the same machine as the server? If not, is the client running any sort of software firewall? You say the two machines have two different AV products, but you don't mention which ones. What products are they, and what versions of those products? I strongly suspect firewall / antivirus involvement. Can you _uninstall_ your AV/firewall on one of the Pg server machines, reboot it, and re-test? Do not just disable it, completely uninstall it, just for testing purposes. > FATAL: could not reattach to shared memory (key=252, addr=02080000): 487 I've seen discussion of this one before, but never any sort of resolution. http://www.google.com.au/search?hl=en&q=%22could+not+reattach+to+shared +memory%22+%22[hackers]%22 Apparently it arises more often in the presence of antivirus software and the like, but isn't known to be directly caused by it. Maybe somone else can shed some more light on this one. -- Craig Ringer
One is running McAfee and the other is running Symantec Endpoint. It does not matter whether the firewalls are on or off. One thing I have noticed it that if I stop and restart the service everything seems to work Ok. Andrew On Fri, Jun 19, 2009 at 11:18 AM, Craig Ringer<craig@postnewspapers.com.au> wrote: > On Fri, 2009-06-19 at 10:50 +1000, Andrew Maclean wrote: > >> 2009-06-19 07:54:51 EST LOG: could not receive data from client: >> Unknown winsock error 10061 > > Winsock error 10061 is WSAECONNREFUSED (10061) Connection Refused. I > presume that means the client has sent an RST packet, but ... wtf? Why? > > Is the client on the same machine as the server? If not, is the client > running any sort of software firewall? > > You say the two machines have two different AV products, but you don't > mention which ones. What products are they, and what versions of those > products? > > I strongly suspect firewall / antivirus involvement. Can you _uninstall_ > your AV/firewall on one of the Pg server machines, reboot it, and > re-test? Do not just disable it, completely uninstall it, just for > testing purposes. > >> FATAL: could not reattach to shared memory (key=252, addr=02080000): 487 > > I've seen discussion of this one before, but never any sort of > resolution. > > http://www.google.com.au/search?hl=en&q=%22could+not+reattach+to+shared > +memory%22+%22[hackers]%22 > > Apparently it arises more often in the presence of antivirus software > and the like, but isn't known to be directly caused by it. Maybe somone > else can shed some more light on this one. > > -- > Craig Ringer > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general > -- ___________________________________________ Andrew J. P. Maclean Centre for Autonomous Systems The Rose Street Building J04 The University of Sydney 2006 NSW AUSTRALIA Ph: +61 2 9351 3283 Fax: +61 2 9351 7474 URL: http://www.acfr.usyd.edu.au/ ___________________________________________
On Fri, 2009-06-19 at 11:30 +1000, Andrew Maclean wrote: > One is running McAfee and the other is running Symantec Endpoint. It > does not matter whether the firewalls are on or off. I increasingly wonder if Symantec or McAfee can be persuaded to offer a buildfarm machine with their software to PostgreSQL. Virus scanners on servers are an (IMO nearly insane) fact of life on Windows, apparently, and certainly on Windows desktops that may also run PostgreSQL, so it needs to get along with them. I'm far from certain that your issues are AV related, but if you want to track them down the first thing to do is UNINSTALL one of your AV products and see if the issues go away. Reinstall it once you know; the point is to test whether the AV is part of the problem or not. -- Craig Ringer
Craig Ringer <craig@postnewspapers.com.au> writes:
> I increasingly wonder if Symantec or McAfee can be persuaded to offer a
> buildfarm machine with their software to PostgreSQL. Virus scanners on
> servers are an (IMO nearly insane) fact of life on Windows, apparently,
> and certainly on Windows desktops that may also run PostgreSQL, so it
> needs to get along with them.
There's always the "friends don't let friends run servers on Windows"
approach.
regards, tom lane
On Fri, 2009-06-19 at 01:03 -0400, Tom Lane wrote: > Craig Ringer <craig@postnewspapers.com.au> writes: > > I increasingly wonder if Symantec or McAfee can be persuaded to offer a > > buildfarm machine with their software to PostgreSQL. Virus scanners on > > servers are an (IMO nearly insane) fact of life on Windows, apparently, > > and certainly on Windows desktops that may also run PostgreSQL, so it > > needs to get along with them. > > There's always the "friends don't let friends run servers on Windows" > approach. ... a sentiment I can't really argue with most of the time. Alas, people are sometimes forced into it by braindead corporate policy, central IT management, and the like. It'd be nice if Pg could play well with at least the less horrifyingly broken virus scanners out there, at least when excluded from scanning. Mostly this seems to mean dealing with DLLs being injected into the process address space. Sometimes people also run Pg on home/work desktops, whether for development or just for small databases. It'd be nice if this use worked well in the face of a frankly rather hostile host (virus scanners, firewalls, etc). Of course, I've done enough development on Windows to know just how much I dislike it, so I'm hardly leaping to the task... I see lots of questions here that seem to be related to (a) virus scanner interference and (b) installation/reinstallation. Lots of the reinstall issues seem to be with people who don't really understand NT users, ACLs, etc and aren't really competent to admin a machine, but they do make me wonder if the Pg installer can do more to help them out, eg: "The data directory you have specified (C:\PgData) already exists, but cannot be accessed by the user you want to run PostgreSQL as. Would you like to: [a] use a new data directory, [b] grant the postgresql user the rights to access the data directory you have specified, or [c] change the user you start PostgreSQL as to the user owning the data directory ? [clean install to new directory][grant access to old directory][change postgresql user][cancel installation]" "The data directory you have specified (C:\PgData) contains a database from an older version of PostgreSQL (8.2) that this version (8.3.6) cannot access. Would you like to use a new data directory C:\PgData-8.3, leaving the old one untouched? Note that PostgreSQL will not automatically convert your data. You REALLY should read the upgrading documentation before continuing. [clean install to new data directory][cancel installation]" "PostgreSQL has detected that another program, probably an older version of PostgreSQL, is listening on port 5432. If you want to use this version on the default port 5432, you will need to stop or uninstall the other program first. [Change PostgreSQL port][Cancel installation]" Of course, if Windows development is un-fun, windows program installation and installer building is more so. -- Craig Ringer
I would NEVER run a production server in windows!
These are just laptops/workstations that are used for development e.g, when
network connections are not available or when travelling. But these things
still shouldn't occur. I will also try the beta release on these machines to
see if it goes away.
Andrew
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Friday, 19 June 2009 15:03
To: Craig Ringer
Cc: a.maclean@cas.edu.au; General
Subject: Re: [GENERAL] postgresql-8.3.7 unexpected connection closures
Craig Ringer <craig@postnewspapers.com.au> writes:
> I increasingly wonder if Symantec or McAfee can be persuaded to offer a
> buildfarm machine with their software to PostgreSQL. Virus scanners on
> servers are an (IMO nearly insane) fact of life on Windows, apparently,
> and certainly on Windows desktops that may also run PostgreSQL, so it
> needs to get along with them.
There's always the "friends don't let friends run servers on Windows"
approach.
regards, tom lane
On Friday 19. June 2009, Andrew Maclean wrote: >I would NEVER run a production server in windows! > >These are just laptops/workstations that are used for development e.g, > when network connections are not available or when travelling. Both my workstation and laptop have run Linux since 2003, and work great. Who needs Windows? -- Leif Biberg Kristensen | Registered Linux User #338009 Me And My Database: http://solumslekt.org/blog/
2009/6/19 Leif B. Kristensen <leif@solumslekt.org>: > On Friday 19. June 2009, Andrew Maclean wrote: >>I would NEVER run a production server in windows! >> >>These are just laptops/workstations that are used for development e.g, >> when network connections are not available or when travelling. > > Both my workstation and laptop have run Linux since 2003, and work > great. Who needs Windows? nobody needs Windows. But Postgres has only one reputation. Problems on windows are PostgreSQL's problem too. And there are some native windows firms that starts develop with Postgres. And this people expecting stability. So if we support some, we have to do it well. regards Pavel Stehule > -- > Leif Biberg Kristensen | Registered Linux User #338009 > Me And My Database: http://solumslekt.org/blog/ > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general >
On Thu, Jun 18, 2009 at 7:30 PM, Andrew Maclean<andrew.amaclean@gmail.com> wrote: > One is running McAfee and the other is running Symantec Endpoint. It > does not matter whether the firewalls are on or off. Note that many packages for windows that do networking and virus scanning installed "wedge" dlls that are always part of the code path of the OS whether the firewall / antivirus are active or not. Uninstalling is the only way to KNOW they aren't affecting your computer.
Craig Ringer wrote: <blockquote cite="mid:1245389967.16434.37.camel@wallace.localnet" type="cite"> On Fri, 2009-06-19 at 01:03 -0400, Tom Lane wrote: I see lots of questions here that seem to be related to (a) virus scanner interference and (b) installation/reinstallation. Lots of the reinstall issues seem to be with people who don't really understand NT users, ACLs, etc and aren't really competent to admin a machine, but they do make me wonder if the Pg installer can do more to help them out, eg: I'm hesitant to agree with this the PG installer doing more automatically. If the user does not understand security and proper configuration to get it to work on windows client, the server setup will be poorly configured with security problems that a MAC truck can drive through. Example is MS itself and CAD developers. I have yet to see a CAD program that does not require to run with Administrator security credentials. MS with many of its Server Programs does similar stuff now that PG does automatically creates users sets up the directory/registry security. Its really easy to trash those setting keeping the app from working. You hear about the same problems many people talk about hear as they do with the other databases running on windows see http://support.microsoft.com/kb/309422 http://support.microsoft.com/kb/287932 http://msdn.microsoft.com/en-us/library/ms175043.aspx The only thing i think that would make sense, is to have the installer add exceptions to the windows firewall for the Postgresql ports. <blockquote cite="mid:1245389967.16434.37.camel@wallace.localnet" type="cite"> "The data directory you have specified (C:\PgData) already exists, but cannot be accessed by the user you want to run PostgreSQL as. Would you like to: [a] use a new data directory, [b] grant the postgresql user the rights to access the data directory you have specified, or [c] change the user you start PostgreSQL as to the user owning the data directory ? [clean install to new directory][grant access to old directory][change postgresql user][cancel installation]" This is the same problem MSSQL has on reinstall except it just creates new directories and Security Credentials automatically. I have seen computers with 5 SQLServer user accounts. along with lots of other crap laying around PG install does lots of the stuff for the user but does not do everything as many installers do which can leave the OS install a complete and utter mess requiring reformat and reinstall to get it to work at all. Or leaves that applications install such tangle mess its impossible to figure out what the user did. I can read it know "Postgresql gurus i go to the PGDATA directory and find it has PGDATA though PGDATA_8 how do i tell which is the current data directory." I have suffered this question with MsSQL. All that is accomplish is changing the question asked. <blockquote cite="mid:1245389967.16434.37.camel@wallace.localnet" type="cite"> "The data directory you have specified (C:\PgData) contains a database from an older version of PostgreSQL (8.2) that this version (8.3.6) cannot access. Would you like to use a new data directory C:\PgData-8.3, leaving the old one untouched? Note that PostgreSQL will not automatically convert your data. You REALLY should read the upgrading documentation before continuing. [clean install to new data directory][cancel installation]" "PostgreSQL has detected that another program, probably an older version of PostgreSQL, is listening on port 5432. If you want to use this version on the default port 5432, you will need to stop or uninstall the other program first. [Change PostgreSQL port][Cancel installation]" I agree more verbose install messages on errors and warnings would be nice. <blockquote cite="mid:1245389967.16434.37.camel@wallace.localnet" type="cite"> Of course, if Windows development is un-fun, windows program installation and installer building is more so. That is very true <blockquote cite="mid:1245389967.16434.37.camel@wallace.localnet" type="cite"> -- Craig Ringer
Pavel Stehule wrote: <blockquote cite="mid:162867790906190935g1194dacdkc52b7216defa5a58@mail.gmail.com" type="cite"><prewrap="">2009/6/19 Leif B. Kristensen <a class="moz-txt-link-rfc2396E" href="mailto:leif@solumslekt.org"><leif@solumslekt.org></a>:</pre> <pre wrap=""> nobody needs Windows. But Postgres has only one reputation. Problems on windows are PostgreSQL's problem too. And there are some native windows firms that starts develop with Postgres. And this people expecting stability. So if we support some, we have to do it well. regards Pavel Stehul</pre></blockquote> i've been running Postgresql on windows for a few years now and did not suffer these problems. I have dealt with these problems running MsSQL 7 and 2000. <br /><br /> If any software is having a specificproblem with windows I guarantee the MS offering is having the same problem. Just replace X application with the MS offering you will have possible list of solutions. <br />
On Fri, 2009-06-19 at 10:49 -0600, Scott Marlowe wrote:
> On Thu, Jun 18, 2009 at 7:30 PM, Andrew
> Maclean<andrew.amaclean@gmail.com> wrote:
> > One is running McAfee and the other is running Symantec Endpoint. It
> > does not matter whether the firewalls are on or off.
>
> Note that many packages for windows that do networking and virus
> scanning installed "wedge" dlls that are always part of the code path
> of the OS whether the firewall / antivirus are active or not.
> Uninstalling is the only way to KNOW they aren't affecting your
> computer.
... assuming the uninstaller was competently written.
*ahem*logitechwebcam*ahem* . Sysinternals Process Explorer and regedit
for actually letting me find and remove that stunning piece of garbage
and its scarily buggy and badly designed hook/wedge DLL. (My webcam
driver broke Pg, gcc, and several other things.)
These days most virus scanners and software firewalls seem to be OK, but
a few years ago I used to have to manually remove leftover bits of
ZoneAlarm in particular from users' machines then reset their IP stack
("net interface ipv4 reset c:\resetlog.txt") to get their networking
going again.
It's still beyond me why anyone installs a software firewall on modern
Windows. The built-in firewall is _perfectly_ reliable and eminently
sufficient. It just works, and stays out of the way. Why replace it with
something that's inevitably buggy, less than perfectly integrated, and
too busy proclaiming to the user "I'm doing something, I'm doing
something".
--
Craig Ringer
> > > I'm hesitant to agree with this the PG installer doing more > automatically. If the user does not understand security and proper > configuration to get it to work on windows client, the server setup > will be poorly configured with security problems that a MAC truck can > drive through. [snip] > The only thing i think that would make sense, is to have the installer > add exceptions to the windows firewall for thePostgresql ports. You have a good point. > I can read it know "Postgresql gurus i go to the PGDATA directory and > find it has PGDATA though PGDATA_8 how do i tell which is the current > data directory." I have suffered this question with MsSQL. All > that is accomplish is changing the question asked. Yuck. Very good point, actually. I guess sometimes there's no good substitute for having a clue. Additionally, the more I think about it the more I realise the installer isn't the right place to tackle some of the issues that _do_ come up. Windows users seem to be very confused by a service failing to start and don't seem to know that the OS records information in the event log or that Pg has its own logs. It'd be nice if the event log messagess contained a note telling the user where the Pg logs were, and if Pg could use the messaging service to notify the user of issues like bad data dir permissions ... but that won't help if the user doesn't know to look in the event log. Of course, if you try to start a service and it fails, the generic error message from Windows tells you to look in the event log for more information. This may be a case of people who don't _want_ to look into it and don't want to think about it. -- Craig Ringer
[snipity snip snip] Notwithstanding all the previous discussion. I still think there is a problem with postgresql on windows. Messages in the log are consistently of the form: 2009-06-23 08:28:26 EST WARNING: worker took too long to start; cancelled FATAL: could not reattach to shared memory (key=252, addr=023F0000): 487 2009-06-23 08:35:58 EST WARNING: worker took too long to start; cancelled FATAL: could not reattach to shared memory (key=252, addr=023F0000): 487 Postgres is actually usable if I restart the service after the machine has booted up. This fixes the problem triggering the error message: "Error connecting to the server: server closed the connection unexpectedly. This probably means that the server terminated abnormally before or while processing the request." However the above messages are still appearing. Personally I have no issues with the installation process. Although I am the first to admit that sometimes I forget to check the log file and the event files. I get used to Linux. Regards Andrew -- ___________________________________________ Andrew J. P. Maclean Centre for Autonomous Systems The Rose Street Building J04 The University of Sydney 2006 NSW AUSTRALIA Ph: +61 2 9351 3283 Fax: +61 2 9351 7474 URL: http://www.acfr.usyd.edu.au/ ___________________________________________
On Tue, 2009-06-23 at 09:28 +1000, Andrew Maclean wrote: > [snipity snip snip] > > Notwithstanding all the previous discussion. I still think there is a > problem with postgresql on windows. I agree, but you don't seem to be prepared take any steps to diagnose what Pg might be interacting with to cause the problem. This doesn't happen on all Windows installs. What makes yours different? If we remove things that make it different from the default, does the problem go away? If so, after what component was removed did the problem go away? If you won't help test by removing your AV software and checking if the problem goes away, nobody can really help you since you're not willing to go through any sort of fault isolation / diagnostic process. Nobody here can wave a magic wand and make the problem go away; it's going to take work on your side to help collect information that might help identify the cause and lead to a fix. -- Craig Ringer
Andrew Maclean <andrew.amaclean@gmail.com> writes:
> Messages in the log are consistently of the form:
> 2009-06-23 08:28:26 EST WARNING: worker took too long to start; cancelled
> FATAL: could not reattach to shared memory (key=252, addr=023F0000): 487
> 2009-06-23 08:35:58 EST WARNING: worker took too long to start; cancelled
> FATAL: could not reattach to shared memory (key=252, addr=023F0000): 487
I suspect the causality is actually the other way around from what you
imply here: an autovac worker process fails to start (generating the
FATAL ... 487 message) and after awhile the autovac launcher figures out
that the worker died and issues the WARNING. It might be hard to tell
that since the launcher would probably try to launch another worker
immediately after realizing the previous one died. Looking at the
startup sequence to see which one appears first would be useful.
The "reattach to shared memory" problem is known, what we don't know is
exactly what causes it or how to fix it. As noted, we need some people
who can reproduce the problem consistently (none of the developers can)
to poke into it and find out what aspect of their systems causes it.
regards, tom lane
Thanks for this. I can't take the machines out of service at present, but when I can, I'll look into shutting down services and seeing what happens. Andrew On Tue, Jun 23, 2009 at 11:49 AM, Tom Lane<tgl@sss.pgh.pa.us> wrote: > Andrew Maclean <andrew.amaclean@gmail.com> writes: >> Messages in the log are consistently of the form: >> 2009-06-23 08:28:26 EST WARNING: worker took too long to start; cancelled >> FATAL: could not reattach to shared memory (key=252, addr=023F0000): 487 >> 2009-06-23 08:35:58 EST WARNING: worker took too long to start; cancelled >> FATAL: could not reattach to shared memory (key=252, addr=023F0000): 487 > > I suspect the causality is actually the other way around from what you > imply here: an autovac worker process fails to start (generating the > FATAL ... 487 message) and after awhile the autovac launcher figures out > that the worker died and issues the WARNING. It might be hard to tell > that since the launcher would probably try to launch another worker > immediately after realizing the previous one died. Looking at the > startup sequence to see which one appears first would be useful. > > The "reattach to shared memory" problem is known, what we don't know is > exactly what causes it or how to fix it. As noted, we need some people > who can reproduce the problem consistently (none of the developers can) > to poke into it and find out what aspect of their systems causes it. > > regards, tom lane > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general > -- ___________________________________________ Andrew J. P. Maclean Centre for Autonomous Systems The Rose Street Building J04 The University of Sydney 2006 NSW AUSTRALIA Ph: +61 2 9351 3283 Fax: +61 2 9351 7474 URL: http://www.acfr.usyd.edu.au/ ___________________________________________