Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
Excerpts from Dave Page's message of mié mar 02 16:38:00 -0300 2011: Should be. Moa is definitely Sun Studio: -bash-3.00$ /opt/sunstudio12.1/bin/cc -V cc: Sun C 5.10 SunOS_i386 2009/06/03 usage: cc [ options] files. Use 'cc -flags' for details And Huia is GCC: -bash-3.00$ /usr/sfw/bin/gcc --version gcc (GCC) 3.4.3 (csl-sol210-3_4-20050802) BTW I just swapped the compiler details for those two animals in the buildfarm database. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On Wed, Apr 27, 2011 at 8:12 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: Excerpts from Dave Page's message of mié mar 02 16:38:00 -0300 2011: Should be. Moa is definitely Sun Studio: -bash-3.00$ /opt/sunstudio12.1/bin/cc -V cc: Sun C 5.10 SunOS_i386 2009/06/03 usage: cc [ options] files. Use 'cc -flags' for details And Huia is GCC: -bash-3.00$ /usr/sfw/bin/gcc --version gcc (GCC) 3.4.3 (csl-sol210-3_4-20050802) BTW I just swapped the compiler details for those two animals in the buildfarm database. I thought Andrew did that already? -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On 04/27/2011 03:15 PM, Dave Page wrote: On Wed, Apr 27, 2011 at 8:12 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: Excerpts from Dave Page's message of mié mar 02 16:38:00 -0300 2011: Should be. Moa is definitely Sun Studio: -bash-3.00$ /opt/sunstudio12.1/bin/cc -V cc: Sun C 5.10 SunOS_i386 2009/06/03 usage: cc [ options] files. Use 'cc -flags' for details And Huia is GCC: -bash-3.00$ /usr/sfw/bin/gcc --version gcc (GCC) 3.4.3 (csl-sol210-3_4-20050802) BTW I just swapped the compiler details for those two animals in the buildfarm database. I thought Andrew did that already? I think I forgot. Thanks Alvaro. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
Excerpts from Dave Page's message of mié abr 27 16:15:33 -0300 2011: On Wed, Apr 27, 2011 at 8:12 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: BTW I just swapped the compiler details for those two animals in the buildfarm database. I thought Andrew did that already? He hadn't gotten around to actually doing it, apparently. Moa was still listed as GCC. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
Andres Freund and...@anarazel.de writes: On Saturday 05 March 2011 17:46:13 Tom Lane wrote: Andres Freund and...@anarazel.de writes: * Collation-related regression failure on buildfarm member pika. This is clearly a bug we need to identify, but maybe we can ship the alpha without a fix --- for one thing, getting more than one report of the problem would be helpful. I have just yesterday hit the same bug while testing some application on then HEAD, so its not just PIKA. What platform, and what locale/encoding environment? One debian and one ubuntu x64 box. I have a WIP patch fixing one of the two issues. Several places in selfuncs.c didn't setup collations. That lead for example to errors during patternsel. I've applied these changes as part of my last commit. However, I now believe that this has nothing to do with pika's problem and we're not going to see it go green :-( I'm pretty well convinced that what is happening on pika is that the first two rows of histogram_bounds data processed by the max() aggregate happen to be of collatable types, but since the aggregate is over anyarray it has no collation to pass to the array_larger() function, so it fails with that error instead of the expected one. I don't know exactly why we see that fail consistently on that machine and not any other buildfarm machines, but it doesn't matter --- the outcome is clearly possible. We could add a variant expected-output file for the polymorphism test, but I don't really want to take on the added maintenance burden. I think it'd be best to just add a WHERE clause to the failing query that will restrict the set of rows considered so that they don't include any columns of collatable types. If pika's next run doesn't show green then I'll do that. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On mån, 2011-03-07 at 12:40 -0500, Tom Lane wrote: Fair enough, but throwing in fmgr_info_collation(DEFAULT_COLLATION) anytime we have a problem seems to me to introduce the exact same issue. Who's to say that that's really the appropriate value to use? It normally isn't the appropriate value to use. It's only appropriate if either that particular part of the code doesn't support collations yet or it's dealing with some hardcoded catalog lookups or some similar case. In most other cases you should be getting the collation passed in from somewhere, and if you aren't there is probably some work to do to get it there. That's at least sort of the experience from developing this. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
Peter Eisentraut pete...@gmx.net writes: On mån, 2011-03-07 at 12:40 -0500, Tom Lane wrote: Fair enough, but throwing in fmgr_info_collation(DEFAULT_COLLATION) anytime we have a problem seems to me to introduce the exact same issue. Who's to say that that's really the appropriate value to use? It normally isn't the appropriate value to use. It's only appropriate if either that particular part of the code doesn't support collations yet or it's dealing with some hardcoded catalog lookups or some similar case. In most other cases you should be getting the collation passed in from somewhere, and if you aren't there is probably some work to do to get it there. That's at least sort of the experience from developing this. Mph. Well, I guess in the case of the pg_statistic stats we can declare by fiat that we calculate the stats according to the default collation. They'll be a bit off when used for a query that is comparing according to some other collation, but it's probably no worse than any other approximation we make in the selectivity code. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On tis, 2011-03-08 at 17:43 -0500, Tom Lane wrote: Mph. Well, I guess in the case of the pg_statistic stats we can declare by fiat that we calculate the stats according to the default collation. They'll be a bit off when used for a query that is comparing according to some other collation, but it's probably no worse than any other approximation we make in the selectivity code. That was my assumption for the time being. Unfortunately, it's hard to create test coverage for these types of issues. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On sön, 2011-03-06 at 12:16 -0500, Tom Lane wrote: I'm still not thrilled with the plan of sprinkling the code with random fmgr_info_collation() calls to make up for the lack of a sane default. IMO, that *is* a default, just a badly implemented one. We have touched upon this point several times during the development of this patch. The main problem is that you need to distinguish no collation from the default collation, so they can't both be OID zero. Another problem is that if you assume OID zero means default, finding bugs in the expression tree analysis would be really hard. It would be like saying, oh, we have type OID zero, let's make it text and proceed. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
Peter Eisentraut pete...@gmx.net writes: On sön, 2011-03-06 at 12:16 -0500, Tom Lane wrote: I'm still not thrilled with the plan of sprinkling the code with random fmgr_info_collation() calls to make up for the lack of a sane default. IMO, that *is* a default, just a badly implemented one. We have touched upon this point several times during the development of this patch. The main problem is that you need to distinguish no collation from the default collation, so they can't both be OID zero. Fair enough, but throwing in fmgr_info_collation(DEFAULT_COLLATION) anytime we have a problem seems to me to introduce the exact same issue. Who's to say that that's really the appropriate value to use? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
Hi,
On Monday, March 07, 2011 06:40:55 PM Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On sön, 2011-03-06 at 12:16 -0500, Tom Lane wrote:
I'm still not thrilled with the plan of sprinkling the code with
random fmgr_info_collation() calls to make up for the lack of a sane
default. IMO, that *is* a default, just a badly implemented one.
We have touched upon this point several times during the development of
this patch. The main problem is that you need to distinguish no
collation from the default collation, so they can't both be OID zero.
Fair enough, but throwing in fmgr_info_collation(DEFAULT_COLLATION)
anytime we have a problem seems to me to introduce the exact same issue.
Its comparatively easier to grep for when you notice something itchy.
Who's to say that that's really the appropriate value to use?
I actually am quite doubtfull that thats the correct value for patternsel and
the other places I added it in the patch. I think that should that be C. On
the other hand its not likely to be that influential.
that looks like it should be corrected btw:
src/backend/tsearch/{wparser_def.c,ts_locale.c}
Oid collation = DEFAULT_COLLATION_OID; /*TODO*/
Thats occuring 6 times in there...
Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On Mon, Mar 7, 2011 at 1:42 PM, Andres Freund and...@anarazel.de wrote:
that looks like it should be corrected btw:
src/backend/tsearch/{wparser_def.c,ts_locale.c}
Oid collation = DEFAULT_COLLATION_OID; /*TODO*/
Thats occuring 6 times in there...
At the risk of hijacking this thread to talk about the subject of this
thread, when are we going to cut alpha4?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On 3/7/11 10:59 AM, Robert Haas wrote:
On Mon, Mar 7, 2011 at 1:42 PM, Andres Freund and...@anarazel.de wrote:
that looks like it should be corrected btw:
src/backend/tsearch/{wparser_def.c,ts_locale.c}
Oid collation = DEFAULT_COLLATION_OID; /*TODO*/
Thats occuring 6 times in there...
At the risk of hijacking this thread to talk about the subject of this
thread, when are we going to cut alpha4?
Any reason not to release it this week, like Thursday?
Peter?
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
Robert Haas robertmh...@gmail.com writes: At the risk of hijacking this thread to talk about the subject of this thread, when are we going to cut alpha4? Well, a prerequisite for cutting an alpha is closing the commitfest, which at this point reduces to deciding what we are going to do with the plpython traceback patch. Other than that, I think we're pretty close. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On Mon, Mar 7, 2011 at 2:43 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: At the risk of hijacking this thread to talk about the subject of this thread, when are we going to cut alpha4? Well, a prerequisite for cutting an alpha is closing the commitfest, which at this point reduces to deciding what we are going to do with the plpython traceback patch. Other than that, I think we're pretty close. AFAIK, there's nothing particularly special about that patch, other than that the author chose to move it back from Returned with Feedback to some other status. I think we should just pick a time to wrap some time in the next day or two, and it either makes it or it doesn't. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
Robert Haas robertmh...@gmail.com wrote: Tom Lane t...@sss.pgh.pa.us wrote: Well, a prerequisite for cutting an alpha is closing the commitfest, which at this point reduces to deciding what we are going to do with the plpython traceback patch. AFAIK, there's nothing particularly special about that patch, other than that the author chose to move it back from Returned with Feedback to some other status. I don't see it having been in Returned with Feedback. The reviewer moved it to Ready for Committer, committers raised issues and moved it to Waiting for Author, and the author submitted a new patch and moved it back to Ready for Committer. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On Mon, Mar 7, 2011 at 3:15 PM, Kevin Grittner kevin.gritt...@wicourts.gov wrote: Robert Haas robertmh...@gmail.com wrote: Tom Lane t...@sss.pgh.pa.us wrote: Well, a prerequisite for cutting an alpha is closing the commitfest, which at this point reduces to deciding what we are going to do with the plpython traceback patch. AFAIK, there's nothing particularly special about that patch, other than that the author chose to move it back from Returned with Feedback to some other status. I don't see it having been in Returned with Feedback. The reviewer moved it to Ready for Committer, committers raised issues and moved it to Waiting for Author, and the author submitted a new patch and moved it back to Ready for Committer. Sorry, you're right. Still, as happy as I am that we've made so much progress with PL/python (and other things) this CommitFest, I think it's time to pick a date and time to ship alpha4 and call this one good. If the patch makes it, great; if not, oh well. We can't keep letting this drag out. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
Robert Haas robertmh...@gmail.com wrote: Still, as happy as I am that we've made so much progress with PL/python (and other things) this CommitFest, I think it's time to pick a date and time to ship alpha4 and call this one good. If the patch makes it, great; if not, oh well. We can't keep letting this drag out. Oh, I agree, all around. I just didn't want there to be a misunderstanding. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On Mon, Mar 7, 2011 at 3:28 PM, Kevin Grittner kevin.gritt...@wicourts.gov wrote: Robert Haas robertmh...@gmail.com wrote: Still, as happy as I am that we've made so much progress with PL/python (and other things) this CommitFest, I think it's time to pick a date and time to ship alpha4 and call this one good. If the patch makes it, great; if not, oh well. We can't keep letting this drag out. Oh, I agree, all around. I just didn't want there to be a misunderstanding. Agreed, and I appreciate the correction. I mis-remembered the history of that patch; yeah for the audit log. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On mån, 2011-03-07 at 15:19 -0500, Robert Haas wrote: Sorry, you're right. Still, as happy as I am that we've made so much progress with PL/python (and other things) this CommitFest, I think it's time to pick a date and time to ship alpha4 and call this one good. If the patch makes it, great; if not, oh well. We can't keep letting this drag out. Go for it. We might add the traceback patch afterwards, but it's not ready at the moment. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On Mon, Mar 7, 2011 at 4:59 PM, Peter Eisentraut pete...@gmx.net wrote: On mån, 2011-03-07 at 15:19 -0500, Robert Haas wrote: Sorry, you're right. Still, as happy as I am that we've made so much progress with PL/python (and other things) this CommitFest, I think it's time to pick a date and time to ship alpha4 and call this one good. If the patch makes it, great; if not, oh well. We can't keep letting this drag out. Go for it. We might add the traceback patch afterwards, but it's not ready at the moment. OK, then I propose we tag and cut the tarball on Wednesday morning, say around 9am Eastern. Objections? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On Mon, 2011-03-07 at 11:00 -0800, Josh Berkus wrote: At the risk of hijacking this thread to talk about the subject of this thread, when are we going to cut alpha4? Any reason not to release it this week, like Thursday? Let's release it before PGEast, please -- I will be there, and won't be able to spend time on packaging. -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On Sat, Mar 5, 2011 at 7:22 AM, Robert Haas robertmh...@gmail.com wrote: Here's a rough attempt at filtering the post-alpha3 commit log down to approximately the set of things worth adding to the alpha4 release notes. Seems that support LIKE and ILIKE index searches via contrib/pg_trgm indexes is not mentioned here. With best regards, Alexander Korotkov.
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
Andres Freund and...@anarazel.de writes: Ah. Finally after trying to stare down the code for some more time the issue is pretty simple. - fmgr_info_collation(irel-rd_index-indcollation.values[attnum-1], + fmgr_info_collation(irel-rd_indcollation[attnum-1], Good catch ... but while I was poking around to make sure that there were no other similar errors, I started to get pretty desperately unhappy with the state of this code altogether. What exactly is indcollation supposed to mean? Does it have any meaning for unordered indexes? If it means something about the index's sort order, why is it that it's not consulted while building the pathkeys that represent the sort order? (It isn't.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
Andres Freund and...@anarazel.de writes: - fmgr_info_collation(irel-rd_index-indcollation.values[attnum-1], + fmgr_info_collation(irel-rd_indcollation[attnum-1], locinfo); BTW, I went ahead and committed this part, since the bug and the fix are clear. I'm still not thrilled with the plan of sprinkling the code with random fmgr_info_collation() calls to make up for the lack of a sane default. IMO, that *is* a default, just a badly implemented one. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On Saturday 05 March 2011 04:44:20 Robert Haas wrote: * Collation-related regression failure on buildfarm member pika. This is clearly a bug we need to identify, but maybe we can ship the alpha without a fix --- for one thing, getting more than one report of the problem would be helpful. pika is still red, but it claims not to have updated in 13 days, so I'm not sure what that means. I have just yesterday hit the same bug while testing some application on then HEAD, so its not just PIKA. Will try to find the bug or file some somewhat reproducible recipe. Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On Fri, Mar 4, 2011 at 11:22 PM, Robert Haas robertmh...@gmail.com wrote: On Fri, Mar 4, 2011 at 10:44 PM, Robert Haas robertmh...@gmail.com wrote: So it seems like the only thing that is an absolute must-do is write some release notes. Here's a rough attempt at filtering the post-alpha3 commit log down to approximately the set of things worth adding to the alpha4 release notes. Working on SGML-ifying this... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On Sat, Mar 5, 2011 at 8:48 AM, Alexander Korotkov korot...@intaro.ru wrote: On Sat, Mar 5, 2011 at 7:22 AM, Robert Haas robertmh...@gmail.com wrote: Here's a rough attempt at filtering the post-alpha3 commit log down to approximately the set of things worth adding to the alpha4 release notes. Seems that support LIKE and ILIKE index searches via contrib/pg_trgm indexes is not mentioned here. Good catch, thanks. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On Sat, Mar 5, 2011 at 8:41 AM, Robert Haas robertmh...@gmail.com wrote: On Fri, Mar 4, 2011 at 11:22 PM, Robert Haas robertmh...@gmail.com wrote: On Fri, Mar 4, 2011 at 10:44 PM, Robert Haas robertmh...@gmail.com wrote: So it seems like the only thing that is an absolute must-do is write some release notes. Here's a rough attempt at filtering the post-alpha3 commit log down to approximately the set of things worth adding to the alpha4 release notes. Working on SGML-ifying this... OK, first attempt committed. Proof-reading and double-checking that I haven't left things out is very welcome. I'm not entirely convinced the sections this is divided up into are the best possible choices, but neither am I sure exactly what would be better. Suggestions welcome. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On 03/04/2011 10:22 PM, Robert Haas wrote: On Fri, Mar 4, 2011 at 10:44 PM, Robert Haasrobertmh...@gmail.com wrote: So it seems like the only thing that is an absolute must-do is write some release notes. Here's a rough attempt at filtering the post-alpha3 commit log down to approximately the set of things worth adding to the alpha4 release notes. Support unlogged tables. The contents of an unlogged table are WAL-logged; um.. are _not_ WAL-logged? -Andy -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On Sat, Mar 5, 2011 at 9:44 AM, Andy Colson a...@squeakycode.net wrote: Support unlogged tables. The contents of an unlogged table are WAL-logged; um.. are _not_ WAL-logged? Uh, yeah. It looks like I fixed that in the version I committed, but introduced another, similar mistake which I have now also fixed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On 03/05/2011 08:54 AM, Robert Haas wrote: On Sat, Mar 5, 2011 at 9:44 AM, Andy Colsona...@squeakycode.net wrote: Support unlogged tables. The contents of an unlogged table are WAL-logged; um.. are _not_ WAL-logged? Uh, yeah. It looks like I fixed that in the version I committed, but introduced another, similar mistake which I have now also fixed. I think you have this section twice: When an autovacuum worker... but it is doubly cool... so... :-) -Andy -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On 03/05/2011 08:54 AM, Robert Haas wrote: On Sat, Mar 5, 2011 at 9:44 AM, Andy Colsona...@squeakycode.net wrote: Support unlogged tables. The contents of an unlogged table are WAL-logged; um.. are _not_ WAL-logged? Uh, yeah. It looks like I fixed that in the version I committed, but introduced another, similar mistake which I have now also fixed. Improved support for parallel make, make -k, and make -q Can we add a line saying -j still doesnt work, dont use it yet or make -j2 works great now. I admit I've never tried to use -j before... is this telling me its ok to use now? -Andy -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On lör, 2011-03-05 at 09:33 -0600, Andy Colson wrote: Can we add a line saying -j still doesnt work, dont use it yet or make -j2 works great now. I admit I've never tried to use -j before... is this telling me its ok to use now? Has make -j ever made any sense? Other than for locking up your system? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
Andres Freund and...@anarazel.de writes: On Saturday 05 March 2011 04:44:20 Robert Haas wrote: * Collation-related regression failure on buildfarm member pika. This is clearly a bug we need to identify, but maybe we can ship the alpha without a fix --- for one thing, getting more than one report of the problem would be helpful. I have just yesterday hit the same bug while testing some application on then HEAD, so its not just PIKA. What platform, and what locale/encoding environment? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On Sat, Mar 05, 2011 at 11:46:13AM -0500, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
On Saturday 05 March 2011 04:44:20 Robert Haas wrote:
* Collation-related regression failure on buildfarm member pika. This
is clearly a bug we need to identify, but maybe we can ship the alpha
without a fix --- for one thing, getting more than one report of the
problem would be helpful.
I have just yesterday hit the same bug while testing some application on
then
HEAD, so its not just PIKA.
What platform, and what locale/encoding environment?
Hi,
i got the same issue using git head and managed to isolate a small testcase.
git head on debian/sid x86_64, gcc45
Reproducible with:
bin/initdb -D data/ --encoding=UTF-8 --locale=en_US
bin/postgres -B16384 -D data/ -p -h localhost
create database test with encoding='UTF8'
create table ad_window (ad_client_id varchar(32) not null , name varchar(60)
not null, ad_module_id varchar(32) not null);
create UNIQUE INDEX ad_window_name on ad_window(ad_client_id, name,
ad_module_id);
insert into ad_window values ('0','Tables and Columns','0');
insert into ad_window values ('0','Reference','0');
The second insert fails consistently with:
WARNING: text_cmp 1-1-0'Tables and Columns0-0Reference0
WARNING: called from varlena: 0'Tables and Columns0 0Reference0 for
collid: (null)
ERROR: locale operation to be invoked, but no collation was derived
The added elogs show the compared values on the second insert which first
pointed me to the unique index as the probable trigger.
Backtrace of the failing text_cmp (not sure if useful):
#1 0x0077054b in bttextcmp (fcinfo=0x7fffbc1f9980) at varlena.c:1595
#2 0x007cade4 in FunctionCall2 (flinfo=0x254e7b8,
arg1=140410956296568, arg2=39118720) at fmgr.c:1387
#3 0x00492330 in _bt_compare ()
#4 0x00491e6a in _bt_binsrch ()
#5 0x0048a381 in _bt_doinsert ()
#6 0x0049077d in btinsert ()
#7 0x007cb230 in FunctionCall6 (flinfo=0x247bc60,
arg1=14041761456, arg2=140736349578208, arg3=140736349578176,
arg4=39118460, arg5=14041755632, arg6=1) at fmgr.c:1500
#8 0x00488ef0 in index_insert (indexRelation=0x7fb402706630,
values=0x7fffbc1fa3e0, isnull=0x7fffbc1fa3c0 ,
heap_t_ctid=0x254e67c, heapRelation=0x7fb402704f70,
checkUnique=UNIQUE_CHECK_YES) at indexam.c:205
#9 0x005cce68 in ExecInsertIndexTuples ()
#10 0x005ddafc in ExecInsert ()
#11 0x005de9e1 in ExecModifyTable ()
#12 0x005c032a in ExecProcNode ()
#13 0x005be204 in ExecutePlan ()
#14 0x005bcabe in standard_ExecutorRun ()
#15 0x005bc9b2 in ExecutorRun ()
#16 0x006d2d9b in ProcessQuery (plan=0x2527350,
sourceText=0x245ebd0 insert into ad_window values ('0','Reference','0');,
params=0x0, dest=0x2527430,
completionTag=0x7fffbc1faa30 ) at pquery.c:187
Regards,
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On Saturday 05 March 2011 17:46:13 Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
On Saturday 05 March 2011 04:44:20 Robert Haas wrote:
* Collation-related regression failure on buildfarm member pika. This
is clearly a bug we need to identify, but maybe we can ship the alpha
without a fix --- for one thing, getting more than one report of the
problem would be helpful.
I have just yesterday hit the same bug while testing some application on
then HEAD, so its not just PIKA.
What platform, and what locale/encoding environment?
One debian and one ubuntu x64 box.
I have a WIP patch fixing one of the two issues.
Several places in selfuncs.c didn't setup collations. That lead for example to
errors during patternsel.
The eqproc don't actually currently need the collation information, but I
think it is more consistent.
(attached)
I am currently looking at the other one. Its quite strange:
I can trigger it reliably on my machines.
with gdb attached:
b indexam.c:875 (thats index_getprocinfo)
...
test=# CREATE TABLE foo(a int, b text, c int);
CREATE TABLE
Time: 65.535 ms
test=# INSERT INTO foo VALUES (1, '1', 2);
INSERT 0 1
Time: 66.777 ms
test=# INSERT INTO foo VALUES (1, '2', 2);
INSERT 0 1
Time: 40.687 ms
#play with gdb
test=# CREATE INDEX foo_abc ON foo (a, b,c);
ERROR: locale operation to be invoked, but no collation was derived
...
(gdb) print irel-rd_indcollation[0]
$8 = 0
(gdb) print irel-rd_indcollation[1]
$9 = 100
(gdb) print irel-rd_indcollation[2]
$10 = 0
(gdb)
$11 = 0
(gdb) print irel-rd_index-indcollation.values[0]
$12 = 0
(gdb) print irel-rd_index-indcollation.values[1]
$13 = 0
(gdb) print irel-rd_index-indcollation.values[2]
$14 = 100
(gdb) print irel-rd_index-indcollation.values[3]
$15 = 0
(gdb) print irel-rd_index-indcollation
$16 = {vl_len_ = 8, ndim = 144, dataoffset = 1, elemtype = 0, dim1 = 26,
lbound1 = 3, values = {0}}
The piece of code using indcollation assumes that dataoffset = 0 which seems to
be an valid assumption...
...
fmgr_info_collation(irel-rd_index-indcollation.values[attnum-1],
locinfo);
...
Thus no valid collation is attached for the text column but a useless one for
the last int column.
Andres
From 2c33f1bb9c363cbb34767ecc37c463e1162372ee Mon Sep 17 00:00:00 2001
From: Andres Freund and...@anarazel.de
Date: Sat, 5 Mar 2011 18:30:04 +0100
Subject: [PATCH] Attach collation information to several FmgrInfo structs in selfuncs.c
---
src/backend/utils/adt/selfuncs.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/src/backend/utils/adt/selfuncs.c b/src/backend/utils/adt/selfuncs.c
index f10110b..783ad7c 100644
*** a/src/backend/utils/adt/selfuncs.c
--- b/src/backend/utils/adt/selfuncs.c
*** var_eq_const(VariableStatData *vardata,
*** 285,290
--- 285,291
FmgrInfo eqproc;
fmgr_info(get_opcode(operator), eqproc);
+ fmgr_info_collation(DEFAULT_COLLATION_OID, eqproc);
for (i = 0; i nvalues; i++)
{
*** eqjoinsel_inner(Oid operator,
*** 2116,2121
--- 2117,2123
nmatches;
fmgr_info(get_opcode(operator), eqproc);
+ fmgr_info_collation(DEFAULT_COLLATION_OID, eqproc);
hasmatch1 = (bool *) palloc0(nvalues1 * sizeof(bool));
hasmatch2 = (bool *) palloc0(nvalues2 * sizeof(bool));
*** eqjoinsel_semi(Oid operator,
*** 2338,2343
--- 2340,2346
nmatches;
fmgr_info(get_opcode(operator), eqproc);
+ fmgr_info_collation(DEFAULT_COLLATION_OID, eqproc);
hasmatch1 = (bool *) palloc0(nvalues1 * sizeof(bool));
hasmatch2 = (bool *) palloc0(nvalues2 * sizeof(bool));
*** prefix_selectivity(PlannerInfo *root, Va
*** 5108,5115
BTGreaterEqualStrategyNumber);
if (cmpopr == InvalidOid)
elog(ERROR, no = operator for opfamily %u, opfamily);
- fmgr_info(get_opcode(cmpopr), opproc);
prefixsel = ineq_histogram_selectivity(root, vardata, opproc, true,
prefixcon-constvalue,
prefixcon-consttype);
--- 5111,5119
BTGreaterEqualStrategyNumber);
if (cmpopr == InvalidOid)
elog(ERROR, no = operator for opfamily %u, opfamily);
+ fmgr_info(get_opcode(cmpopr), opproc);
+ fmgr_info_collation(DEFAULT_COLLATION_OID, opproc);
prefixsel = ineq_histogram_selectivity(root, vardata, opproc, true,
prefixcon-constvalue,
prefixcon-consttype);
*** prefix_selectivity(PlannerInfo *root, Va
*** 5130,5135
--- 5134,5140
if (cmpopr == InvalidOid)
elog(ERROR, no operator for opfamily %u, opfamily);
fmgr_info(get_opcode(cmpopr), opproc);
+ fmgr_info_collation(DEFAULT_COLLATION_OID, opproc);
greaterstrcon = make_greater_string(prefixcon, opproc);
if (greaterstrcon)
--
1.7.1
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On Saturday 05 March 2011 18:37:30 Andres Freund wrote: On Saturday 05 March 2011 17:46:13 Tom Lane wrote: Andres Freund and...@anarazel.de writes: I am currently looking at the other one. Its quite strange: The backtrace during the operations described earlier: 0 index_getprocinfo (irel=0x7f5426cbc820, attnum=1, procnum=1) at indexam.c:875 #1 0x0048ab14 in _bt_mkscankey_nodata (rel=0x7f5426cbc820) at nbtutils.c:123 #2 0x007eb628 in tuplesort_begin_index_btree (indexRel=0x7f5426cbc820, enforceUnique=0 '\000', workMem=1048576, randomAccess=0 '\000') at tuplesort.c:753 #3 0x0048c94c in _bt_spoolinit (index=0x7f5426cbc820, isunique=0 '\000', isdead=0 '\000') at nbtsort.c:165 #4 0x00487074 in btbuild (fcinfo=0x7fff68ab2220) at nbtree.c:116 #5 0x007ca99a in OidFunctionCall3 (functionId=338, arg1=13404896344, arg2=13404869664, arg3=30080592) at fmgr.c:1711 #6 0x004d598d in index_build (heapRelation=0x7f5426cc3058, indexRelation=0x7f5426cbc820, indexInfo=0x1cafe50, isprimary=0 '\000') at index.c:1729 #7 0x004d4c5c in index_create (heapRelation=0x7f5426cc3058, indexRelationName=0x1d41c90 foo_abc, indexRelationId=626424, indexInfo=0x1cafe50, indexColNames=0x1cb0318, accessMethodObjectId=403, tableSpaceId=0, collationObjectId=0x1cb03b8, classObjectId=0x1cb03d8, coloptions=0x1cb03f8, reloptions=0, isprimary=0 '\000', isconstraint=0 '\000', deferrable=0 '\000', initdeferred=0 '\000', allow_system_table_mods=0 '\000', skip_build=0 '\000', concurrent=0 '\000') at index.c:1063 #8 0x0057397f in DefineIndex (heapRelation=0x1d41ca8, indexRelationName=0x1d41c90 foo_abc, indexRelationId=0, accessMethodName=0x1d41d10 btree, tableSpaceName=0x0, attributeList=0x1d41d28, predicate=0x0, options=0x0, exclusionOpNames=0x0, unique=0 '\000', primary=0 '\000', isconstraint=0 '\000', deferrable=0 '\000', initdeferred=0 '\000', is_alter_table=0 '\000', check_rights=1 '\001', skip_build=0 '\000', quiet=0 '\000', concurrent=0 '\000') at indexcmds.c:395 #9 0x006d3d74 in standard_ProcessUtility (parsetree=0x1d30ff0, queryString=0x1d303c0 CREATE INDEX foo_abc ON foo (a, b,c);, params=0x0, isTopLevel=1 '\001', dest=0x1d31390, completionTag=0x7fff68ab2dc0 ) at utility.c:954 #10 0x006d2db3 in ProcessUtility (parsetree=0x1d30ff0, queryString=0x1d303c0 CREATE INDEX foo_abc ON foo (a, b,c);, params=0x0, isTopLevel=1 '\001', dest=0x1d31390, completionTag=0x7fff68ab2dc0 ) at utility.c:334 #11 0x006d1e82 in PortalRunUtility (portal=0x1cade40, utilityStmt=0x1d30ff0, isTopLevel=1 '\001', dest=0x1d31390, completionTag=0x7fff68ab2dc0 ) at pquery.c:1184 #12 0x006d2029 in PortalRunMulti (portal=0x1cade40, isTopLevel=1 '\001', dest=0x1d31390, altdest=0x1d31390, completionTag=0x7fff68ab2dc0 ) at pquery.c:1315 #13 0x006d15ff in PortalRun (portal=0x1cade40, count=9223372036854775807, isTopLevel=1 '\001', dest=0x1d31390, altdest=0x1d31390, completionTag=0x7fff68ab2dc0 ) at pquery.c:813 #14 0x006cb935 in exec_simple_query (query_string=0x1d303c0 CREATE INDEX foo_abc ON foo (a, b,c);) at postgres.c:1018 #15 0x006cfa47 in PostgresMain (argc=2, argv=0x1c79da8, username=0x1c79c40 andres) at postgres.c:3902 #16 0x0068444e in BackendRun (port=0x1cb1e20) at postmaster.c:3590 #17 0x00683b1a in BackendStartup (port=0x1cb1e20) at postmaster.c:3275 #18 0x00680e9a in ServerLoop () at postmaster.c:1449 #19 0x00680677 in PostmasterMain (argc=3, argv=0x1c76ef0) at postmaster.c:1110 #20 0x005fb12d in main (argc=3, argv=0x1c76ef0) at main.c:199 (gdb) Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
Andres Freund and...@anarazel.de writes: I have a WIP patch fixing one of the two issues. Several places in selfuncs.c didn't setup collations. That lead for example to errors during patternsel. Hmm. I have to say that this seems like quite the wrong way to go. If everyplace in the system that could be calling a collation-sensitive function has to be modified like this, we'll be fighting bugs of omission till h*ll freezes over. Why aren't we just setting finfo.fn_collation to DEFAULT_COLLATION_OID by default, or maybe better letting places that inspect it take zero as meaning default collation? Call sites should only need to call fmgr_info_collation() if they have an explicit non-default collation to pass in. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On Saturday 05 March 2011 18:43:31 Tom Lane wrote: Andres Freund and...@anarazel.de writes: I have a WIP patch fixing one of the two issues. Several places in selfuncs.c didn't setup collations. That lead for example to errors during patternsel. Hmm. I have to say that this seems like quite the wrong way to go. If everyplace in the system that could be calling a collation-sensitive function has to be modified like this, we'll be fighting bugs of omission till h*ll freezes over. Why aren't we just setting finfo.fn_collation to DEFAULT_COLLATION_OID by default, or maybe better letting places that inspect it take zero as meaning default collation? Call sites should only need to call fmgr_info_collation() if they have an explicit non-default collation to pass in. I wondered the same. On the other hand it makes errors like the one during index build way much harder to catch... Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On Sat, Mar 5, 2011 at 10:17 AM, Andy Colson a...@squeakycode.net wrote: On 03/05/2011 08:54 AM, Robert Haas wrote: On Sat, Mar 5, 2011 at 9:44 AM, Andy Colsona...@squeakycode.net wrote: Support unlogged tables. The contents of an unlogged table are WAL-logged; um.. are _not_ WAL-logged? Uh, yeah. It looks like I fixed that in the version I committed, but introduced another, similar mistake which I have now also fixed. I think you have this section twice: When an autovacuum worker... but it is doubly cool... so... :-) Thanks, fixed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On Sat, Mar 5, 2011 at 10:33 AM, Andy Colson a...@squeakycode.net wrote: On 03/05/2011 08:54 AM, Robert Haas wrote: On Sat, Mar 5, 2011 at 9:44 AM, Andy Colsona...@squeakycode.net wrote: Support unlogged tables. The contents of an unlogged table are WAL-logged; um.. are _not_ WAL-logged? Uh, yeah. It looks like I fixed that in the version I committed, but introduced another, similar mistake which I have now also fixed. Improved support for parallel make, make -k, and make -q Can we add a line saying -j still doesnt work, dont use it yet or make -j2 works great now. I admit I've never tried to use -j before... is this telling me its ok to use now? I've been using -j3 for a long time. These changes just make it able to parallelize a bit better. As Peter says, -j without arguments is mostly just a footgun. I can't imagine why that option hasn't been removed long since. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On lör, 2011-03-05 at 12:43 -0500, Tom Lane wrote: Why aren't we just setting finfo.fn_collation to DEFAULT_COLLATION_OID by default, or maybe better letting places that inspect it take zero as meaning default collation? Because then you'd just get silently wrong results instead of an error. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On Mar 4, 2011, at 7:44 PM, Robert Haas wrote: So it seems like the only thing that is an absolute must-do is write some release notes. What about this? Yeah, the real problem in my mind is not so much citext as whether the current representation of a type's collation property is sane in the first place. Once we've thrashed that out, I'll be happy with a simple UPDATE pg_type kluge in the citext upgrade script. Doing anything cleaner-looking than that is a future project (and might never happen, seeing that we've never felt a need for ALTER TYPE commands for other properties of a basic type). So really I guess the release-blocker issue is http://archives.postgresql.org/message-id/27152(dot)1299015062(at)sss(dot)pgh(dot)pa(dot)us Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
David E. Wheeler da...@kineticode.com writes: On Mar 4, 2011, at 7:44 PM, Robert Haas wrote: So it seems like the only thing that is an absolute must-do is write some release notes. What about this? http://archives.postgresql.org/message-id/27152(dot)1299015062(at)sss(dot)pgh(dot)pa(dot)us Well, nobody else seems to be excited about it. And it's not like there isn't a clear upgrade path if we decide to change CREATE TYPE later --- it'll just be a bit clunkier. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
Ah. Finally after trying to stare down the code for some more time the issue
is pretty simple.
index_getprocinfo did this:
/* Initialize the lookup info if first time through */
if (locinfo-fn_oid == InvalidOid)
{
...
fmgr_info_cxt(procId, locinfo, irel-rd_indexcxt);
fmgr_info_collation(irel-rd_index-indcollation.values[attnum-1],
locinfo);
}
which is not a good idea because irel-rd_index-indcollation is field after
the variable lenght indkey field.
Indkey is of int2vector type which is important because it means that there is
enough space for a second key without making direct access to indcollation
wrong (which is 4byte alligned). That explains why the issue could only be
triggered by a composite index covering at least 3 columns...
RelationInitIndexAccessInfo already fills the more convenient
Relation.rd_indcollation which makes the fix trivial.
It was a good bug though, because now I understand the relcache to some degree
which I formerly definitely did not ;-)
On Saturday 05 March 2011 18:37:30 Andres Freund wrote:
test=# CREATE TABLE foo(a int, b text, c int);
CREATE TABLE
Time: 65.535 ms
test=# INSERT INTO foo VALUES (1, '1', 2);
INSERT 0 1
Time: 66.777 ms
test=# INSERT INTO foo VALUES (1, '2', 2);
INSERT 0 1
Time: 40.687 ms
test=# CREATE INDEX foo_abc ON foo (a, b,c);
ERROR: locale operation to be invoked, but no collation was derived
Fixed after applying the patch.
Andres
From 91cf261c2af263e0965f5b302129730a7530ff38 Mon Sep 17 00:00:00 2001
From: Andres Freund and...@anarazel.de
Date: Sat, 5 Mar 2011 23:45:22 +0100
Subject: [PATCH] Fix one more 'locale operation to be invoked, but no collation was derived' error
The error was caused by directly accessing Relation.rd_index.indcollation.
The latter is positioned after a variable length field and thus cannot be
accessed directly. Instead use Relation.indcollation which is provided for
that purpose.
---
src/backend/access/index/indexam.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/backend/access/index/indexam.c b/src/backend/access/index/indexam.c
index 6e6af18..f489400 100644
--- a/src/backend/access/index/indexam.c
+++ b/src/backend/access/index/indexam.c
@@ -872,7 +872,7 @@ index_getprocinfo(Relation irel,
procnum, attnum, RelationGetRelationName(irel));
fmgr_info_cxt(procId, locinfo, irel-rd_indexcxt);
- fmgr_info_collation(irel-rd_index-indcollation.values[attnum-1],
+ fmgr_info_collation(irel-rd_indcollation[attnum-1],
locinfo);
}
--
1.7.1
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
Robert, Some minor fixes: 197listitem 198 para 199 emphasisImplement a truly serializable isolation level/emphasis 200 /para 201/listitem Should be: emphasisImplement Serializable Snapshot Isolation, in order to provide a more robust serializable transaction mode/emphasis 212 emphasisAllow multiple collations to be used within a single 213 database/emphasis Should be: Allow collations to be declared at the column level, permitting multiple collations within a single database. I agree that the sections you have are not ideal, but I don't think it's necessary to fix them for an alpha release. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On Sat, Mar 5, 2011 at 5:28 PM, Tom Lane t...@sss.pgh.pa.us wrote: David E. Wheeler da...@kineticode.com writes: On Mar 4, 2011, at 7:44 PM, Robert Haas wrote: So it seems like the only thing that is an absolute must-do is write some release notes. What about this? http://archives.postgresql.org/message-id/27152(dot)1299015062(at)sss(dot)pgh(dot)pa(dot)us Well, nobody else seems to be excited about it. And it's not like there isn't a clear upgrade path if we decide to change CREATE TYPE later --- it'll just be a bit clunkier. I am pretty suspicious that it's not a good design, but I don't understand it well enough to propose a better one (if there is a better one). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
Let's review where we are. On Tue, Mar 1, 2011 at 3:35 PM, Tom Lane t...@sss.pgh.pa.us wrote: * Regression test failures from recent plpython patches. These are affecting enough machines to make them must fix before alpha, IMO. There are some variations in error message wording, which are not too terrible but also not exactly hard to fix. The python assert failure that some Fedora machines are reporting is considerably more disturbing. I believe this is fixed by commit 4c966d920fb75a5d0366b887c2ef28e6d87c1eda, although it seems no one really understands why. * Collation-related regression failure on buildfarm member pika. This is clearly a bug we need to identify, but maybe we can ship the alpha without a fix --- for one thing, getting more than one report of the problem would be helpful. pika is still red, but it claims not to have updated in 13 days, so I'm not sure what that means. * Collation-related changes still needed in contrib/citext. If we don't have this done before alpha4, I'm afraid we'll have to generate a 1.1 update script to fix it for alpha4 users. I'd just as soon not deal with that overhead. I believe that this was fixed by commit 94be9e3f0ca9e7ced66168397eb586565bced9ca. * Rearrange pg_proc and pg_operator comments as suggested here: http://archives.postgresql.org/pgsql-docs/2010-10/msg00041.php While this isn't a must fix, the very end of a development cycle is clearly the best time for such a patch, since at any other time there are going to be a larger number of pending patches that would have to be adjusted. So I'd kind of like to get this done, if I can spare a day for it. I believe this was fixed by commits 94133a935414407920a47d06a6e22734c974c3b8 and 908ab80286401bb20a519fa7dc7a837631f20369. * Generate alpha release notes. This is at least half a day's work for somebody, I think, even with our fairly low standards for alpha release notes. This is all kinds of not done, AFAIK. There are other things I'd like to do, like review and perhaps commit the btree_gist patch, but they're not at the level of must fix. btree_gist was commited as 8436489c81c23af637696ac69cdaafddcc907ee1 So it seems like the only thing that is an absolute must-do is write some release notes. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On Fri, Mar 4, 2011 at 10:44 PM, Robert Haas robertmh...@gmail.com wrote: So it seems like the only thing that is an absolute must-do is write some release notes. Here's a rough attempt at filtering the post-alpha3 commit log down to approximately the set of things worth adding to the alpha4 release notes. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company Add REPLICATION privilege for ROLEs. This makes it possible for replication to be performed by a non-superuser account. Support unlogged tables. The contents of an unlogged table are WAL-logged; thus, they are not available on standby servers and are truncated whenever the database system enters recovery. Indexes on unlogged tables are also unlogged. Unlogged GiST indexes are not currently supported. Support RIGHT and FULL OUTER JOIN in hash joins. Allow casting a table's row type to the table's supertype if it's a typed table. This is analogous to the existing facility that allows casting a row type to a supertable's row type. Foreign tables. Implement remaining fields of information_schema.sequences view. Add a conflicts column to pg_stat_database, and a new view pg_stat_database conflicts. New system view pg_stat_replication. Fix GIN to support null keys, empty and null items, and full index scans. Teach GIN to combine duplicate keys even across different quals. Server support for streaming base backups. New client, pg_basebackup. Many PL/python improvements and clenaups, including explicit subtransactions, better error reporting, custom SPI exceptions, and quoting functions. Log replication connections only when log_connections is on. Avoid detoast in texteq/textne/byteaeq/byteane for unequal-length strings. Add a new psql command \dL to list languages. New contrib module pg_test_fsync, based on the old src/tools/test_fsync Allow the wal_buffers setting to be auto-tuned to a reasonable value. Add 'directory' format to pg_dump. sepgsql, an SE-Linux integration for PostgreSQL. ALTER TABLE ADD UNIQUE/PRIMARY KEY USING INDEX Try to compact the fsync request queue when it overflows, instead of doing an fsync per block. Log restartpoints in the same fashion as checkpoints. Implement genuine serializable isolation level. If an autovacuum worker, other than one performing an anti-wraparound vacuum, is unable to obtain a lock on the target related, skip it, to avoid pinning down a worker. The next cycle will try again. ALTER TABLE .. ADD FOREIGN KEY .. NOT VALID and ALTER TABLE .. VALIDATE CONSTRAINT. Recovery control functions. Change behavior to pause at recovery target, if there is one. Named restore points. Per-column collation support. Extensions. Track time of last statistics reset on databases and bgwriter. Send status updates from streaming replication clients back to the master. Teach ALTER TABLE .. SET DATA TYPE to avoid some table rewrites. Hot standby feedback. Convert PostgreSQL arrays to Perl arrays on PL/perl input arguments. Add transaction-level advisory locks. Make ecpg accept dynamic cursor names even in WHERE CURRENT OF clauses. Set psql client encoding from locale by default Support for foreign tables and foreign data wrappers. file_fdw. Add ENCODING option to COPY TO/FROM. Allow binary I/O of type void. Fix pageinspect's heap_page_item function to return infomasks as 32 bit values. Rearrange snapshot handling to make rule expansion more consistent. Change pg_last_xlog_receive_location() not to move backwards. Add KNNGIST support to contrib/btree_gist. Support data-modifying CTEs. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
Robert Haas robertmh...@gmail.com writes: So it seems like the only thing that is an absolute must-do is write some release notes. The buildfarm is showing that I broke MSVC builds, but other than that, yeah. What needs to happen for MSVC is that the rules for installing DATA files need to be applied for the pl directories not just contrib. I looked around but couldn't see exactly where the pl stuff gets installed at all in those scripts. Maybe somebody who knows those scripts better than me can fix it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On 02/03/11 01:05, Andrew Dunstan wrote: On 03/01/2011 05:19 PM, Jan Urbański wrote: On 01/03/11 22:07, Andrew Dunstan wrote: On 03/01/2011 03:53 PM, Jan Urbański wrote: On 01/03/11 21:35, Tom Lane wrote: Josh Berkusj...@agliodbs.com writes: I'm ok with closing things as of the end of the 15 days, say Thursday or Friday. It might be a good idea to make a list of what we have left to do before we can wrap an alpha. Here are some things on my list. Not all of them are necessarily release blockers, but we need to discuss which ones are: * Regression test failures from recent plpython patches. These are affecting enough machines to make them must fix before alpha, IMO. There are some variations in error message wording, which are not too terrible but also not exactly hard to fix. The python assert failure that some Fedora machines are reporting is considerably more disturbing. I agree. I'm looking into the crash, no luck so long. Is there anything you need that would help you? Could you try this patch and see if it fixes the failures? I'm at a loss as to why this happens, but judging from the traceback the spiexceptions module is getting unreffed somewhere and when garbage collection kicks it it barfs on an object with refcount 0. So I'm forcing an incref of the module to confirm that. I tried various tricks on 32 bit Debian, with Python 2.6, 2.7, Python compiled from Fedora's SRPM and I never saw anything wrong. Will keep on trying, but tommorrow evening, time to sleep :( Thanks. That seems to have fixed it, so I have applied the patch. Would you like to supply some comments to got with it? The comment would be something like /* XXX it appears that in some circumstantes the reference count of the spiexceptions module drops to zero causing a Python assert failure when the garbage collector visits the module. This has been observed on the buildfarm. To fix this, add an additional ref for the module here. */ I have no idea why the refcount of the module becomes zero, debug prints I added on my system were always showing 1. Jan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On Wed, Mar 2, 2011 at 6:14 AM, Jan Urbański wulc...@wulczer.org wrote: That seems to have fixed it, so I have applied the patch. Would you like to supply some comments to got with it? The comment would be something like /* XXX it appears that in some circumstantes the reference count of the spiexceptions module drops to zero causing a Python assert failure when the garbage collector visits the module. This has been observed on the buildfarm. To fix this, add an additional ref for the module here. */ I have no idea why the refcount of the module becomes zero, debug prints I added on my system were always showing 1. But does bumping the ref count then create a leak the rest of the time? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On 02/03/11 14:25, Robert Haas wrote: On Wed, Mar 2, 2011 at 6:14 AM, Jan Urbański wulc...@wulczer.org wrote: That seems to have fixed it, so I have applied the patch. Would you like to supply some comments to got with it? The comment would be something like /* XXX it appears that in some circumstantes the reference count of the spiexceptions module drops to zero causing a Python assert failure when the garbage collector visits the module. This has been observed on the buildfarm. To fix this, add an additional ref for the module here. */ I have no idea why the refcount of the module becomes zero, debug prints I added on my system were always showing 1. But does bumping the ref count then create a leak the rest of the time? Not really, because you never want to garbage collect the spiexceptions module (just like you don't want to GC th plpy module, or the plpy.info function etc.). So the reference count of that module should never drop to zero, but apparently on some machines it does. So just reffing artificailly is kind of a valid solution, I'm just uneasy with not knowing why it fails on some machines and does not on others. Jan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org writes: On 02/03/11 14:25, Robert Haas wrote: But does bumping the ref count then create a leak the rest of the time? Not really, because you never want to garbage collect the spiexceptions module (just like you don't want to GC th plpy module, or the plpy.info function etc.). So the reference count of that module should never drop to zero, but apparently on some machines it does. So just reffing artificailly is kind of a valid solution, I'm just uneasy with not knowing why it fails on some machines and does not on others. Yeah, that last point makes me nervous too. A look into the Fedora repository shows that the python version shipped in F13 is rather heavily patched: http://pkgs.fedoraproject.org/gitweb/?p=python.git;a=tree;h=refs/heads/f13/master;hb=refs/heads/f13/master It's not clear to me which of their changes from a stock build might be at issue, though, and even less clear whether they introduced a bug or did something to expose a bug of ours. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On 02/03/11 16:28, Tom Lane wrote: =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org writes: On 02/03/11 14:25, Robert Haas wrote: But does bumping the ref count then create a leak the rest of the time? Not really, because you never want to garbage collect the spiexceptions module (just like you don't want to GC th plpy module, or the plpy.info function etc.). So the reference count of that module should never drop to zero, but apparently on some machines it does. So just reffing artificailly is kind of a valid solution, I'm just uneasy with not knowing why it fails on some machines and does not on others. Yeah, that last point makes me nervous too. A look into the Fedora repository shows that the python version shipped in F13 is rather heavily patched: http://pkgs.fedoraproject.org/gitweb/?p=python.git;a=tree;h=refs/heads/f13/master;hb=refs/heads/f13/master It's not clear to me which of their changes from a stock build might be at issue, though, and even less clear whether they introduced a bug or did something to expose a bug of ours. FWIW I looked at these patches yesterday when I was trying to reproduce the bug, but did not find anything interesting. It's mostly for stuff in the standard library. I haven't tried building Python with all of of these patches though, and did not find an easy way to rebuild a SRPM on a Debian system. I'm also wondering if it can be a 32 vs 64 bit issue?... Jan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org writes: FWIW I looked at these patches yesterday when I was trying to reproduce the bug, but did not find anything interesting. It's mostly for stuff in the standard library. I haven't tried building Python with all of of these patches though, and did not find an easy way to rebuild a SRPM on a Debian system. I'm also wondering if it can be a 32 vs 64 bit issue?... Well, we can eliminate that last theory, because there were both 32 and 64 bit buildfarm machines showing the crash, cf bobcat and crake. BTW, I see the former is now running F14, not F13 as claimed on the buildfarm dashboard, so it doesn't look to be specific to a particular Fedora version either. I'm a bit tempted to install F15 alpha and see if it's still there ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On 03/02/2011 11:49 AM, Tom Lane wrote: Well, we can eliminate that last theory, because there were both 32 and 64 bit buildfarm machines showing the crash, cf bobcat and crake. BTW, I see the former is now running F14, not F13 as claimed on the buildfarm dashboard, That's because David apparently hasn't run update_personality.pl, although he has in the past. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On Wed, Mar 02, 2011 at 12:02:30PM -0500, Andrew Dunstan wrote: On 03/02/2011 11:49 AM, Tom Lane wrote: Well, we can eliminate that last theory, because there were both 32 and 64 bit buildfarm machines showing the crash, cf bobcat and crake. BTW, I see the former is now running F14, not F13 as claimed on the buildfarm dashboard, That's because David apparently hasn't run update_personality.pl, although he has in the past. Oops! Sorry about that! Done :) Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On Mar 2, 2011, at 9:02 AM, Andrew Dunstan wrote: That's because David apparently hasn't run update_personality.pl, although he has in the past. Is this something we can run against crazier community members? Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
Excerpts from Andrew Dunstan's message of mié mar 02 14:02:30 -0300 2011: On 03/02/2011 11:49 AM, Tom Lane wrote: Well, we can eliminate that last theory, because there were both 32 and 64 bit buildfarm machines showing the crash, cf bobcat and crake. BTW, I see the former is now running F14, not F13 as claimed on the buildfarm dashboard, That's because David apparently hasn't run update_personality.pl, although he has in the past. Does this also explain that moa reports being GCC while it's actually Sun Studio? -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On Thu, Mar 3, 2011 at 12:42 AM, Alvaro Herrera alvhe...@commandprompt.com wrote: Excerpts from Andrew Dunstan's message of mié mar 02 14:02:30 -0300 2011: On 03/02/2011 11:49 AM, Tom Lane wrote: Well, we can eliminate that last theory, because there were both 32 and 64 bit buildfarm machines showing the crash, cf bobcat and crake. BTW, I see the former is now running F14, not F13 as claimed on the buildfarm dashboard, That's because David apparently hasn't run update_personality.pl, although he has in the past. Does this also explain that moa reports being GCC while it's actually Sun Studio? moa has never changed - but there was a mixup with huia's keys when they were first registered on the buildfarm. I wonder if it wasn't the keys, but the rest of the info that was actually confused. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On 03/02/2011 02:12 PM, Alvaro Herrera wrote: Excerpts from Andrew Dunstan's message of mié mar 02 14:02:30 -0300 2011: On 03/02/2011 11:49 AM, Tom Lane wrote: Well, we can eliminate that last theory, because there were both 32 and 64 bit buildfarm machines showing the crash, cf bobcat and crake. BTW, I see the former is now running F14, not F13 as claimed on the buildfarm dashboard, That's because David apparently hasn't run update_personality.pl, although he has in the past. Does this also explain that moa reports being GCC while it's actually Sun Studio? No, that's just plain wrong. update_personality lets you change the OS and compiler version, but not the name or either. If you change OS or compiler you need a new animal. In this case it just looks like it was misdescribed from the start, so I'll fix it in the database. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On 03/02/2011 02:16 PM, Dave Page wrote: On Thu, Mar 3, 2011 at 12:42 AM, Alvaro Herrera alvhe...@commandprompt.com wrote: Excerpts from Andrew Dunstan's message of mié mar 02 14:02:30 -0300 2011: On 03/02/2011 11:49 AM, Tom Lane wrote: Well, we can eliminate that last theory, because there were both 32 and 64 bit buildfarm machines showing the crash, cf bobcat and crake. BTW, I see the former is now running F14, not F13 as claimed on the buildfarm dashboard, That's because David apparently hasn't run update_personality.pl, although he has in the past. Does this also explain that moa reports being GCC while it's actually Sun Studio? moa has never changed - but there was a mixup with huia's keys when they were first registered on the buildfarm. I wonder if it wasn't the keys, but the rest of the info that was actually confused. Oh, ugh. So if I switch the compiler names and versions on these two they will be correct? cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On Thu, Mar 3, 2011 at 12:54 AM, Andrew Dunstan and...@dunslane.net wrote: On 03/02/2011 02:16 PM, Dave Page wrote: On Thu, Mar 3, 2011 at 12:42 AM, Alvaro Herrera alvhe...@commandprompt.com wrote: Excerpts from Andrew Dunstan's message of mié mar 02 14:02:30 -0300 2011: On 03/02/2011 11:49 AM, Tom Lane wrote: Well, we can eliminate that last theory, because there were both 32 and 64 bit buildfarm machines showing the crash, cf bobcat and crake. BTW, I see the former is now running F14, not F13 as claimed on the buildfarm dashboard, That's because David apparently hasn't run update_personality.pl, although he has in the past. Does this also explain that moa reports being GCC while it's actually Sun Studio? moa has never changed - but there was a mixup with huia's keys when they were first registered on the buildfarm. I wonder if it wasn't the keys, but the rest of the info that was actually confused. Oh, ugh. So if I switch the compiler names and versions on these two they will be correct? Should be. Moa is definitely Sun Studio: -bash-3.00$ /opt/sunstudio12.1/bin/cc -V cc: Sun C 5.10 SunOS_i386 2009/06/03 usage: cc [ options] files. Use 'cc -flags' for details And Huia is GCC: -bash-3.00$ /usr/sfw/bin/gcc --version gcc (GCC) 3.4.3 (csl-sol210-3_4-20050802) Thanks. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On 3/1/11 12:35 PM, Tom Lane wrote: * Generate alpha release notes. This is at least half a day's work for somebody, I think, even with our fairly low standards for alpha release notes. I can help with this. Possibly Selena can too. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On Mar 1, 2011, at 12:35 PM, Tom Lane wrote: * Collation-related changes still needed in contrib/citext. If we don't have this done before alpha4, I'm afraid we'll have to generate a 1.1 update script to fix it for alpha4 users. I'd just as soon not deal with that overhead. What needs to happen here, exactly? I'm ignorant about about the correlation changes, but need to learn, and of course am willing to help out with citext, especially if correlation support might make it better. David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On 01/03/11 21:35, Tom Lane wrote: Josh Berkus j...@agliodbs.com writes: I'm ok with closing things as of the end of the 15 days, say Thursday or Friday. It might be a good idea to make a list of what we have left to do before we can wrap an alpha. Here are some things on my list. Not all of them are necessarily release blockers, but we need to discuss which ones are: * Regression test failures from recent plpython patches. These are affecting enough machines to make them must fix before alpha, IMO. There are some variations in error message wording, which are not too terrible but also not exactly hard to fix. The python assert failure that some Fedora machines are reporting is considerably more disturbing. I'm looking into the crash, no luck so long. Jan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On 03/01/2011 03:53 PM, Jan Urbański wrote: On 01/03/11 21:35, Tom Lane wrote: Josh Berkusj...@agliodbs.com writes: I'm ok with closing things as of the end of the 15 days, say Thursday or Friday. It might be a good idea to make a list of what we have left to do before we can wrap an alpha. Here are some things on my list. Not all of them are necessarily release blockers, but we need to discuss which ones are: * Regression test failures from recent plpython patches. These are affecting enough machines to make them must fix before alpha, IMO. There are some variations in error message wording, which are not too terrible but also not exactly hard to fix. The python assert failure that some Fedora machines are reporting is considerably more disturbing. I agree. I'm looking into the crash, no luck so long. Is there anything you need that would help you? cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On tis, 2011-03-01 at 12:50 -0800, David E. Wheeler wrote: On Mar 1, 2011, at 12:35 PM, Tom Lane wrote: * Collation-related changes still needed in contrib/citext. If we don't have this done before alpha4, I'm afraid we'll have to generate a 1.1 update script to fix it for alpha4 users. I'd just as soon not deal with that overhead. What needs to happen here, exactly? I'm ignorant about about the correlation changes, but need to learn, and of course am willing to help out with citext, especially if correlation support might make it better. I think you just need to put something like UPDATE pg_type SET typcollation = (SELECT oid FROM pg_collation WHERE collname = 'default') WHERE typname = 'citext'; into the upgrade script. The discussion last time was whether there should be ALTER TYPE support for that, but I guess we settled on not bothering. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
David E. Wheeler da...@kineticode.com writes: On Mar 1, 2011, at 12:35 PM, Tom Lane wrote: * Collation-related changes still needed in contrib/citext. If we don't have this done before alpha4, I'm afraid we'll have to generate a 1.1 update script to fix it for alpha4 users. I'd just as soon not deal with that overhead. What needs to happen here, exactly? I'm ignorant about about the correlation changes, but need to learn, and of course am willing to help out with citext, especially if correlation support might make it better. Collation, not correlation. The question is what collation property the citext type needs to have, and how we get it to have that setting during an upgrade from 9.0. See http://archives.postgresql.org/message-id/11548.1297983...@sss.pgh.pa.us regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On Mar 1, 2011, at 1:12 PM, Tom Lane wrote: Collation, not correlation. Yeah, I'm fat-fingered today. The question is what collation property the citext type needs to have, and how we get it to have that setting during an upgrade from 9.0. See http://archives.postgresql.org/message-id/11548.1297983...@sss.pgh.pa.us Ah, I remember now. That lead to this: http://archives.postgresql.org/pgsql-hackers/2011-02/msg01824.php So it looks like what Peter said about updating the catalog is what needs to be done, and is simple, yes? But then pg_dump needs more collation-juju. Am I right? Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
Tom Lane t...@sss.pgh.pa.us writes: Any other must fix items on people's minds? I'd like it if Magnus could commit his last round of work on pg_basebackup to stream the WALs in a subprocess. It's been about ready and waiting for more tests and code review while I've been ill. I should be able to get there by Friday, on the parts where I can help. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On Tue, Mar 1, 2011 at 22:20, Dimitri Fontaine dimi...@2ndquadrant.fr wrote: Tom Lane t...@sss.pgh.pa.us writes: Any other must fix items on people's minds? I'd like it if Magnus could commit his last round of work on pg_basebackup to stream the WALs in a subprocess. It's been about ready and waiting for more tests and code review while I've been ill. I should be able to get there by Friday, on the parts where I can help. I'd love to, but there's at least one bug still in there that needs to be tracked down. And I'm doing training most of this week, so unless someone else can pitch in, it may not be done on time. And while it's nice, I don't think it falls under *must* fix. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
David E. Wheeler da...@kineticode.com writes: On Mar 1, 2011, at 1:12 PM, Tom Lane wrote: The question is what collation property the citext type needs to have, and how we get it to have that setting during an upgrade from 9.0. See http://archives.postgresql.org/message-id/11548.1297983...@sss.pgh.pa.us Ah, I remember now. That lead to this: http://archives.postgresql.org/pgsql-hackers/2011-02/msg01824.php So it looks like what Peter said about updating the catalog is what needs to be done, and is simple, yes? But then pg_dump needs more collation-juju. Am I right? Yeah, the real problem in my mind is not so much citext as whether the current representation of a type's collation property is sane in the first place. Once we've thrashed that out, I'll be happy with a simple UPDATE pg_type kluge in the citext upgrade script. Doing anything cleaner-looking than that is a future project (and might never happen, seeing that we've never felt a need for ALTER TYPE commands for other properties of a basic type). So really I guess the release-blocker issue is http://archives.postgresql.org/message-id/27152.1299015...@sss.pgh.pa.us regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On 01/03/11 22:07, Andrew Dunstan wrote: On 03/01/2011 03:53 PM, Jan Urbański wrote: On 01/03/11 21:35, Tom Lane wrote: Josh Berkusj...@agliodbs.com writes: I'm ok with closing things as of the end of the 15 days, say Thursday or Friday. It might be a good idea to make a list of what we have left to do before we can wrap an alpha. Here are some things on my list. Not all of them are necessarily release blockers, but we need to discuss which ones are: * Regression test failures from recent plpython patches. These are affecting enough machines to make them must fix before alpha, IMO. There are some variations in error message wording, which are not too terrible but also not exactly hard to fix. The python assert failure that some Fedora machines are reporting is considerably more disturbing. I agree. I'm looking into the crash, no luck so long. Is there anything you need that would help you? Could you try this patch and see if it fixes the failures? I'm at a loss as to why this happens, but judging from the traceback the spiexceptions module is getting unreffed somewhere and when garbage collection kicks it it barfs on an object with refcount 0. So I'm forcing an incref of the module to confirm that. I tried various tricks on 32 bit Debian, with Python 2.6, 2.7, Python compiled from Fedora's SRPM and I never saw anything wrong. Will keep on trying, but tommorrow evening, time to sleep :( Cheers, Jan diff --git a/src/pl/plpython/plpython.c b/src/pl/plpython/plpython.c index 4cc0708..a2ebd22 100644 --- a/src/pl/plpython/plpython.c +++ b/src/pl/plpython/plpython.c @@ -3936,6 +3936,7 @@ PLy_add_exceptions(PyObject *plpy) #endif if (PyModule_AddObject(plpy, spiexceptions, excmod) 0) PLy_elog(ERROR, failed to add the spiexceptions module); + Py_INCREF(excmod); PLy_exc_error = PyErr_NewException(plpy.Error, NULL, NULL); PLy_exc_fatal = PyErr_NewException(plpy.Fatal, NULL, NULL); -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)
On 03/01/2011 05:19 PM, Jan Urbański wrote: On 01/03/11 22:07, Andrew Dunstan wrote: On 03/01/2011 03:53 PM, Jan Urbański wrote: On 01/03/11 21:35, Tom Lane wrote: Josh Berkusj...@agliodbs.com writes: I'm ok with closing things as of the end of the 15 days, say Thursday or Friday. It might be a good idea to make a list of what we have left to do before we can wrap an alpha. Here are some things on my list. Not all of them are necessarily release blockers, but we need to discuss which ones are: * Regression test failures from recent plpython patches. These are affecting enough machines to make them must fix before alpha, IMO. There are some variations in error message wording, which are not too terrible but also not exactly hard to fix. The python assert failure that some Fedora machines are reporting is considerably more disturbing. I agree. I'm looking into the crash, no luck so long. Is there anything you need that would help you? Could you try this patch and see if it fixes the failures? I'm at a loss as to why this happens, but judging from the traceback the spiexceptions module is getting unreffed somewhere and when garbage collection kicks it it barfs on an object with refcount 0. So I'm forcing an incref of the module to confirm that. I tried various tricks on 32 bit Debian, with Python 2.6, 2.7, Python compiled from Fedora's SRPM and I never saw anything wrong. Will keep on trying, but tommorrow evening, time to sleep :( Thanks. That seems to have fixed it, so I have applied the patch. Would you like to supply some comments to got with it? cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
