Re: [HACKERS] Python 3.0 does not work with PL/Python
On Monday 06 April 2009 02:10:59 James Pye wrote: Any thoughts on the acceptability of a complete rewrite for Python 3? http://www.joelonsoftware.com/articles/fog69.html -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cleaning up stray references
On Sunday 03 May 2009 18:48:15 Robert Haas wrote: replace a couple of references to files that no longer exist in the source tree with references to the appropriate URLs. Done. I linked to Development_information instead of Developer_FAQ instead, as it is more general. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] windows shared memory error
Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: Now presumably we sleep for 1 sec between the CloseHandle() call and the CreateFileMapping() call in that code for a reason. I'm not sure. Magnus never did answer my question about why the sleep and retry was put in at all; it seems not unlikely from here that it was mere speculation. It was necessary at the time. The actual 1 second value was completely random - it fixed all the issues on my test VM at the time. I don't recall exactly the details, but I do recall having to run a lot of tests before I managed to provoke an error, and that with the 1 sec thing i could run it for a day of repeated restarts without any errors. //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] high shared buffer and swap
Friendly greetings ! I found something odd (something that i can't explain) this weekend. An octocore server with 32GB of ram, running postgresql 8.3.6 Running only postgresql, slony-I and pgbouncer. Just for testing purpose, i tried a setting with 26GB of shared_buffer. I quickly noticed that the performances wasn't very good and the server started to swap slowly but surely. (but still up to 2000query/second as reported by pgfouine) It used all the 2GB of swap. I removed the server from production, added 10GB of swap and left it for the weekend with only slony and postgresql up to keep it in sync with the master database. This morning i found that the whole 12GB of swap were used : Mem: 32892008k total, 32714728k used, 177280k free,70872k buffers Swap: 12582896k total, 12531812k used,51084k free, 27047696k cached # cat /proc/meminfo MemTotal: 32892008 kB MemFree:171140 kB Buffers: 70852 kB Cached: 27065208 kB SwapCached:4752492 kB Active: 24362168 kB Inactive: 7806884 kB HighTotal: 0 kB HighFree:0 kB LowTotal: 32892008 kB LowFree:171140 kB SwapTotal:12582896 kB SwapFree:53064 kB Dirty: 122636 kB Writeback: 0 kB AnonPages: 280336 kB Mapped: 14118588 kB Slab: 224632 kB PageTables: 235120 kB NFS_Unstable:0 kB Bounce: 0 kB CommitLimit: 29028900 kB Committed_AS: 28730620 kB VmallocTotal: 34359738367 kB VmallocUsed: 12916 kB VmallocChunk: 34359725307 kB While i understand that a very high shared_buffer wasn't a good idea, i don't understand this behaviour. Any tought ? I tried this setup because having 2 level of data caching doesn't make sense to me. (1 in OS filesystem cache and 1 in shm (shared_buffer)). I'd love to understand what's happening here ! Thank you :) -- F4FQM Kerunix Flan Laurent Laborde -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] libpq is not thread safe
Tom Lane píše v ne 03. 05. 2009 v 16:39 -0400: Zdenek Kotala zdenek.kot...@sun.com writes: When postgreSQL is compiled with --thread-safe that libpq should be thread safe. But it is not true when somebody call fork(). The problem is that fork() forks only active threads and some mutex can stay locked by another thread. We use ssl_config mutex which is global. fork() without exec() when there are open libpq connections is unbelievably dangerous anyway --- you will have multiple processes that all think they own the same database connection. The difference is that developer can close connection, but he is not able to unlock a lock after fork. OK libpq does not offer any PQFinish variant which frees only resources and close connection without terminate message, but he can do it with dirty hacking. Another advantage of atfork handler is that you can close all open connection and clean resource (similar to what pkcs11 library does). But at this moment libpq does not keep list of open connections and atfork handler works only with pthreads. I think writing code to deal with this for the ssl_config mutex is entirely a waste of time. yeah, I prefer to document it together how to deal with fork() and sessions. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] could not reattach to shared memory captured in buildfarm
Tom Lane wrote: vaquita has an interesting report today: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=vaquitadt=2009-05-01%2020:00:06 Partway through the contrib tests, for absolutely no visible reason whatsoever, connections start to fail with FATAL: could not reattach to shared memory (key=364, addr=0292): 487 Note that 487 is invalid address, and should not have anything to do with the issues Andrew mentioned (which were about the already-exists error). Somebody else mentioned, and IIRC I talked to Dave about this before, that this could be because the address is no longer available. The reason for this could be some kind of race condition in the backends starting - the address is available when the postmaster starts and thus it's used, but when a regular backend starts, the memory is used for something else. One proposed fix is to allocate a fairly large block of memory in the postmaster just before we get the shared memory, and then free it right away. The effect should be to push down the shared memory segment further in the address space. Comments? //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] windows shared memory error
Tom Lane wrote: Magnus Hagander mag...@hagander.net writes: Tom Lane wrote: It says here: http://msdn.microsoft.com/en-us/library/ms885627.aspx FWIW, this is the Windows CE documentation. The one for win32 is at: http://msdn.microsoft.com/en-us/library/ms679360(VS.85).aspx Sorry, that was the one that came up first in a Google search ... Yeah, it's annoying, but that often happens. One has to be careful to check though - the wince stuff is usually just a subset of the full win32, but sometimes there can be subtle differences. So I recommend always making sure you look at the win32 docs, not wince. The quick try would be to stick a SetLastError(0) in there, just to be sure... Could be worth a try? I kinda think we should do that whether or not it can be proven to have anything to do with Andrew's report. It's just like errno = 0 for Unix --- sometimes you have to do it to be sure of whether a particular function has thrown an error. Right. Ok, I've applied a patch that does this. Given that it's certainly not in a performance critical path, the overhead shouldn't be noticeable, and it's certainly not wrong to do it :) //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] windows doesn't notice backend death
Tom Lane wrote: Magnus Hagander mag...@hagander.net writes: FWIW, this certainly used to work. So we've either broken this recently, or it's always been broken on Vista (I've never tried it myself on Vista, only 2000, XP and 2003). Maybe a quick check if it still works on non-Vista versions would be in order, to eliminate one or the other of those theories. I'll have to take this back. I just tested back to 8.2.latest on XP, and it has the same behavior. We don't notice a kill -9 from the task manager. If it worked, it's either 8.2, or it's something that changed with a service pack to XP as well. //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] windows doesn't notice backend death
Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: Well, I can tell you that it is getting an exit code of 1, which is why the postmaster isn't restarting. Blech. Count on Windows to find a way to break things. Yup. A quick search gives this: http://support.microsoft.com/kb/155075 which clearly states that task manager simply uses TerminateProcess(). And it's probably hard-coded with an exit code. Which really means this can't have worked, and my memory was wrong. I still claim it works when the process actually *crashes* though - since that will give you one of those funky huge exit numbers. That raises two questions in my mind. First, is that the behaviour we expect when we kill the backend this way? And second, why is it still showing up in the output of pg_stat_activity? Well, if the process is being hard-killed without an opportunity to run through proc_exit(), then yes it is going to still show up in pg_stat_activity. It's pgstat_beshutdown_hook that removes that entry. That's certainly what task manager does. TerminateProcess() just stops all threads and removes the process. No chance for atexit() stuff to run. The problem here is that we need to be able to distinguish a task manager kill from a voluntary exit(1). Have M$ really been stupid enough to make an external kill look just like an exit() call? It certainly looks that way. It probably goes back to the use threads, not processes, on this platform design... //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] windows doesn't notice backend death
Andrew Dunstan wrote: justin wrote: Tom Lane wrote: Have M$ really been stupid enough to make an external kill look just like an exit() call? regards, tom lane kind of :-( Would it not be easy to set the normal exitcode to something other than 1 to see the difference ExitProcess() Not really, as Tom showed later this is an example of a more general problem. I think his solution of detecting when backends have cleaned up nicely and when they have not is the right way to go. Well, if we picked a different value than 1, the probability would certainly go up that things work. I bet most external libs that do such an evil thing would be doing exit(1). If we picked a return code way up in the space (say something well above 2^16), the likelihood that a lib would be using exactly that one decreases drastically. But there's no guarantee - so it'd just be a better workaround. //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why isn't stats_temp_directory automatically created?
Tom Lane wrote: Fujii Masao masao.fu...@gmail.com writes: Here is the revised patch; If stats_temp_directory indicates the symlink, we pursue the chain of symlinks and create the referenced directory. I looked at this patch a bit. I'm still entirely unconvinced that we should be doing this at all --- if the directory is not there, there's a significant probability that there's something wrong that is beyond the backend's ability to understand or correct. However, even ignoring that objection, the patch is not ready to commit for a number of reasons: * Repeating the operation every time the stats file is written doesn't seem like a particularly good idea; it eats cycles, and if the directory disappears during live operation then there is *definitely* something fishy going on. Can't we fix it so that the work is only done when the path setting changes? (In principle you could do it in assign_pgstat_temp_directory(), but I think something would be needed to ensure that only the stats collector process actually tries to create the directory. Or maybe it would be simplest to try to run the code only when we get a failure from trying to create the stats temp file.) My idea was to have it run when it tries to create the temp file and fails. Seems simpler than in the assign hook. * I don't think the mkdir_p code belongs in fd.c. It looks like you copied-and-pasted it from initdb.c, which isn't any good either; we don't want to maintain multiple copies of this. Maybe a new src/port/ file is indicated. Yes, that's what I thought as well. How about src/port/dirmod.c though - it has rename/unlink/symlink now which seem at least remotely related. //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] high shared buffer and swap
Sorry for top-posting - the iphone mail client sucks. I think what's happening is that the sytem is seeing that some pages of shared memory haven't been used recently and because there's more shared memory than filesystem cache less recently than the filesystem cache pages. So it pages out the shared memory. This is really awful because we use a kind of lru algorithm for shared memory so the pages that it's paging out are precisely the pges likely to be used soon. I wonder if we should try to mlock shared buffers. -- Greg On 4 May 2009, at 10:10, Laurent Laborde kerdez...@gmail.com wrote: Friendly greetings ! I found something odd (something that i can't explain) this weekend. An octocore server with 32GB of ram, running postgresql 8.3.6 Running only postgresql, slony-I and pgbouncer. Just for testing purpose, i tried a setting with 26GB of shared_buffer. I quickly noticed that the performances wasn't very good and the server started to swap slowly but surely. (but still up to 2000query/second as reported by pgfouine) It used all the 2GB of swap. I removed the server from production, added 10GB of swap and left it for the weekend with only slony and postgresql up to keep it in sync with the master database. This morning i found that the whole 12GB of swap were used : Mem: 32892008k total, 32714728k used, 177280k free,70872k buffers Swap: 12582896k total, 12531812k used,51084k free, 27047696k cached # cat /proc/meminfo MemTotal: 32892008 kB MemFree:171140 kB Buffers: 70852 kB Cached: 27065208 kB SwapCached:4752492 kB Active: 24362168 kB Inactive: 7806884 kB HighTotal: 0 kB HighFree:0 kB LowTotal: 32892008 kB LowFree:171140 kB SwapTotal:12582896 kB SwapFree:53064 kB Dirty: 122636 kB Writeback: 0 kB AnonPages: 280336 kB Mapped: 14118588 kB Slab: 224632 kB PageTables: 235120 kB NFS_Unstable:0 kB Bounce: 0 kB CommitLimit: 29028900 kB Committed_AS: 28730620 kB VmallocTotal: 34359738367 kB VmallocUsed: 12916 kB VmallocChunk: 34359725307 kB While i understand that a very high shared_buffer wasn't a good idea, i don't understand this behaviour. Any tought ? I tried this setup because having 2 level of data caching doesn't make sense to me. (1 in OS filesystem cache and 1 in shm (shared_buffer)). I'd love to understand what's happening here ! Thank you :) -- F4FQM Kerunix Flan Laurent Laborde -- Sent via pgsql-performance mailing list (pgsql-performa...@postgresql.org ) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] windows doesn't notice backend death
Tom Lane wrote: I wrote: The first idea that comes to mind is to have some sort of dead man switch that flags an active backend and is reset by proc_exit() after it's finished cleaning up everything else. If the postmaster sees this flag still set after backend exit, then it treats the backend as having crashed regardless of what the reported exit code is. Another thought that came to mind: we could set up an atexit hook that does all the work that proc_exit() currently does, and reduce proc_exit() itself to just an exit() call. psql already relies on having atexit (or on_exit) so this doesn't appear to add any new portability issues. This will probably not fix the Vista taskmanager issue, since I'll bet it's not running atexit hooks anyway. What it would do is improve the situation so that a clueless exit() call would be no worse than elog(FATAL), rather than triggering a DB-wide restart as the dead man switch would do. This sounds like a good idea in general - because it will avoid having to restart on unix. It'd still have to be combined with the dead-man-switch idea to defend completely. But it could be worthwhile doing anyway, for other platforms. //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] high shared buffer and swap
On Mon, May 04, 2009 at 10:57:47AM +0200, Greg Stark wrote: I think what's happening is that the sytem is seeing that some pages of shared memory haven't been used recently and because there's more shared memory than filesystem cache less recently than the filesystem cache pages. So it pages out the shared memory. This is really awful because we use a kind of lru algorithm for shared memory so the pages that it's paging out are precisely the pges likely to be used soon. I wonder if we should try to mlock shared buffers. You can try, but it probably won't work. You often need to be root to lock pages, and even on Linux 2.6.9+ where you don't need to be root there's a limit of 32KB (that's only my machine anyway). Sure, that can be changed, if you're root. Actually locking the shared buffers seems to me like a footgun. People occasionally give postgresql masses of memory leaving not enough to run the rest of the system. Locking the memory would make the situation worse. Personally I've never seen a benefit of setting shared buffer above the expected working set size. I generally let the kernel share the remaining memory between postgresql disk cache and other processes I might be running. On a NUMA machine you want to be keeping your memory on the local node and letting the kernel copy that data from elsewhere to your local memory when you need it. Have a nice day, -- Martijn van Oosterhout klep...@svana.org http://svana.org/kleptog/ Please line up in a tree and maintain the heap invariant while boarding. Thank you for flying nlogn airlines. signature.asc Description: Digital signature
Re: [HACKERS] Python 3.0 does not work with PL/Python
On May 3, 2009, at 11:02 PM, Peter Eisentraut wrote: http://www.joelonsoftware.com/articles/fog69.html Good read. =) However, complete rewrite being relative in this case: WIP: http://github.com/jwp/postgresql-plpython3/tree/c804e693b6a0df98c0e5c465e75ba2e9014ebf37/src/pl/plpython3 That is, from pgsql's perspective it would be a complete rewrite. From my perspective it would be a refactored version of plpy for Python 3.x and pgsql 8.5/head. Additionally, plpy originally came from plpythonu(7.3 or 7.4), but was *massively* refactored(read: effectively rewritten). I wouldn't want to start from scratch, actually. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Documentation: GiST extension implementation
On Wednesday 29 April 2009 16:43:44 Dimitri Fontaine wrote: The following documentation page explains the GiST API to extensions authors: I think we should be a little more verbose, I didn't propose a real doc patch mainly because english isn't my native language, and while you'll have to reword the content... There aren't a lot of people who have the experience to write that documentation. So if you want to improve it, you will have to write it, or at least organize the outline. Others can help cleaning it up. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] windows doesn't notice backend death
Magnus Hagander mag...@hagander.net writes: Tom Lane wrote: Another thought that came to mind: we could set up an atexit hook that This sounds like a good idea in general - because it will avoid having to restart on unix. It'd still have to be combined with the dead-man-switch idea to defend completely. But it could be worthwhile doing anyway, for other platforms. Right, exactly. I'll try to produce a patch today. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] windows shared memory error
Magnus Hagander wrote: Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: Now presumably we sleep for 1 sec between the CloseHandle() call and the CreateFileMapping() call in that code for a reason. I'm not sure. Magnus never did answer my question about why the sleep and retry was put in at all; it seems not unlikely from here that it was mere speculation. It was necessary at the time. The actual 1 second value was completely random - it fixed all the issues on my test VM at the time. I don't recall exactly the details, but I do recall having to run a lot of tests before I managed to provoke an error, and that with the 1 sec thing i could run it for a day of repeated restarts without any errors. Well, my untested hypothesis is that the actual time required is variable, depending on environmental factors such as machine load. So testing repeatedly where such factors are constant might not be good enough. That's why I suggested some sort of increasing backoff, in an attempt to be adaptive. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] windows shared memory error
Andrew Dunstan and...@dunslane.net writes: Magnus Hagander wrote: The actual 1 second value was completely random - it fixed all the issues on my test VM at the time. I don't recall exactly the details, but I do recall having to run a lot of tests before I managed to provoke an error, and that with the 1 sec thing i could run it for a day of repeated restarts without any errors. Well, my untested hypothesis is that the actual time required is variable, depending on environmental factors such as machine load. Seems reasonable. So testing repeatedly where such factors are constant might not be good enough. That's why I suggested some sort of increasing backoff, in an attempt to be adaptive. I still think there's absolutely no evidence suggesting that a variable backoff is necessary. Given how little this code is going to be exercised in the real world, how long will it take till we find out if you get it wrong? Use a simple retry loop and be done with it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] could not reattach to shared memory captured in buildfarm
Magnus Hagander mag...@hagander.net writes: Somebody else mentioned, and IIRC I talked to Dave about this before, that this could be because the address is no longer available. The reason for this could be some kind of race condition in the backends starting - the address is available when the postmaster starts and thus it's used, but when a regular backend starts, the memory is used for something else. How is it no longer available, when the new backend is a brand new process? The race condition bit seems even sillier --- if there are multiple backends starting, they're each an independent process. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] windows shared memory error
Tom Lane wrote: I still think there's absolutely no evidence suggesting that a variable backoff is necessary. Given how little this code is going to be exercised in the real world, how long will it take till we find out if you get it wrong? Use a simple retry loop and be done with it. Why should a 1 second delay between CloseHandle() and CreateFileMapping() be enough now when it was not enough 1 second ago? If the event we needed an offset from were outside the loop I'd agree with you. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] windows shared memory error
Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: Magnus Hagander wrote: The actual 1 second value was completely random - it fixed all the issues on my test VM at the time. I don't recall exactly the details, but I do recall having to run a lot of tests before I managed to provoke an error, and that with the 1 sec thing i could run it for a day of repeated restarts without any errors. Well, my untested hypothesis is that the actual time required is variable, depending on environmental factors such as machine load. Seems reasonable. So testing repeatedly where such factors are constant might not be good enough. That's why I suggested some sort of increasing backoff, in an attempt to be adaptive. I still think there's absolutely no evidence suggesting that a variable backoff is necessary. Given how little this code is going to be exercised in the real world, how long will it take till we find out if you get it wrong? Use a simple retry loop and be done with it. +1. Let's keep it as simple as possible for now. I doubt it's actually dependent on the *failed* call. Andrew, you want to write up a patch or do you want me to do it? //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PERFORM] high shared buffer and swap
On Mon, May 4, 2009 at 2:10 AM, Laurent Laborde kerdez...@gmail.com wrote: Friendly greetings ! I found something odd (something that i can't explain) this weekend. An octocore server with 32GB of ram, running postgresql 8.3.6 Running only postgresql, slony-I and pgbouncer. Just for testing purpose, i tried a setting with 26GB of shared_buffer. I quickly noticed that the performances wasn't very good and the server started to swap slowly but surely. (but still up to 2000query/second as reported by pgfouine) It used all the 2GB of swap. I removed the server from production, added 10GB of swap and left it for the weekend with only slony and postgresql up to keep it in sync with the master database. This morning i found that the whole 12GB of swap were used : Mem: 32892008k total, 32714728k used, 177280k free, 70872k buffers Swap: 12582896k total, 12531812k used, 51084k free, 27047696k cached Try setting swappiness =0. But as someone else mentioned, I've alwas had better luck letting the OS do most of the caching anyway. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] conditional dropping of columns/constraints
On 05/04/2009 04:10 PM, Andres Freund wrote: Would a patch adding 'IF EXISTS' support to: - ALTER TABLE ... DROP COLUMN - ALTER TABLE ... DROP CONSTRAINT possibly be accepted? Having it makes the annoying task of writing/testing of schema-upgrade scripts a bit easier. Oh, and to any other sensible place given there are more? Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] windows shared memory error
Magnus Hagander wrote: Andrew, you want to write up a patch or do you want me to do it? This is going to be backpatched, I assume? -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Synchronous replication: Promotion of Standby to Primary
Hi, Re-opening the discussion related to triggers to promote standby server. In the earlier dicussion, there were 2 proposals, Trigger based on file and trigger based on signals. I think there was no conclusion on this. http://archives.postgresql.org/pgsql-hackers/2008-12/msg01231.php According to the proposal, it seems to be better if signals are used as we can avoid checking the file existance in the loop. Or the other approach is to use inotify (http://en.wikipedia.org/wiki/Inotify). But portability to other unix like OS is an issue to look for. Could you please get back which is being implemented/ considered for promotion of standby? regards, Niranjan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] windows shared memory error
Alvaro Herrera alvhe...@commandprompt.com writes: This is going to be backpatched, I assume? Yeah, back to 8.2 I suppose. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] windows shared memory error
Magnus Hagander mag...@hagander.net writes: Tom Lane wrote: I still think there's absolutely no evidence suggesting that a variable backoff is necessary. Given how little this code is going to be exercised in the real world, how long will it take till we find out if you get it wrong? Use a simple retry loop and be done with it. +1. Let's keep it as simple as possible for now. I doubt it's actually dependent on the *failed* call. Exactly. Presumably we're waiting for some system bookkeeping to finish. Maybe it will take more than 1 second, but we're not going to be slowing it noticeably by trying once a second. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] could not reattach to shared memory captured in buildfarm
Tom Lane wrote: Magnus Hagander mag...@hagander.net writes: Somebody else mentioned, and IIRC I talked to Dave about this before, that this could be because the address is no longer available. The reason for this could be some kind of race condition in the backends starting - the address is available when the postmaster starts and thus it's used, but when a regular backend starts, the memory is used for something else. How is it no longer available, when the new backend is a brand new process? The race condition bit seems even sillier --- if there are multiple backends starting, they're each an independent process. Because some other DLL that was loaded on process startup allocated memory differently - in a different order, different size because or something, or something like that. I didn't mean race condition between backends. I meant against a potential other thread started by a loaded DLL for initialization. (Again, things like antivirus are known to do this, and we do see these issues more often if AV is present for example) //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] windows shared memory error
Magnus Hagander wrote: Andrew, you want to write up a patch or do you want me to do it? Go for it. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] conditional dropping of columns/constraints
Hi, Would a patch adding 'IF EXISTS' support to: - ALTER TABLE ... DROP COLUMN - ALTER TABLE ... DROP CONSTRAINT possibly be accepted? Having it makes the annoying task of writing/testing of schema-upgrade scripts a bit easier. Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] hellow Postmaster and Postgres
hi please I want to understands what is the tie between Postgres.c and Postmaster.c thanks
Re: [HACKERS] conditional dropping of columns/constraints
On Mon, May 4, 2009 at 10:10 AM, Andres Freund and...@anarazel.de wrote: Would a patch adding 'IF EXISTS' support to: - ALTER TABLE ... DROP COLUMN - ALTER TABLE ... DROP CONSTRAINT possibly be accepted? Having it makes the annoying task of writing/testing of schema-upgrade scripts a bit easier. Can't speak for the committers, but I've wished for this a time or two myself. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] hellow Postmaster and Postgres
On Monday 04 May 2009 17:24:29 abdelhak benmohamed wrote: what is the tie between Postgres.c and Postmaster.c Roughly speaking, postgres.c is the server session process, and postmaster.c is the master process that forks the session processes. The entry point to everything is in main.c. Start reading there if you are interested in the details. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] hellow Postmaster and Postgres
On Mon, May 4, 2009 at 10:24 AM, abdelhak benmohamed abdelhak.benmoha...@yahoo.fr wrote: hi please I want to understands what is the tie between Postgres.c and Postmaster.c thanks Like most of the questions you've posted to the list in the last month, this question is so general that I'm not really sure what sort of answer you're looking for. If you know C, you should be able to read the code and the comments and answer this question for yourself, or at least post a much more specific question. If you don't know C, the people who read this mailing list are not going to teach you, just because none of us get paid to do that. You should think about signing up for a programming class. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Synchronous replication: replication_timeout parameter
Hi, This is with respect to the planned GUC parameter 'replication_timeout' which used in context with 'replication_timeout_action' parameter. http://archives.postgresql.org/pgsql-hackers/2008-12/msg01231.php Here the proposal is to use the milliseconds as the unit for the 'replication_timeout'. The client applications based on the type of transactions ie if the applications support very large transactions and if it uses low-end HW configurations for replication, then it need to configure this parameter correctly to avoid unneccessary timeouts. Are there any ideas already implemented in this front? Also are there any possible conflicts because of inclusion of this parameter? regards, Niranjan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Synchronous replication: Admin command for replication_timeout_action
Hi, This is to support an admin command or utility which can trigger the server to be taken to a standalone mode if there a connection failure detection between Primary and server. It need not be always, that the replication_timeout needs to be accomplished to detect the connection failure because it could happen that cluster/hearbeat framework might detect the connection failure earlier to the replication_timeout. So the admin command, which will abstract the implementation details will assist in taking the server to standalone mode earlier to replication_timeout. Are there any suggestions from your side with respect to this? regards, Niranjan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] ALTER TABLE should change respective views
hi, I have many views dependent on a table. So whenever I do alter table and change the column type I have to drop and recreate all the views. Is there any other easy way to propagate the changes in the table to the views. Any suggestion is welcome. Thanks,Archana
Re: [HACKERS] windows shared memory error
Andrew Dunstan wrote:
Magnus Hagander wrote:
Andrew, you want to write up a patch or do you want me to do it?
Go for it.
How does this look?
Passes my tests, but I can't really reproduce the requirement to retry,
so I haven't been able to test that part :(
//Magnus
*** a/src/backend/port/win32_shmem.c
--- b/src/backend/port/win32_shmem.c
***
*** 123,128 PGSharedMemoryCreate(Size size, bool makePrivate, int port)
--- 123,129
HANDLE hmap,
hmap2;
char *szShareMem;
+ int i;
/* Room for a header? */
Assert(size MAXALIGN(sizeof(PGShmemHeader)));
***
*** 131,184 PGSharedMemoryCreate(Size size, bool makePrivate, int port)
UsedShmemSegAddr = NULL;
- /* In case CreateFileMapping() doesn't set the error code to 0 on success */
- SetLastError(0);
-
- hmap = CreateFileMapping((HANDLE) 0x, /* Use the pagefile */
- NULL, /* Default security attrs */
- PAGE_READWRITE, /* Memory is Read/Write */
- 0L, /* Size Upper 32 Bits */
- (DWORD) size, /* Size Lower 32 bits */
- szShareMem);
-
- if (!hmap)
- ereport(FATAL,
- (errmsg(could not create shared memory segment: %lu, GetLastError()),
- errdetail(Failed system call was CreateFileMapping(size=%lu, name=%s).,
- (unsigned long) size, szShareMem)));
-
/*
! * If the segment already existed, CreateFileMapping() will return a
! * handle to the existing one.
*/
! if (GetLastError() == ERROR_ALREADY_EXISTS)
{
- /*
- * When recycling a shared memory segment, it may take a short while
- * before it gets dropped from the global namespace. So re-try after
- * sleeping for a second.
- */
- CloseHandle(hmap); /* Close the old handle, since we got a valid
- * one to the previous segment. */
-
- Sleep(1000);
-
/* In case CreateFileMapping() doesn't set the error code to 0 on success */
SetLastError(0);
! hmap = CreateFileMapping((HANDLE) 0x, NULL, PAGE_READWRITE, 0L, (DWORD) size, szShareMem);
if (!hmap)
ereport(FATAL,
(errmsg(could not create shared memory segment: %lu, GetLastError()),
errdetail(Failed system call was CreateFileMapping(size=%lu, name=%s).,
(unsigned long) size, szShareMem)));
if (GetLastError() == ERROR_ALREADY_EXISTS)
! ereport(FATAL,
! (errmsg(pre-existing shared memory block is still in use),
! errhint(Check if there are any old server processes still running, and terminate them.)));
}
free(szShareMem);
/*
--- 132,184
UsedShmemSegAddr = NULL;
/*
! * When recycling a shared memory segment, it may take a short while
! * before it gets dropped from the global namespace. So re-try after
! * sleeping for a second, and continue retrying 10 times.
! * (both the 1 second time and the 10 retries are completely arbitrary)
*/
! for (i = 0; i 10; i++)
{
/* In case CreateFileMapping() doesn't set the error code to 0 on success */
SetLastError(0);
! hmap = CreateFileMapping((HANDLE) 0x, /* Use the pagefile */
! NULL, /* Default security attrs */
! PAGE_READWRITE, /* Memory is Read/Write */
! 0L, /* Size Upper 32 Bits */
! (DWORD) size, /* Size Lower 32 bits */
! szShareMem);
!
if (!hmap)
ereport(FATAL,
(errmsg(could not create shared memory segment: %lu, GetLastError()),
errdetail(Failed system call was CreateFileMapping(size=%lu, name=%s).,
(unsigned long) size, szShareMem)));
+ /*
+ * If the segment already existed, CreateFileMapping() will return a
+ * handle to the existing one.
+ */
if (GetLastError() == ERROR_ALREADY_EXISTS)
! {
! CloseHandle(hmap); /* Close the old handle, since we got a valid
! * one to the previous segment. */
! Sleep(1000);
! continue;
! }
! break;
}
+ /*
+ * If the last call in the loop still returned ERROR_ALREADY_EXISTS, this shared memory
+ * segment exists and we assume it belongs to somebody else.
+ */
+ if (GetLastError() == ERROR_ALREADY_EXISTS)
+ ereport(FATAL,
+ (errmsg(pre-existing shared memory block is still in use),
+ errhint(Check if there are any old server processes still running, and terminate them.)));
+
free(szShareMem);
/*
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] windows shared memory error
Magnus Hagander wrote: How does this look? Passes my tests, but I can't really reproduce the requirement to retry, so I haven't been able to test that part :( I'm disappointed :-( I thought this thread (without reading it too deeply) was about fixing the problem that backends sometimes fail to connect to shmem, on a system that's been running for a while. But I see that it's about recycling the segment after a crash (and/or restart?), so it has no relationship to the other case at all :-( I can't comment on the patch itself. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unicode string literals versus the world
On Tuesday 14 April 2009 21:34:51 Peter Eisentraut wrote:
On Tuesday 14 April 2009 17:13:00 Marko Kreen wrote:
If the parsing does not happen in 2 passes and it does not take account
of stdstr setting then the default breakage would be:
stdstr=off, U' \' UESCAPE '!'.
I think we can handle that and the cases Tom presents by erroring out when
the U syntax is used with stdstr off.
Proposed patch for that attached.
Index: doc/src/sgml/syntax.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v
retrieving revision 1.131
diff -u -3 -p -r1.131 syntax.sgml
--- doc/src/sgml/syntax.sgml 27 Apr 2009 16:27:36 - 1.131
+++ doc/src/sgml/syntax.sgml 4 May 2009 22:08:27 -
@@ -500,6 +500,17 @@ Uamp;'d!0061t!+61' UESCAPE '!'
/para
para
+ Also, the Unicode escape syntax for string constants only works
+ when the configuration
+ parameter xref linkend=guc-standard-conforming-strings is
+ turned on. This is because otherwise this syntax could confuse
+ clients that parse the SQL statements to the point that it could
+ lead to SQL injections and similar security issues. If the
+ parameter is set to off, this syntax will be rejected with an
+ error message.
+/para
+
+para
To include the escape character in the string literally, write it
twice.
/para
Index: src/backend/parser/scan.l
===
RCS file: /cvsroot/pgsql/src/backend/parser/scan.l,v
retrieving revision 1.151
diff -u -3 -p -r1.151 scan.l
--- src/backend/parser/scan.l 19 Apr 2009 21:08:54 - 1.151
+++ src/backend/parser/scan.l 4 May 2009 22:08:27 -
@@ -469,6 +469,11 @@ other .
startlit();
}
{xusstart} {
+ if (!standard_conforming_strings)
+ ereport(ERROR,
+(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+ errmsg(unsafe use of string constant with Unicode escapes),
+ errdetail(String constants with Unicode escapes cannot be used when standard_conforming_strings is off.)));
SET_YYLLOC();
BEGIN(xus);
startlit();
Index: src/test/regress/expected/strings.out
===
RCS file: /cvsroot/pgsql/src/test/regress/expected/strings.out,v
retrieving revision 1.35
diff -u -3 -p -r1.35 strings.out
--- src/test/regress/expected/strings.out 29 Oct 2008 08:04:54 - 1.35
+++ src/test/regress/expected/strings.out 4 May 2009 22:08:27 -
@@ -22,6 +22,7 @@ ERROR: syntax error at or near ' - thi
LINE 3: ' - third line'
^
-- Unicode escapes
+SET standard_conforming_strings TO on;
SELECT U'd\0061t\+61' AS Ud\0061t\+61;
data
--
@@ -34,6 +35,18 @@ SELECT U'd!0061t\+61' UESCAPE '!' A
dat\+61
(1 row)
+SELECT U' \' UESCAPE '!' AS tricky;
+ tricky
+
+ \
+(1 row)
+
+SELECT 'tricky' AS U\ UESCAPE '!';
+ \
+
+ tricky
+(1 row)
+
SELECT U'wrong: \061';
ERROR: invalid Unicode escape value at or near \061'
LINE 1: SELECT U'wrong: \061';
@@ -46,6 +59,32 @@ SELECT U'wrong: +0061' UESCAPE '+';
ERROR: invalid Unicode escape character at or near +'
LINE 1: SELECT U'wrong: +0061' UESCAPE '+';
^
+SET standard_conforming_strings TO off;
+SELECT U'd\0061t\+61' AS Ud\0061t\+61;
+ERROR: unsafe use of string constant with Unicode escapes
+DETAIL: String constants with Unicode escapes cannot be used when standard_conforming_strings is off.
+SELECT U'd!0061t\+61' UESCAPE '!' AS Ud*0061t\+61 UESCAPE '*';
+ERROR: unsafe use of string constant with Unicode escapes
+DETAIL: String constants with Unicode escapes cannot be used when standard_conforming_strings is off.
+SELECT U' \' UESCAPE '!' AS tricky;
+ERROR: unsafe use of string constant with Unicode escapes
+DETAIL: String constants with Unicode escapes cannot be used when standard_conforming_strings is off.
+SELECT 'tricky' AS U\ UESCAPE '!';
+ \
+
+ tricky
+(1 row)
+
+SELECT U'wrong: \061';
+ERROR: unsafe use of string constant with Unicode escapes
+DETAIL: String constants with Unicode escapes cannot be used when standard_conforming_strings is off.
+SELECT U'wrong: \+0061';
+ERROR: unsafe use of string constant with Unicode escapes
+DETAIL: String constants with Unicode escapes cannot be used when standard_conforming_strings is off.
+SELECT U'wrong: +0061' UESCAPE '+';
+ERROR: unsafe use of string constant with Unicode escapes
+DETAIL: String constants with Unicode escapes cannot be used when standard_conforming_strings is off.
+RESET standard_conforming_strings;
--
-- test conversions between various string types
-- E021-10 implicit casting among the character data types
Index: src/test/regress/sql/strings.sql
===
RCS file: /cvsroot/pgsql/src/test/regress/sql/strings.sql,v
retrieving revision
Re: [HACKERS] windows doesn't notice backend death
I wrote: I don't think we'll be able to prevent PHP from doing that :-(. But it now seems clear that we should try to make the database as a whole recover with some degree of grace. I'll go work up a patch. Attached is a proposed patch for the dead man switch idea. The switch is armed when a child process acquires a regular PGPROC and disarmed when the PGPROC is released. (So there is no coverage for auxiliary processes, but I doubt we need that.) I chose to put the management code into pmsignal.c --- if you hold your head at the proper angle, this can be seen as a form of child-to-postmaster signaling, so that seemed like a reasonable place. The array slot number is passed down to child processes in the same way as for MyCancelKey. Also, since the number of array slots needed is exactly the same as the size of the ShmemBackendArray for the EXEC_BACKEND case, I tweaked the code for the latter a little bit to avoid duplicate array-searching --- the array slot number assigned for the deadman switch flag is also used to index ShmemBackendArray. One bit of ugliness is that in the EXEC_BACKEND case, InitProcess is done before CreateSharedMemoryAndSemaphores; so it's necessary to have special-case code to pass down the shmem state pointer for pmsignal.c, similarly to what we do for ProcGlobal and a few other pointers. We could avoid that by arming the switch only sometime after CreateSharedMemoryAndSemaphores ... but if we're gonna have this mechanism at all, I'd like it to cover the process's entire ownership of shared-memory objects, not only part of it. This doesn't include the proposed change to use an atexit callback to ensure that proc_exit cleanup gets done --- that looks like a trivial refactoring in proc_exit, but it's a separate idea anyway. Barring objections I'll go ahead and apply this to HEAD. I'm wondering whether we are sufficiently worried about the Windows task manager issue to risk back-patching into 8.3 and 8.2 ... comments? regards, tom lane binzFCsl5KUH7.bin Description: dead-man-switch-1.patch.gz -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] windows shared memory error
Alvaro Herrera alvhe...@commandprompt.com writes: I'm disappointed :-( I thought this thread (without reading it too deeply) was about fixing the problem that backends sometimes fail to connect to shmem, on a system that's been running for a while. Nobody knows yet what's wrong there or how to fix it. This thread is about Andrew's complaint here: http://archives.postgresql.org//pgsql-hackers/2009-05/msg3.php which seems relatively straightforward to fix, or at least reduce the probability of trouble to the vanishing point. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] windows shared memory error
Magnus Hagander mag...@hagander.net writes: Passes my tests, but I can't really reproduce the requirement to retry, so I haven't been able to test that part :( The patch looks sane to me. If you want to test, perhaps reducing the sleep to 1 msec or so would reproduce the need to go around the loop more than once. (Don't forget to put the machine under additional load, too.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unicode string literals versus the world
Peter Eisentraut pete...@gmx.net writes: On Tuesday 14 April 2009 21:34:51 Peter Eisentraut wrote: I think we can handle that and the cases Tom presents by erroring out when the U syntax is used with stdstr off. Proposed patch for that attached. I have not been able to think of any security hole in that proposal, so this patch seems acceptable to me. I wonder though whether any corresponding change is needed in psql's lexer, and if so how should it react exactly to the rejection case. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] ERROR: out of memory when using aggregates over a partitioned table
Hi everyone, I'm unexpectedly getting out of memory error both with 8.3.3 and 8.4beta1 when doing something as simple as: SELECT id, COUNT(*) AS counter, MAX(last_modified) AS last_modified FROM foo GROUP BY id; where foo is a partitioned table and id is a uuid column. It looks like the HashAggregate estimate is set to a default of 200 even though ndistinct in each partition is averaging at -0.59. As RhodiumToad pointed out there's a comment explaining the behaviour: * XXX This means the Var represents a column of an append * relation. Later add code to look at the member relations and * try to derive some kind of combined statistics? I just wanted to raise it as something that might happen to those using partitions as it's very likely that a partitioned table is bigger than the available RAM. However I don't think it happens very often that one needs to run an aggregate query on it. I just needed it to populate a separate table that will be kept up to date via triggers. Here's the EXPLAIN output: HashAggregate (cost=1344802.32..1344805.32 rows=200 width=24) - Append (cost=0.00..969044.47 rows=50101047 width=24) - Seq Scan on foo (cost=0.00..16.60 rows=660 width=24) - Seq Scan on part_0 foo (cost=0.00..60523.89 rows=3129289 width=24) - Seq Scan on part_1 foo (cost=0.00..60555.37 rows=3130937 width=24) - Seq Scan on part_2 foo (cost=0.00..60532.17 rows=3129717 width=24) - Seq Scan on part_3 foo (cost=0.00..60550.86 rows=3130686 width=24) - Seq Scan on part_4 foo (cost=0.00..60545.07 rows=3130407 width=24) - Seq Scan on part_5 foo (cost=0.00..60579.93 rows=3131393 width=24) - Seq Scan on part_6 foo (cost=0.00..60566.70 rows=3131470 width=24) - Seq Scan on part_7 foo (cost=0.00..60610.66 rows=3133766 width=24) - Seq Scan on part_8 foo (cost=0.00..60546.67 rows=3129667 width=24) - Seq Scan on part_9 foo (cost=0.00..60509.92 rows=3128592 width=24) - Seq Scan on part_a foo (cost=0.00..60581.25 rows=3132225 width=24) - Seq Scan on part_b foo (cost=0.00..60552.81 rows=3130781 width=24) - Seq Scan on part_c foo (cost=0.00..60621.15 rows=3134315 width=24) - Seq Scan on part_d foo (cost=0.00..60714.26 rows=3139126 width=24) - Seq Scan on part_e foo (cost=0.00..60552.85 rows=3130785 width=24) - Seq Scan on part_f foo (cost=0.00..60484.31 rows=3127231 width=24) Cheers -- Matteo Beccati http://www.openx.org/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] community equipment
Hi all, It has been brought to our attention that many in the PostgreSQL community are still not aware that we have equipment which has been donated for community use (e.g. development and testing). As requested we have set up an additional web page on pgfoundy and a new mailing list to discuss usage of the equipment. Note that the web page points back to the wiki for information that was already been created, and that this mailing lists is not intended to replace lists already in place such as pgsql-hackers or pgsql-performance: http://perflab.projects.postgresql.org/ Regards, Mark -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] could not reattach to shared memory captured in buildfarm
Magnus Hagander wrote: I didn't mean race condition between backends. I meant against a potential other thread started by a loaded DLL for initialization. (Again, things like antivirus are known to do this, and we do see these issues more often if AV is present for example) I don't understand this. How can memory allocated by a completely separate process affect what happens to a backend? I mean, if an antivirus is running, surely it does not run on the backend's process? Or does it? -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unicode string literals versus the world
Hi.
quick test for great patch. !
== SCRIPT ==
set CLIENT_ENCODING to 'UTF-8';
DROP TABLE ucheck CASCADE;
CREATE TABLE ucheck (key VARCHAR(10) PRIMARY KEY, data NCHAR(50));
set STANDARD_CONFORMING_STRINGS to on;
INSERT INTO ucheck VALUES('ucheck1',u'\68ee\9dd7\5916');
SELECT * FROM ucheck;
set CLIENT_ENCODING to 'SHIFTJIS2004';
SELECT * FROM ucheck;
set STANDARD_CONFORMING_STRINGS to off;
INSERT INTO ucheck VALUES('ucheck2',u'\68ee\9dd7\5916');
=== As for psql ===
This should notice the console of Japanese windows-XP about code can't to display.
C:\workpsql
psql (8.4beta1)
help でヘルプを表示します.
HIROSHI=# set CLIENT_ENCODING to 'UTF-8';
SET
HIROSHI=# DROP TABLE ucheck CASCADE;
DROP TABLE
HIROSHI=# CREATE TABLE ucheck (key VARCHAR(10) PRIMARY KEY, data NCHAR(50));
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index ucheck_pkey for
table ucheck
CREATE TABLE
HIROSHI=# set STANDARD_CONFORMING_STRINGS to on;
SET
HIROSHI=# INSERT INTO ucheck VALUES('ucheck',u'\68ee\9dd7\5916');
INSERT 0 1
HIROSHI=# SELECT * FROM ucheck;
key | data
+---
ucheck | 譽ョ鮃怜、・
(1 行)
HIROSHI=# set CLIENT_ENCODING to 'SHIFTJIS2004';
SET
HIROSHI=# SELECT * FROM ucheck;
key | data
+---
ucheck | 森・外
(1 行)
HIROSHI=# set STANDARD_CONFORMING_STRINGS to off;
SET
HIROSHI=# INSERT INTO ucheck VALUES('ucheck2',u'\68ee\9dd7\5916');
ERROR: unsafe use of string constant with Unicode escapes
DETAIL: String constants with Unicode escapes cannot be used when standard_conf
orming_strings is off.
=== As for pgAdminIII ===
pgadmin is shown very well.!!:-)
http://winpg.jp/~saito/pg_work/ucheck/jisx0213.png
P.S)
This test obtains the same result by MimerDB.
Regards,
Hiroshi Saito
- Original Message -
From: Tom Lane t...@sss.pgh.pa.us
Peter Eisentraut pete...@gmx.net writes:
On Tuesday 14 April 2009 21:34:51 Peter Eisentraut wrote:
I think we can handle that and the cases Tom presents by erroring out when
the U syntax is used with stdstr off.
Proposed patch for that attached.
I have not been able to think of any security hole in that proposal,
so this patch seems acceptable to me. I wonder though whether any
corresponding change is needed in psql's lexer, and if so how should
it react exactly to the rejection case.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ALTER TABLE ... ALTER COLUMN ... SET DISTINCT
On Mon, May 04, 2009 at 10:13:31PM -0400, Robert Haas wrote: nit + own analysis indicates otherwie). When set to a negative value, which s/otherwie/otherwise /nit A question: why does attdistinct become entry #5 instead of going at the end? I assume it's because the order here controls the column order, and it makes sense to have attdistinct next to attstattarget, since they're related. Is that right? Thanks in advance... --- 185,210 * */ ! #define Natts_pg_attribute 19 #define Anum_pg_attribute_attrelid 1 #define Anum_pg_attribute_attname 2 #define Anum_pg_attribute_atttypid 3 #define Anum_pg_attribute_attstattarget 4 ! #define Anum_pg_attribute_attdistinct 5 ! #define Anum_pg_attribute_attlen6 ! #define Anum_pg_attribute_attnum7 - Josh / eggyknap signature.asc Description: Digital signature
