Re: [HACKERS] Differences in UTF8 between 8.0 and 8.1
On 2005-10-24, Paul Lindner <[EMAIL PROTECTED]> wrote: > Here's a cut and paste from emacs hexl-mode: > > : 3530 3833 6335 3038 330a 3c20 5641 4c55 5083c5083.< VALU > 0010: 4553 2028 3230 3235 3533 2c20 27c1 f9d4 ES (202553, '... > 0020: c2d0 c7d2 b927 2c20 0a2d 2d2d 0a3e 2056 .', .---.> V > 0030: 414c 5545 5320 2832 3032 3535 332c 2027 ALUES (202553, ' > 0040: d2b9 272c 200a 3136 3939 3432 6331 3639 ..', .169942c169 > 0050: 3934 320a 3c20 5641 4c55 4553 2028 3833 942.< VALUES (83 > 0060: 3031 352c 2027 b7ed a8c6 a448 272c 200a 015, '.H', . > 0070: 2d2d 2d0a 3e20 5641 4c55 4553 2028 3833 ---.> VALUES (83 > 0080: 3031 352c 2027 c6a4 4827 2c20 0a 015, '..H', . > > This is of a minimal diff between a UTF8 scrubbed file and the > original dump. > > It appears the offending bytes are: > > C1 F9 C2 D0 C7 I'm inclined to suspect that the whole sequence c1 f9 d4 c2 d0 c7 d2 b9 was never actually a valid utf-8 string, and that the d2 b9 is only valid by coincidence (it's a Cyrillic letter from Azerbaijani). I know the 8.0 utf-8 check was broken, but I didn't realize it was quite so bad. > and > > B7 ED A8 Likewise, that whole sequence b7 ed a8 c6 a4 was probably never valid; c6 a4 also isn't a character you'd expect to find in common use. My guess is that this was data in some non-utf-8 charset that managed to get past the defective checks in 8.0. -- Andrew, Supernews http://www.supernews.com - individual and corporate NNTP services ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Differences in UTF8 between 8.0 and 8.1
Thanks go out to John Hansen, he recommended to run the dump through iconv: iconv -c -f UTF8 -t UTF8 -o fixed.sql dump.sql This seems to strip out invalid UTF8 and will allow for a clean import. Someone should add this to the Release Notes/FAQ.. Yes I think that's extremely important to put in the 'upgrading/back compatibiliy' section for these release notes. Chris ---(end of broadcast)--- TIP 1: 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] [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance
"Andrew Dunstan" <[EMAIL PROTECTED]> wrote > > This patch passes regression and demonstrates the expected speedup on my > machine. > Looks good from here: - several rounds of regression test - psql -f set_time_out.sql - pg_ctl signal sending test - psql deadlock test Is there any way to test socket? Regards, Qingqing ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] broken link in 8.1 docs
Hello, I just have found that the link to The Hitch-Hiker's Guide to Evolutionary Computation in http://developer.postgresql.org/docs/postgres/geqo-biblio.html is broken. It should be changed to one of the mirrors from http://www.cs.bham.ac.uk/Mirrors/ftp.de.uu.net/EC/clife/www/location.htm With Best Regards, Sergey * Sergey E. Koposov Max-Planck Institut fuer Astronomie Web: http://lnfm1.sai.msu.ru/~math E-mail: [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Differences in UTF8 between 8.0 and 8.1
On Sun, Oct 23, 2005 at 05:56:50AM -, Andrew - Supernews wrote: > On 2005-10-22, Paul Lindner <[EMAIL PROTECTED]> wrote: > > I've generated dumps using pg_dump from 8.0 and 8.1. Attempting to > > restore these results in > > > > Invalid UNICODE byte sequence detected near byte ... > > What were the exact offending bytes? Here's a cut and paste from emacs hexl-mode: : 3530 3833 6335 3038 330a 3c20 5641 4c55 5083c5083.< VALU 0010: 4553 2028 3230 3235 3533 2c20 27c1 f9d4 ES (202553, '... 0020: c2d0 c7d2 b927 2c20 0a2d 2d2d 0a3e 2056 .', .---.> V 0030: 414c 5545 5320 2832 3032 3535 332c 2027 ALUES (202553, ' 0040: d2b9 272c 200a 3136 3939 3432 6331 3639 ..', .169942c169 0050: 3934 320a 3c20 5641 4c55 4553 2028 3833 942.< VALUES (83 0060: 3031 352c 2027 b7ed a8c6 a448 272c 200a 015, '.H', . 0070: 2d2d 2d0a 3e20 5641 4c55 4553 2028 3833 ---.> VALUES (83 0080: 3031 352c 2027 c6a4 4827 2c20 0a 015, '..H', . This is of a minimal diff between a UTF8 scrubbed file and the original dump. It appears the offending bytes are: C1 F9 C2 D0 C7 and B7 ED A8 > > Question: > > > > Does the 8.1 Unicode sanity code accept the full set of characters > > accepted by the 8.0 Unicode sanity code? > > No. 8.0 and before accepted a lot of stuff that it should never have, and > failed to accept stuff that it should have. Thanks go out to John Hansen, he recommended to run the dump through iconv: iconv -c -f UTF8 -t UTF8 -o fixed.sql dump.sql This seems to strip out invalid UTF8 and will allow for a clean import. Someone should add this to the Release Notes/FAQ.. -- Paul Lindner| | | | | | | | | | [EMAIL PROTECTED] pgpTkStRkxDSK.pgp Description: PGP signature
Re: [HACKERS] Call for port reports
Hello Tom, Slackware 10.0, kernel 2.6.12, x86, gcc 3.3.4 All 98 tests passed. Sergey * Sergey E. Koposov Max-Planck Institut fuer Astronomie Web: http://lnfm1.sai.msu.ru/~math E-mail: [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Call for port reports
Tom, SuSE Linux 9.3 Professional, 2.6.11.4-20a-default, gcc (GCC) 3.3.5, Athlon64 --with-perl --with-integer-datetimes --with-pgport=5801 --prefix=/usr/local/pg81 == All 98 tests passed. == -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance
Tom Lane wrote: "Magnus Hagander" <[EMAIL PROTECTED]> writes: Here's another version of this patch ;-) I've based it on your patch, so the changes to ovalue etc should sitill be there. In the spirit of incremental improvement ... I've taken Magnus' version and added the proposed change to re-enable Qingqing's patch by skipping WaitForSingleObjectEx altogether in the CHECK_FOR_INTERRUPTS code path. I also removed WaitForSingleObjectEx in pgwin32_poll_signals(), which AFAICS should be just like CHECK_FOR_INTERRUPTS. I think this is what we are proposing to actually apply to 8.1beta4. I can't test it though, so please check it over... This patch passes regression and demonstrates the expected speedup on my machine. cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance
> > But. in theory, we can get a false positive from > > UNBLOCKED_SIGNAL_QUEUE(), right? > > We could have gotten a false positive from the old coding, too. > The event was certainly not any more tightly tied to the > presence of an unserviced signal flag than > UNBLOCKED_SIGNAL_QUEUE, and arguably less so. > > I think this concern is irrelevant anyway. Returning EINTR from > select() is OK even if no signal was actually serviced, so > long as it doesn't recur indefinitely. EINTR just means "I > didn't do the select(), try again". Ok. I don't see any way why it would recur indefinitly, since we'll clean it up in the dispatch routine. And any half-updated-value will be fully updated a *very* short time later. So we sohuld be fine. //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance
Qingqing Zhou <[EMAIL PROTECTED]> writes: > Are we asserting that > UNBLOCKED_SIGNAL_QUEUE() != 0 > then > WaitForSingleObjectEx(0)==WAIT_OBJECT_0 No. > If so, we can put this assertion in. Only if you want it to crash every so often. The "race condition" is that a signal delivered right about the time the check is made may be serviced before the event is set, meaning that after the dust settles the event will still be set when there's nothing to do. This was true before, too, and will have no impact worse than causing an extra entry to dispatch_signals later on. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance
"Magnus Hagander" <[EMAIL PROTECTED]> writes: > But. in theory, we can get a false positive from > UNBLOCKED_SIGNAL_QUEUE(), right? We could have gotten a false positive from the old coding, too. The event was certainly not any more tightly tied to the presence of an unserviced signal flag than UNBLOCKED_SIGNAL_QUEUE, and arguably less so. I think this concern is irrelevant anyway. Returning EINTR from select() is OK even if no signal was actually serviced, so long as it doesn't recur indefinitely. EINTR just means "I didn't do the select(), try again". regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance
> > In the spirit of incremental improvement ... I've taken Magnus' > > version and added the proposed change to re-enable > Qingqing's patch by > > skipping WaitForSingleObjectEx altogether in the > CHECK_FOR_INTERRUPTS code path. > > I also removed WaitForSingleObjectEx in > pgwin32_poll_signals(), which > > AFAICS should be just like CHECK_FOR_INTERRUPTS. I think > this is what > > we are proposing to actually apply to 8.1beta4. I can't test it > > though, so please check it over... > > > Questions: > > Are we asserting that > > UNBLOCKED_SIGNAL_QUEUE() != 0 > then > WaitForSingleObjectEx(0)==WAIT_OBJECT_0 > > If so, we can put this assertion in. Seems there is some > race. In pg_queue_signal(), we do it like this: > > enter_critical_section(); > mask the signal; > leave_critical_section(); > SetEvent(); > > That is, we may detect the value first before we got event. > So at least the above assertion is not correct. This may > cause other problems, just for a quick feedback. Actually, wasn't the latest that we *only* use the event object in order to "break out" of blocking operations in the socket code? And only use checking + checking in critical seciton to deliver? In this case, it shouldn't matter when the event is set as long as it's always set *after* we update the values. Meaning that we'd have for the check just: UNBLOCKED_SIGNAL_QUEUE() enter_critical_section() UNBLOCKE_DSIGNAL_QUEUE() again leave_critical_section() and when we use the event to break out, tha'ts just a WFSO before that whole cycle runs. (Don't have the code around right now, and it's getting a bit late after a long day, so forgive me if I'm missing something obvious in that reasoning :P) //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance
On Sun, 23 Oct 2005, Magnus Hagander wrote: > > But. in theory, we can get a false positive from > UNBLOCKED_SIGNAL_QUEUE(), right? Since we do it unlocked between two > threads. If we do that, we'll "recover" in dispatch_signals, because > we'l lcheck again locked and not dispatch any signals. *but*. If this > happens, we will return EINTR even when there is no signal. That doesn't > seem correct to me. It's a very small window, but it should be possible, > no? > > We probably need an actual check, so for example have > dispatch_queued_signals return a value indicating if any signals were > actually dispatched, and use that to control EINTR? > > Comments? Or am I completely off being too tired right now? ;-) > You are not. Basically that's what I just sent an email about :-) Since signals are not quite often happened, so I am thinking just adding a UNBLOCKED_SIGNAL_QUEUE() is more safe maybe for now. Regards, Qingqing ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance
On Sun, 23 Oct 2005, Tom Lane wrote: > "Magnus Hagander" <[EMAIL PROTECTED]> writes: > > In the spirit of incremental improvement ... I've taken Magnus' version > and added the proposed change to re-enable Qingqing's patch by skipping > WaitForSingleObjectEx altogether in the CHECK_FOR_INTERRUPTS code path. > I also removed WaitForSingleObjectEx in pgwin32_poll_signals(), which > AFAICS should be just like CHECK_FOR_INTERRUPTS. I think this is what > we are proposing to actually apply to 8.1beta4. I can't test it though, > so please check it over... > Questions: Are we asserting that UNBLOCKED_SIGNAL_QUEUE() != 0 then WaitForSingleObjectEx(0)==WAIT_OBJECT_0 If so, we can put this assertion in. Seems there is some race. In pg_queue_signal(), we do it like this: enter_critical_section(); mask the signal; leave_critical_section(); SetEvent(); That is, we may detect the value first before we got event. So at least the above assertion is not correct. This may cause other problems, just for a quick feedback. Regards, Qingqing ---(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: [HACKERS] [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance
> > Here's another version of this patch ;-) I've based it on > your patch, > > so the changes to ovalue etc should sitill be there. > > In the spirit of incremental improvement ... I've taken > Magnus' version and added the proposed change to re-enable > Qingqing's patch by skipping WaitForSingleObjectEx altogether > in the CHECK_FOR_INTERRUPTS code path. > I also removed WaitForSingleObjectEx in > pgwin32_poll_signals(), which AFAICS should be just like > CHECK_FOR_INTERRUPTS. I think this is what we are proposing > to actually apply to 8.1beta4. I can't test it though, so > please check it over... That does seem right. I think the only reason it was there i nthe first place was to deliver the APCs. But. in theory, we can get a false positive from UNBLOCKED_SIGNAL_QUEUE(), right? Since we do it unlocked between two threads. If we do that, we'll "recover" in dispatch_signals, because we'l lcheck again locked and not dispatch any signals. *but*. If this happens, we will return EINTR even when there is no signal. That doesn't seem correct to me. It's a very small window, but it should be possible, no? We probably need an actual check, so for example have dispatch_queued_signals return a value indicating if any signals were actually dispatched, and use that to control EINTR? Comments? Or am I completely off being too tired right now? ;-) //Magnus ---(end of broadcast)--- TIP 1: 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] [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance
"Magnus Hagander" <[EMAIL PROTECTED]> writes: > Here's another version of this patch ;-) I've based it on your patch, so > the changes to ovalue etc should sitill be there. In the spirit of incremental improvement ... I've taken Magnus' version and added the proposed change to re-enable Qingqing's patch by skipping WaitForSingleObjectEx altogether in the CHECK_FOR_INTERRUPTS code path. I also removed WaitForSingleObjectEx in pgwin32_poll_signals(), which AFAICS should be just like CHECK_FOR_INTERRUPTS. I think this is what we are proposing to actually apply to 8.1beta4. I can't test it though, so please check it over... regards, tom lane bin3JMoD5yTKE.bin Description: timer3.patch ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance
On Sun, 23 Oct 2005, Magnus Hagander wrote: > If we're going to create a separate thread, there is no need to deal > with APCs at all, I beleive. We can just use the existing timeout > functionality in WaitForSingleObjectEx(), which simplifies the code a > bit. [ Finally I copied it from the website. Don't know why I can't find it in my email reader or news reader. ] Yeah, this is better. > PS. Qingqing: it helps at least me if you can post your patch as an > attached file instead of inline. That makes absolutely sure my mailer > (yeah, I know...) doesn't get a chance to break the lines. Yeah, several times I want to submit with an attachment, but I got an error message saying that "I can't post a binary to a non-binary group". If any one happens to use pine newsreader and know the solution, please let me know, thanks. Regards, Qingqing ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance
On Sun, 23 Oct 2005, Magnus Hagander wrote: > > > Here's another version of this patch ;-) I've based it on > > your patch, > > > so the changes to ovalue etc should sitill be there. > > I didn't find a thread saying above? Something wrong with my newsreader? Regards, Qingqing ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance
> > Here's another version of this patch ;-) I've based it on > your patch, > > so the changes to ovalue etc should sitill be there. > > This looks fairly reasonable to me, but I'm feeling a bit > gun-shy after the previous fiasco. Before we consider > applying it so late in beta, I'd like to get Merlin or > another one of the win32 hackers to sign off on the patch too. Definitly agreed. I'd like to see both Merlin and Andrew run through the same test suites they did before. And it wouldn't hurt to get a test run on a differnet OS - so far I've only tested on XP SP2. I doubt there would be OS specific differences, but jus tin case... //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance
"Magnus Hagander" <[EMAIL PROTECTED]> writes: > Here's another version of this patch ;-) I've based it on your patch, so > the changes to ovalue etc should sitill be there. This looks fairly reasonable to me, but I'm feeling a bit gun-shy after the previous fiasco. Before we consider applying it so late in beta, I'd like to get Merlin or another one of the win32 hackers to sign off on the patch too. regards, tom lane ---(end of broadcast)--- TIP 1: 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] [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance
> > Tom Lane wrote: > >> Well, you tried to "scale" into a domain where the performance is > >> going to be disk-I/O-limited, so I'm not sure it proves anything. > > > Good point. I took a 5% random extract from the lineitems table and > > saw the expected improvement. > > Sounds better. Certainly there are cases where > CHECK_FOR_INTERRUPTS isn't going to be a meaningful drag on > performance, but there are others where it will be. > > BTW, looking at the code some more, I am thinking that > checking pgwin32_signal_event should be completely > unnecessary in pgwin32_check_queued_signals; that is, if > UNBLOCKED_SIGNAL_QUEUE() is nonzero we might as well just > enter pgwin32_dispatch_queued_signals unconditionally. The > only usefulness of calling WaitForSingleObjectEx is to allow > any pending APCs to be dispatched. Are there any other APCs > queued against the main thread besides the timer.c one? Right, the check should be unnecessary. We need the event, because we wait on it in the socket layer and in pgwin32_backend_usleep(). But as long as the event is still reset in pgwin32_dispatch_queued_signals, that should continue to work just as before. There should be no other APCs. After we learned that we can't do socket operations in APCs, we got rid of all other instances (signals code initially used it a lot). (Plus, if there were other APCs, they won't get called anyway for the same reason the timer APC wasn't called any more..) (Tried removing it in my code, and it still passes regression tests and deadlock test, so it looks good. I kept the pgwin32_check_queued_signals, but we could just as well get rid of that one then, since it'll only contain a call to dispatch. I just didn't want to have to do a complete rebuild after changing the macro..) //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance
> Here is the full patch of the timer implemenation with threading safty > added. Basic test is by several rounds of "make check" and threading > safty test is by a SQL file with many lines of "set > statement_timeout = > x". I don't know if there are any corner cases that I should > consider, if > any, let me know. Here's another version of this patch ;-) I've based it on your patch, so the changes to ovalue etc should sitill be there. If we're going to create a separate thread, there is no need to deal with APCs at all, I beleive. We can just use the existing timeout functionality in WaitForSingleObjectEx(), which simplifies the code a bit. That is assuming we don't need sub-millisecond accuracy, because WFSO only provides milliseconds (waitabletimer provides 1/10th of a microsecond). Tested with both serial and parallel regression tests and with a manual set statement_timeout test, just as yours. And finally, also tested the deadlock detection which I beleive also uses setitimer(). //Magnus PS. Qingqing: it helps at least me if you can post your patch as an attached file instead of inline. That makes absolutely sure my mailer (yeah, I know...) doesn't get a chance to break the lines. timer2.patch Description: timer2.patch ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance
Qingqing Zhou wrote: I guess there are several ways to skin this cat - the way I had sort of worked out reading the MSDN docs was to call QueueUserAPC on the timer thread. I'd like to know what Magnus and Merlin especially think out it. I am not sure - does this not require another thread in an alterable state? Maybe, I don't know. My impression from the docs was that the thread could call WaitForSingleObjectEx on the timer handle and it would also respond to the APC call. But my Windows API knowledge is not exactly large. As long as what you have works it should be OK. cheers andrew ---(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
[HACKERS] Call for port reports
If you don't see your favorite platform already listed as tested for 8.1 at http://developer.postgresql.org/docs/postgres/supported-platforms.html then please give it a try and send in your results. I'd recommend using 8.1beta4 or later, as beta4 already includes a few small portability fixes over beta3 --- no point in reinventing that 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
[HACKERS] prepared queries in plpgsql
Hi all, I've finalized the patch that does prepared queries in plperl, tests included, it's at http://www.karasik.eu.org/software/patches/pgsql-plperl.patch I'd like to ask if there's a chance that it might be included in 8.2 -- Sincerely, Dmitry Karasik --- catpipe Systems ApS *BSD solutions, consulting, development www.catpipe.net +45 7021 0050 ---(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: [HACKERS] Question about Ctrl-C and less
On Sat, Oct 22, 2005 at 02:48:53PM -0700, Sean Utt wrote: > Except that if I am in less, and I do CONTROL-C, it doesn't do anything at > all. > > It doesn't exit. > > If I send a kill -2 to the process, it doesn't exit. less ignores SIGINT > completely. Not quite, It interprets it as "abort command". Obviously if you're not doing anything at the time it appears to do nothing. Start a search (/) or turn on follow mode (F) and you'll see you can (or indeed in the latter case, must) use Ctrl-C to get back to the command prompt. Indeed, in follow mode it says: Waiting for data... (interrupt to abort) > If we are in the pager, don't respond to CONTROL-C, and instead output a > helpful hint telling people to use q to quit, which will do what they > really wanted anyway. That's wrong too, who says q exits the pager? Not to mention the message screws the screen also, needing a ^L to redraw the screen. Best do nothing at all (ie ignore). If the user doesn't know how to use less, then they shouldn't use it as pager. Besides, less comes with online help (press h), with how to quit being the first thing you read. > In theory, we already deal gracefully with q being pressed in the pager. Yes, by not reading stdin. Ergo, we should also not respond to ^C either. Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them. pgpEMzGRlaosM.pgp Description: PGP signature
Re: [HACKERS] [Slony1-general] Slony1_funcs broken with 8.1
Tom Lane wrote: Andreas Pflug <[EMAIL PROTECTED]> writes: So postmaster doesn't clean up pg_listener, It never has. If you're complaining about this patch http://archives.postgresql.org/pgsql-committers/2005-10/msg00073.php you ought to say so, rather than expecting us to guess it from an out-of-context quote from another mailing list. Not complaining, just RFC. But I wonder why postmaster doesn't truncate pg_listener at restart, since PIDs can't be valid any more (truncating would reduce bloating too). A redesign based on shmem or so wouldn't keep the data either. As near as I can tell, the technique Jan describes is an abuse of pg_listener, and I won't feel any great sympathy when it does break completely, which it will do before long when pg_listener goes away in the planned rewrite of LISTEN/NOTIFY. Well slony uses LISTEN for its main purpose too. I'd guess there's always a demand to find out which backend is listening, so a pg_listener (probably a view wrapping a function) will be necessary. AFAICS a backend that notices loss of client connection will usually clean up its listener entries, so apparently slony doesn't need to take care of this, at least for 8.1 (with the postmaster crash exception). Regards, Andreas ---(end of broadcast)--- TIP 1: 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] On externals sorts and other IO bottlenecks in postgresql.
I don't recall this being mentioned in the prior threads: http://www.cs.duke.edu/TPIE/ GPLed, but perhaps it has some good ideas. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
