Re: [HACKERS] TODO item:Allow to_date() and to_timestamp() accept localized month names
(I really should stop reading the code after 12:00AM) So if I understand correctly, the proper solution would be to handle the localized (TM) format within to_date (seq_search). This means that prior calling to_date a SET LC_MESSAGES must be given. but if we are following Oracle, (http://www.techonthenet.com/oracle/functions/to_date.php) a third parameter to enforce the nls_language is required. Please advice. Regards, Gevik. -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 05, 2008 2:29 AM To: Gevik Babakhani Cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] TODO item:Allow to_date() and to_timestamp() accept localized month names Gevik Babakhani [EMAIL PROTECTED] writes: Surely it should be the inverse of the solution for output, eg TMMon selects localized input. Of cource. But how would TM enforce a localized formatting. (perhaps I am off 2:10 am...) Lets say I have en_US database but the dates I am trying to format is nl_NL. If I am not mistaking SET LC_MESSAGES won't help. Works for me: postgres=# show lc_messages ; lc_messages - de_DE.utf8 (1 row) postgres=# select to_char(now(), 'TMDay, DD TMMonth '); to_char - Montag, 04 Februar 2008 (1 row) postgres=# set lc_messages TO 'es_ES.utf8'; SET postgres=# select to_char(now(), 'TMDay, DD TMMonth '); to_char Lunes, 04 Febrero 2008 (1 row) 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: [HACKERS] Why are we waiting?
On Mon, 2008-02-04 at 17:06 -0500, Tom Lane wrote: Basically I'd rather try to attack the problem with dtrace ... OK. I'll switch to Solaris. Or do you something I don't about dtrace on linux? -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Page-at-a-time Locking Considerations
On Mon, 2008-02-04 at 18:08 -0300, Alvaro Herrera wrote: Simon Riggs wrote: On Mon, 2008-02-04 at 20:03 +, Gregory Stark wrote: I wonder how hard it would be to shove the clog into regular shared memory pages and let the clock sweep take care of adjusting the percentage of shared mem allocated to the clog versus data pages. There is a reason that's not been done... try it and see. What is it? Time to locate a block differs in the two cases. clog requires a search of data on 1 cache line, which isn't often changed. shared_buffers requires a hash table search on a volatile data structure. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[HACKERS] path with spaces in config.pl
Hi, I would like report an observations regarding compilation with msvc++ I was trying to compile with nls='C:\Program Files\GnuWin32\' (of course with GetText installed and everything) The build process breaks on link with missing Program.obj error. When I changed nls='C:\prog\pgsql\depend\gettext' everything compiled just fine. Perhaps we should document this. Regards, Gevik. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Re: [COMMITTERS] pgsql: configure tag'd 8.3.0 and built witih autoconf 2.59
On Mon, Feb 04, 2008 at 08:36:47PM -0500, Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: I don't really buy the double patching argument. Back patching becomes more difficult when there has been significant code drit, but we surely don't expect that much drift in the next week or two. Back patching when there has been no code drift is pretty simple. Well, it's not hard, but it is tedious. Bruce and I, who are the people most likely to bear the brunt of such tedium, both voted to wait a week or so before branching. Peter did not bother to vote. I assume this vote was taken out on -core? I don't mind -core deciding on this, not at all, but I would appreciate it if you would post the result of the vote on -hackers. It makes a lot of difference with an open-ended we'll branch sometmie later and a we talked about it, and we decided we'll branch in one to two weeks unless something unusual comes up. If you alraedy did this and I missed it in the mail-flood around fixing all the presskits, I apologize in advance ;-) //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Re: [COMMITTERS] pgsql: configure tag'd 8.3.0 and built witih autoconf 2.59
On Tue, Feb 05, 2008 at 10:57:16AM +, Dave Page wrote: On Feb 5, 2008 9:00 AM, Magnus Hagander [EMAIL PROTECTED] wrote: I assume this vote was taken out on -core? I don't mind -core deciding on this, not at all, but I would appreciate it if you would post the result of the vote on -hackers. It wasn't a 'vote' in the formal sense. It was just a discussion with people airing their opinion. *how* you came to the decision isn't really what I care about in this case.. //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Re: [COMMITTERS] pgsql: configure tag'd 8.3.0 and built witih autoconf 2.59
On Feb 5, 2008 9:00 AM, Magnus Hagander [EMAIL PROTECTED] wrote: I assume this vote was taken out on -core? I don't mind -core deciding on this, not at all, but I would appreciate it if you would post the result of the vote on -hackers. It wasn't a 'vote' in the formal sense. It was just a discussion with people airing their opinion. /D ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] path with spaces in config.pl
On Tue, Feb 05, 2008 at 11:11:42AM +0100, Gevik Babakhani wrote: Hi, I would like report an observations regarding compilation with msvc++ I was trying to compile with nls='C:\Program Files\GnuWin32\' (of course with GetText installed and everything) The build process breaks on link with missing Program.obj error. When I changed nls='C:\prog\pgsql\depend\gettext' everything compiled just fine. Perhaps we should document this. Or we should fix it, if we can figure out why. Is it the fact that it only works with what happens to be the directory layout I use, or is it the space in the filename that's breaking something? Can you test a third case to figure that out? //Magnus ---(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] Re: [COMMITTERS] pgsql: configure tag'd 8.3.0 and built witih autoconf 2.59
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: I don't really buy the double patching argument. Back patching becomes more difficult when there has been significant code drit, but we surely don't expect that much drift in the next week or two. Back patching when there has been no code drift is pretty simple. Well, it's not hard, but it is tedious. Bruce and I, who are the people most likely to bear the brunt of such tedium, both voted to wait a week or so before branching. Peter did not bother to vote. I suspect that you made this decision thinking that it didn't affect anybody else much. But it does affect buildfarm members. The buildfarm requires manual adjustment for each new branch to be built. Up to now (as Peter showed) owners have been able to say Oh, there's a new release. I'll start building the new branch. With the branch delayed they will have to say Oh, there's a new release. I wonder when they will branch so I can start building the new branch. I suspect there are some buildfarm owners who don't read -hackers religiously, and who will be somewhat in the dark. This probably wasn't on the core team's horizon - IIRC Dave is the only member of core who runs a buildfarm member. cheers andrew ---(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] Re: [COMMITTERS] pgsql: configure tag'd 8.3.0 and built witih autoconf 2.59
Gregory Stark wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: With the branch delayed they will have to say Oh, there's a new release. I wonder when they will branch so I can start building the new branch. No, I wrote that, not Tom. Your snipping went slightly astray. cheers andrew ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [COMMITTERS] pgsql: configure tag'd 8.3.0 and built witih autoconf 2.59
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: With the branch delayed they will have to say Oh, there's a new release. I wonder when they will branch so I can start building the new branch. Doesn't that just mean they should be sure to announce the branch loudly when it happens? I can't really see them failing to do that anyways. Whether the branch or not is just an procedural detail that only committers need to be concerned with. I think this is all projected anguish over something related. Tom says if there were people chomping at the bit to commit but that just raises the question: why aren't there people chomping at said bit? There are certainly tons of patches queued up in Bruce's held for 8.4 queue. Is it that just that we have queued up 8.3.x patches occupying committers attention? Or is it that reviewers and committers are exhausted from 8.3 and not quite ready yet to tackle new patches? Either way we need to find a solution that doesn't overload reviewers and committers and makes continual progress against pending patches. If we don't keep the patch queue short now we're only going to have a repeat of the last-minute rush at feature-freeze time again. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! ---(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] Re: [COMMITTERS] pgsql: configure tag'd 8.3.0 and built witih autoconf 2.59
On Feb 5, 2008 11:50 AM, Andrew Dunstan [EMAIL PROTECTED] wrote: This probably wasn't on the core team's horizon - IIRC Dave is the only member of core who runs a buildfarm member. To be honest the zoo beside me didn't even cross my mind when that thread happened. I didn't pay much attention as it's doesn't affect me much - plus I've spent the last 2 months double patching pgAdmin since the EDB QA team started finding all sorts of obscure buglets, so I can see where Tom's coming from. /D ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] path with spaces in config.pl
Or we should fix it, if we can figure out why. Is it the fact that it only works with what happens to be the directory layout I use, or is it the space in the filename that's breaking something? Can you test a third case to figure that out? I think it is the darn msbuild which accepts spaces in include but not in lib Attached is a quick patch that fixed the link error on my machine. Regards, Gevik Babakhani PostgreSQL NL http://www.postgresql.nl TrueSoftware BV http://www.truesoftware.nl patch-0.2-combined.patch Description: Binary data ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [COMMITTERS] pgsql: configure tag'd 8.3.0 and built witih autoconf 2.59
Andrew Dunstan [EMAIL PROTECTED] writes: Gregory Stark wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: With the branch delayed they will have to say Oh, there's a new release. I wonder when they will branch so I can start building the new branch. No, I wrote that, not Tom. Your snipping went slightly astray. Er, yeah. Whatever Tom wrote would have had another level of s. Obviously I should have snipped one more line. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Why are we waiting?
Simon Riggs wrote: On Mon, 2008-02-04 at 17:06 -0500, Tom Lane wrote: Basically I'd rather try to attack the problem with dtrace ... OK. I'll switch to Solaris. Or do you something I don't about dtrace on linux? One idea would be to add new arguments to LWLockAcquire as you suggest, but instead of modifying all call sites, decorate it with a macro that passes __FILE__ and __LINE__ as the extra arguments. The good thing about that is that it's a relatively small patch and you can easily switch it on/off with a #ifdef. And there's no need to push for inclusion of that into CVS, because it would be an easy patch to maintain yourself. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] path with spaces in config.pl
On Tue, Feb 05, 2008 at 01:55:40PM +0100, Gevik Babakhani wrote: Or we should fix it, if we can figure out why. Is it the fact that it only works with what happens to be the directory layout I use, or is it the space in the filename that's breaking something? Can you test a third case to figure that out? I think it is the darn msbuild which accepts spaces in include but not in lib Attached is a quick patch that fixed the link error on my machine. Looks good to me, applied, thanks! //Magnus ---(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] Remove pg_dump -i option (was Re: Proposed patch: synchronized_scanning GUC variable)
On Thu, Jan 31, 2008 at 11:02:03AM -0500, Bruce Momjian wrote: Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Am Donnerstag, 31. Januar 2008 schrieb Alvaro Herrera: Effect: we would stop receiving complaints that an old pg_dump can talk to a server that most likely is incompatible with it. People would learn on the spot that they must install the newer pg_dump. I think a more moderate measure might be to clarify the error message aborting because of version mismatch (Use the -i option to proceed anyway.)\n I would be satisfied with that if I thought people would actually read the message. My complaint is really directed at certain admin packages (and they know who they are) that invoke pg_dump *by default*, behind the user's back, with -i. Oh? That isn't good. Right. Dave - why do we do that? ;-) //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] Why are we waiting?
On Tue, 2008-02-05 at 14:14 +, Heikki Linnakangas wrote: Simon Riggs wrote: On Mon, 2008-02-04 at 17:06 -0500, Tom Lane wrote: Basically I'd rather try to attack the problem with dtrace ... OK. I'll switch to Solaris. Or do you something I don't about dtrace on linux? One idea would be to add new arguments to LWLockAcquire as you suggest, but instead of modifying all call sites, decorate it with a macro that passes __FILE__ and __LINE__ as the extra arguments. The good thing about that is that it's a relatively small patch and you can easily switch it on/off with a #ifdef. And there's no need to push for inclusion of that into CVS, because it would be an easy patch to maintain yourself. Thanks for the idea. It had occurred to me to make a private patch, but I prefer my patches to be open, so they're easier to discuss results arising from them. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(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] patternsel() and histogram_selectivity() and the hard cutoff of 100
So I had a thought about how to soften the controversial hard cutoff of 100 for the use of the histogram selectivity. Instead of switching 100% one way or the other between the two heuristics why not calculate both and combine them. The larger the sample size from the histogram the more we can weight the histogram calculation. The smaller the histogram size the more we weight the heuristic. My first thought was to scale it linearly so we use 10% of the histogram sample + 90% of the heuristic for default statistic sizes of 10 samples. That degenerates to the status quo for 100 samples and up. But actually I wonder if we can't get some solid statistics behind the percentages. The lower the sample size the larger the 95th percentile confidence interval and we want to use heuristic to adjust the result within the confidence interval. I think there are even ways of calculating pessimistic confidence intervals for unrepresentative samples. This would allow the results to degrade smoothly. So a sample size of 50 would be expected to give results somewhere between those of 10 and 100. Instead of the current behaviour where the results will be exactly the same until you hit 100 and then suddenly jump to a different value. I would do it by just making histogram_selectivity() never fail unless the histogram is less than 2 * the ignored values. There would be an additional parameter with a double* where the function would store the percentage weight to give the result. The caller would be responsible for combining the result just as it is with the MCV estimates. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support! ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [BUGS] BUG #3909: src\tools\msvc\clean.bat clears parse.h file
On Mon, Jan 28, 2008 at 06:27:05PM +, Pavel Golub wrote: The following bug has been logged online: Bug reference: 3909 Logged by: Pavel Golub Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3RC2 Operating system: WinXP Description:src\tools\msvc\clean.bat clears parse.h file Details: Executing clean.bat from src\tools\msvc clears src\backend\parser\parse.h However, in help stated: Bison and Flex are required to build from CVS, but not required when building from a release file. Also in src\backend\parser\Makefile we have comments: # gram.c, parse.h, and scan.c are in the distribution tarball, so they # are not cleaned here. Because of this bug there is no opportunity to build PostgreSQL by Visual Studio without using Bison. So, may be as a workaround we may use such scheme: 1. We have src\backend\parser\parse.h.release (or whatever postfix) file 2. GenerateFiles() in Solution.pm must check if Bison is available. If so then generate parse.h by Bison, else copy parse.h.release as parse.h 3. When clean will be called parse.h will be deleted, but not parse.h.release I think a better solution is to add a parameter to clean.bat to make it work like make clean does. So you'd to clean when you mean make clean, and clean dist when you mean make distclean. Thoughts on this? //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] GSSAPI and V2 protocol
On Tue, Jan 29, 2008 at 03:34:19AM -0500, Kris Jurka wrote: Is it possible to authenticate using GSSAPI over the V2 protocol? Is there any documentation on the message formats for V2? Honestly - don't know :-) Never looked at that part. I mean, the V2 protocol is *really* old by now, isn't it? Do you actually need it for something? //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Remove pg_dump -i option (was Re: Proposed patch: synchronized_scanning GUC variable)
On Feb 5, 2008 3:27 PM, Magnus Hagander [EMAIL PROTECTED] wrote: On Thu, Jan 31, 2008 at 11:02:03AM -0500, Bruce Momjian wrote: Tom Lane wrote: I would be satisfied with that if I thought people would actually read the message. My complaint is really directed at certain admin packages (and they know who they are) that invoke pg_dump *by default*, behind the user's back, with -i. Oh? That isn't good. Right. Dave - why do we do that? ;-) I didn't realise we did until Tom mentioned it - I didn't write that code. Please go ahead and remove the -i - it's not like users cannot cannot specify which set of pg utilities to use if they need a specific version. /D ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [BUGS] BUG #3909: src\tools\msvc\clean.bat clears parse.h file
On Feb 5, 2008 3:24 PM, Magnus Hagander [EMAIL PROTECTED] wrote: On Mon, Jan 28, 2008 at 06:27:05PM +, Pavel Golub wrote: I think a better solution is to add a parameter to clean.bat to make it work like make clean does. So you'd to clean when you mean make clean, and clean dist when you mean make distclean. Thoughts on this? Pretty sure I griped at you before about this, because when it removes it, it fails to rebuild it the next time round, even on in an env like mine which can build from CVS perfectly well. More than once I've had to unpack the tarball again having run a clean. /D ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Problem with site doc search
No. It's on the list, but other things around the release haev priority. //Magnus On Mon, Feb 04, 2008 at 06:43:09PM -0800, Gurjeet Singh wrote: Hi guys any updates on this? Pinging you just so that we do not forget it in the heap of mails in our inboxes. Best regards, On Feb 3, 2008 8:40 AM, Magnus Hagander [EMAIL PROTECTED] wrote: Oleg Bartunov wrote: On Sat, 2 Feb 2008, Gurjeet Singh wrote: Hi All, I just noticed a minor bug in our search results. Searching for is_insteadbool in 8.3 docs returns the following page: http://www.postgresql.org/docs/8.3/static/catalog-pg-rewrite.html is_instead is a column, and bool is the datatype, both mentioned in different columns. I know it is based on postgres' own full text search, but am not sure about the method how docs are read by the search engine. It seems that the problem lies in the the way the doc was read and fed to the index builder, because the initial search results show these two words combined. Also, is it possible to teach our search engine to *not* treat _ (underscore) as a word separator? This would be great help and would result much better results. Sure, there are many ways to do this. Magnus ? Which way would you recommend? You're the tsearch master ;-) //Magnus -- [EMAIL PROTECTED] [EMAIL PROTECTED] gmail | hotmail | indiatimes | yahoo }.com EnterpriseDB http://www.enterprisedb.com 17° 29' 34.37N, 78° 30' 59.76E - Hyderabad 18° 32' 57.25N, 73° 56' 25.42E - Pune 37° 47' 19.72N, 122° 24' 1.69 W - San Francisco * http://gurjeet.frihost.net Mail sent from my BlackLaptop device ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] patternsel() and histogram_selectivity() and the hard cutoff of 100
Gregory Stark [EMAIL PROTECTED] writes: So I had a thought about how to soften the controversial hard cutoff of 100 for the use of the histogram selectivity. Instead of switching 100% one way or the other between the two heuristics why not calculate both and combine them. The larger the sample size from the histogram the more we can weight the histogram calculation. The smaller the histogram size the more we weight the heuristic. My first thought was to scale it linearly so we use 10% of the histogram sample + 90% of the heuristic for default statistic sizes of 10 samples. That degenerates to the status quo for 100 samples and up. Incidentally I hacked up a patch to do this: postgres=# create table xx as (select i||'x'||i from generate_series(1,1) as i(i)); SELECT postgres=# alter table xx alter x set statistics 1; ANALYZE postgres=# analyze xx; ALTER TABLE postgres=# explain analyze select * from xx where x like '%x1%'; QUERY PLAN - Seq Scan on xx (cost=0.00..174.00 rows=2000 width=9) (actual time=0.095..11.814 rows=1112 loops=1) Filter: (x ~~ '%x1%'::text) Total runtime: 13.957 ms (3 rows) postgres=# alter table xx alter x set statistics 10; analyze xx; explain analyze select * from xx where x like '%x1%'; ... Seq Scan on xx (cost=0.00..174.00 rows=1920 width=9) (actual time=0.036..11.454 rows=1112 loops=1) ... postgres=# alter table xx alter x set statistics 20; analyze xx; explain analyze select * from xx where x like '%x1%'; Seq Scan on xx (cost=0.00..174.00 rows=1820 width=9) (actual time=0.036..11.446 rows=1112 loops=1) ... postgres=# alter table xx alter x set statistics 50; analyze xx; explain analyze select * from xx where x like '%x1%'; Seq Scan on xx (cost=0.00..174.00 rows=1520 width=9) (actual time=0.036..11.406 rows=1112 loops=1) ... postgres=# alter table xx alter x set statistics 70; analyze xx; explain analyze select * from xx where x like '%x1%'; Seq Scan on xx (cost=0.00..174.00 rows=1320 width=9) (actual time=0.036..10.725 rows=1112 loops=1) ... postgres=# alter table xx alter x set statistics 90; analyze xx; explain analyze select * from xx where x like '%x1%'; Seq Scan on xx (cost=0.00..174.00 rows=1220 width=9) (actual time=0.036..10.326 rows=1112 loops=1) ... postgres=# alter table xx alter x set statistics 100; analyze xx; explain analyze select * from xx where x like '%x1%'; Seq Scan on xx (cost=0.00..174.00 rows=1120 width=9) (actual time=0.037..11.411 rows=1112 loops=1) ... postgres=# alter table xx alter x set statistics 200; analyze xx; explain analyze select * from xx where x like '%x1%'; Seq Scan on xx (cost=0.00..174.00 rows=1106 width=9) (actual time=0.037..11.328 rows=1112 loops=1) ... postgres=# alter table xx alter x set statistics 1; analyze xx; explain analyze select * from xx where x like '%x1%'; Seq Scan on xx (cost=0.00..174.00 rows=2000 width=9) (actual time=0.037..11.810 rows=1112 loops=1) patternsel-combine-heuristics.patch.gz Description: Binary data -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training! ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Why are we waiting?
Simon Riggs [EMAIL PROTECTED] writes: On Mon, 2008-02-04 at 17:06 -0500, Tom Lane wrote: Basically I'd rather try to attack the problem with dtrace ... OK. I'll switch to Solaris. Or do you something I don't about dtrace on linux? Nope :-(. The SystemTap guys keep promising support for userspace probes but it's not there yet. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [BUGS] BUG #3909: src\tools\msvc\clean.bat clears parse.h file
Dave Page wrote: On Feb 5, 2008 3:24 PM, Magnus Hagander [EMAIL PROTECTED] wrote: On Mon, Jan 28, 2008 at 06:27:05PM +, Pavel Golub wrote: I think a better solution is to add a parameter to clean.bat to make it work like make clean does. So you'd to clean when you mean make clean, and clean dist when you mean make distclean. Thoughts on this? Pretty sure I griped at you before about this, because when it removes it, it fails to rebuild it the next time round, even on in an env like mine which can build from CVS perfectly well. More than once I've had to unpack the tarball again having run a clean. Uh, that would be a different issue, and I thought that one was fixed. I certainly clean/rebuild a lot, and it works just fine with the stuff coming out of cvs. The problem comes from if you remove *one* of the files but not *all* of them. We only trigger on one of them (unlike the makefile which triggers on all). But as long as they are all removed, it should be ok. Can you confirm if you actually still have that problem with 8.3.0? //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] GSSAPI and V2 protocol
On Tue, 5 Feb 2008, Magnus Hagander wrote: On Tue, Jan 29, 2008 at 03:34:19AM -0500, Kris Jurka wrote: Is it possible to authenticate using GSSAPI over the V2 protocol? Is there any documentation on the message formats for V2? Honestly - don't know :-) Never looked at that part. I mean, the V2 protocol is *really* old by now, isn't it? Do you actually need it for something? The JDBC driver exposes an option to connect via either protocol version. I was looking at adding GSSAPI support and it seemed orthogonal to the protocol version used, but I couldn't get it working under V2. People still use the V2 protocol to connect because it uses string interpolation for ? in prepared statements while V3 passes them out of line. So for apps that do things like SELECT timestamp ? that will only work under V2. Kris Jurka ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Remove pg_dump -i option (was Re: Proposed patch: synchronized_scanning GUC variable)
Dave Page wrote: On Feb 5, 2008 3:27 PM, Magnus Hagander [EMAIL PROTECTED] wrote: On Thu, Jan 31, 2008 at 11:02:03AM -0500, Bruce Momjian wrote: Tom Lane wrote: I would be satisfied with that if I thought people would actually read the message. My complaint is really directed at certain admin packages (and they know who they are) that invoke pg_dump *by default*, behind the user's back, with -i. Oh? That isn't good. Right. Dave - why do we do that? ;-) I didn't realise we did until Tom mentioned it - I didn't write that code. Please go ahead and remove the -i - it's not like users cannot cannot specify which set of pg utilities to use if they need a specific version. Ok, done! //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] GSSAPI and V2 protocol
Kris Jurka wrote: On Tue, 5 Feb 2008, Magnus Hagander wrote: On Tue, Jan 29, 2008 at 03:34:19AM -0500, Kris Jurka wrote: Is it possible to authenticate using GSSAPI over the V2 protocol? Is there any documentation on the message formats for V2? Honestly - don't know :-) Never looked at that part. I mean, the V2 protocol is *really* old by now, isn't it? Do you actually need it for something? The JDBC driver exposes an option to connect via either protocol version. I was looking at adding GSSAPI support and it seemed orthogonal to the protocol version used, but I couldn't get it working under V2. People still use the V2 protocol to connect because it uses string interpolation for ? in prepared statements while V3 passes them out of line. So for apps that do things like SELECT timestamp ? that will only work under V2. Ok. I see the reason, but I can't help you further. Requires a deeper dig in the code, I guess. Does this mean you have GSSAPI auth working for protocol v3? :-) //Magnus ---(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] GSSAPI and V2 protocol
On Tue, 5 Feb 2008, Magnus Hagander wrote: Does this mean you have GSSAPI auth working for protocol v3? :-) Yes, but since I'm not terribly familiar with GSSAPI or JAAS, I'm not sure what configuration options need to get exposed to the user. http://archives.postgresql.org/pgsql-jdbc/2008-01/threads.php#00144 Kris Jurka ---(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] GSSAPI and V2 protocol
Kris Jurka wrote: On Tue, 5 Feb 2008, Magnus Hagander wrote: Does this mean you have GSSAPI auth working for protocol v3? :-) Yes, but since I'm not terribly familiar with GSSAPI or JAAS, I'm not sure what configuration options need to get exposed to the user. http://archives.postgresql.org/pgsql-jdbc/2008-01/threads.php#00144 Hmm. I think most of that is a Java issue, which I know next to nothing about. But you would need to be able to control at least as much as libpq is - which means you need to be able to control the service name, and that's about it. Not sure how it works on windows - for libpq on windows, you can choose if you want MIT kerberos or if you want the SSPI kerberos in Windows, dunno if that applies to the java stuff. //Magnus ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Possible BUG in MSVC Install.pm in GenerateNLSFiles
Hi, Is it only on my system or the Install.pm:GenerateNLSFiles just does not copy any NLS files. It seems that in Install.pm:468:next.po$/); does not let anything through. Can someone please confirm? Regards, Gevik. ---(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] Remove pg_dump -i option (was Re: Proposed patch: synchronized_scanning GUC variable)
On Feb 5, 2008 6:11 PM, Magnus Hagander [EMAIL PROTECTED] wrote: Please go ahead and remove the -i - it's not like users cannot cannot specify which set of pg utilities to use if they need a specific version. Ok, done! Thanks. /D ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Possible BUG in MSVC Install.pm in GenerateNLSFiles
The traces from buildfarm baiji seem to indicate that at least some NLS files are installed. Those three dots are printed as default. (looking at Install.pm:456) Regards, Gevik. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Possible BUG in MSVC Install.pm in GenerateNLSFiles
Gevik Babakhani wrote: Hi, Is it only on my system or the Install.pm:GenerateNLSFiles just does not copy any NLS files. It seems that in Install.pm:468:next.po$/); does not let anything through. Can someone please confirm? The traces from buildfarm baiji seem to indicate that at least some NLS files are installed. Please try tracing the execution to see what get skipped where. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] Feature Freeze Date for Next Release
Can I ask when the Feature Freeze for next release will be? Last time we discussed this the only date mentioned was end-March-2008, which is less than 2 months away now. We've long expressed the wish to move development onto a cycle that ends in the Spring, so next alternative would appear to be end-March-2009, which is 14 months away now. Both of those dates seem extreme to me, so something along the lines of Sept 30 seems like a compromise - so 8 months away. That means we give up trying to make a Spring freeze, but at least we'd be consistently Dec/Jan, roughly as we have done for last 4 releases. It also means we are able to take advantage of GSoC projects, if appropriate. I'm of course happy to go with any date Core wishes, though I would like it decided now-ish so we can plan the developments we can make for the next release. We're increasingly in a position where personal time needs to be booked, projects accepted or rejected, funding sought, server time booked. Almost every major contributor has a commercial interest and planning that contribution is important. Non-commercial contributors similarly need to plan their potential contributions around life, exams, contract end dates. Some users also want to plan whether they will upgrade to 8.3 now or wait, in the case of a very short 8.4, whereas if it is a long way off, they will upgrade now. We also spoke about interim syncpoints, possibly quarterly, as a way of reducing the post-freeze interregnum. Insha'Allah, -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Feature Freeze Date for Next Release
On Feb 5, 2008 8:57 PM, Simon Riggs [EMAIL PROTECTED] wrote: Can I ask when the Feature Freeze for next release will be? I shall be posting on this topic in the next day or so. /D ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] configurability of OOM killer
On Mon, Feb 04, 2008 at 08:46:26PM +, Simon Riggs wrote: On Mon, 2008-02-04 at 15:31 -0500, Tom Lane wrote: I cannot see any way of restricting global memory consumption that won't hurt performance and flexibility. We've discussed particular ways of doing this previously and not got very far, its true. I think we need to separate problem identification from problem resolution, so we can get past the first stage and look for solutions. This is my longest running outstanding problem with managing Postgres on operational systems. Sure, OOM killer sucks. So there's two problems, not one. Yes, this problem goes way beyond OOM. Just try and configure work_memory aggressively on a server that might see 50 database connections, and do it in such a way that you won't swap. Good luck. We really do need a way to limit how much memory we will use in total. -- Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 pgp4bgwyT7x7v.pgp Description: PGP signature
Re: [HACKERS] Feature Freeze Date for Next Release
Wouldn't seeing which patches are trickling in during the first months of 8.4 development give a better indication of when it should be freezable? I'm all in favor of having lots of advance notice and predictable schedules --- but it seems in the next month or so we'll have a lot more insight of whether 8.4'll be getting big features or little ones based on what work-in-progress patches start coming. Simon Riggs wrote: Can I ask when the Feature Freeze for next release will be? This gives me flashbacks to this earlier thread: http://archives.postgresql.org/pgsql-hackers/2006-09/msg01979.php Simon Riggs in 2006 wrote: David Page wrote: Following the recent discussion on this list and another on pgsql-core, we have decided that we would like to aim to meet the following schedule for the release of PostgreSQL 8.3: April 1st 2007 - Feature freeze June 1st 2007 - Release I'm very happy to have clearly stated dates. That means we can all plan what we'll be able to achieve in that time, which is important when some of the largest or most complex features are being considered. Quoting Simon in 2008 again: We've long expressed the wish to move development onto a cycle that ends in the Spring, so next alternative would appear to be end-March-2009, which is 14 months away now. In light of the 2006 thread, I'd say April First like the previous thread would be better than End-March for those with a sense of irony. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [BUGS] BUG #3909: src\tools\msvc\clean.bat clears parse.h file
On Feb 5, 2008 5:56 PM, Magnus Hagander [EMAIL PROTECTED] wrote: Dave Page wrote: On Feb 5, 2008 3:24 PM, Magnus Hagander [EMAIL PROTECTED] wrote: On Mon, Jan 28, 2008 at 06:27:05PM +, Pavel Golub wrote: I think a better solution is to add a parameter to clean.bat to make it work like make clean does. So you'd to clean when you mean make clean, and clean dist when you mean make distclean. Thoughts on this? Pretty sure I griped at you before about this, because when it removes it, it fails to rebuild it the next time round, even on in an env like mine which can build from CVS perfectly well. More than once I've had to unpack the tarball again having run a clean. Uh, that would be a different issue, and I thought that one was fixed. I certainly clean/rebuild a lot, and it works just fine with the stuff coming out of cvs. The problem comes from if you remove *one* of the files but not *all* of them. We only trigger on one of them (unlike the makefile which triggers on all). But as long as they are all removed, it should be ok. Can you confirm if you actually still have that problem with 8.3.0? Yup - run clean.bat, and then build.bat and the resulting build fails because parser/parse.h is missing. Thats with the 8.3.0 tarball, which built just fine prior to running clean. Bison and flex are in the path. /D ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] configurability of OOM killer
Decibel! wrote: Yes, this problem goes way beyond OOM. Just try and configure work_memory aggressively on a server that might see 50 database connections, and do it in such a way that you won't swap. Good luck. That sounds like an even broader and more difficult problem than managing memory. If you have 50 connections that all want to perform large sorts, what do you want to have happen? a) they each do their sorts in parallel with small amounts of memory for each; probably all spilling to disk? b) they each get a big chunk of memory but some have to wait for each other? c) something else? Seems (a)'s already possible today with setting small work_mem. Seems (b)'s already possible today with a larger work_mem and pg_pool. Stepping back from the technical details, what do you think should happen. (though perhaps it should be taken to a different thread) ---(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] Feature Freeze Date for Next Release
Simon Riggs wrote: Can I ask when the Feature Freeze for next release will be? Also, from http://www.postgresql.org/about/press/faq Q: When will 8.4 come out? A: Historically, PostgreSQL has released approximately every 12 months and there is no desire in the community to change from that pattern. So expect 8.4 sometime in the fourth quarter of 2008. So you can count back from then to guess a freeze. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Feature Freeze Date for Next Release
On Tue, 05 Feb 2008 13:56:48 -0800 Ron Mayer [EMAIL PROTECTED] wrote: Simon Riggs wrote: Can I ask when the Feature Freeze for next release will be? Also, from http://www.postgresql.org/about/press/faq Q: When will 8.4 come out? A: Historically, PostgreSQL has released approximately every 12 months and there is no desire in the community to change from that pattern. So expect 8.4 sometime in the fourth quarter of 2008. So you can count back from then to guess a freeze. Until Dave sends the email, all balls are in the air. Joshua D. Drake ---(end of broadcast)--- TIP 6: explain analyze is your friend -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL SPI Liaison | SPI Director | PostgreSQL political pundit signature.asc Description: PGP signature
Re: [HACKERS] Feature Freeze Date for Next Release
Ron Mayer [EMAIL PROTECTED] writes: Simon Riggs wrote: Can I ask when the Feature Freeze for next release will be? Also, from http://www.postgresql.org/about/press/faq Q: When will 8.4 come out? A: Historically, PostgreSQL has released approximately every 12 months and there is no desire in the community to change from that pattern. So expect 8.4 sometime in the fourth quarter of 2008. I think that text failed to get updated since last fall :-( At this point, 12 months would be counted from 4 Feb 2008, so something like first-quarter-2009 seems more likely. The core committee is currently working on a proposal to make to pgsql-hackers about how to schedule and manage the 8.4 development cycle --- I think it's obvious to everyone that 8.3 did not go the way we wanted, so something's got to be done to avoid a repeat of that fiasco. Expect something about this in the next day or so. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[HACKERS] Where is share\locale dir on Win?
Is it my imagination or the share\locale directory for nls support just does not get installed on Windows. (Even with NLS option chosen). It does for 8.2 Regards, Gevik. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] GSSAPI and V2 protocol
Magnus Hagander [EMAIL PROTECTED] writes: On Tue, Jan 29, 2008 at 03:34:19AM -0500, Kris Jurka wrote: Is it possible to authenticate using GSSAPI over the V2 protocol? Is there any documentation on the message formats for V2? Honestly - don't know :-) Never looked at that part. I tried it --- it's easy to hack libpq so that it does V2 instead of V3: $ diff -c fe-connect.c~ fe-connect.c *** fe-connect.c~ Mon Jan 28 21:06:30 2008 --- fe-connect.cTue Feb 5 19:35:34 2008 *** *** 855,861 conn-addrlist = addrs; conn-addr_cur = addrs; conn-addrlist_family = hint.ai_family; ! conn-pversion = PG_PROTOCOL(3, 0); conn-status = CONNECTION_NEEDED; /* --- 855,861 conn-addrlist = addrs; conn-addr_cur = addrs; conn-addrlist_family = hint.ai_family; ! conn-pversion = PG_PROTOCOL(2, 0); conn-status = CONNECTION_NEEDED; /* $ The answer is no, it doesn't work: $ psql -l psql: GSSAPI continuation error: Invalid token was supplied GSSAPI continuation error: No error $ This surprises me; I would have thought the protocol was fairly orthogonal to the auth method. We should look into it and see if there's an easy fix or not. I have no time to poke further right now, though. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] configurability of OOM killer
On Tue, Feb 05, 2008 at 01:54:17PM -0800, Ron Mayer wrote: Decibel! wrote: Yes, this problem goes way beyond OOM. Just try and configure work_memory aggressively on a server that might see 50 database connections, and do it in such a way that you won't swap. Good luck. That sounds like an even broader and more difficult problem than managing memory. If you have 50 connections that all want to perform large sorts, what do you want to have happen? a) they each do their sorts in parallel with small amounts of memory for each; probably all spilling to disk? b) they each get a big chunk of memory but some have to wait for each other? c) something else? Seems (a)'s already possible today with setting small work_mem. Seems (b)'s already possible today with a larger work_mem and pg_pool. b is not possible with pgpool; you're assuming that all connections are trying to use work_mem. Stepping back from the technical details, what do you think should happen. (though perhaps it should be taken to a different thread) Yes... it's been discussed in the past. As Simon said, the first step is deciding that this is a problem, then we can try and figure out a solution. -- Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 pgpaWHvcVK2VX.pgp Description: PGP signature
Re: [HACKERS] GSSAPI and V2 protocol
I wrote: The answer is no, it doesn't work: $ psql -l psql: GSSAPI continuation error: Invalid token was supplied GSSAPI continuation error: No error $ This surprises me; I would have thought the protocol was fairly orthogonal to the auth method. We should look into it and see if there's an easy fix or not. I have no time to poke further right now, though. The problem seems to be that AuthenticationGSSContinue messages carry a variable-length payload, and the V2 protocol doesn't really cope with that because it doesn't have a message length word. In the existing libpq code, the V2 path ends up computing llen as zero because it's used a phonied-up value of msgLength. So it doesn't pass any of the contained data to GSS, and the error message is maybe not so surprising. So there seem to be three possible responses: 1. If the GSSContinue payload is self-identifying about its length, qwe could teach fe-connect.c how to determine that. That doesn't look real promising; I see this in strace output: recvfrom(4, R\0\0\0\10`\201\226\6\t*\206H\206\367\22\1\2\2\2\0o\201\2060\201\203\240\3\2\1\5\241\3\2\1\17\242w0u\240\3\2\1\20\242n\4l|\375a?\252}\25\241\344x\366aioX\17+I\356\215\265\252\260\353g|S\235\241 2F\25\237\254\365EZ\376Ws\20\23\tF#\37\362);/G\362\242\225D\366z\320\340\225\213p3_;\235\276\363\262o\30\6\t\225\3\351\365+\3546L#\4\243\31e\206z\0065~\345\203\200\201A\210\345\366\346\344\n\275\26r, 16384, 0, NULL, NULL) = 158 It looks like all encrypted data after the authentication type code, but maybe there's something there that I'm not aware of. 2. We could retroactively redefine the contents of AuthenticationGSSContinue as carrying a length word after the authentication type code, but only in V2 protocol (so as not to break existing working cases). This is pretty ugly but certainly possible. 3. We could decide not to support GSS in V2 protocol. If so, I'd want to make the backend throw an error in this case, rather than proceeding to send a message that we know can't be interpreted successfully. Thoughts? regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Re: [COMMITTERS] pgsql: configure tag'd 8.3.0 and built witih autoconf 2.59
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Tuesday, February 05, 2008 10:00:29 +0100 Magnus Hagander [EMAIL PROTECTED] wrote: On Mon, Feb 04, 2008 at 08:36:47PM -0500, Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: I don't really buy the double patching argument. Back patching becomes more difficult when there has been significant code drit, but we surely don't expect that much drift in the next week or two. Back patching when there has been no code drift is pretty simple. Well, it's not hard, but it is tedious. Bruce and I, who are the people most likely to bear the brunt of such tedium, both voted to wait a week or so before branching. Peter did not bother to vote. I assume this vote was taken out on -core? I don't mind -core deciding on this, not at all, but I would appreciate it if you would post the result of the vote on -hackers. It makes a lot of difference with an open-ended we'll branch sometmie later and a we talked about it, and we decided we'll branch in one to two weeks unless something unusual comes up. Actually, branch in one to two weeks has been the status quo almost since day one ... not that I'm against branch on release, I'm only saying that we've followed this same procedure on branching since ... forever. - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHqTeE4QvfyHIvDvMRAlisAKCxactS3Xp6V9/PbOOn11vhPioQaACgm+Ck psuY9S9odAYdj91T5/QlYDc= =CdzR -END PGP SIGNATURE- ---(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
