Re: [PATCHES] [HACKERS] Open Items
I am going to discard these emails. We haven't solve the Win32 terminal server problem and I think it needs to be moved to the TODO list instead. --- Zeugswetter Andreas DAZ SD wrote: o fix shared memory on Win2k terminal server We might be able to just mark this as not supported. 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). It was necessary to differenciate OS versions, this might be better put elsewhere. 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). Andreas Content-Description: shmem.win32.patch [ Attachment, skipping... ] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [HACKERS] Open Items
I am going to discard these emails. We haven't solve the Win32 terminal server problem and I think it needs to be moved to the TODO list instead. Yes, please do that. I do not think there is a problem on TS other than some missing permissions. The patch was only intended to avoid starting 2 postmasters for the same datadir. The patch is not 100% since I was told that my check would fail on Win95 and falsely assume Win95 allows a \ in the shmem name. I think that would currently not matter, but it is unclean for the future. Andreas ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [HACKERS] Open Items
It makes no difference on any of my systems, so at least it doesn't completely solve the problem. I haven't heard any confirmation on wether it partially solves it. It certainly does not solve any part of your problem. I think your problem is a permissions problem. It does however make sure the shmem is global, which I think we need for detecting certain parallel startup (still running backend) situations. Andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] [HACKERS] Open Items
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. 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. 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. 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. Andreas ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] [HACKERS] Open Items
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. Well I don't know that I agree with this. Probably the biggest problem with Windows is not Windows, it is lazy admins. You either want to do it right, or you don't. Most Windows admins just want it to work as quickly as possible, throwing caution and and common sense to the wind. And no, I am not a Windows hater, I am just someone who used to make a lot of money fixing the mistakes of all those lazy admins. Sincerely, Joshua D. Drake 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. 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. Andreas ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL begin:vcard fn:Joshua Drake n:Drake;Joshua org:Command Prompt, Inc. adr:;;PO Box 215 ;Cascade Locks;OR;97014;US email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0334 x-mozilla-html:FALSE url:http://www.commandprompt.com version:2.1 end:vcard ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] Open Items
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 get overwritten... 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. //Magnus ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] [HACKERS] Open Items
Just one question about the actual implementation of the patch - why are you setting the OS version *before* you call GetVersionEx()? The Microsoft Example did a memset on the structure before calling void GetVersionEx(). Setting it to a version that needs the Global\ is only a safeguard against a failing call. I guess the call cannot fail, and thus setting it before is not really needed. It'll just get overwritten... Yes, if the void call does not fail to work. Andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] [HACKERS] Open Items
Just one question about the actual implementation of the patch - why are you setting the OS version *before* you call GetVersionEx()? The Microsoft Example did a memset on the structure before calling void GetVersionEx(). The docs only say you have tos et the dwOSVersionInfoSize member before you call it, no need to memset. Setting it to a version that needs the Global\ is only a safeguard against a failing call. I guess the call cannot fail, and thus setting it before is not really needed. The call will return FALSE when it fails, and this should probably be checked - missed that. It is *not* a void function, it is a BOOL function. It can fail. For example, if you pass it a size that is not supported by the OS you are on (say a OSVERSIONINFOEX structure on a pre-sp6 NT4). I don't think it can fail for other reasons than that, but I'm not sure. It should probably be checked.. (See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo /base/getversionex.asp) //Magnus ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] [HACKERS] Open Items
It makes no difference on any of my systems, so at least it doesn't completely solve the problem. I haven't heard any confirmation on wether it partially solves it. //Magnus -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Where are we on this patch? --- Zeugswetter Andreas DAZ SD wrote: o fix shared memory on Win2k terminal server We might be able to just mark this as not supported. 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). It was necessary to differenciate OS versions, this might be better put elsewhere. 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). Andreas Content-Description: shmem.win32.patch [ Attachment, skipping... ] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] Open Items
Where are we on this patch? --- Zeugswetter Andreas DAZ SD wrote: o fix shared memory on Win2k terminal server We might be able to just mark this as not supported. 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). It was necessary to differenciate OS versions, this might be better put elsewhere. 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). Andreas Content-Description: shmem.win32.patch [ Attachment, skipping... ] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] [HACKERS] Open Items
o fix shared memory on Win2k terminal server We might be able to just mark this as not supported. 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). Does this actually fix the problem for you? Because, as I have previously posted I think, it does *not* solve the problem on any of my test machines. I still get the shmget() error message when running from a TS session. I think you are having another problem. I can create it here (with or without the patch). I am running W2000 5.00.2195 SP4. Maybe you are having a permissions problem? I am using a user with near Administrator privs. Also, I don't really see how the visibility of the shmem segment matters. If it really does not matter, please don't apply my patch Bruce. (still do the rename though please) We can't *create* the first instance of it, which should not affect this at all. And if we passed that, all backends are still execute in the same session, so there is no effect on it. Yes it only matters if postmaster is started/trying to start from different TS Sessions. I think we need to determine global existance of the shm segment to get rid of old processes/segments. services.msc only interacts with the SCM, it has nothing at all to do with shmem. I meant if run as a service, which is the same TS session as the console. Andreas ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] Open Items
Agreed on the memory name change and I will do it when I apply the patch. Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- Zeugswetter Andreas DAZ SD wrote: o fix shared memory on Win2k terminal server We might be able to just mark this as not supported. 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). It was necessary to differenciate OS versions, this might be better put elsewhere. 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). Andreas Content-Description: shmem.win32.patch [ Attachment, skipping... ] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] [HACKERS] Open Items
o fix shared memory on Win2k terminal server We might be able to just mark this as not supported. 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). Does this actually fix the problem for you? Because, as I have previously posted I think, it does *not* solve the problem on any of my test machines. I still get the shmget() error message when running from a TS session. (Yes, I tried specifically with your patch, since I thought maybe I got something wrong before) I'm on Windows 2000 Server, tested both DC and non-DC machines. What are you testing on? Also, I don't really see how the visibility of the shmem segment matters. We can't *create* the first instance of it, which should not affect this at all. And if we passed that, all backends are still execute in the same session, so there is no effect on it. services.msc only interacts with the SCM, it has nothing at all to do with shmem. //Magnus ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
