> > > > o fix shared memory on Win2k terminal server
> > > >
> > > > We might be able to just mark this as not supported.
> The shmem code works in a terminal server session with or
> without the patch.
> Magnus had a different problem, probably permissions. Since I
> do not have a non admin user (on a TS server) I disabled the
> win32_is_admin check.
Ok. That explains why it didn't work for me - it wasn't intended to
solve the problem I was looking at.
> It is my opinion that we should allow pg to run as Admin on
> Windows, at least with an override option. Services that run
> under a specified user are a headache on Win32, because you
> need to store a password, and a lot of systems only have one user.
That is a different issue alltogether. But really - install from the
installer and it will handle these things for you. And keeping one extra
password in your safe storage is not going to make much difference...
But again, different issue.
> > > I have attached a patch that I think fixes this. The
> problem I saw
> > > and fixed is, that the shmem created in a terminal
> services client
> > > is not visible to the console (or services.msc).
> The decision is simple. If we want the shmem to be global on
> the machine we need the patch. I think we want that, but can
> not give an authoritative answer.
Right. Looking at the patch from that POV, it certainly seems
reasonable. The issue otherwise is that one pg installation running in a
TS session could conflict with one running as a service, for example.
(The postmaster-already-up-detection breaks)
(This only applies to commandline-started things, services *always* use
the global namespace by default)
Just one question about the actual implementation of the patch - why are
you setting the OS version *before* you call GetVersionEx()? It'll just
> > > I think in addition the system global name "sharemem.1" should be
> > > made more pg specific, like "PostgreSQL.1". I have not done this
> > > since a new compile would not detect a running old beta.
> But now would be the time (or never).
> I think all agreed that this is good.
Yes. Definitly. For stuff in the global namespace it's definitly
preferred if you can relate to which app/server it belongs.
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend