Re: [HACKERS] PostgreSQL under Windows
Justin, can you add this to the release notes section on the sourceforge site if it's not already there? Robert Treat On Saturday 14 June 2003 12:02 am, Justin Clift wrote: > Hi guys, > > Although the "Proof of Concept" build works, it does have a few drawbacks: > > + Only works on English (US at least) installations, because it's hard > coded to install in C:\Program Files\PostgreSQL. On non-English > installations, "C:\Program Files" is named differently and causes things > to fail. > > + It's missing the pager program "less", and the gzip libraries, so > using pg_dump and psql have problems. > > + It's based on an old version of PostgreSQL, 7.3.1 from memory. > > All that being said, it should be ok to use, but don't run it in a > production environment. Development and testing environments should be ok. > > :-) > > Regards and best wishes, > > Justin Clift > > Robert Treat wrote: > > On Wed, 2003-06-11 at 08:03, Bruno Wolff III wrote: > >>On Tue, Jun 10, 2003 at 22:34:04 -0700, > >> > >> "P.M" <[EMAIL PROTECTED]> wrote: > >>>I was thinking that PostgreSQL could help me to reduce > >>>the cost of a such software. But i would like to know > >>>what is the status of the PostGreSQL version under > >>>Windows ? > >>>I mean, i know that some of you are trying to do an > >>>installer version under Windows for PostGreSQL and i > >>>would like to know if a beta version already exist or > >>>not > >> > >>There will be a beta native windows port available in about 3 weeks. > >>It is currently possible to run postgresql on windows using cygwin. > > > > If you don't want to wait and not big on cygwin, you can get a "proof of > > concept" build at > > http://sourceforge.net/project/showfiles.php?group_id=9764&release_id=136 > >623 > > > > It's not supported by anyone and I can't even say if it will work for > > you, but it has worked for some in the past and might be a good way to > > get your feet wet. > > > > Once you get up and running be sure to come back and help us beta test! > > > > :-) > > > > Robert Treat ---(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: [HACKERS] PostgreSQL under Windows
Hi guys, Although the "Proof of Concept" build works, it does have a few drawbacks: + Only works on English (US at least) installations, because it's hard coded to install in C:\Program Files\PostgreSQL. On non-English installations, "C:\Program Files" is named differently and causes things to fail. + It's missing the pager program "less", and the gzip libraries, so using pg_dump and psql have problems. + It's based on an old version of PostgreSQL, 7.3.1 from memory. All that being said, it should be ok to use, but don't run it in a production environment. Development and testing environments should be ok. :-) Regards and best wishes, Justin Clift Robert Treat wrote: On Wed, 2003-06-11 at 08:03, Bruno Wolff III wrote: On Tue, Jun 10, 2003 at 22:34:04 -0700, "P.M" <[EMAIL PROTECTED]> wrote: I was thinking that PostgreSQL could help me to reduce the cost of a such software. But i would like to know what is the status of the PostGreSQL version under Windows ? I mean, i know that some of you are trying to do an installer version under Windows for PostGreSQL and i would like to know if a beta version already exist or not There will be a beta native windows port available in about 3 weeks. It is currently possible to run postgresql on windows using cygwin. If you don't want to wait and not big on cygwin, you can get a "proof of concept" build at http://sourceforge.net/project/showfiles.php?group_id=9764&release_id=136623 It's not supported by anyone and I can't even say if it will work for you, but it has worked for some in the past and might be a good way to get your feet wet. Once you get up and running be sure to come back and help us beta test! :-) Robert Treat ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] PostgreSQL libraries - PThread Support, but
Lee, I have been looking at the code, and though the quoted function is OK to avoid the non-posix case, it seems the later ones are a problem: #if defined HAVE_NONPOSIX_GETPWUID_R /* broken (well early POSIX draft) getpwuid_r() which returns * 'struct passwd *' */ *result = getpwuid_r(uid, resultbuf, buffer, buflen); #else /* no getpwuid_r() available, just use getpwuid() */ *result = getpwuid(uid); #endif /* HAVE_NONPOSIX_GETPWUID_R */ return( (*result == NULL) ? -1 : 0 ); In this case, what logic do we use? Seems you don't want to use getpwuid_r if it exists, but only if getpwuid isn't thread safe, and I have no idea how do to this. Can we just use the *_r versions if they exist? --- Bruce Momjian wrote: > > Lee, I have a question about this code: > > char *pqStrerror(int errnum, char *strerrbuf, size_t buflen) > { > #if defined HAVE_STRERROR_R > /* reentrant strerror_r is available */ > strerror_r(errnum, strerrbuf, buflen); > return strerrbuf; > #elif defined HAVE_NONPOSIX_STRERROR_R > /* broken (well early POSIX draft) strerror_r() which returns 'char *' */ > return strerror_r(errnum, strerrbuf, buflen); > #else > /* no strerror_r() available, just use strerror */ > return strerror(errnum); > #endif > } > > Why do we have to care about HAVE_NONPOSIX_STRERROR_R? Can't we just > use the HAVE_STRERROR_R code in all cases? > > --- > > Lee Kindness wrote: > Content-Description: message body text > > > Patch attached, along with new libpq-reentrant.c and libpq-reentrant.h > > files for src/interfaces/libpq. > > > > Also at http://services.csl.co.uk/postgresql/ > > > > Thanks, Lee. > > > > Lee Kindness writes: > > > Ok guys, I propose that the new libpq diff and 2 source files which > > > i'll soon send to pgsql-patches is applied to the source. This diff is > > > a cleaned up version of the previous version with the wrapper > > > functions moved out into their own file and more comments added. Also > > > the use of crypt_r() has been removed (not worth the effort), the > > > cpp defines have been renamed to be consistent with each other and > > > Tom's concerns with loose #defines has been partly addressed. > > > > > > This diff does not include any configure changes. I plan to tackle > > > this separately ASAP, and hopefully produce something more acceptable. > > > > > > I will add checks for appropriate compiler thread flags (for compiling > > > libpq, and alow the removal of #defines in libpq-reentrant.h), and > > > link flags & libs (for a planned threaded libpq test program and > > > renentrant ecpg library). If a thread environment is found then check > > > for the reentrant functions will be done. > > > > > > Looking at various open source projects configure.in files there seems > > > to be little commonality in the thread test macros (telp gratefully > > > accepted!), I currently think that something like the approach used by > > > glib is most suitable (switch on OS). > > > > > > All sound acceptable? > > > > > > Thanks, Lee. > > > > > > Peter Eisentraut writes: > > > > Lee Kindness writes: > > > > > > > > > Patches attached to make libpq thread-safe, now uses strerror_r(), > > > > > gethostbyname_r(), getpwuid_r() and crypt_r() where available. Where > > > > > strtok() was previously used strchr() is now used. > > > > > > > > AC_TRY_RUN tests are prohibited. Also, try to factor out some of these > > > > huge tests into separate macros and put them into config/c-library.m4. > > > > And it would be nice if there was some documentation about what was > > > > checked for. If you just want to check whether gethostbyname_r() has 5 or > > > > 6 arguments you can do that in half the space. > > > > [ Attachment, skipping... ] > > [ Attachment, skipping... ] > > [ Attachment, skipping... ] > > -- > 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] > -- 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: [HACKERS] Compiling Win32
You should be able to compile, but not link the backend. --- Paul Ramsey wrote: > Yep, have done that... > Configure even runs right through, but nothing after that. :/ > P. > > Bruce Momjian wrote: > > No, we are not there yet, but you can download Mingw and Msys to get > > started. > > > > --- > > > > Paul Ramsey wrote: > > > >>I have started playing with the pre7.4 code to see if I can compile a > >>win32 version with PostGIS support. So far, finding it a little hard. Is > >>there a wee guide to compiling 7.4 native win32 around? > >>Thanks, > >>Paul > >> > > > > -- 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 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Compiling Win32
Yep, have done that... Configure even runs right through, but nothing after that. :/ P. Bruce Momjian wrote: No, we are not there yet, but you can download Mingw and Msys to get started. --- Paul Ramsey wrote: I have started playing with the pre7.4 code to see if I can compile a win32 version with PostGIS support. So far, finding it a little hard. Is there a wee guide to compiling 7.4 native win32 around? Thanks, Paul ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Compiling Win32
No, we are not there yet, but you can download Mingw and Msys to get started. --- Paul Ramsey wrote: > I have started playing with the pre7.4 code to see if I can compile a > win32 version with PostGIS support. So far, finding it a little hard. Is > there a wee guide to compiling 7.4 native win32 around? > Thanks, > Paul > > -- >__ > / > | Paul Ramsey > | Refractions Research > | Email: [EMAIL PROTECTED] > | Phone: (250) 885-0632 > \_ > > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster > -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Compiling Win32
I have started playing with the pre7.4 code to see if I can compile a win32 version with PostGIS support. So far, finding it a little hard. Is there a wee guide to compiling 7.4 native win32 around? Thanks, Paul -- __ / | Paul Ramsey | Refractions Research | Email: [EMAIL PROTECTED] | Phone: (250) 885-0632 \_ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Mirro updates
On Fri, 13 Jun 2003 [EMAIL PROTECTED] wrote: > Hi vince, Hi Marc > > Although I understand why, I think it's a bit f a pity that there's no > mirror of web anymore. For that it means that 1) every thing is now on > your shoulders and that if anything goes wrong you've got no mirror to > rely on. > > BUT the Good thing is it advocates for database replication as this could > make mirrors run again :) God, I never enough thought about that ... a read-only replication would be *very* easy to setup ... Dave/Robert? Thoughts? ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Mirro updates
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 13 June 2003 15:19 > To: pgsql-hackers list > Subject: [HACKERS] Mirro updates > > > Hi every one, > > Is it normal that mirro site now all redirect to www.postgresql.org? > > It also seem that rsync is doing nothing when updating www... Yes, this is expected. Currently the website is not being mirrored due to it's dependency on a backend database. We are considering different ways of overcoming this problem in a useful way. Regards, Dave. ---(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
[HACKERS] dblink_ora - a first shot on Oracle ...
Hi there ... I have spent some time working on an Oracle version of dblink. It works quite nicely for me and I hope it does for others. It already supports some basic features such as persistent connection and fetching data. This is not a perfect piece of software and there is lot of room for enhancing this stuff. If there is somebody out there who is interesting in this kind of stuff I would be glad. Maybe I will have some time in the next few days so that I can provide an interface for flat files and some other database such as Berkley DB as well. Maybe there will also be a version for MySQL but this one will be used for MIGRATION purposes only. In other words: I won't touch MySQL - just for migration and to get rid of it. Personal thanks to Joe Conway, most of the code has been stolen from him. Here is what you can do with the Oracle version: SELECT dblink_oraconnect('scott/[EMAIL PROTECTED]'); SELECT * FROM dblink_ora('SELECT ename, sal FROM emp') AS (ename text, sal text); SELECT 'BEGIN', dblink_oraexec('BEGIN'); SELECT 'UPDATE emp SET sal = sal - 1', dblink_oraexec('UPDATE emp SET sal = sal - 1'); SELECT 'ROLLBACK', dblink_oraexec('ROLLBACK'); SELECT * FROM dblink_ora('SELECT ename, sal FROM emp') AS (ename text, sal text); SELECT 'BEGIN', dblink_oraexec('BEGIN'); SELECT 'UPDATE emp SET sal = sal + 1', dblink_oraexec('UPDATE emp SET sal = sal + 1'); SELECT * FROM dblink_ora('SELECT ename, sal FROM emp') AS (ename text, sal text); SELECT 'UPDATE emp SET sal = sal - 1', dblink_oraexec('UPDATE emp SET sal = sal - 1'); SELECT 'COMMIT', dblink_oraexec('COMMIT'); SELECT dblink_oradisconnect(); [EMAIL PROTECTED] dblink_ora]$ psql test < func.sql DROP FUNCTION CREATE FUNCTION DROP FUNCTION CREATE FUNCTION DROP FUNCTION CREATE FUNCTION DROP FUNCTION CREATE FUNCTION DROP FUNCTION CREATE FUNCTION dblink_oraconnect --- OK (1 row) NOTICE: SQL statement successful NOTICE: Found 2 columns ename | sal +-- SMITH | 798 ALLEN | 1598 WARD | 1248 JONES | 2973 MARTIN | 1248 BLAKE | 2848 CLARK | 2448 SCOTT | 2998 KING | 4998 TURNER | 1498 ADAMS | 1098 JAMES | 948 FORD | 2998 MILLER | 1298 (14 rows) NOTICE: Affected: -1 ERROR: Cannot execute SQL statement NOTICE: Affected: 14 ?column? | dblink_oraexec --+ UPDATE emp SET sal = sal - 1 | 14 (1 row) NOTICE: Affected: 0 ?column? | dblink_oraexec --+ ROLLBACK | 0 (1 row) NOTICE: SQL statement successful NOTICE: Found 2 columns ename | sal +-- SMITH | 798 ALLEN | 1598 WARD | 1248 JONES | 2973 MARTIN | 1248 BLAKE | 2848 CLARK | 2448 SCOTT | 2998 KING | 4998 TURNER | 1498 ADAMS | 1098 JAMES | 948 FORD | 2998 MILLER | 1298 (14 rows) NOTICE: Affected: -1 ERROR: Cannot execute SQL statement NOTICE: Affected: 14 ?column? | dblink_oraexec --+ UPDATE emp SET sal = sal + 1 | 14 (1 row) NOTICE: SQL statement successful NOTICE: Found 2 columns ename | sal +-- SMITH | 799 ALLEN | 1599 WARD | 1249 JONES | 2974 MARTIN | 1249 BLAKE | 2849 CLARK | 2449 SCOTT | 2999 KING | 4999 TURNER | 1499 ADAMS | 1099 JAMES | 949 FORD | 2999 MILLER | 1299 (14 rows) NOTICE: Affected: 14 ?column? | dblink_oraexec --+ UPDATE emp SET sal = sal - 1 | 14 (1 row) NOTICE: Affected: 0 ?column? | dblink_oraexec --+ COMMIT | 0 (1 row) dblink_oradisconnect -- OK (1 row) Regards, Hans -- Cybertec Geschwinde u Schoenig Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria Tel: +43/2952/30706; +43/664/233 90 75 www.cybertec.at, www.postgresql.at, kernel.cybertec.at dblink_ora.tar.gz Description: GNU Zip compressed data ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Pre-allocation of shared memory ...
On Friday 13 June 2003 12:46, Nigel J. Andrews wrote: > On Fri, 13 Jun 2003, Lamar Owen wrote: > > Incidentally, Red Hat as of about 7.0 began insisting on swap space at > > least as large as twice RAM size. In my case on my 512MB RAM notebook, > > that meant it wanted 1GB swap. If you upgrade your RAM you could get > > into trouble. In that case, you create a swap file on one of your other > > partitions that the kernel can use. > I'm not sure I agree with this. To a large extent these days of cheap > memory swap space is there to give you time to notice the excessive use of > it and repair the system, since you'd normally be running everything in > RAM. It is or was a Linux kernel problem. The 2.2 kernel required double swap space, even though it wasn't well documented. Early 2.4 kernels also required double swap space, and it was better documented. Current Red Hat 2.4 kernels, I'm not sure which VM system is in use. The old VM certainly DID require double physical memory swap space. >From a message I wrote in January of 2002: "On Tuesday 22 January 2002 03:48 pm, Jim Wilcoxson wrote: > I should have said, we're running this way on 2.2.19, not 2.4 -J > > Is this Linux requirement documented anywhere? We're running 256MB > > of swap on 1GB machines and have not had any problems. But we don't > > swap much either. 2.2 actually needs 2x swap, but the problems are worse with 2.4. 2.2 won't die a horrible screaming death -- but 2.4 WILL DIE if you run out of swap in the wrong way. As to documentation, I can't tell you how I found out about it, as I'm under NDA from that source. However, it is public information: see http://lwn.net/2001/0607/kernel.php3 for some pointers. Also see http://www.geocrawler.com/archives/3/84/2001/5/0/5867356/ http://www.tuxedo.org/~esr/writings/ultimate-linux-box/configuration.html and http://www.ultraviolet.org/mail-archives/linux-kernel.2001/28831.html And note that Red Hat Linux 7.1 and 7.2 will complain vociferously if you create a swap partition smaller than 2x RAM during installation (anaconda). What it doesn't do is complain when you upgrade RAM but don't upgrade your swap." Now, as to whether this is _still_ a requirement or not, I don't know. Search the lkml (Linux Kernel Mailing List) for it. However, understand that the Red Hat kernel is closer to an Alan Cox kernel than to a Linus kernel. At least that was true up to 2.4.18; the Red Hat 2.4.20 is very different, with NPTL and its ilk thrown in. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Pre-allocation of shared memory ...
On Fri, Jun 13, 2003 at 12:32:24PM -0400, Lamar Owen wrote: > > Incidentally, Red Hat as of about 7.0 began insisting on swap space at least > as large as twice RAM size. In my case on my 512MB RAM notebook, that meant > it wanted 1GB swap. If you upgrade your RAM you could get into trouble. In > that case, you create a swap file on one of your other partitions that the > kernel can use. RedHat's position may be influenced by the fact that, AFAIR, they use the Rik van Riel virtual memory system which is inclusive--i.e., you need at least as much swap as you have physical memory before you really have any virtual memory at all. This was fixed by the competing Andrea Arcangeli system, which became standard for the Linux kernel around 2.4.10 or so. Jeroen ---(end of broadcast)--- TIP 10: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] UTF8 and KOI8 mini-howto
Hi there, I've managed to get postgresql working with UTF8 and KOI8. Here is some mini-howto: http://www.sai.msu.su/~megera/postgres/utf8.html Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 10: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] SOLUTION: Insert a Euro symbol as UTF-8 from a latin1 charset.
On Friday 13 June 2003 17:28, Roland Glenn McIntosh wrote: > This is my solution / bug report / RFC cross-posted from [GENERAL] > regarding insertion of hexadecimal characters from the command line. > --- > > Okay. I have NO IDEA why this works. If someone could enlighten me as to > the math involved I'd appreciate it. First, a little background: > > The Euro symbol is unicode value 0x20AC. UTF-8 encoding is a way of > representing most unicode characters in two bytes, and most latin > characters in one byte. > > The only way I have found to insert a euro symbol into the database from > the command line psql client is this: INSERT INTO mytable > VALUES('\342\202\254'); > > I don't know why this works. In hex, those octal values are: > E2 82 AC My apologies, I forgot to mention converting to UTF-8 in my original reply. > Additionally, according to the psql online documentation and man page: > "Anything contained in single quotes is furthermore subject to C-like > substitutions for \n (new line), \t (tab), \digits, \0digits, and \0xdigits > (the character with the given decimal, octal, or hexadecimal code)." > > Those digits *should* be interpreted as decimal digits, but they aren't. > The man page for psql is either incorrect, or the implementation is buggy. The docs are easy to misunderstand if you are scanning them in a hurry. This section is referring to substitutions in psql's own meta commands, not SQL statements, e.g. this: \echo '\0xe2\0x82\0xac' will display the Euro sign (assuming your terminal can print it). Ian Barwick [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Pre-allocation of shared memory ...
I will say I do use swap sometimes when I am editing a huge image or something --- there are peak times when it is required. --- Nigel J. Andrews wrote: > On Fri, 13 Jun 2003, Lamar Owen wrote: > > > On Friday 13 June 2003 11:55, Josh Berkus wrote: > > > Regrettably, few of the GUI installers for Linux (SuSE or Red Hat, for > > > example), include adequate swap space in their "suggested" disk formatting. > > > Some versions of some distributions do not create a swap partition at all; > > > others allocate only 130mb to this partition regardless of actual RAM. > > > > Incidentally, Red Hat as of about 7.0 began insisting on swap space at least > > as large as twice RAM size. In my case on my 512MB RAM notebook, that meant > > it wanted 1GB swap. If you upgrade your RAM you could get into trouble. In > > that case, you create a swap file on one of your other partitions that the > > kernel can use. > > I'm not sure I agree with this. To a large extent these days of cheap memory > swap space is there to give you time to notice the excessive use of it and > repair the system, since you'd normally be running everything in RAM. > > Using the old measure of twice physical memory for swap is excessive on a > decent system imo. I certainly would not allocate 1GB of swap! Well, okay, I > might if I've got a 16GB machine with the potential for an excessive > but transitory workload, or say 4-8GB machine with a few very large memory > usage processes that can be started as part of the normal work load. > > In short, imo these days swap is there to prevent valid processes dying for > lack of system memory and not to provide normal workspace for them. > > Having said all that, I haven't read the start of this thread so I've probably > missed the reason for the complaint about lack of swap space, like a problem on > a small memory system. > > > -- > Nigel J. Andrews > > > ---(end of broadcast)--- > TIP 9: most folks find a random_page_cost between 1 or 2 is ideal > -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Pre-allocation of shared memory ...
On Fri, 13 Jun 2003, Lamar Owen wrote: > On Friday 13 June 2003 11:55, Josh Berkus wrote: > > Regrettably, few of the GUI installers for Linux (SuSE or Red Hat, for > > example), include adequate swap space in their "suggested" disk formatting. > > Some versions of some distributions do not create a swap partition at all; > > others allocate only 130mb to this partition regardless of actual RAM. > > Incidentally, Red Hat as of about 7.0 began insisting on swap space at least > as large as twice RAM size. In my case on my 512MB RAM notebook, that meant > it wanted 1GB swap. If you upgrade your RAM you could get into trouble. In > that case, you create a swap file on one of your other partitions that the > kernel can use. I'm not sure I agree with this. To a large extent these days of cheap memory swap space is there to give you time to notice the excessive use of it and repair the system, since you'd normally be running everything in RAM. Using the old measure of twice physical memory for swap is excessive on a decent system imo. I certainly would not allocate 1GB of swap! Well, okay, I might if I've got a 16GB machine with the potential for an excessive but transitory workload, or say 4-8GB machine with a few very large memory usage processes that can be started as part of the normal work load. In short, imo these days swap is there to prevent valid processes dying for lack of system memory and not to provide normal workspace for them. Having said all that, I haven't read the start of this thread so I've probably missed the reason for the complaint about lack of swap space, like a problem on a small memory system. -- Nigel J. Andrews ---(end of broadcast)--- TIP 9: most folks find a random_page_cost between 1 or 2 is ideal
Re: [HACKERS] Pre-allocation of shared memory ...
Lamar Owen wrote: > On Friday 13 June 2003 11:55, Josh Berkus wrote: > > Regrettably, few of the GUI installers for Linux (SuSE or Red Hat, for > > example), include adequate swap space in their "suggested" disk formatting. > > Some versions of some distributions do not create a swap partition at all; > > others allocate only 130mb to this partition regardless of actual RAM. > > Incidentally, Red Hat as of about 7.0 began insisting on swap space at least > as large as twice RAM size. In my case on my 512MB RAM notebook, that meant > it wanted 1GB swap. If you upgrade your RAM you could get into trouble. In > that case, you create a swap file on one of your other partitions that the > kernel can use. Oh, that's interesting. I know the newer BSD releases got rid of the large swap requirement, on the understanding that you usually aren't going to be using it anyway. What old BSD releases used to do was to allocate swap space as backing _all_ RAM, even when it wasn't going to need it, while later releases allocated swap only when it was needed, so it was only for cases _exceeding_ RAM, so your virtual memory was now RAM _plus_ swap. Of course, if you exceed swap, your system hangs. -- 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 10: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] PostgreSQL libraries - PThread Support, but
Bruce Momjian writes: > My point is why do we care whether it returns char * or nothing --- we > should just return strerrbuf in all cases. Ok, I see. Guess that is reasonable. L. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] PostgreSQL libraries - PThread Support, but
My point is why do we care whether it returns char * or nothing --- we should just return strerrbuf in all cases. --- Lee Kindness wrote: > Your call, but the "broken" call is in earlier glibc versions for > sure (if you're on a Linux box take a look in /usr/include - the > prototype is still there, may even get used depending on compiler > options!). I seem to remember compiling this on recent Solaris, HPUX, > Linux and AIX versions without hitting the "broken" version, but... > > L. > > Bruce Momjian writes: > > > > Lee, I have a question about this code: > > > >char *pqStrerror(int errnum, char *strerrbuf, size_t buflen) > >{ > >#if defined HAVE_STRERROR_R > > /* reentrant strerror_r is available */ > > strerror_r(errnum, strerrbuf, buflen); > > return strerrbuf; > >#elif defined HAVE_NONPOSIX_STRERROR_R > > /* broken (well early POSIX draft) strerror_r() which returns 'char *' */ > > return strerror_r(errnum, strerrbuf, buflen); > >#else > > /* no strerror_r() available, just use strerror */ > > return strerror(errnum); > >#endif > >} > > > > Why do we have to care about HAVE_NONPOSIX_STRERROR_R? Can't we just > > use the HAVE_STRERROR_R code in all cases? > > > > --- > > > > Lee Kindness wrote: > > Content-Description: message body text > > > > > Patch attached, along with new libpq-reentrant.c and libpq-reentrant.h > > > files for src/interfaces/libpq. > > > > > > Also at http://services.csl.co.uk/postgresql/ > > > > > > Thanks, Lee. > > > > > > Lee Kindness writes: > > > > Ok guys, I propose that the new libpq diff and 2 source files which > > > > i'll soon send to pgsql-patches is applied to the source. This diff is > > > > a cleaned up version of the previous version with the wrapper > > > > functions moved out into their own file and more comments added. Also > > > > the use of crypt_r() has been removed (not worth the effort), the > > > > cpp defines have been renamed to be consistent with each other and > > > > Tom's concerns with loose #defines has been partly addressed. > > > > > > > > This diff does not include any configure changes. I plan to tackle > > > > this separately ASAP, and hopefully produce something more acceptable. > > > > > > > > I will add checks for appropriate compiler thread flags (for compiling > > > > libpq, and alow the removal of #defines in libpq-reentrant.h), and > > > > link flags & libs (for a planned threaded libpq test program and > > > > renentrant ecpg library). If a thread environment is found then check > > > > for the reentrant functions will be done. > > > > > > > > Looking at various open source projects configure.in files there seems > > > > to be little commonality in the thread test macros (telp gratefully > > > > accepted!), I currently think that something like the approach used by > > > > glib is most suitable (switch on OS). > > > > > > > > All sound acceptable? > > > > > > > > Thanks, Lee. > > > > > > > > Peter Eisentraut writes: > > > > > Lee Kindness writes: > > > > > > > > > > > Patches attached to make libpq thread-safe, now uses strerror_r(), > > > > > > gethostbyname_r(), getpwuid_r() and crypt_r() where available. Where > > > > > > strtok() was previously used strchr() is now used. > > > > > > > > > > AC_TRY_RUN tests are prohibited. Also, try to factor out some of these > > > > > huge tests into separate macros and put them into config/c-library.m4. > > > > > And it would be nice if there was some documentation about what was > > > > > checked for. If you just want to check whether gethostbyname_r() has 5 or > > > > > 6 arguments you can do that in half the space. > > > > > > > [ Attachment, skipping... ] > > > > [ Attachment, skipping... ] > > > > [ Attachment, skipping... ] > > > > -- > > 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 > -- 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 7: don't forget to increase your free space map settings
Re: [HACKERS] Pre-allocation of shared memory ...
On Friday 13 June 2003 11:55, Josh Berkus wrote: > Regrettably, few of the GUI installers for Linux (SuSE or Red Hat, for > example), include adequate swap space in their "suggested" disk formatting. > Some versions of some distributions do not create a swap partition at all; > others allocate only 130mb to this partition regardless of actual RAM. Incidentally, Red Hat as of about 7.0 began insisting on swap space at least as large as twice RAM size. In my case on my 512MB RAM notebook, that meant it wanted 1GB swap. If you upgrade your RAM you could get into trouble. In that case, you create a swap file on one of your other partitions that the kernel can use. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 9: most folks find a random_page_cost between 1 or 2 is ideal
Re: [PATCHES] [HACKERS] PostgreSQL libraries - PThread Support, but
Your call, but the "broken" call is in earlier glibc versions for sure (if you're on a Linux box take a look in /usr/include - the prototype is still there, may even get used depending on compiler options!). I seem to remember compiling this on recent Solaris, HPUX, Linux and AIX versions without hitting the "broken" version, but... L. Bruce Momjian writes: > > Lee, I have a question about this code: > > char *pqStrerror(int errnum, char *strerrbuf, size_t buflen) > { > #if defined HAVE_STRERROR_R >/* reentrant strerror_r is available */ >strerror_r(errnum, strerrbuf, buflen); >return strerrbuf; > #elif defined HAVE_NONPOSIX_STRERROR_R >/* broken (well early POSIX draft) strerror_r() which returns 'char *' */ >return strerror_r(errnum, strerrbuf, buflen); > #else >/* no strerror_r() available, just use strerror */ >return strerror(errnum); > #endif > } > > Why do we have to care about HAVE_NONPOSIX_STRERROR_R? Can't we just > use the HAVE_STRERROR_R code in all cases? > > --- > > Lee Kindness wrote: > Content-Description: message body text > > > Patch attached, along with new libpq-reentrant.c and libpq-reentrant.h > > files for src/interfaces/libpq. > > > > Also at http://services.csl.co.uk/postgresql/ > > > > Thanks, Lee. > > > > Lee Kindness writes: > > > Ok guys, I propose that the new libpq diff and 2 source files which > > > i'll soon send to pgsql-patches is applied to the source. This diff is > > > a cleaned up version of the previous version with the wrapper > > > functions moved out into their own file and more comments added. Also > > > the use of crypt_r() has been removed (not worth the effort), the > > > cpp defines have been renamed to be consistent with each other and > > > Tom's concerns with loose #defines has been partly addressed. > > > > > > This diff does not include any configure changes. I plan to tackle > > > this separately ASAP, and hopefully produce something more acceptable. > > > > > > I will add checks for appropriate compiler thread flags (for compiling > > > libpq, and alow the removal of #defines in libpq-reentrant.h), and > > > link flags & libs (for a planned threaded libpq test program and > > > renentrant ecpg library). If a thread environment is found then check > > > for the reentrant functions will be done. > > > > > > Looking at various open source projects configure.in files there seems > > > to be little commonality in the thread test macros (telp gratefully > > > accepted!), I currently think that something like the approach used by > > > glib is most suitable (switch on OS). > > > > > > All sound acceptable? > > > > > > Thanks, Lee. > > > > > > Peter Eisentraut writes: > > > > Lee Kindness writes: > > > > > > > > > Patches attached to make libpq thread-safe, now uses strerror_r(), > > > > > gethostbyname_r(), getpwuid_r() and crypt_r() where available. Where > > > > > strtok() was previously used strchr() is now used. > > > > > > > > AC_TRY_RUN tests are prohibited. Also, try to factor out some of these > > > > huge tests into separate macros and put them into config/c-library.m4. > > > > And it would be nice if there was some documentation about what was > > > > checked for. If you just want to check whether gethostbyname_r() has 5 or > > > > 6 arguments you can do that in half the space. > > > > [ Attachment, skipping... ] > > [ Attachment, skipping... ] > > [ Attachment, skipping... ] > > -- > 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 9: most folks find a random_page_cost between 1 or 2 is ideal
Re: [HACKERS] Pre-allocation of shared memory ...
Josh Berkus wrote: > Tom, et al, > > > > Given that swap space is cheap, and that killing random processes is > > > obviously bad, it's not apparent to me why people think this is not > > > a good approach --- at least for high-reliability servers. And Linux > > > would definitely like to think of itself as a server-grade OS. > > Regrettably, few of the GUI installers for Linux (SuSE or Red Hat, for > example), include adequate swap space in their "suggested" disk formatting. > Some versions of some distributions do not create a swap partition at all; > others allocate only 130mb to this partition regardless of actual RAM. > > So regardless of what they *should* be doing, there's thousands of Linux users > out there with too little or no swap on disk ... Yes, I have seen that on BSD's too. I am unsure if we need actual swap backing store, or just sufficient RAM to allow fork expansion for dirty pages. -- 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: [HACKERS] Pre-allocation of shared memory ...
Tom, et al, > > Given that swap space is cheap, and that killing random processes is > > obviously bad, it's not apparent to me why people think this is not > > a good approach --- at least for high-reliability servers. And Linux > > would definitely like to think of itself as a server-grade OS. Regrettably, few of the GUI installers for Linux (SuSE or Red Hat, for example), include adequate swap space in their "suggested" disk formatting. Some versions of some distributions do not create a swap partition at all; others allocate only 130mb to this partition regardless of actual RAM. So regardless of what they *should* be doing, there's thousands of Linux users out there with too little or no swap on disk ... -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 10: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] PostgreSQL libraries - PThread Support, but
Lee, I have a question about this code: char *pqStrerror(int errnum, char *strerrbuf, size_t buflen) { #if defined HAVE_STRERROR_R /* reentrant strerror_r is available */ strerror_r(errnum, strerrbuf, buflen); return strerrbuf; #elif defined HAVE_NONPOSIX_STRERROR_R /* broken (well early POSIX draft) strerror_r() which returns 'char *' */ return strerror_r(errnum, strerrbuf, buflen); #else /* no strerror_r() available, just use strerror */ return strerror(errnum); #endif } Why do we have to care about HAVE_NONPOSIX_STRERROR_R? Can't we just use the HAVE_STRERROR_R code in all cases? --- Lee Kindness wrote: Content-Description: message body text > Patch attached, along with new libpq-reentrant.c and libpq-reentrant.h > files for src/interfaces/libpq. > > Also at http://services.csl.co.uk/postgresql/ > > Thanks, Lee. > > Lee Kindness writes: > > Ok guys, I propose that the new libpq diff and 2 source files which > > i'll soon send to pgsql-patches is applied to the source. This diff is > > a cleaned up version of the previous version with the wrapper > > functions moved out into their own file and more comments added. Also > > the use of crypt_r() has been removed (not worth the effort), the > > cpp defines have been renamed to be consistent with each other and > > Tom's concerns with loose #defines has been partly addressed. > > > > This diff does not include any configure changes. I plan to tackle > > this separately ASAP, and hopefully produce something more acceptable. > > > > I will add checks for appropriate compiler thread flags (for compiling > > libpq, and alow the removal of #defines in libpq-reentrant.h), and > > link flags & libs (for a planned threaded libpq test program and > > renentrant ecpg library). If a thread environment is found then check > > for the reentrant functions will be done. > > > > Looking at various open source projects configure.in files there seems > > to be little commonality in the thread test macros (telp gratefully > > accepted!), I currently think that something like the approach used by > > glib is most suitable (switch on OS). > > > > All sound acceptable? > > > > Thanks, Lee. > > > > Peter Eisentraut writes: > > > Lee Kindness writes: > > > > > > > Patches attached to make libpq thread-safe, now uses strerror_r(), > > > > gethostbyname_r(), getpwuid_r() and crypt_r() where available. Where > > > > strtok() was previously used strchr() is now used. > > > > > > AC_TRY_RUN tests are prohibited. Also, try to factor out some of these > > > huge tests into separate macros and put them into config/c-library.m4. > > > And it would be nice if there was some documentation about what was > > > checked for. If you just want to check whether gethostbyname_r() has 5 or > > > 6 arguments you can do that in half the space. > [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] -- 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: [HACKERS] SOLUTION: Insert a Euro symbol as UTF-8 from a latin1 charset.
On Fri, Jun 13, 2003 at 11:28:36AM -0400, Roland Glenn McIntosh wrote: > > The Euro symbol is unicode value 0x20AC. UTF-8 encoding is a way of representing > most unicode characters in two bytes, and most latin characters in one byte. More precisely, UTF-8 encodes ASCII characters in one byte. All other latin-1 characters take 2 bytes IIRC, with the rest taking up to 4 bytes. > I don't know why my "20" byte turned into two bytes of E2 and 82. Haven't got the spec handy, but UTF-8 uses the most-significant bit(s) of each byte as a "continuation" field. If the upper bit is zero, the char is a plain 7-bit ASCII value. If it's 1, the byte is part of a multibyte sequence with a few most-significant bits indicating the sequence's length and the byte's position in it (IIRC it's something like a countdown to the end of the sequence). In a nutshell, you can't just take bits away from your Unicode value and call it UTF-8; it's a variable-length encoding and it needs some extra room for the length information to go. Furthermore, I don't think the Euro symbol is in latin-1 at all. It was added in latin-9 (iso 8859-15) and so it's not likely to have gotten a retroactive spot in the bottom 256 character values. Hence it will take UTF-8 more bytes to encode it. > Furthermore, I was under the impression that a UTF-8 encoding of the Euro sign only > took two bytes. Corroborating this assumption, upon dumping that table with pg_dump > and examining the resultant file in a hex editor, I see this in that character > position: AC 20 How does that "corroborate the assumption?" You're looking at the Unicode value now, in a fixed-length 16-bit encoding. > I did try the '\0x20AC' method, and '\0x20\0xAC' without success. > It's worth noting that the field I'm inserting into is an SQL_ASCII field, and I'm > reading my UTF-8 string out of it like this, via JDBC: You can't fit UTF-8 into ASCII. UTF-8 is an eight-byte encoding; ASCII is a 7-bit character set. Jeroen ---(end of broadcast)--- TIP 9: most folks find a random_page_cost between 1 or 2 is ideal
Re: [HACKERS] Mirro updates
Hi vince, Hi Marc Although I understand why, I think it's a bit f a pity that there's no mirror of web anymore. For that it means that 1) every thing is now on your shoulders and that if anything goes wrong you've got no mirror to rely on. BUT the Good thing is it advocates for database replication as this could make mirrors run again :) On Fri, 13 Jun 2003, The Hermit Hacker wrote: > Date: Fri, 13 Jun 2003 11:34:40 -0300 (ADT) > From: The Hermit Hacker <[EMAIL PROTECTED]> > To: Vince Vielhaber <[EMAIL PROTECTED]> > Cc: The Hermit Hacker <[EMAIL PROTECTED]>, [EMAIL PROTECTED], > pgsql-hackers list <[EMAIL PROTECTED]> > Subject: Re: [HACKERS] Mirro updates > > On Fri, 13 Jun 2003, Vince Vielhaber wrote: > > > On Fri, 13 Jun 2003, The Hermit Hacker wrote: > > > > > > > > for the web, yes ... the new site doesn't support mirroring, as its highly > > > database driven ... only thing still mirrorable, really, is the ftp > > > server ... > > > > I knew that was gonna happen. > > So did we ... :) > You have not warned us :) -- Olivier PRENANT Tel:+33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] SOLUTION: Insert a Euro symbol as UTF-8 from a latin1 charset.
This is my solution / bug report / RFC cross-posted from [GENERAL] regarding insertion of hexadecimal characters from the command line. --- Okay. I have NO IDEA why this works. If someone could enlighten me as to the math involved I'd appreciate it. First, a little background: The Euro symbol is unicode value 0x20AC. UTF-8 encoding is a way of representing most unicode characters in two bytes, and most latin characters in one byte. The only way I have found to insert a euro symbol into the database from the command line psql client is this: INSERT INTO mytable VALUES('\342\202\254'); I don't know why this works. In hex, those octal values are: E2 82 AC I don't know why my "20" byte turned into two bytes of E2 and 82. Furthermore, I was under the impression that a UTF-8 encoding of the Euro sign only took two bytes. Corroborating this assumption, upon dumping that table with pg_dump and examining the resultant file in a hex editor, I see this in that character position: AC 20 Additionally, according to the psql online documentation and man page: "Anything contained in single quotes is furthermore subject to C-like substitutions for \n (new line), \t (tab), \digits, \0digits, and \0xdigits (the character with the given decimal, octal, or hexadecimal code)." Those digits *should* be interpreted as decimal digits, but they aren't. The man page for psql is either incorrect, or the implementation is buggy. I did try the '\0x20AC' method, and '\0x20\0xAC' without success. It's worth noting that the field I'm inserting into is an SQL_ASCII field, and I'm reading my UTF-8 string out of it like this, via JDBC: String value = new String( resultset.getBytes(1), "UTF-8"); Can anyone help me make sense of this mumbo jumbo? -Roland ---(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: [HACKERS] Mirro updates
On Fri, 13 Jun 2003, Vince Vielhaber wrote: > On Fri, 13 Jun 2003, The Hermit Hacker wrote: > > > > > for the web, yes ... the new site doesn't support mirroring, as its highly > > database driven ... only thing still mirrorable, really, is the ftp > > server ... > > I knew that was gonna happen. So did we ... :) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Mirro updates
On Fri, 13 Jun 2003, The Hermit Hacker wrote: > > for the web, yes ... the new site doesn't support mirroring, as its highly > database driven ... only thing still mirrorable, really, is the ftp > server ... I knew that was gonna happen. Vince. -- Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/ http://www.meanstreamradio.com http://www.unknown-artists.com Internet radio: It's not file sharing, it's just radio. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Mirro updates
for the web, yes ... the new site doesn't support mirroring, as its highly database driven ... only thing still mirrorable, really, is the ftp server ... On Fri, 13 Jun 2003 [EMAIL PROTECTED] wrote: > Hi every one, > > Is it normal that mirro site now all redirect to www.postgresql.org? > > It also seem that rsync is doing nothing when updating www... > > Regards > > -- > Olivier PRENANT Tel:+33-5-61-50-97-00 (Work) > Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) > 31190 AUTERIVE +33-6-07-63-80-64 (GSM) > FRANCE Email: [EMAIL PROTECTED] > -- > Make your life a dream, make your dream a reality. (St Exupery) > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] Mirro updates
Hi every one, Is it normal that mirro site now all redirect to www.postgresql.org? It also seem that rsync is doing nothing when updating www... Regards -- Olivier PRENANT Tel:+33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] security flaw
On Tue, 10 Jun 2003, scott.marlowe wrote: > Date: Tue, 10 Jun 2003 08:15:06 -0600 (MDT) > From: scott.marlowe <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: pgsql-hackers list <[EMAIL PROTECTED]> > Subject: Re: [HACKERS] security flaw > > On Sat, 7 Jun 2003 [EMAIL PROTECTED] wrote: > > > Hi all, > > > > I wonder if it's a security problem: One of my customer noticed that he > > could see all databases on the system with phppgadmin. not only he sees > > databases but tables, views, fonctions... Fortunatly he can't see any row. > > > > This customer has the ability to create databases but not users. > > I wonder if the super_user privilege should be separated from the > > priviledge of creating databases/users. > > > > I alose think that only a superuser should list databases and objects. > > > > What do you think? > > Since security by obscurity is presumed to be ineffective, conversely, > revealing the location of an object produces no real decrease in security. > > Now, it might be nice from the user's perspective if they could filter out > the stuff they don't have access to, in order to ensure a nice neat little > view of their own data in a galaxy of information (i.e. 100 other users > each with their own data set and priveldges.) > > Since schemas provide a simple way to limit your own view, they provide > for that function. > > Can phppgadmin be programmed to only use certain search paths in the > schema? > > Hmm. Surely I did'nt make myself clear, PhpPgAdmin is not a problm here. The problem is user A is owner of databses X1,Y1 Z1 user B is owner of databases X2,Yé,Z2 both users can see the the others DB. by doing a simple \l It would be nice that unless a user is superuser he could'nt see databases that are not his. BTW how can I change ownership of databases and tables easealy? -- Olivier PRENANT Tel:+33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(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: [HACKERS] Pre-allocation of shared memory ...
On Fri, Jun 13, 2003 at 09:25:49AM -0400, Bruce Momjian wrote: > > malloc() - should fail right away if it can't reserve the requested > memory; assuming application request memory they don't use just seems > dumb --- fix the bad apps. > > fork() - this is the tricky one because you don't know at fork time who > is going to be sharing the data pages as read-only or doing an exec to > overlay a new process, and who is going to be modifying them and need a > private copy. > > I think only the fork case is tricky. But how do you tell that a malloc() can't get enough memory, once you've had to overcommit on fork()s? If a really large program did a regular fork()/exec() and there wasn't enough free virtual memory to support the full fork() "just in case the program isn't going to exec()," then *any* malloc() occurring between the two calls would have to fail. That may be better than random killing in theory, but the practical effect would be close to that. There's other complications as well, I'm sure. If this were easy, we probably wouldn't be discussing this problem now. Jeroen ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Pre-allocation of shared memory ...
Patrick Welche wrote: > On Thu, Jun 12, 2003 at 10:10:02PM -0400, Bruce Momjian wrote: > > Tom Lane wrote: > > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > > You have to love that swap + 1/2 ram option --- when you need four > > > > possible options, there is something wrong with your approach. :-) > > > > > > I'm still wondering what the "no overcommit handling" option does, > > > exactly. > > > > I assume it does no kills, and allows you to commit until you run of of > > swap and hang. This might be the BSD 4.4 behavior, actually. > > ? I thought the idea of no overcommit was that your malloc fails ENOMEM > if there isn't enough memory free for your whole request, rather than > gambling that other processes aren't actually using all of theirs right now > and have pages swapped out. I don't see where the hang comes in.. I think there are two important memory cases: malloc() - should fail right away if it can't reserve the requested memory; assuming application request memory they don't use just seems dumb --- fix the bad apps. fork() - this is the tricky one because you don't know at fork time who is going to be sharing the data pages as read-only or doing an exec to overlay a new process, and who is going to be modifying them and need a private copy. I think only the fork case is tricky. -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Pre-allocation of shared memory ...
On Thu, Jun 12, 2003 at 10:10:02PM -0400, Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > You have to love that swap + 1/2 ram option --- when you need four > > > possible options, there is something wrong with your approach. :-) > > > > I'm still wondering what the "no overcommit handling" option does, > > exactly. > > I assume it does no kills, and allows you to commit until you run of of > swap and hang. This might be the BSD 4.4 behavior, actually. ? I thought the idea of no overcommit was that your malloc fails ENOMEM if there isn't enough memory free for your whole request, rather than gambling that other processes aren't actually using all of theirs right now and have pages swapped out. I don't see where the hang comes in.. > It is bad to hang the system, but if it reports swap failure, at least > the admin knows why it failed, rather than killing random processes. Yes! Patrick ---(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: [HACKERS] Pre-allocation of shared memory ...
Shridhar Daithankar wrote: > On 12 Jun 2003 at 11:31, Bruce Momjian wrote: > > > > > OK, doc patch attached and applied. Improvements? > > Can we point people to /usr/src/linux/doc...place where they can find more > documentation and if their kernel supports it or not. Yes, we could, but the name of the parameter seems enough. They certainly can look that up. -- 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: [HACKERS] Pre-allocation of shared memory ...
On Thu, Jun 12, 2003 at 07:22:14PM -0700, Ron Mayer wrote: > I'm guessing any database backend (postgres, oracle) > that wasn't part of a long-lived connection seems like > an especially attractive target to this algorithm. Yeah, IIRC it tries to pick daemons that can be restarted, or will be restarted automatically, but may need a lot less memory after that. Jeroen ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster