Re: [BUGS] BUG #2406: Not all systems support SHM_SHARE_MMU
Paul van der Zwan <[EMAIL PROTECTED]> writes: > Maybe noone ever ran Postgres on Solaris on a VIA Epia system. Maybe. What is a "VIA Epia system"? Frankly, I'm afraid that your patch is likely to break way more systems than it fixes. What is getpagesizes(), and is it guaranteed to exist on *every* Solaris system? What the heck correlation does its result have to whether SHM_SHARE_MMU will work? regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #2406: Not all systems support SHM_SHARE_MMU
Paul van der Zwan <[EMAIL PROTECTED]> writes: > AFAIK getpagesizes() appeared in 2001 so that probably means it is > missing in anything before Solaris 9. We could handle this without relying on getpagesizes() by just trying and falling back: #ifdef SHM_SHARE_MMU memAddress = shmat(shmid, addr, SHM_SHARE_MMU); if (memAddress == (void *) -1 && errno == EINVAL) memAddress = shmat(shmid, addr, 0); #else memAddress = shmat(shmid, addr, 0); #endif However, I would argue that a system is pretty broken if it exposes the SHM_SHARE_MMU #define and then rejects it at runtime. > I'll see if I can get the x86 experts here to have a look at it... I think either Solaris/x86 should not expose this #define, or it should silently ignore the bit at runtime. AFAICS, SHM_SHARE_MMU has no guaranteed semantic effect anyway, it's just a performance hint; so ignoring it on platforms that can't handle it is reasonable. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #2371: database crashes with semctl failed
Sure. I should note that we're moving to Linux for our production servers so our interest in the Windows port is waning (at least for the time being). In particular, the stuck WAL segment rename problem has occasionally been rather a pain in the neck. As long as we still have Windows test servers around though, it's easy enough to apply a patch and load up the database to see if anything interesting happens. Pete >>> "Qingqing Zhou" <[EMAIL PROTECTED]> 04/25/06 7:01 am >>> There is a "Win32 semaphore patch" in the patch list, but we are lack of evidence to prove its usefulness. If you can try to apply it to your *test* server (8.0.*, 8.1.* are all ok), that would be very helpful to see the result. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #2406: Not all systems support SHM_SHARE_MMU
On 25-apr-2006, at 7:48, Tom Lane wrote: "Paul van der Zwan" <[EMAIL PROTECTED]> writes: Only systems with large pagesizes support ISM, so always defining #define PG_SHMAT_FLAGS SHM_SHARE_MMU in src/backend/port/sysv_shmem.c will cause all calls to shmat to fail with EINVAL on systems that do not support large pages. That code's been in there since PG 7.3, and no one before you has complained. Are you sure you've identified the problem correctly? regards, tom lane I am 99% sure that is the cause. If I put shmsys:ism_off=1 in /etc/ system it ignores the SHM_SHARE_MMU flag and it works. Maybe noone ever ran Postgres on Solaris on a VIA Epia system. I haven't rebuilt postgres with my suggested patch (yet) so that's were the 1% doubt comes in. I'll try to do that sometime this week. Paul ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #2406: Not all systems support SHM_SHARE_MMU
On 25-apr-2006, at 9:08, Tom Lane wrote: Paul van der Zwan <[EMAIL PROTECTED]> writes: Maybe noone ever ran Postgres on Solaris on a VIA Epia system. Maybe. What is a "VIA Epia system"? VIA is a hardware manufacturer who make small, low power boards with their own X86 compatible cpu on it, you can find more about it on : http://www.via.com.tw/en/ products/mainboards/mini_itx/epia/index.jsp Frankly, I'm afraid that your patch is likely to break way more systems than it fixes. What is getpagesizes(), and is it guaranteed to exist on *every* Solaris system? What the heck correlation does its result have to whether SHM_SHARE_MMU will work? AFAIK getpagesizes() appeared in 2001 so that probably means it is missing in anything before Solaris 9. If you look at line 308 of http://cvs.opensolaris.org/source/xref/on/ usr/src/uts/common/os/shm.c you'll see that shmat return EINVAL if only one pagesize is available. Which is what happens on my system, and possibly also on older (32 bit pre Ultra ) Sparc systems. My guess is that all UltraSparce and 'modern' x86/amd64 cpu's support large pages and therefor will n ever hit this failure mode of shmat(). I'll see if I can get the x86 experts here to have a look at it... Regards Paul ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2305: "No bufferspace available" error on large insert
Hi, I've investigated the problem further, and here are my findings. I believe this will be enough to allow you to provide a permanent fix to this problem. To recap: we get an unusual error message from Postgres when storing a lot of data (hundreds of megabytes) on a machine that is running Windows 2000 and doesn't have all that much memory (384MB). What happens is this: apparently, when both the client and the server of a TCP connection are on the same machine, Windows (at least, this version of it) will allocate as much memory as it needs to hold the data. Since my client is writing much faster than Postgres can store the data, that buffer grows until memory runs out. At that point, instead of returning the normal error code for "out of memory", Windows returns an unusual and non-standard error message. So: - The buffer actually used by Windows is much larger than the one specified by TCP/IP - I'm guessing, for such a local connection, it is simply made as large as it needs to be to hold all the data. - If there is too much data a non-standard error code is returned. I solved the problem by simply waiting for a few seconds when I get back the "no buffer space available" message from Postgres, and retrying the command. This gives Postgres time to do its work, and allows the buffer to shrink to acceptable proportions. Obviously it would be appreciated if Postgres actually did that for me ;-) To reproduce, I simply allocate most of the memory available on the machine (be sure to force it to be committed by writing to it), and then send a large number of large inserts. This causes the buffer to overflow, thus triggering the weird error. I hope this helps in solving this issue. If you have any further questions, please let me know. Regards, Hans Guijt TERMA B.V. Schuttersveld 9 NL-2316 XG, Leiden The Netherlands Phone: +31 (0)71 52 40 835 Telefax: +31 (0)71 51 43 277 E-mail: [EMAIL PROTECTED] - Original Message - From: "John R Pierce" <[EMAIL PROTECTED]> To: "H. Guijt" <[EMAIL PROTECTED]>; Sent: Wednesday, March 08, 2006 10:35 PM Subject: Re: [BUGS] BUG #2305: "No bufferspace available" error on large insert ... Upon issuing the insert statement I receive the following error message: "could not send data to server: No buffer space available (0x2747/10055)" I suspect that this happens because we are inserting a lot of data: the first BYTEA column is about 1.8MB, while the second is about 0.5MB. However... - The same operation completes without problems when running on other machines (which are all running Windows XP and the same Postgres version). ... are the various tuning parameters in $PGDATA/postgresql.conf set the same on these various systems ? ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2406: Not all systems support SHM_SHARE_MMU
Paul van der Zwan <[EMAIL PROTECTED]> writes: > On 25-apr-2006, at 16:46, Tom Lane wrote: >> AFAICS, SHM_SHARE_MMU has no >> guaranteed semantic effect anyway, it's just a performance hint; so >> ignoring it on platforms that can't handle it is reasonable. >> > I disagree, I have no definite info why it is a hard failure, > probably because > there is no way to communicate to the app that it's request is > ignored. Which applications do you think will do anything except exactly what you are proposing we do, ie, just redo the call without the flag bit? Why are you going to make every application jump through this hoop in order to cope with a (possibly temporary) inadequacy in some seldom-used versions of Solaris? We'll probably put in the kluge because we have no other choice, but I strongly disagree that it's our problem. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
