Re: [HACKERS] Time to package 8.2.4
On Mar 24, 2007, at 1:55 AM, Joshua D. Drake wrote: Hello, We have had several customers get bit by the 8.2.3 stats collector bug. It is also starting to get reported in areas such as IRC. The really bad thing about this bug is that you won't know what is wrong unless you know where to look, PostgreSQL will just appear slow and tying up resources. Can we please package 8.2.4 and get it out the door? +1 this is a show-stopper for me, I won't move production to 8.2, unless that's fixed. Can't allow this to happen in production. -- Grzegorz Jaskiewicz C/C++ freelance for hire ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Time to package 8.2.4
Am Sat, 24 Mar 2007 13:19:28 +0100 hat Grzegorz Jaskiewicz [EMAIL PROTECTED] geschrieben: On Mar 24, 2007, at 1:55 AM, Joshua D. Drake wrote: Hello, We have had several customers get bit by the 8.2.3 stats collector bug. It is also starting to get reported in areas such as IRC. The really bad thing about this bug is that you won't know what is wrong unless you know where to look, PostgreSQL will just appear slow and tying up resources. Can we please package 8.2.4 and get it out the door? +1 this is a show-stopper for me, I won't move production to 8.2, unless that's fixed. Can't allow this to happen in production. +1 -- Hakan ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] EXISTS optimization
On Fri, Mar 23, 2007 at 05:30:27PM -0500, Kevin Grittner wrote: I don't understand -- TRUE OR UNKNOWN evaluates to TRUE, so why would the IN need to continue? I'm not quite following the rest; could you elaborate or give an example? (Sorry if I'm lagging behind the rest of the class here.) You're right, I'm getting confused with the interaction of NULL and NOT IN. The multiple evaluation thing still applies, but that's minor. Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
[HACKERS] tsearch2 regression test failures
tsearch2 regression tests are also failing on win32/msvc, with attached
diffs.
Any pointers on where to start? ;)
//Magnus
*** ./expected/tsearch2.out 2006-09-10 19:36:52.0 +0200
--- ./results/tsearch2.out 2007-03-24 15:03:01.59375 +0100
***
*** 799,806
/usr/local/fff /awdf/dwqe/4325 rewt/ewr wefjn /wqe-324/ewr gist.h gist.h.c
gist.c. readline 4.2 4.2. 4.2, readline-4.2 readline-4.2. 234
i b wow jqw qwerty');
to_tsvector
!
--
! 'ad':17 'dw':19 'jf':39 '234':63 '345':1 '4.2':54,55,56,59,62 '455':31
'jqw':66 'qwe':2,18,27,28,35 'wer':36 'wow':65 'asdf':37 'ewr1':43 'qwer':38
'sdjk':40 '5.005':32 'efd.r':3 'ewri2':44 'hjwer':42 'qwqwe':29 'wefjn':48
'gist.c':52 'gist.h':50 'qwerti':67 '234.435':30 'qwe-wer':34
'readlin':53,58,61 'www.com':4 '+4.0e-10':26 'gist.h.c':51 'rewt/ewr':47
'/?ad=qwedw':7,10,14,22 '/wqe-324/ewr':49 'aew.werc.ewr':6
'readline-4.2':57,60 '1aew.werc.ewr':9 '2aew.werc.ewr':11 '3aew.werc.ewr':13
'4aew.werc.ewr':15 '/usr/local/fff':45 '/awdf/dwqe/4325':46 '[EMAIL
PROTECTED]':33 '/?ad=qwedw=%20%32':25 '5aew.werc.ewr:8100':16
'6aew.werc.ewr:8100':21 '7aew.werc.ewr:8100':24 'aew.werc.ewr/?ad=qwedw':5
'1aew.werc.ewr/?ad=qwedw':8 '3aew.werc.ewr/?ad=qwedw':12
'6aew.werc.ewr:8100/?ad=qwedw':20 '7aew.werc.ewr:8100/?ad=qwedw=%20%32':23
(1 row)
SELECT length(to_tsvector('default', '345 qw'));
--- 799,806
/usr/local/fff /awdf/dwqe/4325 rewt/ewr wefjn /wqe-324/ewr gist.h gist.h.c
gist.c. readline 4.2 4.2. 4.2, readline-4.2 readline-4.2. 234
i b wow jqw qwerty');
to_tsvector
!
-
! 'i':64 'ad':17 'dw':19
[HACKERS] Idea for cleaner representation of snapshots
I've always been annoyed by the implementation of HeapTupleSatisfiesVisibility (in src/include/utils/tqual.h): the normal case of an MVCC snapshot is the last one handled, and we can't expand the set of special cases without slowing it down even more. Also, as noted in tqual.h, the way we represent special snapshots is a gross violation of the rules for writing portable C. I had an idea about how to make this cleaner and faster at the same time. Make all snapshots be real pointers to SnapshotData structures (except InvalidSnapshot, which remains an alias for NULL). Add a struct field that is a pointer to the satifies function for the snapshot type. Then HeapTupleSatisfiesVisibility reduces to something like ((*(snapshot)-satisfies) ((tuple)-t_data, snapshot, buffer)) which ought to be faster than it is now. We could also add an mvcc bool field to simplify IsMVCCSnapshot() --- or just make it test the contents of the satisfies-function field. The names SnapshotNow etc would become names of suitably-initialized global variables (really global constants, since they'll never change). I'm half inclined to get rid of SnapshotDirty as a global variable, though: it's ugly because HeapTupleSatisfiesDirty writes into it, creating a non-reentrant API. Since the above API change causes HeapTupleSatisfiesDirty to get a pointer to the snapshot struct it's being used with, callers that need this could use a local snapshot variable to receive the output xmin/xmax. This would be cleaner than what we have in a couple of other ways too: in particular it would eliminate the gotcha that CopySnapshot/FreeSnapshot don't work on special snapshots. It might also simplify the idea we were kicking around on -patches of maintaining reference counts for snapshots; that's not gonna work for special snapshots either, unless they become real structs. Thoughts, objections? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Idea for cleaner representation of snapshots
On Sat, Mar 24, 2007 at 02:00:30PM -0400, Tom Lane wrote: I had an idea about how to make this cleaner and faster at the same time. Make all snapshots be real pointers to SnapshotData structures (except InvalidSnapshot, which remains an alias for NULL). Add a struct field that is a pointer to the satifies function for the snapshot type. Then HeapTupleSatisfiesVisibility reduces to something like ((*(snapshot)-satisfies) ((tuple)-t_data, snapshot, buffer)) which ought to be faster than it is now. We could also add an mvcc bool field to simplify IsMVCCSnapshot() --- or just make it test the contents of the satisfies-function field. Sounds like a winner. Essentially snapshots becomes objects that have methods you can use to interact with them. Make a new shapshot type, most of the code doesn't need to care. So yep, good idea. Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] Idea for cleaner representation of snapshots
Martijn van Oosterhout kleptog@svana.org writes: On Sat, Mar 24, 2007 at 02:00:30PM -0400, Tom Lane wrote: HeapTupleSatisfiesVisibility reduces to something like ((*(snapshot)-satisfies) ((tuple)-t_data, snapshot, buffer)) Sounds like a winner. Essentially snapshots becomes objects that have methods you can use to interact with them. Right, it's poor man's C++ ;-). I've just finished coding the patch and it looks good ... still testing though. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Effects of GUC settings on automatic replans
On Mar 21, 2007, at 5:11 AM, Tom Lane wrote: constraint_exclusion I'm inclined not to worry about these, since changing them can't affect the semantics of the query, at worst its performance. Hrm... wasn't that option added in case there was a bug in the exclusion code? I certainly can't think of any performance reason why you'd want to disable it... so it might be worth invalidating plans if it changes. -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(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] Vacation
Should anyone be looking for me for some reason... I'll be in New Zealand from Mar 24 - Apr 8, and will have very limited access to email. -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(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] Grouped Index Tuples / Clustered Indexes
Added to TODO: o Add more logical syntax CLUSTER table ORDER BY index; support current syntax for backward compatibility --- Simon Riggs wrote: On Sun, 2007-03-11 at 11:22 +, Heikki Linnakangas wrote: Gregory Stark wrote: On Wed, 2007-03-07 at 10:32 +, Heikki Linnakangas wrote: I've been thinking we should call this feature just Clustered Indexes So we would have clustered tables which are tables whose heap is ordered according to an index and separately clustered indexes which are indexes optimized for such tables? Yes, that's what I was thinking. There's a third related term in use as well. When you issue CLUSTER, the table will be clustered on an index. And that index is then the index the table is clustered on. That's a bit cumbersome but that's the terminology we're using at the moment. Maybe we should to come up with a new term for that to avoid confusion.. First thought: we can use the term cluster*ing* index for CLUSTER and use the term clustered to refer to what has happened to the table and the index. That will probably be confused with high availability clustering, so perhaps not. Better thought: say that CLUSTER requires an order-defining index. That better explains the point that it is the table being clustered, using the index to define the physical order of the rows in the heap. We then use the word clustered to refer to what has happened to the table, and with this patch, for the index also. That way we can have new syntax for CLUSTER CLUSTER table ORDER BY indexname which is then the preferred syntax, rather than the perverse CLUSTER index ON table which gives the wrong impression about what is happening, since it is the table that is changed, not the index. - - - - Are you suggesting that we have an explicit new syntax CREATE [UNIQUE] CLUSTERED INDEX [CONCURRENTLY] fooidx ON foo () ... or just that we refer to this feature as Clustered Indexes? - Do we still need the index WITH option, in either case? - Do you think that all Primary Keys should be clustered? - Are you thinking to rename docs, catalog etc to reflect the new naming/meaning? My thinking would be: CLUSTERED, no, yes, yes but I'd like to know what you think? -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(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 -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Documentation access problems.
Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: It should be standard docs imo. PDF is a heck of a lot easier to read if you have a good PDF reader. Just out of curiosity, what would that be? I've used both Acrobat and Preview, and I do not like either. Have you tried acroread recently? Version 7 is much better than previous version -- at least in that it actually, you know, works... It still, incredibly, has the stupid 1980s style MDI interface though. But as long as you're only working with one document at a time it's usable. Much faster than navigating separate web pages. I don't use it for the Postgres docs which are reasonable to navigate in HTML, but for something like the SQL spec where I want to be able to search through hundreds of pages and jump around repeatedly it's much faster. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Idea for cleaner representation of snapshots
HeapTupleSatisfiesVisibility reduces to something like ((*(snapshot)-satisfies) ((tuple)-t_data, snapshot, buffer)) which ought to be faster than it is now. It sounds like a fine idea from the point of view of flexibility. But as far as faster... I guess it depends on how often HeapTupleSatisfiesVisibility is used in contexts where the compiler is able to optimize away the conditionals or the cpu is able to predict them accurately. I suspect in the cases where we actually care--scans where it's being called thousands of times quickly--the latter is quite effective. Function pointers are notoriously hard to optimize around and can actually make the surrounding code harder to optimize as well especially since we compile with -fno-strict-aliasing. So whether it's faster or slower may depend a lot on the specific call site. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] datestyle GUC broken in HEAD?
(perhaps with the committing and then reversing of the custom variables patch?) postgres=# show datestyle; DateStyle --- ISO, DMY (1 row) postgres=# set datestyle='DMY,ISO'; SET postgres=# show datestyle; DateStyle --- ISO, DMY (1 row) -- Gregory Stark EnterpriseDB http://www.enterprisedb.com User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Effects of GUC settings on automatic replans
Jim Nasby [EMAIL PROTECTED] writes: On Mar 21, 2007, at 5:11 AM, Tom Lane wrote: constraint_exclusion I'm inclined not to worry about these, since changing them can't affect the semantics of the query, at worst its performance. Hrm... wasn't that option added in case there was a bug in the exclusion code? I certainly can't think of any performance reason why you'd want to disable it... so it might be worth invalidating plans if it changes. It was added precisely because we didn't have plan invalidation... If you dropped a constraint there was previously nothing to force the plan to be recalculated if it depended on the constraint for correctness. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(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] Copyrights on files
Someone has pointed out to me that we have non-PostgreSQL/Berkeley copyrights on a number of files: src/port/rint.c * Copyright (c) 1999, repas AEG Automation GmbH src/backend/port/dynloader/aix.c * This is an unpublished work copyright (c) 1992 HELIOS Software GmbH * 30159 Hannover, Germany src/backend/port/dynloader/ultrix4.h * Copyright (c) 1993 Andrew K. Yu, University of California at Berkeley * All rights reserved. ... BSD copyright text follows src/backend/utils/mb/Unicode/UCS_to_GB18030.pl # Copyright 2002 by Bill Huang I have emailed Andrew Yu to see if we can remove his line, but I question whether the other people can be reached. How should we handle this? -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] BSD advertizing clause in some files
Someone has pointed out that the following files have the 4-part BSD copyright, which includes the advertising clause: src/backend/port/darwin/system.c src/backend/port/dynloader/freebsd.c src/backend/port/dynloader/openbsd.c src/backend/port/dynloader/netbsd.c src/backend/utils/mb/wstrcmp.c src/backend/utils/mb/wstrncmp.c src/port/strtoul.c src/port/getopt.c src/port/getopt_long.c src/port/inet_aton.c src/port/strtol.c src/port/snprintf.c contrib/pgcrypto/blf.c contrib/pgcrypto/blf.h Because Berkeley has said the advertising clause is to be ignored/removed, should we remove it from our files too? -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [GENERAL] Fun with Cursors- how to rewind a cursor
Tom Lane wrote: Postgres User [EMAIL PROTECTED] writes: On 3/1/07, Tom Lane [EMAIL PROTECTED] wrote: Postgres User [EMAIL PROTECTED] writes: before opening cursor ref_entry = 'c_entry'; after looping thru cursor MOVE Backward All In c_entry; You have to use EXECUTE for the latter. I had tried several variations of MOVE Backward inside an Execute statement earlier. And now, I'm seeing this error appear again: ERROR: 0A000: cannot manipulate cursors directly in PL/pgSQL Hm, you're right. This arises from the fact that _SPI_execute_plan rejects cursor-related utility statements. While I'd never stopped to question that before, it does seem like this restriction is a bit pointless. Does anyone remember why it's like that? Is there anything to do on this item? -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] BSD advertizing clause in some files
Bruce Momjian wrote: Someone has pointed out that the following files have the 4-part BSD copyright, which includes the advertising clause: src/backend/port/darwin/system.c src/backend/port/dynloader/freebsd.c src/backend/port/dynloader/openbsd.c src/backend/port/dynloader/netbsd.c src/backend/utils/mb/wstrcmp.c src/backend/utils/mb/wstrncmp.c src/port/strtoul.c src/port/getopt.c src/port/getopt_long.c src/port/inet_aton.c src/port/strtol.c src/port/snprintf.c contrib/pgcrypto/blf.c contrib/pgcrypto/blf.h Because Berkeley has said the advertising clause is to be ignored/removed, should we remove it from our files too? I don't think we *need* to remove it, but I agree we should remove it for the sake of clarity. Note that the UC declaration only applies to code that is copyright UC Berkeley -- which is most of the above files, but not all of them (e.g. blf.c and blf.h are copyright Niels Provos). Rather than removing the copyright clause per se, it might be better to just update to the latest versions of these files in an upstream source (e.g. NetBSD). They've already gone through their source tree and updated the Berkeley copyrights as appropriate. -Neil ---(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] Copyrights on files
Bruce Momjian wrote: Someone has pointed out to me that we have non-PostgreSQL/Berkeley copyrights on a number of files: src/port/rint.c * Copyright (c) 1999, repas AEG Automation GmbH src/backend/port/dynloader/aix.c * This is an unpublished work copyright (c) 1992 HELIOS Software GmbH * 30159 Hannover, Germany src/backend/port/dynloader/ultrix4.h * Copyright (c) 1993 Andrew K. Yu, University of California at Berkeley * All rights reserved. ... BSD copyright text follows src/backend/utils/mb/Unicode/UCS_to_GB18030.pl # Copyright 2002 by Bill Huang I have emailed Andrew Yu to see if we can remove his line, but I question whether the other people can be reached. How should we handle this? If they are released under the BSD license, why do we care about it? -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] BSD advertizing clause in some files
Bruce Momjian wrote: Someone has pointed out that the following files have the 4-part BSD copyright, which includes the advertising clause: src/backend/port/darwin/system.c src/backend/port/dynloader/freebsd.c src/backend/port/dynloader/openbsd.c src/backend/port/dynloader/netbsd.c src/backend/utils/mb/wstrcmp.c src/backend/utils/mb/wstrncmp.c src/port/strtoul.c src/port/getopt.c src/port/getopt_long.c src/port/inet_aton.c src/port/strtol.c src/port/snprintf.c contrib/pgcrypto/blf.c contrib/pgcrypto/blf.h Because Berkeley has said the advertising clause is to be ignored/removed, should we remove it from our files too? Yes. -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Copyrights on files
Bruce Momjian wrote: Someone has pointed out to me that we have non-PostgreSQL/Berkeley copyrights on a number of files: src/port/rint.c * Copyright (c) 1999, repas AEG Automation GmbH src/backend/port/dynloader/aix.c * This is an unpublished work copyright (c) 1992 HELIOS Software GmbH * 30159 Hannover, Germany src/backend/port/dynloader/ultrix4.h * Copyright (c) 1993 Andrew K. Yu, University of California at Berkeley * All rights reserved. ... BSD copyright text follows src/backend/utils/mb/Unicode/UCS_to_GB18030.pl # Copyright 2002 by Bill Huang I have emailed Andrew Yu to see if we can remove his line, but I question whether the other people can be reached. How should we handle this? We either have to rewrite those parts entirely, or accept them as they are. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(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] Copyrights on files
Alvaro Herrera wrote: Bruce Momjian wrote: Someone has pointed out to me that we have non-PostgreSQL/Berkeley copyrights on a number of files: src/port/rint.c * Copyright (c) 1999, repas AEG Automation GmbH src/backend/port/dynloader/aix.c * This is an unpublished work copyright (c) 1992 HELIOS Software GmbH * 30159 Hannover, Germany src/backend/port/dynloader/ultrix4.h * Copyright (c) 1993 Andrew K. Yu, University of California at Berkeley * All rights reserved. ... BSD copyright text follows src/backend/utils/mb/Unicode/UCS_to_GB18030.pl # Copyright 2002 by Bill Huang I have emailed Andrew Yu to see if we can remove his line, but I question whether the other people can be reached. How should we handle this? If they are released under the BSD license, why do we care about it? Because BSD != BSD in all cases. Consider the advertising clause for example. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
