Re: [PATCHES] Run-as-admin warning for win32
Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Why? If we refuse to run as root on Unix, I do not see an argument for >> being more forgiving on Windows. > I am not sure it is as easy to run as non-admin on Win32 as it is to run > as non-root on Unix. Is it? Ease of use has nothing to do with this. Given the demonstrated security weaknesses of Windows, we would be completely irresponsible to allow Postgres to be started in an obviously-insecure way on that platform. In other words, I do not wish to be the author of code that could become the vector for the next SQL Slammer worm. I am already deathly afraid of what the Windows port is likely to do to Postgres' reputation for reliability and security. Do *not* get me started by proposing that we insert obvious security holes on lame "ease of use" grounds. Haven't the boys in Redmond already proven the wrongness of those priorities many times over? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] ceiling() and power() (SQL2003)
Doesn't your patch cause problems with the PostgreSQL ODBC driver which adds ... Well, the odbc driver will be able to drop those functions. Also, Neil's functions will appear in pg_catalog while the odbc ones will be in public, so there won't be a conflict as such. Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Run-as-admin warning for win32
Tom Lane wrote: > "Magnus Hagander" <[EMAIL PROTECTED]> writes: > > Previously, postgresql has exited out on Unix when running as root - > > this is a similar check, with the following differences: > > > * We do a ereport(WARNING) instead of exitting out. > > Why? If we refuse to run as root on Unix, I do not see an argument for > being more forgiving on Windows. I am not sure it is as easy to run as non-admin on Win32 as it is to run as non-root on Unix. Is it? -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] ceiling() and power() (SQL2003)
Neil, Doesn't your patch cause problems with the PostgreSQL ODBC driver which adds ... -- CEILING(num) CREATE OR REPLACE FUNCTION ceiling(numeric) RETURNS numeric AS ' SELECT ceil($1); ' LANGUAGE SQL; -- POWER(num, num) CREATE OR REPLACE FUNCTION power(double precision, double precision) RETURNS double precision AS ' SELECT pow($1, $2); ' LANGUAGE SQL; CREATE OR REPLACE FUNCTION power(numeric, numeric) RETURNS numeric AS ' SELECT pow($1, $2); ' LANGUAGE SQL; On first glance this seems to be same ... Regards, Hans Neil Conway wrote: This patch makes the following changes: (1) Add ceiling() as an alias for ceil() (both double precision and numeric variants). This is required by SQL2003, so both spellings of the function name have been documented. (2) Add power() as an alias for pow(). SQL2003 only defines power() AFAICS. Rather than documenting two identical spellings of the same command, I think it makes sense to migrate toward the spelling that is preferred by the standard. Therefore, I renamed the documentation for pow() to refer to power(). I didn't remove pow(): that would break far too much existing code, and there is little harm in keeping around an additional pg_proc entry or two. I think that keeping pow() but not documenting it should ensure that new users prefer power() but older applications do not need to be changed, which is a reasonable compromise between backward compatibility and forward progress. Regression tests are included (I believe I updated all the variants of float8 properly, but please speak up if that is not the case). This patch bumps the catalog version number. Barring any objections, I intend to apply this within 24 hours. -Neil ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Cybertec Geschwinde u Schoenig Schoengrabern 134, A-2020 Hollabrunn, Austria Tel: +43/2952/30706 or +43/664/233 90 75 www.cybertec.at, www.postgresql.at, kernel.cybertec.at ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Run-as-admin warning for win32
"Magnus Hagander" <[EMAIL PROTECTED]> writes: > Previously, postgresql has exited out on Unix when running as root - > this is a similar check, with the following differences: > * We do a ereport(WARNING) instead of exitting out. Why? If we refuse to run as root on Unix, I do not see an argument for being more forgiving on Windows. > The reason for this > is that we can expect there are win32 admins that will want to run the > server with a high privilege account. Translated: "we can expect a higher proportion of Windows admins who will refuse to be force-fed a clue"? Not a lot of sympathy here. > * The Unix check is directly in main.c. We cannot do this on win32, > because at this stage we can only printf and exit. Win32 needs ereport. We could move the Unix check later without any problem. I agree with keeping both checks in the same place. regards, tom lane ---(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] smgr cleanup
Alvaro Herrera <[EMAIL PROTECTED]> writes: > This patch removes a couple of no-ops. I object to this change. The fact that these modules don't currently need to do anything at commit/abort doesn't mean that they never again will need to. In particular I do not like putting in a blanket assumption that no smgr module will ever need control at these points. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] Run-as-admin warning for win32
For review, comments and possible application to HEAD. This code implements a warning when the postmaster is started as a high-privilege account on win32 (administrator or power users). Previously, postgresql has exited out on Unix when running as root - this is a similar check, with the following differences: * We do a ereport(WARNING) instead of exitting out. The reason for this is that we can expect there are win32 admins that will want to run the server with a high privilege account. Just sending a warning will permit this (say, when debugging etc, or if people are just too lazy to care), while clearly stating it's not a recommended way to do it. * The Unix check is directly in main.c. We cannot do this on win32, because at this stage we can only printf and exit. Win32 needs ereport. Consider when runinng as a service - before we have loaded up postgresql.conf and noticed we should write to the eventlog, we cannot inform the user in any way (stderr = /dev/null from a service by default). Therefor, the win32 check is in PostmasterMain. There might be a slightly better place to put it, not 100% sure about that.. The win32 specific code is mainly in the file security.c to go in src/backend/port/win32. //Magnus <> <> security.c Description: security.c admin_warning.patch Description: admin_warning.patch ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] win32 service proposal
I played a bit with that code. According to Microsoft samples for service managers, errors and events should be logged to eventlog. so I added a function (almost copy of sample service code), it's a messy, but it was enough to see what is happening with the service. After testing it, I have noticed two confusing things: 1. I'll try to describe what happens in few steps: a.) register service using: C:\msys\1.0\local\pgsql\bin\postmaster /register postgres -D C:/msys/1.0/local/pgsql/data b.) start service manager c.) start the service (it starts fine) d.) unregister service using: C:\msys\1.0\local\pgsql\bin\postmaster /unregister postgres After that postgres "status type" in service manager changes to "disabled", and I'm unable to do anything with service. The only way is restarting NT. It seems that this happens no matter service is started or stopped, enough is that service manager is started and cursor is positioned on "postgres" service. Is this some kind of Win bug ? 2. When invalid parameter for postmaster is set, for example: -D C:/msys/1.0/local/pgsql/dataX, CreateProcess returns true, but postmaster exit with FATAL. How can we detect this situation and send the postmaster error string into log ? Here is changed "main.c" that I played with. Regards ! - Original Message - From: "Claudio Natoli" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, May 03, 2004 12:01 PM Subject: [PATCHES] win32 service proposal > > [For review only. Not for committing.] > > Decided to take a crack at this in the interests of knocking over the > remaining TODO win32 items asap. > > Would appreciate any comments on the code, particularly from win32 people. > An obvious missing feature is allowing the service to be registered under a > user account, something we certainly need to allow (with this service > running under SYSTEM, I've already tripped over some permission issues in > the regression tests). > > A consensus also needs to reached on whether or not to include this in the > postmaster: Do we want the win32 service in the postmaster, or a > stand-alone exe? (currently hooks into the main.c with a one-liner, but > trivial to wrap as a stand-alone exe). > > Spoke about this off-list with Magnus; he's strongly for stand-alone; I'm > fence-sitting. We see that clearly there are some niceties to having this in > the postmaster (one less exe to build/configure; same install set for > win/*nix; etc), but the downsides include minor impact on the core code and > the fact that a user will see two postmaster processes running... the latter > I find particularly obnoxious (using a thread to handle the service or > PostmasterMain would alleviate this, but would require more work to be able > to catch postmaster shutdowns, meaning impact to core code, and unexpected > terminations would leave the user at the mercy of the Service Manager). > > Cheers, > Claudio > > > > --- > Certain disclaimers and policies apply to all email sent from Memetrics. > For the full text of these disclaimers and policies see > href="http://www.memetrics.com/emailpolicy.html";>http://www.memetrics.com/em > ailpolicy.html > > > > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) > main.c Description: Binary data ---(end of broadcast)--- TIP 8: explain analyze is your friend
[PATCHES] smgr cleanup
Hackers,
This patch removes a couple of no-ops. I'm trying to get rid of unused
code that is in the transaction processing path.
Unrelated: it also adds an index term to the performance tips chapter.
The smgrcommit and smgrabort functions no longer do anything useful so I
removed them. We could argue that a hypotethical future storage manager
could do something at commit/abort so the hooks are needed, but we
haven't had a different storage manager for years.
If there are no objections, please apply.
--
Alvaro Herrera ()
"Pensar que el espectro que vemos es ilusorio no lo despoja de espanto,
sólo le suma el nuevo terror de la locura" (Perelandra, CSLewis)
Index: doc/src/sgml/perform.sgml
===
RCS file: /home/alvherre/cvs/pgsql-server/doc/src/sgml/perform.sgml,v
retrieving revision 1.45
diff -c -r1.45 perform.sgml
*** doc/src/sgml/perform.sgml 22 Apr 2004 17:38:14 - 1.45
--- doc/src/sgml/perform.sgml 4 May 2004 00:44:07 -
***
*** 5,10
--- 5,14
Performance Tips
+
+performance
+
+
Query performance can be affected by many things. Some of these can
be manipulated by the user, while others are fundamental to the underlying
Index: src/backend/access/transam/xact.c
===
RCS file: /home/alvherre/cvs/pgsql-server/src/backend/access/transam/xact.c,v
retrieving revision 1.165
diff -c -r1.165 xact.c
*** src/backend/access/transam/xact.c 5 Apr 2004 03:11:39 - 1.165
--- src/backend/access/transam/xact.c 4 May 2004 01:31:37 -
***
*** 475,483
TransactionId xid = GetCurrentTransactionId();
XLogRecPtr recptr;
- /* Tell bufmgr and smgr to prepare for commit */
- BufmgrCommit();
-
START_CRIT_SECTION();
/*
--- 475,480
***
*** 964,970
smgrDoPendingDeletes(true);
AtCommit_Cache();
AtEOXact_Buffers(true);
- /* smgrcommit already done */
AtCommit_Locks();
--- 961,966
***
*** 1074,1080
smgrDoPendingDeletes(false);
AtAbort_Cache();
AtEOXact_Buffers(false);
- smgrabort();
AtAbort_Locks();
--- 1070,1075
Index: src/backend/storage/buffer/bufmgr.c
===
RCS file: /home/alvherre/cvs/pgsql-server/src/backend/storage/buffer/bufmgr.c,v
retrieving revision 1.164
diff -c -r1.164 bufmgr.c
*** src/backend/storage/buffer/bufmgr.c 25 Apr 2004 23:50:54 - 1.164
--- src/backend/storage/buffer/bufmgr.c 4 May 2004 00:45:19 -
***
*** 940,956
}
/*
- * Do whatever is needed to prepare for commit at the bufmgr and smgr levels
- */
- void
- BufmgrCommit(void)
- {
- /* Nothing to do in bufmgr anymore... */
-
- smgrcommit();
- }
-
- /*
* BufferGetBlockNumber
*Returns the block number associated with a buffer.
*
--- 940,945
Index: src/backend/storage/smgr/md.c
===
RCS file: /home/alvherre/cvs/pgsql-server/src/backend/storage/smgr/md.c,v
retrieving revision 1.104
diff -c -r1.104 md.c
*** src/backend/storage/smgr/md.c 19 Apr 2004 17:42:58 - 1.104
--- src/backend/storage/smgr/md.c 4 May 2004 00:46:51 -
***
*** 576,605
}
/*
- *mdcommit() -- Commit a transaction.
- */
- bool
- mdcommit(void)
- {
- /*
-* We don't actually have to do anything here...
-*/
- return true;
- }
-
- /*
- *mdabort() -- Abort a transaction.
- */
- bool
- mdabort(void)
- {
- /*
-* We don't actually have to do anything here...
-*/
- return true;
- }
-
- /*
*mdsync() -- Sync previous writes to stable storage.
*/
bool
--- 576,581
Index: src/backend/storage/smgr/smgr.c
===
RCS file: /home/alvherre/cvs/pgsql-server/src/backend/storage/smgr/smgr.c,v
retrieving revision 1.70
diff -c -r1.70 smgr.c
*** src/backend/storage/smgr/smgr.c 11 Feb 2004 22:55:25 - 1.70
--- src/backend/storage/smgr/smgr.c 4 May 2004 01:10:48 -
***
*** 47,54
char *buffer);
BlockNumber (*smgr_nblocks) (SMgrRelation reln);
BlockNumber (*smgr_truncate) (SMgrRelation reln, BlockNumber nblocks);
- bool(*smgr_commit) (void); /* may be NULL */
- bool(*smgr_abort) (void); /* may be NULL */
bool(*smgr_sync) (void);/* may be NULL */
} f_smgr;
--- 47,52
***
*** 56,62
static const f_smgr smgr
Re: [PATCHES] Run-as-admin warning for win32
1. You forgot to check "localsystem", as well as "domain admins". These two have even higher permissions than the ones you test for, and one of them is the default if Postgre ever makes it to become a service. 2. Are you sure "Powerusers" is such a good idea? It's the default for all non-admin users. When Postgres becomes a service, it's going to be relatively easy to configure it to run as a low-priv user. Until then, however, isn't it too difficult for admins to set up the system for it to run as a different user? Shachar Magnus Hagander wrote: For review, comments and possible application to HEAD. This code implements a warning when the postmaster is started as a high-privilege account on win32 (administrator or power users). Previously, postgresql has exited out on Unix when running as root - this is a similar check, with the following differences: * We do a ereport(WARNING) instead of exitting out. The reason for this is that we can expect there are win32 admins that will want to run the server with a high privilege account. Just sending a warning will permit this (say, when debugging etc, or if people are just too lazy to care), while clearly stating it's not a recommended way to do it. * The Unix check is directly in main.c. We cannot do this on win32, because at this stage we can only printf and exit. Win32 needs ereport. Consider when runinng as a service - before we have loaded up postgresql.conf and noticed we should write to the eventlog, we cannot inform the user in any way (stderr = /dev/null from a service by default). Therefor, the win32 check is in PostmasterMain. There might be a slightly better place to put it, not 100% sure about that.. The win32 specific code is mainly in the file security.c to go in src/backend/port/win32. //Magnus <> <> ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] mingw regression test fixes
Peter Eisentraut wrote: > Claudio Natoli wrote: > > Peter, did you mean $host_platform by any chance... as originally > > submitted? I see no use of $build_platform anywhere, and as committed > > this plain fails. > > I meant that $build_platform would be better than `uname`, not that my > word is to be taken blindly without testing. But... > > > > > I don't see why there is any need for discussion over this. There are > > 3 cases statements preceding this one, all of which use > > $host_platform. The one immediately preceding it does the very same > > thing for DIFFFLAGS! > > ... that is a very good argument for $host_platform as originally > proposed. OK, new code, back to original. :-) case $host_platform in *-*-mingw32*) PWDFLAGS=-W;; *) PWDFLAGS=;; esac -- 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] win32 service proposal
> Spoke about this off-list with Magnus; he's strongly for > stand-alone; I'm fence-sitting. We see that clearly there are > some niceties to having this in the postmaster (one less exe > to build/configure; same install set for win/*nix; etc), but > the downsides include minor impact on the core code and the > fact that a user will see two postmaster processes running... > the latter I find particularly obnoxious (using a thread to > handle the service or PostmasterMain would alleviate this, > but would require more work to be able to catch postmaster > shutdowns, meaning impact to core code, and unexpected > terminations would leave the user at the mercy of the Service > Manager). Hmm, did I come across as stringly for stand-alone? That was not my intention :-) I'm definitly leaning in that direction, but I wouldn't say I'm strongly for it. Apart from that, those are the points I see. It's just a matter of weighting them. //Magnus ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[PATCHES] win32 service proposal
[For review only. Not for committing.] Decided to take a crack at this in the interests of knocking over the remaining TODO win32 items asap. Would appreciate any comments on the code, particularly from win32 people. An obvious missing feature is allowing the service to be registered under a user account, something we certainly need to allow (with this service running under SYSTEM, I've already tripped over some permission issues in the regression tests). A consensus also needs to reached on whether or not to include this in the postmaster: Do we want the win32 service in the postmaster, or a stand-alone exe? (currently hooks into the main.c with a one-liner, but trivial to wrap as a stand-alone exe). Spoke about this off-list with Magnus; he's strongly for stand-alone; I'm fence-sitting. We see that clearly there are some niceties to having this in the postmaster (one less exe to build/configure; same install set for win/*nix; etc), but the downsides include minor impact on the core code and the fact that a user will see two postmaster processes running... the latter I find particularly obnoxious (using a thread to handle the service or PostmasterMain would alleviate this, but would require more work to be able to catch postmaster shutdowns, meaning impact to core code, and unexpected terminations would leave the user at the mercy of the Service Manager). Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see http://www.memetrics.com/emailpolicy.html";>http://www.memetrics.com/em ailpolicy.html service.c Description: Binary data ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] win32: whitespace in dir names, shmem bug
> > Great to see you caught that. That's one more off my list > of things to > > dig into. > > Are there any not listed here: > http://momjian.postgresql.org/main/writings/pgsql/win32.html > > If so, they probably should be put up. I don't think so. It's mostly sub-issues under the known locale issues, from what I can tell so far. I'll know more once I have that one solved. //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
Re: [PATCHES] win32: whitespace in dir names, shmem bug
> Great to see you caught that. That's one more off my list of things to > dig into. Are there any not listed here: http://momjian.postgresql.org/main/writings/pgsql/win32.html If so, they probably should be put up. Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see http://www.memetrics.com/emailpolicy.html";>http://www.memetrics.com/em ailpolicy.html ---(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] win32: whitespace in dir names, shmem bug
> For application to HEAD, following community review. > > sysv_shmem.c patch is to correct a bug that prevents the > postmaster recovering from an unexpected backend termination. Great to see you caught that. That's one more off my list of things to dig into. I expected it was something that easy, but it still has to be found... > The remaining patches are to allow whitespace in db/install > directory names. Looks good to me. //Magnus ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
