Re: [HACKERS] Feature freeze progress report
Bruce Momjian wrote: Sounds interesting, but I am not sure how that is going to track multiple versions of the patch, They could easily be submitted through the web interface as revisions to the original version. or changes in the email subject. We'd need to keep the reference number in there, but other than that it could change. We could also examine the in-reply-to header of every email and attach based on that, but I'm not sure that's necessary. The bottom line is that there is a lot of thinking that the patch queue is so large because no one knows what to do. Oh, if we were better communicators, more would be done. The patch queue is large because we have lots of March 31 patches, and because we don't have enough people to review them quickly. Thats is true, but there are also patches in there that have been there for quite some time adn have had little or no feedback. Consider Heikki's grouped index items patch (http://momjian.us/mhonarc/patches/msg00032.html). That thread starts on 7th March when he posted an update because the old one had bitrotted. There are six messages in the thread on the patch queue, four of which say message no available, and the last means little without the preceeding messages. When a committer comes to look at this, if he's not sure of something he's going to be wasting time searching the archives to find all the different thread fragments that make up the various discussions on the topic, and those related to each individual revision of the patch. That has got to be part of what makes reviewing patches both hard, and uninteresting work. If we can make it easier and quicker, even with just the current committers we might have found that one of you were able (and keen) to review much more quickly. The people who have expressed interest in reviewing patches already know where we stand on the patches, and a status email of where we are each patch will be posted shortly. I just can't do it this time because I am traveling. This is precisely the sort of trivial task that I believe we can make much easier for you, if not eliminate altogether. If you want to try a tracking system, go ahead, just pull from the patches email list, and somehow try to grab discussion from hackers/patches on this patches, and give a way to manually update the patch status via a web site. OK, I will give it some thought. Obviously I'm not going to do much more before release though. If your system works, I will not need to maintain a separate patches queue, but I will keep doing it until we know the web site idea will work, just in case. I would expect nothing less :-) Regards, Dave. ---(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] Fwd: [PATCHES] Preliminary GSSAPI Patches
Tom Lane wrote: Henry B. Hotz [EMAIL PROTECTED] writes: Don't you want to maintain some interoperability between 8.2 client/ server and 8.3 server/client at least? Hm, you mean that what you called a C API change actually break^H^H^H^H^Hchanges the on-the-wire protocol as well? That sounds not very nice :-( It's a completely new authentication method, that just happens to use Kerberos underneath it. And it uses the API/wireprotocol that's recommended by the Kerberos folks. And in fact when talking to the MIT folks back when I found that security issue two years back it seems we're more or less the only ones other than sample apps taht use the native api. Fact is that the way we do it now is not very pretty. The GSSAPI way lets PostgreSQL handle sending/receiving and wrapping in whatever we want, whereas the current method we just pass in the socket. I think in a lot of ways it's just pure luck that it works reasonably well alongside OpenSSL for example. I think the correct path is to put it in GSSAPI and deprecate krb5 for at least one release, and then get rid of krb5 completely. Oh, and I do think putting in GSSAPI authentication only (and not encryption) is the way to go for now, since we can do encryption with OpenSSL. It'll make the changes localized to just the authentication. //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Fwd: [PATCHES] Preliminary GSSAPI Patches
Henry B. Hotz wrote: OK, so posted. ;-) snip Would you like a new version of the patch with the incomplete functionality commented out (or otherwise removed)? Yes please :-) I was going to try to do one of those myself, but since you already know your way around the code, please do it. And please go for removing it alltogether instead of just commenting it out - it's in the list archives and can be referred to there if/when we want to add it back in. I'd also vote for changing the name of the non encrypted version to just gss instead of gss-np. //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] How to hidde the column from the user
Hi, I want to add a column in the table and also want to hidde that column from the user. So that user's normal insertion and update goes on (means user will not supply the value for my hidden column). Is there any way to hidde the column from the user. I tried to make my column (attisdropped setting as true). So now that column is hide from the user but now that column will be sometime deleted by postgres. But i do not want that my column should be deleted. Is there any way for doing this. Or can you suggest some better way for this. Thanks, Rupesh Bajaj
Re: [HACKERS] How to hidde the column from the user
rupesh bajaj wrote: Hi, I want to add a column in the table and also want to hidde that column from the user. So that user's normal insertion and update goes on (means user will not supply the value for my hidden column). Is there any way to hidde the column from the user. I tried to make my column (attisdropped setting as true). So now that column is hide from the user but now that column will be sometime deleted by postgres. But i do not want that my column should be deleted. Is there any way for doing this. Or can you suggest some better way for this. You should ask usage questions on pgsql-general to get more informative responses. Create a view on top of the table that hides the column. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] How to hidde the column from the user
On Tue, May 01, 2007 at 03:09:17PM +0530, rupesh bajaj wrote: Hi, I want to add a column in the table and also want to hidde that column from the user. So that user's normal insertion and update goes on (means user will not supply the value for my hidden column). Is there any way to hidde the column from the user. I tried to make my column (attisdropped setting as true). So now that column is hide from the user but now that column will be sometime deleted by postgres. But i do not want that my column should be deleted. Is there any way for doing this. Or can you suggest some better way for this. Make it a view on a real table and revoke access permissions on the real table? Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] 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] How to hidde the column from the user
On Tue, 1 May 2007, rupesh bajaj wrote: Hi, I want to add a column in the table and also want to hidde that column from the user. So that user's normal insertion and update goes on (means user will not supply the value for my hidden column). Is there any way to hidde the column from the user. I tried to make my column (attisdropped setting as true). So now that column is hide from the user but now that column will be sometime deleted by postgres. But i do not want that my column should be deleted. Is there any way for doing this. Or can you suggest some better way for this. Let user work with view public.table_view, which is a view of backend.table. Regards, Oleg _ Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru), Sternberg Astronomical Institute, Moscow University, Russia Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(495)939-16-83, +007(495)939-23-83 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Heap page diagnostic functions
Any suggestions? pgdiagnostics? I'm happy with forensics myself. Bruce Momjian wrote: Sounds good, though I am worried that forensics will not be a word easily understood by non-native English speakers. --- Heikki Linnakangas wrote: I'm taking over Simon's heap page diagnostic functions to get them into shape for committing. I'm thinking of having a new contrib-module for them: pgforensics. All the new functions go there, and I'm also going to move bt_page_items, bt_page_stats, and bt_metap functions from pgstattuple to the new module. They're all low-level functions that no application should be calling, so there shouldn't be any compatibility issues in moving them. That'd leave only the functions that a DBA or tools should be concerned with in pgstattuple, and all the low-level debugging aids to the new module. Thoughts? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org -- Heikki Linnakangas 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
Re: [HACKERS] SOS, help me please, one problem towards the postgresql developement on windows
thankyou very much. but the method, you said, is adding a alias name, so it can not work. and as i need to add many functions likes this, so the best way is to compile the whole postgresql. eventhough, i did, it didnot work, so i am puzzled, can add a function directly in the source file, and compile it, can it work?? BTW: I have just seach the source for addingthe built-in function, and found it need to add declaration in the include geo_decls.h, and add the function in the geo_ops.c. can it not be enough?? On 5/1/07, Martijn van Oosterhout [EMAIL PROTECTED] wrote: On Mon, Apr 30, 2007 at 11:05:35AM +0800, shieldy wrote: thankyou for your reply. I added it to the backend, because the internal ones such as box_intersect() function is keeped at there. so in my opinion, I just need to add a function to the files, and then compile it. then we can use it as the internal ones. bytheway, what's the backend file used for? I just didnot quite understand the postgresql. and your meaning place it in a module , how should i do?? First, please reply to the list, not to me directly. Secondly, just because you add it to the backend doesn't mean you can use it straight away. There are thousands of functions in postgresql you can't access from SQL, you have to declare them. See here: http://www.postgresql.org/docs/8.2/interactive/xfunc-internal.html Finally, by putting it in the backend you have to rebuild postgres every time you want to change a function. Complete waste of time as postgres can load external modules. See here: http://www.postgresql.org/docs/8.2/interactive/xfunc-c.html Or better, just read the whole Extending SQL section. http://www.postgresql.org/docs/8.2/interactive/extend.html Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFGNwoKIB7bNG8LQkwRAjXuAJ9atldhI9Q81lIuRpD8Egguv5ojvgCcCk4v /Jkr0WGrKP9mxN94iw9X3/U= =Swve -END PGP SIGNATURE-
Re: [HACKERS] Feature freeze progress report
Dave Page wrote: The bottom line is that there is a lot of thinking that the patch queue is so large because no one knows what to do. Oh, if we were better communicators, more would be done. The patch queue is large because we have lots of March 31 patches, and because we don't have enough people to review them quickly. Thats is true, but there are also patches in there that have been there for quite some time adn have had little or no feedback. Consider Heikki's grouped index items patch (http://momjian.us/mhonarc/patches/msg00032.html). That thread starts on 7th March when he posted an update because the old one had bitrotted. There are six messages in the thread on the patch queue, four of which say message no available, and the last means little without the preceeding messages. When a committer comes to look at this, if he's not sure of something he's going to be wasting time searching the archives to find all the different thread fragments that make up the various discussions on the topic, and those related to each individual revision of the patch. That has got to be part of what makes reviewing patches both hard, and uninteresting work. If we can make it easier and quicker, even with just the current committers we might have found that one of you were able (and keen) to review much more quickly. The bottom line is if you had a system that was 100% perfect in capturing all information about a patch, it only helps us 2% toward reviewing the patch, and what is the cost of keeping 100% information? -- 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] Heap page diagnostic functions
Heikki Linnakangas wrote: Any suggestions? pgdiagnostics? Yes, I like diagnostics, or internals. I just think forensics isn't going to be understood by the average native English speaker, let alone non-English speakers. --- I'm happy with forensics myself. Bruce Momjian wrote: Sounds good, though I am worried that forensics will not be a word easily understood by non-native English speakers. --- Heikki Linnakangas wrote: I'm taking over Simon's heap page diagnostic functions to get them into shape for committing. I'm thinking of having a new contrib-module for them: pgforensics. All the new functions go there, and I'm also going to move bt_page_items, bt_page_stats, and bt_metap functions from pgstattuple to the new module. They're all low-level functions that no application should be calling, so there shouldn't be any compatibility issues in moving them. That'd leave only the functions that a DBA or tools should be concerned with in pgstattuple, and all the low-level debugging aids to the new module. Thoughts? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org -- Heikki Linnakangas 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 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Feature freeze progress report
Naz Gassiep wrote: I believe the suggestion was to have an automated process that only ran on known, sane patches. How do we know in advance of reviewing them that they are sane? What is more, we often run into situations where patch a will require changes in patch b, so testing them individually against CVS is not likely to be terribly useful. Frankly, our problems are not primarily technological. They have to do mainly with scarcity of available time from competent reviewers. No amount of automation will fix that. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Feature freeze progress report
On Tue, 2007-01-05 at 02:54 +0100, Gregory Stark wrote: Naz Gassiep [EMAIL PROTECTED] writes: Even if the patch inventory wasn't kept right up to date, this system could potentially help many regression issues or bugs to surface sooner, I just don't understand what this would accomplish. People run regressions before submitting anyways. They can't run them on all architectures but bugs that only affect some architectures are uncommon. The intention is to help keep patches, which may remain in the queue for extended lengths of time, reasonably current. The mechanism aims to help with these specific problems: - patches accumulates bitrot and are consequently harder to apply and understand - the author, by the time review occurs, no longer has the details of the patch uppermost in their mind If the author can be automatically prodded when the patch no longer cleanly applies, or when it suddenly breaks regression tests, they will be able to keep the patch current, may discover bugs in it themselves prior to review, and it will remain more fresh in their minds. For sure, there will be classes of patch for which this mechanism provides no benefit. For instance, where a patch contains code that is for discussion only, or a patch that is dependant on another patch. In these cases, the mechanism would simply note that they don't apply cleanly, or don't pass tests, and would do nothing further. I can see no harm here. This seems to be merely institutionalizing having a large backlog of patches which survive for long periods of time. But even in that situation I don't see what it buys us. Detecting bitrot isn't terribly helpful and it doesn't help us actually deal with the bitrot once it's happened. I hope that it would not encourage reviewers to leave things in the patch queue. I don't see why it would, so don't think this would institutionalize a backlog. I also disagree that detecting bitrot is not helpful. If I had eagerly submitted a patch, I would definitely want to fix any bitrot that occurred and would be thankful to be automatically informed. And to clarify, I do not think the buildfarm should be involved in this process. __ Marc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Feature freeze progress report
Bruce Momjian wrote: The bottom line is if you had a system that was 100% perfect in capturing all information about a patch, it only helps us 2% toward reviewing the patch, and what is the cost of keeping 100% information? 2% for you or Tom reviewing a recently discussed, run-of-the mill patch. I suspect that %age will rise as the patch complexity increases and the reviewers experience decreases - which is exactly the situation that it would help to improve. Also note that I'm not saying I can produce a system that's 100% correct - just one that will capture the posts that keep the patch ID in their subject line *automatically* - meaning you don't have to worry about keeping threads for the existing queue or tracking the patch status. Regards Dave ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Another problem with result type selection in inline_function
I just realized that there's a problem with the patch I applied here http://archives.postgresql.org/pgsql-committers/2007-03/msg00057.php to ensure that the result type of an inline'd SQL function is correctly marked in the resulting expression tree. To wit, it doesn't work for functions returning pseudotypes: regression=# create function if(bool,anyelement,anyelement) returns anyelement regression-# as $$ select case when $1 then $2 else $3 end $$ language sql; CREATE FUNCTION regression=# explain verbose select if(true,1,2) from int4_tbl; server closed the connection unexpectedly The crash is because this newly-added assert fails: Assert(IsBinaryCoercible(exprType(newexpr), funcform-prorettype)); and beyond that, we don't actually want the other added line (adding a RelabelType node) either, because it'd be relabeling the expression as type ANYELEMENT which is entirely unhelpful. I think the correct thing is to do nothing, and assume the expanded expression must have the right type already, if the function is declared to return a pseudotype. The only pseudotypes allowed as SQL-function results are RECORD, VOID, and polymorphic, and this seems OK and maybe even required in each case. But having gotten this wrong once already, maybe I better call for comments... regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Heap page diagnostic functions
Bruce Momjian [EMAIL PROTECTED] writes: Heikki Linnakangas wrote: Any suggestions? pgdiagnostics? Yes, I like diagnostics, or internals. I just think forensics isn't going to be understood by the average native English speaker, let alone non-English speakers. diagnostics is a two-dollar word also. It might be a bit more widely known than forensics, but it's longer and harder to spell. Not that I have any great suggestions to make. Maybe pgtestfuncs? regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Heap page diagnostic functions
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Heikki Linnakangas wrote: Any suggestions? pgdiagnostics? Yes, I like diagnostics, or internals. I just think forensics isn't going to be understood by the average native English speaker, let alone non-English speakers. diagnostics is a two-dollar word also. It might be a bit more widely known than forensics, but it's longer and harder to spell. Not that I have any great suggestions to make. Maybe pgtestfuncs? I thought about pgdebugfuncs myself at first. But that's so generic and pgtestfuncs even more so. Diagnostics is pretty good, that word is in use in other languages as well as a medical term, so it's meaning would be clear to a lot of people even if they've never encountered the English word before. Besides, the audience for these functions is quite narrow: people working on PostgreSQL internals, so I don't think the language issue matters that much. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Feature freeze progress report
Bruce, The bottom line is if you had a system that was 100% perfect in capturing all information about a patch, it only helps us 2% toward reviewing the patch, and what is the cost of keeping 100% information? 2% for you or Tom reviewing a recently discussed, run-of-the mill patch. I suspect that %age will rise as the patch complexity increases and the reviewers experience decreases - which is exactly the situation that it would help to improve. Moreover, what I'm looking for is tools which will: 1) allow existing reviewers to make better use of the time that they have, and 2) encourage/assist new reviewers in helping out, and 3) not bottleneck on the availability of a single project member The current patch-queue process is failing to scale with the project: every release it gets to be more work for you Tom to integrate the patches. We need to think of new approaches to make the review process scale. As a pointed example, you're about to go on tour for 2 weeks and patch review will stall while you're gone. That's not sustainable. If you don't think that a web tool will help, then what *do* you think will help? Just soldiering on isn't really an answer, and I notice that you're very quick to come up with reasons why anything we might try will fail, but extremely reluctant to make suggestions for improvement. == Dave, Also note that I'm not saying I can produce a system that's 100% correct - just one that will capture the posts that keep the patch ID in their subject line *automatically* - meaning you don't have to worry about keeping threads for the existing queue or tracking the patch status. Is there a reason why the system needs to be primarily based on e-mail? I was thinking that the patch manager would be entirely a web tool, with people submitting and modifying a patch directly through a web interface. This would be lots easier to build than an e-mail based system, and also far more useful from a monitoring standpoint. I've worked with e-mail based systems like RT and OTRS, and frankly they're extremely high-maintenance and suffer a large amount of lost information. We could also build a number of other things into the web tool, like a You are submitting this patch under BSD disclaimer and pointers to the Developer FAQ and other relevant documents. -- Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] temporal variants of generate_series()
On Apr 28, 2007, at 8:00 PM, David Fetter wrote:
Here's an SQL version without much in the way of bounds checking :)
CREATE OR REPLACE FUNCTION generate_series (
start_ts timestamptz,
end_ts timestamptz,
step interval
) RETURNS SETOF timestamptz
LANGUAGE sql
AS $$
SELECT
CASE
WHEN $1 $2 THEN
$1
WHEN $1 $2 THEN
$2
END + s.i * $3 AS generate_series
FROM generate_series(
0,
floor(
CASE
WHEN $1 $2 AND $3 INTERVAL '0 seconds' THEN
extract('epoch' FROM $2) -
extract('epoch' FROM $1)
WHEN $1 $2 AND $3 INTERVAL '0 seconds' THEN
extract('epoch' FROM $1) -
extract('epoch' FROM $2)
END/extract('epoch' FROM $3)
)::int8
) AS s(i);
$$;
It should be straight-forward to make similar ones to those below.
Are you sure the case statements are needed? It seems it would be
better to just punt to the behavior of generate_series (esp. if
generate_series eventually learns how to count backwards).
--
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Feature freeze progress report
Two more ideas for the manager, now that we seem to have consensus to build one. On Apr 30, 2007, at 6:04 PM, Josh Berkus wrote: -- We could save the patches by applied date and index them, and then have a place to point users when they ask: When was X fixed? Do I *have* to upgrade to 8.1 or just 8.0? This should also make doing the release notes substantially easier, though since there's probably some stuff that wouldn't go through the patch queue we'd want commits from the patch queue to be marked differently. That brings up another idea for the patch management webapp... presumably it could handle most/all of the process of actually committing a patch. Granted, that's not a huge amount of work, but it's silly to have committers do by hand that hich could be automated. -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Heap page diagnostic functions
Heikki Linnakangas wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Heikki Linnakangas wrote: Any suggestions? pgdiagnostics? Yes, I like diagnostics, or internals. I just think forensics isn't going to be understood by the average native English speaker, let alone non-English speakers. diagnostics is a two-dollar word also. It might be a bit more widely known than forensics, but it's longer and harder to spell. Not that I have any great suggestions to make. Maybe pgtestfuncs? I thought about pgdebugfuncs myself at first. But that's so generic and pgtestfuncs even more so. Diagnostics is pretty good, that word is in use in other languages as well as a medical term, so it's meaning would be clear to a lot of people even if they've never encountered the English word before. Besides, the audience for these functions is quite narrow: people working on PostgreSQL internals, so I don't think the language issue matters that much. I did not find forensics in translator and It mentions in Oxford vocabulary but explanation is not clear for me. I agree with Bruce It is not good name. What about short form of diagnostic diag? Zdenek ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Feature freeze progress report
Josh, Josh Berkus wrote: Is there a reason why the system needs to be primarily based on e-mail? I was thinking that the patch manager would be entirely a web tool, with people submitting and modifying a patch directly through a web interface. This would be lots easier to build than an e-mail based system, and also far more useful from a monitoring standpoint. I've worked with e-mail based systems like RT and OTRS, and frankly they're extremely high-maintenance and suffer a large amount of lost information. The reason for basing the system on email is simply that it minimises the changes required in the community process. If it were entirely web based, we'd have to change the way we all work to discuss patches in a forum style, rather than a list style. I have a sneaking suspicion that at least one of our most valued contributors might object to that. As long as the patch were initially submitted through the web interface so that it got assigned an ID, we could automatically track the initial, and followup threads on any of the lists as long as the ID is retained in the subject line. We could also build a number of other things into the web tool, like a You are submitting this patch under BSD disclaimer and pointers to the Developer FAQ and other relevant documents. Oh for sure. We could even do silly stuff like try to automatically determine if the patch is in diff -c format ;-) Regards, Dave ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Feature freeze progress report
Dave, The reason for basing the system on email is simply that it minimises the changes required in the community process. If it were entirely web based, we'd have to change the way we all work to discuss patches in a forum style, rather than a list style. I have a sneaking suspicion that at least one of our most valued contributors might object to that. Hmmm, yeah, I can see. However, I think it's possible to separate the patch discussion from patch submission; that is, to submit/edit/update patch code through the interface, but to do the discussion either through e-mail or the interface. As long as the patch were initially submitted through the web interface so that it got assigned an ID, we could automatically track the initial, and followup threads on any of the lists as long as the ID is retained in the subject line. Yes, and any changes to the patch code itself, as well. My concern with making the tool e-mail centric is that, based on e-mail based tools I've worked with, I'm afraid that the tool will be clunky/buggy enough not to be an improvement over the current process -- too much of e-mail format is optional varies by MUA. If e-mail is limited to commentary, though, I don't see that as a problem. And, of course, it would be easy for the tool to send e-mail to pgsql-patches. If many people are going to block on using a web tool for submitting new versions of a patch, claiming responsibility for review, etc., though, then we should probably abandon this discussion right here. No new tool is going to work if we have people who won't make any changes at all in their work habits. Oh for sure. We could even do silly stuff like try to automatically determine if the patch is in diff -c format ;-) No! Dave, you're a real radical sometimes. -- Josh Berkus PostgreSQL @ Sun San Francisco ---(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] Heap page diagnostic functions
Zdenek Kotala wrote: I did not find forensics in translator and It mentions in Oxford vocabulary but explanation is not clear for me. I agree with Bruce It is not good name. What about short form of diagnostic diag? Doesn't forensics basically mean to find the cause of something *after* it happened, based on traces that the event left behind? Like finding the culprit of a crime done using for example fingerprints he left, or tracing the actions of an intruder by analyzing logfiles or modified binaries? In that case, it doesn't accuratly describe those functions anyway I think, because you call them from inside the database while it's running, not from the outside after it was stopped or crashed. Just the 2 eurocents of a non-native speaker... Greetings, Florian Pflug ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Feature freeze progress report
On Tue, 2007-05-01 at 09:43 -0700, Josh Berkus wrote: The current patch-queue process is failing to scale with the project: every release it gets to be more work for you Tom to integrate the patches. We need to think of new approaches to make the review process scale. As a pointed example, you're about to go on tour for 2 weeks and patch review will stall while you're gone. That's not sustainable. This seems a reasonable observation on events. I'll come up with ideas to help, if asked, but I'd like to follow a proposal from Core on this issue. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Fwd: [PATCHES] Preliminary GSSAPI Patches
On May 1, 2007, at 1:16 AM, Magnus Hagander wrote: Henry B. Hotz wrote: OK, so posted. ;-) snip Would you like a new version of the patch with the incomplete functionality commented out (or otherwise removed)? Yes please :-) I was going to try to do one of those myself, but since you already know your way around the code, please do it. And please go for removing it alltogether instead of just commenting it out - it's in the list archives and can be referred to there if/when we want to add it back in. I can do that. Could I ask you, or someone else, to look at what needs to happen to configure? The way you capture `krb5-config --libs gssapi` into a variable is completely different in BSD and GNU make, and I don't know how to deal with that. (The configure logic for mod_auth_kerb suffers from that problem, too.) The README.GSSAPI file in the patch has reasonable notes, and it should be pretty simple otherwise. I'd also vote for changing the name of the non encrypted version to just gss instead of gss-np. I happen to disagree on this point. There are a whole class of attacks that become possible if the encryption from the original authentication exchange isn't used for the on-going channel encryption/integrity. They may be impossible in practice, but how many cans of worms do you want to deal with when you recommend a secure configuration to an average admin? I would rather not hide the distinction by changing the name that way. Also, if I *do* get the buffering disentangled and create a working gss mechanism, what would I call it if the name is already taken? At that point it would become the recommended mechanism unless high- volume performance made it impractical. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Heap page diagnostic functions
Florian G. Pflug [EMAIL PROTECTED] writes: Doesn't forensics basically mean to find the cause of something *after* it happened, based on traces that the event left behind? Hmm ... the Oxford English Dictionary defines forensic as pertaining to, connected with, or used in courts of law. There are also some senses related to argumentation, but nothing specifically about evidence analysis, whether after-the-fact or not. So yeah, it doesn't seem like a good name for these functions anyhow. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Another problem with result type selection in inline_function
I wrote: I think the correct thing is to do nothing, and assume the expanded expression must have the right type already, if the function is declared to return a pseudotype. The only pseudotypes allowed as SQL-function results are RECORD, VOID, and polymorphic, and this seems OK and maybe even required in each case. But having gotten this wrong once already, maybe I better call for comments... Make that 0 for 2 :-(. On closer inspection the correct patch seems to be just to use result_type, ie the result type the function call node was already labeled with, not funcform-prorettype (the function's declared result type). This can be seen to be correct from two arguments: 1. The whole point of the RelabelType insertion is to ensure that the exposed type of the expression tree (as reported by exprType say) remains the same as before. And result_type is exactly what it was before. 2. result_type, not prorettype, is in fact what check_sql_fn_retval() was checking against. That Assert was intended to back up that we were in sync with check_sql_fn_retval(), but we weren't. So this is just a pure thinko in the previous patch. Sigh. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Heap page diagnostic functions
Zdenek Kotala wrote: Heikki Linnakangas wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Heikki Linnakangas wrote: Any suggestions? pgdiagnostics? Yes, I like diagnostics, or internals. I just think forensics isn't going to be understood by the average native English speaker, let alone non-English speakers. diagnostics is a two-dollar word also. It might be a bit more widely known than forensics, but it's longer and harder to spell. Not that I have any great suggestions to make. Maybe pgtestfuncs? I thought about pgdebugfuncs myself at first. But that's so generic and pgtestfuncs even more so. Diagnostics is pretty good, that word is in use in other languages as well as a medical term, so it's meaning would be clear to a lot of people even if they've never encountered the English word before. Besides, the audience for these functions is quite narrow: people working on PostgreSQL internals, so I don't think the language issue matters that much. I did not find forensics in translator and It mentions in Oxford vocabulary but explanation is not clear for me. I agree with Bruce It is not good name. What about short form of diagnostic diag? Webster lists scientific analysis of physical evidence (as from a crime scene) as one meaning: http://www.webster.com/dictionary/forensics. I'm going to go with pgdiagnostics. We could short it to just pgdiag, but that feels too short :). We could make it pgdiagfuncs, but that's not much shorter than pgdiagnostics. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Fwd: [PATCHES] Preliminary GSSAPI Patches
Magnus, I'd also vote for changing the name of the non encrypted version to just gss instead of gss-np. I don't. We'll want to support GSS encryption once we have the code, so we should leave the namespace open to address that. Oh, and I do think putting in GSSAPI authentication only (and not encryption) is the way to go for now, since we can do encryption with OpenSSL. It'll make the changes localized to just the authentication. For now, yes. In the long run, we want to provide users with other methods of encrypted connections than the rather flaky and not-available-on-every-platform OpenSSL. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Fwd: [PATCHES] Preliminary GSSAPI Patches
Henry B. Hotz wrote: On May 1, 2007, at 1:16 AM, Magnus Hagander wrote: Henry B. Hotz wrote: Would you like a new version of the patch with the incomplete functionality commented out (or otherwise removed)? Yes please :-) I was going to try to do one of those myself, but since you already know your way around the code, please do it. And please go for removing it alltogether instead of just commenting it out - it's in the list archives and can be referred to there if/when we want to add it back in. I can do that. Thanks! Could I ask you, or someone else, to look at what needs to happen to configure? The way you capture `krb5-config --libs gssapi` into a variable is completely different in BSD and GNU make, and I don't know how to deal with that. (The configure logic for mod_auth_kerb suffers from that problem, too.) The README.GSSAPI file in the patch has reasonable notes, and it should be pretty simple otherwise. I'll leave the autoconf-fu to someone else if possible, but I can look at it later if nobody does (will look at the rest too). The docs need to be moved from README into the proper docs as well, but I can take care of that once the code is settled. I'd also vote for changing the name of the non encrypted version to just gss instead of gss-np. I happen to disagree on this point. There are a whole class of attacks that become possible if the encryption from the original authentication exchange isn't used for the on-going channel encryption/integrity. They may be impossible in practice, but how many cans of worms do you want to deal with when you recommend a secure configuration to an average admin? I would rather not hide the distinction by changing the name that way. Also, if I *do* get the buffering disentangled and create a working gss mechanism, what would I call it if the name is already taken? At that point it would become the recommended mechanism unless high-volume performance made it impractical. I would call them gss and gss-sec. Or possibly gss-enc. I think that's a lot more clear than gss-np (something ending with -sec is a giveaway) But I won't fight for it, it's not that important to me :-) (And whether it's recommended or not depends on the environment - there are a cases where it's just unnecessary to add it. Say if you're employing ipsec across your network, adding a second layer of encryption will just make things slower for no gain - and it makes things more complex. Even if you're not talking high volume.) //Magnus ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Fwd: [PATCHES] Preliminary GSSAPI Patches
Josh Berkus wrote: Magnus, I'd also vote for changing the name of the non encrypted version to just gss instead of gss-np. I don't. We'll want to support GSS encryption once we have the code, so we should leave the namespace open to address that. I agree that we should do this, I'm just suggesting different names, namely gss and gss-sec. Oh, and I do think putting in GSSAPI authentication only (and not encryption) is the way to go for now, since we can do encryption with OpenSSL. It'll make the changes localized to just the authentication. For now, yes. In the long run, we want to provide users with other methods of encrypted connections than the rather flaky and not-available-on-every-platform OpenSSL. Certainly. I'm talking short-term when I say that. When we eventually do -sec, it might be worthwhile to consider that in the context of the GnuTLS patches that were thrown around earlier - maybe something can be done for both of them, so we don't get a hugely expanded codebase. //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Feature freeze progress report
Josh Berkus wrote: If many people are going to block on using a web tool for submitting new versions of a patch, claiming responsibility for review, etc., though, then we should probably abandon this discussion right here. No new tool is going to work if we have people who won't make any changes at all in their work habits. We could do most of what people want using a tracker, but that discussion always seems to end up nowhere. And, as I have noted before, use of a tracker will become a total mess unless there are adequate resources to keep it clean and up to date (e.g. to put links in items to mailing list discussions, update state etc.) So if the commercial backers of PostgreSQL want better management of the project, maybe they need to find some resources to help out. cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Fwd: [PATCHES] Preliminary GSSAPI Patches
Josh Berkus wrote: Magnus, I'd also vote for changing the name of the non encrypted version to just gss instead of gss-np. I don't. We'll want to support GSS encryption once we have the code, so we should leave the namespace open to address that. Oh, and I do think putting in GSSAPI authentication only (and not encryption) is the way to go for now, since we can do encryption with OpenSSL. It'll make the changes localized to just the authentication. For now, yes. In the long run, we want to provide users with other methods of encrypted connections than the rather flaky and not-available-on-every-platform OpenSSL. I'm curious - on what platform is OpenSSL NOT available ? Stefan ---(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] MSVC
Andrew Dunstan wrote: Now that we seem to have MSVC building working tolerably well, I think we need a bit of cleanup. In particular, I think the config setup needs to be more like the arguments we pass to the standard configure script. Why? I'm not saying I'm against it, I'd just like to know why? Personally, I find the store-in-a-file a whole lot more handy. This shouldn't be hard, but I think it should be done before we go to beta, if possible. I think the names should match up pretty much one for one - this should make faking out pg_config easier. If we're changing it then yes, it's definitely better to do it before beta. Since this is a perl hash, we'll need to have some sort of mapping convention. I suggest this: . where the configure arg doesn't take a value, make the hash value undef (e.g. '--enable-integer-datetimes' = undef ) Is there a way to differ that from just not being defined? otherwise, why not just make it 1 instead of undef? . where the configure arg would occur with a single value, just set that (e.g. '--prefix' = 'c:\\foo' ) . where the configure arg would occur with a multiple value, provide a listref (e.g. '--with-libs' = [ 'c:\\bar', 'd:\\baz' ] ) These I get. ;-) //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Feature freeze progress report
Josh Berkus wrote: Dave, The reason for basing the system on email is simply that it minimises the changes required in the community process. If it were entirely web based, we'd have to change the way we all work to discuss patches in a forum style, rather than a list style. I have a sneaking suspicion that at least one of our most valued contributors might object to that. Hmmm, yeah, I can see. However, I think it's possible to separate the patch discussion from patch submission; that is, to submit/edit/update patch code through the interface, but to do the discussion either through e-mail or the interface. I'd just keep all discussion in email, no need to do that off the web. As long as you can *read* all the references on the web. As long as the patch were initially submitted through the web interface so that it got assigned an ID, we could automatically track the initial, and followup threads on any of the lists as long as the ID is retained in the subject line. Yes, and any changes to the patch code itself, as well. My concern with making the tool e-mail centric is that, based on e-mail based tools I've worked with, I'm afraid that the tool will be clunky/buggy enough not to be an improvement over the current process -- too much of e-mail format is optional varies by MUA. If e-mail is limited to commentary, though, I don't see that as a problem. And, of course, it would be easy for the tool to send e-mail to pgsql-patches. I believe that's what Dave is proposing. If we want to implement something like reviewer signoff (which we'd at least eventually want to do, IMHO), doing that through the web interface primarily (for a nice tally table) is probably a good start - it's a lot easier than parsing emails. //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Fwd: [PATCHES] Preliminary GSSAPI Patches
Stefan Kaltenbrunner [EMAIL PROTECTED] writes: Josh Berkus wrote: For now, yes. In the long run, we want to provide users with other methods of encrypted connections than the rather flaky and not-available-on-every-platform OpenSSL. I'm curious - on what platform is OpenSSL NOT available ? And even more curious to see you defend that offhanded bashing of OpenSSL, a tool a whole lot of people (including me) depend on all day every day. If Postgres had the market penetration of OpenSSL, our lives would be a lot different. Have you got even a shred of evidence that GSSAPI is more stable than OpenSSL? regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Feature freeze progress report
Andrew, So if the commercial backers of PostgreSQL want better management of the project, maybe they need to find some resources to help out. I don't think they really care, or we'd have heard something by now. I think this is up to us PG developers. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Fwd: [PATCHES] Preliminary GSSAPI Patches
Magnus Hagander [EMAIL PROTECTED] writes: I would call them gss and gss-sec. Or possibly gss-enc. I think that's a lot more clear than gss-np (something ending with -sec is a giveaway) +1 regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] MSVC
Magnus Hagander wrote: Andrew Dunstan wrote: Now that we seem to have MSVC building working tolerably well, I think we need a bit of cleanup. In particular, I think the config setup needs to be more like the arguments we pass to the standard configure script. Why? I'm not saying I'm against it, I'd just like to know why? Personally, I find the store-in-a-file a whole lot more handy. I am only talking about the names. I want the hash key names to be the same as the configure argument names. Since this is a perl hash, we'll need to have some sort of mapping convention. I suggest this: . where the configure arg doesn't take a value, make the hash value undef (e.g. '--enable-integer-datetimes' = undef ) Is there a way to differ that from just not being defined? otherwise, why not just make it 1 instead of undef? I guess we can just handle 1/0, and if we detect one of those act appropriately - I don't think we have any cases where those would be expected values of configure arguments. . where the configure arg would occur with a single value, just set that (e.g. '--prefix' = 'c:\\foo' ) . where the configure arg would occur with a multiple value, provide a listref (e.g. '--with-libs' = [ 'c:\\bar', 'd:\\baz' ] ) These I get. ;-) OK. I think we have a plan. Let's work on it. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] MSVC
Andrew Dunstan wrote: Why? I'm not saying I'm against it, I'd just like to know why? Personally, I find the store-in-a-file a whole lot more handy. I am only talking about the names. I want the hash key names to be the same as the configure argument names. Oh, misunderstood you there. Then I have no objection :-) Since this is a perl hash, we'll need to have some sort of mapping convention. I suggest this: . where the configure arg doesn't take a value, make the hash value undef (e.g. '--enable-integer-datetimes' = undef ) Is there a way to differ that from just not being defined? otherwise, why not just make it 1 instead of undef? I guess we can just handle 1/0, and if we detect one of those act appropriately - I don't think we have any cases where those would be expected values of configure arguments. I think it would make things clearer. At least for those of us who don't breathe perl :-) //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Feature freeze progress report
Josh Berkus wrote: Andrew, So if the commercial backers of PostgreSQL want better management of the project, maybe they need to find some resources to help out. I don't think they really care, or we'd have heard something by now. I think this is up to us PG developers. Well, I have no confidence that any formal system will succeed without someone trusted by core and committers stepping up to the plate to do the required ongoing legwork. As for voting on patches, that seems a most un-postgres-like way of doing things. What is more, it assumes that multiple people will be reviewing patches. Our trouble right now is finding even one qualified reviewer with enough time for some patches. cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Feature freeze progress report
--- Original Message --- From: Andrew Dunstan [EMAIL PROTECTED] To: Josh Berkus [EMAIL PROTECTED] Sent: 01/05/07, 21:10:07 Subject: Re: [HACKERS] Feature freeze progress report So if the commercial backers of PostgreSQL want better management of the project, maybe they need to find some resources to help out. I'm not proposing this as an EDB employee, but as a community member who has heard the same concerns from various PostgreSQL developers both in and out of EDB. And yes, I am expecting to put some resource into making this work. Regards, Dave ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] temporal variants of generate_series()
Jim Nasby [EMAIL PROTECTED] writes: Are you sure the case statements are needed? It seems it would be better to just punt to the behavior of generate_series (esp. if generate_series eventually learns how to count backwards). What's this eventually? regression=# select * from generate_series(10,1,-1); generate_series - 10 9 8 7 6 5 4 3 2 1 (10 rows) regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] NO INHERIT
I notice that we have two versions of not INHERITing: ALTER ROLE meek NOINHERIT earth; ALTER TABLE meek NO INHERIT earth; Is there some merit in deciding on just one of these syntaxes? It seems like we will have to support both the above, but we should encourage just one common way, just for sanity? (Yes, I understand the word means totally different thing in each case). -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Fwd: [PATCHES] Preliminary GSSAPI Patches
Tom, And even more curious to see you defend that offhanded bashing of OpenSSL, a tool a whole lot of people (including me) depend on all day every day. If Postgres had the market penetration of OpenSSL, our lives would be a lot different. Have you got even a shred of evidence that GSSAPI is more stable than OpenSSL? Short answer: Existing Kerberos libs with GSSAPI may have the same issues; I don't know. What I was speaking in favor of was having several encryption mechanisms available so that at least one of them would be available on the user's system at installation time. For that matter, I think we should support Gnu-TLS if someone offers us a patch. Long Answer: I've been dealing with OpenSSL binary incompatibility issues for the last few Solaris builds and it's made me very unhappy with the upgrade/versioning/linking of OpenSSL, and explained a lot of issues I've had around using OpenSSL with PostgreSQL and Apache previously. That is, 0.9.8 isn't always backwards compatible to 0.9.7 or 0.9.6, making applications built against one version of OpenSSL not necessarily portable or easily upgraded, and causing a lot of installation-related pain. (yes, I know this describes PostgreSQL as well. People complain about it all the time to us, and they're right) When you combine that with the platform providers (like Novell, Sun and RH) treating OpenSSL as if there were no upgrade issues (even though there are), or being version-specific but not providing packages for other versions, you end up with a situation where a lot of users can't actually use OpenSSL on their system without ripping out a bunch of libraries and replacing them with compatible versions. I've had this issue on SuSE, Solaris, and OSX at different times. The OpenSSL team appears to be is very aware of these issues, which is why Richard Levitte started the OpenTLS project (www.opentls.org) as a successor to OpenSSL, where the issues are apparently insoluable 9http://marc.info/?l=openssl-devm=113042556401979w=2). OpenSSL has also added a stronger EVP_API and some versioning of symbols in the most recent release, but that won't help most of our users for a while until 0.9.6 and 0.9.7 dissapear from userspace. Also, last I checked OpenSSL didn't ship with Windows and Kerberos encryption did. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Fwd: [PATCHES] Preliminary GSSAPI Patches
On May 1, 2007, at 1:33 PM, Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: I would call them gss and gss-sec. Or possibly gss-enc. I think that's a lot more clear than gss-np (something ending with -sec is a giveaway) +1 If we settle on gss-np and gss-sec is that a good compromise? The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Fwd: [PATCHES] Preliminary GSSAPI Patches
Josh Berkus wrote: Tom, And even more curious to see you defend that offhanded bashing of OpenSSL, a tool a whole lot of people (including me) depend on all day every day. If Postgres had the market penetration of OpenSSL, our lives would be a lot different. Have you got even a shred of evidence that GSSAPI is more stable than OpenSSL? Short answer: Existing Kerberos libs with GSSAPI may have the same issues; I don't know. What I was speaking in favor of was having several encryption mechanisms available so that at least one of them would be available on the user's system at installation time. For that matter, I think we should support Gnu-TLS if someone offers us a patch. IIRC we had a gnutls patch offered, but rejected. Also, last I checked OpenSSL didn't ship with Windows and Kerberos encryption did. How long ago did you check? I've been using OpenSSL on windows for many years. Actually, it was supported just fine on Windows back when it was added to PostgreSQL *at least*. //Magnus ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] NO INHERIT
Simon Riggs [EMAIL PROTECTED] writes: I notice that we have two versions of not INHERITing: ALTER ROLE meek NOINHERIT earth; ALTER TABLE meek NO INHERIT earth; Where are you reading that? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Fwd: [PATCHES] Preliminary GSSAPI Patches
Henry B. Hotz wrote: On May 1, 2007, at 1:33 PM, Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: I would call them gss and gss-sec. Or possibly gss-enc. I think that's a lot more clear than gss-np (something ending with -sec is a giveaway) +1 If we settle on gss-np and gss-sec is that a good compromise? I still think the -np part is unclear - it's not easily guessable without reading the documentation, unless you're already familiar with it. //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Fwd: [PATCHES] Preliminary GSSAPI Patches
On May 1, 2007, at 2:30 PM, Magnus Hagander wrote: Henry B. Hotz wrote: On May 1, 2007, at 1:33 PM, Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: I would call them gss and gss-sec. Or possibly gss-enc. I think that's a lot more clear than gss-np (something ending with - sec is a giveaway) +1 If we settle on gss-np and gss-sec is that a good compromise? I still think the -np part is unclear - it's not easily guessable without reading the documentation, unless you're already familiar with it. //Magnus gss-noprot and gss-prot gss-noenc and gss-enc ?? The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Fwd: [PATCHES] Preliminary GSSAPI Patches
Henry B. Hotz wrote: I would call them gss and gss-sec. Or possibly gss-enc. I think that's a lot more clear than gss-np (something ending with -sec is a giveaway) +1 If we settle on gss-np and gss-sec is that a good compromise? I still think the -np part is unclear - it's not easily guessable without reading the documentation, unless you're already familiar with it. //Magnus gss-noprot and gss-prot gss-noenc and gss-enc Those I like better. I still think it's unnecessary, but I won't object to those :-) //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Fwd: [PATCHES] Preliminary GSSAPI Patches
On May 1, 2007, at 1:32 PM, Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: Josh Berkus wrote: For now, yes. In the long run, we want to provide users with other methods of encrypted connections than the rather flaky and not-available-on-every-platform OpenSSL. I'm curious - on what platform is OpenSSL NOT available ? And even more curious to see you defend that offhanded bashing of OpenSSL, a tool a whole lot of people (including me) depend on all day every day. If Postgres had the market penetration of OpenSSL, our lives would be a lot different. Have you got even a shred of evidence that GSSAPI is more stable than OpenSSL? regards, tom lane Windows? I don't do Windows, so I'm guessing. If you accept that Microsoft's SSPI is a flavor of GSSAPI, then GSSAPI is more widely supported and probably more stable on Windows machines than OpenSSL is. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(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] Fwd: [PATCHES] Preliminary GSSAPI Patches
Josh Berkus [EMAIL PROTECTED] writes: Long Answer: I've been dealing with OpenSSL binary incompatibility issues for the last few Solaris builds and it's made me very unhappy with the upgrade/versioning/linking of OpenSSL, and explained a lot of issues I've had around using OpenSSL with PostgreSQL and Apache previously. That is, 0.9.8 isn't always backwards compatible to 0.9.7 or 0.9.6, making applications built against one version of OpenSSL not necessarily portable or easily upgraded, and causing a lot of installation-related pain. (yes, I know this describes PostgreSQL as well. People complain about it all the time to us, and they're right) Indeed, but I dunno why you think things will be all magically better in GSSAPI-land. What I foresee as more likely is that we'll just be opening up another front in the versioning war. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Fwd: [PATCHES] Preliminary GSSAPI Patches
Short answer: Existing Kerberos libs with GSSAPI may have the same issues; I don't know. What I was speaking in favor of was having several encryption mechanisms available so that at least one of them would be available on the user's system at installation time. For that matter, I think we should support Gnu-TLS if someone offers us a patch. IIRC we had a gnutls patch offered, but rejected. That is correct. THere is a very long thread on it here: http://archives.postgresql.org/pgsql-hackers/2006-12/msg01213.php http://archives.postgresql.org/pgsql-patches/2006-05/msg00040.php Also, last I checked OpenSSL didn't ship with Windows and Kerberos encryption did. How long ago did you check? I've been using OpenSSL on windows for many years. Actually, it was supported just fine on Windows back when it was added to PostgreSQL *at least*. //Magnus ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate -- === 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 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] NO INHERIT
Simon Riggs [EMAIL PROTECTED] writes: (Yes, I understand the word means totally different thing in each case). Geez, you had me worried. So it's just the spelling that you're noting? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Fwd: [PATCHES] Preliminary GSSAPI Patches
Henry B. Hotz [EMAIL PROTECTED] writes: Windows? I don't do Windows, so I'm guessing. If you accept that Microsoft's SSPI is a flavor of GSSAPI, then GSSAPI is more widely supported and probably more stable on Windows machines than OpenSSL is. I can't speak to the situation on Windows either; if OpenSSL isn't commonly used on Windows that may be a sufficient reason for supporting GSSAPI too. I'm just unconvinced by any argument that suggests we'll replace our SSL support with it. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] NO INHERIT
On Tue, 2007-05-01 at 17:30 -0400, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: I notice that we have two versions of not INHERITing: ALTER ROLE meek NOINHERIT earth; ALTER TABLE meek NO INHERIT earth; Where are you reading that? http://developer.postgresql.org/pgdocs/postgres/sql-alterrole.html http://developer.postgresql.org/pgdocs/postgres/sql-altertable.html ... and gram.y -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Where to find kind code for STATISTIC_KIND GEOMETRY?
Ale Raza wrote: Simon, I am forwarding this to pgsql-hackers. I can send the requirements once I get the right contact. This is it, but as Simon stated, you probably want to get the PostGIS guys involved too, so that duplicates can be sorted out. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(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] Fwd: [PATCHES] Preliminary GSSAPI Patches
Tom, Josh, Magnus. I can't speak to the situation on Windows either; if OpenSSL isn't commonly used on Windows that may be a sufficient reason for supporting GSSAPI too. I'm just unconvinced by any argument that suggests we'll replace our SSL support with it. I can't imagine we will either. I think we should offer users choices, within reason. IIRC we had a gnutls patch offered, but rejected. Darn, this happened while I was offline. I would have supported it. I still think it's a good idea, pending patch quality. Also, last I checked OpenSSL didn't ship with Windows and Kerberos encryption did. How long ago did you check? I've been using OpenSSL on windows for many years. Actually, it was supported just fine on Windows back when it was added to PostgreSQL *at least*. I didn't say *available for download*, I said *ship with*. That is, does a Windows Vista Pro box from the factory come with OpenSSL on it? It does come with Microsoft SSPI, although I don't know compatibility issues. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] temporal variants of generate_series()
On Tue, May 01, 2007 at 05:08:45PM -0400, Tom Lane wrote:
Jim Nasby [EMAIL PROTECTED] writes:
Are you sure the case statements are needed? It seems it would be
better to just punt to the behavior of generate_series (esp. if
generate_series eventually learns how to count backwards).
What's this eventually?
regression=# select * from generate_series(10,1,-1);
generate_series
-
10
9
8
7
6
5
4
3
2
1
(10 rows)
regards, tom lane
Good point. I believe the function below does the right thing. When
given decreasing TIMESTAMPTZs and a negative interval, it will
generate them going backward in time. When given increasing
TIMESTAMPTZs and a positive interval, it will generate them going
forward in time. Given a 0 interval, it errors out, although not with
the same message as generate_series(1,1,0), and decreasing
TIMESTAMPTZs and a positive interval or vice versa, it generates no
rows.
CREATE OR REPLACE FUNCTION generate_series (
start_ts timestamptz,
end_ts timestamptz,
step interval
) RETURNS SETOF timestamptz
STRICT
LANGUAGE sql
AS $$
SELECT
$1 + s.i * $3 AS generate_series
FROM generate_series(
CASE WHEN $1 = $2
THEN 0
ELSE
floor(
(
extract('epoch' FROM $2) - extract('epoch' FROM $1)
)/extract('epoch' FROM $3)
)::int8
END,
CASE WHEN $1 = $2
THEN ceil(
(
extract('epoch' FROM $2) - extract('epoch' FROM $1)
)/extract('epoch' FROM $3)
)::int8
ELSE
0
END,
sign(
extract('epoch' FROM $2) - extract('epoch' FROM $1)
)::int8
) AS s(i)
ORDER BY s.i ASC
;
$$;
--
David Fetter [EMAIL PROTECTED] http://fetter.org/
phone: +1 415 235 3778AIM: dfetter666
Skype: davidfetter
Remember to vote!
Consider donating to PostgreSQL: http://www.postgresql.org/about/donate
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [HACKERS] Fwd: [PATCHES] Preliminary GSSAPI Patches
Also, last I checked OpenSSL didn't ship with Windows and Kerberos encryption did. How long ago did you check? I've been using OpenSSL on windows for many years. Actually, it was supported just fine on Windows back when it was added to PostgreSQL *at least*. I didn't say *available for download*, I said *ship with*. That is, does a Windows Vista Pro box from the factory come with OpenSSL on it? It does come with Microsoft SSPI, although I don't know compatibility issues. No, of course not. Microsoft OSes don't ship with *any* third party software. So yeah, didn't get what you meant, and you do have a point there. Provided the SSPI stuff actually does gssapi encryption - but I'll trust the people who say it does. I've only ever used the authentication parts myself. //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] NO INHERIT
On Tue, 2007-05-01 at 22:36 +0100, Gregory Stark wrote: Simon Riggs [EMAIL PROTECTED] writes: (Yes, I understand the word means totally different thing in each case). Geez, you had me worried. So it's just the spelling that you're noting? Yes, the space appears to be mis spelled. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] NO INHERIT
Simon Riggs [EMAIL PROTECTED] writes: On Tue, 2007-05-01 at 17:30 -0400, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: I notice that we have two versions of not INHERITing: ALTER ROLE meek NOINHERIT earth; ALTER TABLE meek NO INHERIT earth; Where are you reading that? http://developer.postgresql.org/pgdocs/postgres/sql-alterrole.html http://developer.postgresql.org/pgdocs/postgres/sql-altertable.html Oh, you're complaining about the lack of parallelism between ALTER ROLE and ALTER TABLE. They're not really that parallel anyway: regression=# ALTER ROLE meek NOINHERIT earth; ERROR: syntax error at or near earth LINE 1: ALTER ROLE meek NOINHERIT earth; ^ regression=# It's actually ALTER ROLE meek NOINHERIT, which is spelled that way because user/role related options have always been spelled that way: http://www.postgresql.org/docs/6.4/static/sql-createuser.htm Maybe we'd do it differently if we were starting over, but I don't see a point in changing it now. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Feature freeze progress report
Andrew Dunstan wrote: Josh Berkus wrote: Andrew, So if the commercial backers of PostgreSQL want better management of the project, maybe they need to find some resources to help out. I don't think they really care, or we'd have heard something by now. I think this is up to us PG developers. Well, I have no confidence that any formal system will succeed without someone trusted by core and committers stepping up to the plate to do the required ongoing legwork. As for voting on patches, that seems a most un-postgres-like way of doing things. What is more, it assumes that multiple people will be reviewing patches. Our trouble right now is finding even one qualified reviewer with enough time for some patches. The typical use-case is that someone is going to like the patch, but what X changed in it, so a simple vote isn't going to work, and neither is automatic patch application. Rarely is a patch applied unmodified by the applier. -- 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] Fwd: [PATCHES] Preliminary GSSAPI Patches
On May 1, 2007, at 3:11 PM, Magnus Hagander wrote: Also, last I checked OpenSSL didn't ship with Windows and Kerberos encryption did. How long ago did you check? I've been using OpenSSL on windows for many years. Actually, it was supported just fine on Windows back when it was added to PostgreSQL *at least*. I didn't say *available for download*, I said *ship with*. That is, does a Windows Vista Pro box from the factory come with OpenSSL on it? It does come with Microsoft SSPI, although I don't know compatibility issues. No, of course not. Microsoft OSes don't ship with *any* third party software. So yeah, didn't get what you meant, and you do have a point there. Provided the SSPI stuff actually does gssapi encryption - but I'll trust the people who say it does. I've only ever used the authentication parts myself. The SSPI has encryption and integrity functions, just like the GSSAPI. I don't remember Jeffrey Altman's interop example code well enough to say if he demonstrates that they interoperate as well. Spending 5 seconds looking at it, the SSPI appears to make a distinction between message and stream encryption that the GSSAPI does not make, so there is at least some profiling needed to identify what's common. I suspect that interoperability was intended. If we find bugs and tell the right people Microsoft might even fix them someday. As to the question of GSSAPI vs SSL, I would never argue we don't want both. Part of what made the GSSAPI encryption mods difficult was my intent to insert them above the SSL encryption/buffering layer. That way you could double-encrypt the channel. Since GSSAPI and SSL are (probably, not necessarily) referenced to completely different ID infrastructure there are scenarios where that's beneficial. (The other thing that made it hard is that I needed to make changes in different places in the FE and the BE versions of libpq in order to get the same effect.) The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Where to find kind code for STATISTIC_KIND GEOMETRY?
For all that Tom reserved 100 numbers for us, we're only using one right now. lwgeom_estimate.c:47:#define STATISTIC_KIND_GEOMETRY 100 Paul Alvaro Herrera wrote: Ale Raza wrote: Simon, I am forwarding this to pgsql-hackers. I can send the requirements once I get the right contact. This is it, but as Simon stated, you probably want to get the PostGIS guys involved too, so that duplicates can be sorted out. -- Paul Ramsey Refractions Research http://www.refractions.net [EMAIL PROTECTED] Phone: 250-383-3022 Cell: 250-885-0632 ---(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] Feature freeze progress report
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Jim Nasby) wrote: Two more ideas for the manager, now that we seem to have consensus to build one. One other thing a webapp would allow that would help grow the community. If the patches are all in a public place then reviewer wannabees can get their feet wet relatively easily. Some may argue this is already possible but I, personally, don't even know where to look for patches. -arturo ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] autovacuum does not start in HEAD
ITAGAKI Takahiro wrote:
I wrote:
I found that autovacuum launcher does not launch any workers in HEAD.
The attached autovacuum-fix.patch could fix the problem. I changed
to use 'greater or equal' instead of 'greater' at the decision of
next autovacuum target.
I developed a different fix, which is possible due to the addition of
TimestampDifferenceExceeds to the TimestampTz API. (Thanks Tom).
It continues to work for me here, but please confirm that it fixes the
bug you reported -- I don't have a low-resolution platform handy.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Index: src/backend/postmaster/autovacuum.c
===
RCS file: /home/alvherre/Code/cvs/pgsql/src/backend/postmaster/autovacuum.c,v
retrieving revision 1.42
diff -c -p -r1.42 autovacuum.c
*** src/backend/postmaster/autovacuum.c 18 Apr 2007 16:44:18 - 1.42
--- src/backend/postmaster/autovacuum.c 2 May 2007 01:53:02 -
*** AutoVacLauncherMain(int argc, char *argv
*** 549,556
if (can_launch AutoVacuumShmem-av_startingWorker != INVALID_OFFSET)
{
- long secs;
- int usecs;
WorkerInfo worker = (WorkerInfo) MAKE_PTR(AutoVacuumShmem-av_startingWorker);
if (current_time == 0)
--- 549,554
*** AutoVacLauncherMain(int argc, char *argv
*** 566,576
* startingWorker pointer before trying to connect; only low-level
* problems, like fork() failure, can get us here.
*/
! TimestampDifference(worker-wi_launchtime, current_time,
! secs, usecs);
!
! /* ignore microseconds, as they cannot make any difference */
! if (secs autovacuum_naptime)
{
LWLockRelease(AutovacuumLock);
LWLockAcquire(AutovacuumLock, LW_EXCLUSIVE);
--- 564,571
* startingWorker pointer before trying to connect; only low-level
* problems, like fork() failure, can get us here.
*/
! if (TimestampDifferenceExceeds(worker-wi_launchtime, current_time,
! autovacuum_naptime * 1000))
{
LWLockRelease(AutovacuumLock);
LWLockAcquire(AutovacuumLock, LW_EXCLUSIVE);
*** AutoVacLauncherMain(int argc, char *argv
*** 618,630
if (elem != NULL)
{
avl_dbase *avdb = DLE_VAL(elem);
- long secs;
- int usecs;
-
- TimestampDifference(current_time, avdb-adl_next_worker, secs, usecs);
! /* do we have to start a worker? */
! if (secs = 0 usecs = 0)
launch_worker(current_time);
}
else
--- 613,625
if (elem != NULL)
{
avl_dbase *avdb = DLE_VAL(elem);
! /*
! * launch a worker if next_worker is right now or it is in the
! * past
! */
! if (TimestampDifferenceExceeds(avdb-adl_next_worker,
! current_time, 0))
launch_worker(current_time);
}
else
*** do_start_worker(void)
*** 1037,1058
if (dbp-adl_datid == tmp-adw_datid)
{
- TimestampTz curr_plus_naptime;
- TimestampTz next = dbp-adl_next_worker;
-
- curr_plus_naptime =
- TimestampTzPlusMilliseconds(current_time,
- autovacuum_naptime * 1000);
-
/*
! * What we want here if to skip if next_worker falls between
* the current time and the current time plus naptime.
*/
! if (timestamp_cmp_internal(current_time, next) 0)
! skipit = false;
! else if (timestamp_cmp_internal(next, curr_plus_naptime) 0)
! skipit = false;
! else
skipit = true;
break;
--- 1032,1046
if (dbp-adl_datid == tmp-adw_datid)
{
/*
! * Skip this database if its next_worker value falls between
* the current time and the current time plus naptime.
*/
! if (TimestampDifferenceExceeds(current_time,
! dbp-adl_next_worker, 0)
! !TimestampDifferenceExceeds(current_time,
! dbp-adl_next_worker,
! autovacuum_naptime * 1000))
skipit = true;
break;
---(end of broadcast)---
TIP 6: explain analyze is your friend
[HACKERS] Patch queue triage
Bruce Momjian [EMAIL PROTECTED] writes: FYI, Tom, Heikki, I need one of you to post the list of patches and where we think we are on each one, even if the list is imperfect. This message is an attempt to sort out which patch queue entries have no hope of getting into 8.3 (and so we shouldn't spend more time on them right now), which ones can get in but are waiting on their authors for more work, and which ones are ready for immediate review. You'll notice that numerically quite a lot of the patches fall into the dead category. This isn't actually all that surprising because if they were apply-able they'd have gotten in. (It's not like we've completely neglected applying patches for the last six months...) However, many of the remaining live patches are huge ones, like HOT and delayed commit, and are going to consume considerable review effort (again, if they didn't, they might have been in already). The bottom line is that we are desperately in need of more review manpower. I'm pleased to report that Heikki Linnakangas has promised to devote most of the next few weeks to helping review, and has already picked out some patches he feels qualified to work on, as you'll see below. I have also been coordinating reviewing assignments off-list with Neil and Magnus to avoid duplication of effort. But I'd like to encourage everyone who's done any backend hacking to look at the live patches not shown as assigned to someone specific. The more eyeballs the better; anything you catch is something someone else might miss. Also, several of the open patches are in need of more performance testing, so if you can help out in that fashion please do so. With that, the patches: * Re: [pgsql-patches] [PATCHES] [HACKERS] [Fwd: Index Advisor] /Gurjeet Singh/ I don't think this can be applied in anything like its current state. The internal interface to the planner is not very good, and ditto for the user API. What I would suggest trying to do is get a set of plugin hooks defined for the planner that would allow the advisor to be implemented entirely as an external module, and then let it be worked on as a pgfoundry project. I have some ideas about appropriate design of the plugin hooks (as mentioned in my review message of a month ago), but I have to say that getting that done for 8.3 is lower-priority than some of the other patches. * [pgsql-patches] Ctid chain following enhancement /Pavan Deolasee/ I'm not very excited about this --- it seems to me to complicate the code in some places that are not in fact performance-critical. While it doesn't seem likely to break things, I'm not in favor of reducing code readability unless a measurable performance improvement can be shown. Can we have some tests showing this is worthwhile? * [PATCHES] Error correction for n_dead_tuples /ITAGAKI Takahiro/ Waiting for OldestXmin patch to be accepted or rejected. However, regardless of the fate of that patch, I'm concerned that this one creates an open-loop behavior in which the n_dead_tuples estimate will diverge arbitrarily far from reality over time. I criticized the original proposal on that basis, and I'm not convinced this version fixes it, because of the fact that stats counter updates occur much later than the actions they count. (My recent patch to rate-limit tabstat messages made that problem worse, but it existed anyway.) What might make sense is for vacuum to count the number of dead-but-not-removable tuples it skips over, and apply that as the value of n_dead_tuples on receipt of the vacuum message (instead of setting to zero as now). This is likely to be wrong with respect to the actions of transactions running concurrently with the vacuum, but I think so is the proposed patch; and at least in this form the error certainly cannot accumulate across vacuum cycles. * [PATCHES] Table function support /Pavel Stehule/ Neil has promised to review this. AFAIK there are no showstoppers but there are some disagreements on the details of the functionality. * [HACKERS] Grouped Index Tuples /Heikki Linnakangas/ * [HACKERS] Grouped Index Tuples / Clustered Indexes /Heikki Linnakangas/ Needs review. I'm not sure how many people besides Heikki have really looked at this (I know I haven't). * Re: [PATCHES] POSIX shared memory support /Chris Marcellino/ I'm not convinced that we want this at all. The original proposal was to provide an alternative for platforms without SysV shmem support, but the working versions of the patch fail to remove the SysV dependency, and the portability of this code is itself quite unproven. Do we really want to take on maintenance of yet-another shmem implementation just to let people be lazy about changing their SHMMAX settings? As best I can tell the main problem in that department is Darwin, and it'd be a whole lot simpler if Apple just raised their darn default SHMMAX to something that's sensible for the 21st century. [BTW, there was a
Re: [HACKERS] strange buildfarm failures
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Oh, another thing that I think may be happening is that the stack is restored in longjmp, so it is trying to report an error elsewhere but it crashes because something got overwritten or something; i.e. a bug in the error recovery code. Hm, something trying to elog before the setjmp's been executed? Although I thought it was coded so that elog.c would just proc_exit if there was noplace to longjmp to. A mistake here might explain the lack of any message in the postmaster log: if elog.c thinks it should longjmp then it doesn't print the message first. Well, there seems to be plenty of code which is happy to elog(ERROR) before the longjmp target block has been set; for example InitFileAccess(), which is called on BaseInit(), which comes before sigsetjmp() both on postgres.c and autovacuum.c. (This particular case is elog(FATAL) not ERROR however). mdinit() also does some memory allocation which could certainly fail. I'm wondering if it wouldn't be more robust to define a longjmp target block before calling BaseInit(), and have it exit cleanly in case of failure (which is what you say elog.c should be doing if there is no target block). In errstart(), it is checked if PG_exception_stack is NULL. Now, this symbol is defined in elog.c and initialized to NULL, but I wonder if a child process inherits the value that postmaster set, or it comes back to NULL. The backend would not inherit any of the values the postmaster set if the latter were the case, so I'm assuming that PG_exception_stack stays as the postmaster left it. I wonder what happens if the child process finds that this is an invalid point to jump to? -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(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] Patch queue triage
On Tue, 1 May 2007, Tom Lane wrote: * Re: [PATCHES] Synchronized Scan WIP patch /Simon Riggs/ Heikki is reviewing this one. Also I believe Greg Smith is doing more performance testing. Actually it was the Automatic adjustment of bgwriter_lru_maxpages patch from Itagaki Takahiro I've been working on--which, by the way, Bruce sent out a note about the other day saying was already booted into 8.4. I've integrated a part of the LRU patch usefully into the new pg_stat_bgwriter, renamed some variables around accordingly, cleanup I felt had to preceed performance testing. Heikki might want to wait for me to finish that before putting time into it. The buffer allocation monitoring part would be useful to apply even if the GUC and behavior changes are deemed outside of the 8.3 scope. Also, I think I was the most vocal participant in the COPY-able sql log outputs feature discussion and therefore was planning to do what review what I can of the final patch API immediately afterwards. I try not to complain about things unless I'm willing to help fix them. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] strange buildfarm failures
Alvaro Herrera [EMAIL PROTECTED] writes: I'm wondering if it wouldn't be more robust to define a longjmp target block before calling BaseInit(), and have it exit cleanly in case of failure (which is what you say elog.c should be doing if there is no target block). No, because elog is already supposed to deal with that case; and does, every time you connect to a bad database name for example. If it's failing, the question to answer is why. In errstart(), it is checked if PG_exception_stack is NULL. Now, this symbol is defined in elog.c and initialized to NULL, but I wonder if a child process inherits the value that postmaster set, or it comes back to NULL. Hmm ... I was about to say that the postmaster never sets PG_exception_stack, but maybe an error out of a PG_TRY/PG_RE_THROW could do it? Does the postmaster ever execute PG_TRY? (And if so, should it? The postmaster really ought not be dealing in anything very hairy --- it should be passing such work off to children.) regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Patch queue triage
Greg Smith [EMAIL PROTECTED] writes: On Tue, 1 May 2007, Tom Lane wrote: * Re: [PATCHES] Synchronized Scan WIP patch /Simon Riggs/ Heikki is reviewing this one. Also I believe Greg Smith is doing more performance testing. Actually it was the Automatic adjustment of bgwriter_lru_maxpages patch from Itagaki Takahiro I've been working on--which, by the way, Bruce sent out a note about the other day saying was already booted into 8.4. It's still on the patch queue list, and Heikki and I were assuming it was still live. I've integrated a part of the LRU patch usefully into the new pg_stat_bgwriter, renamed some variables around accordingly, cleanup I felt had to preceed performance testing. Heikki might want to wait for me to finish that before putting time into it. The buffer allocation monitoring part would be useful to apply even if the GUC and behavior changes are deemed outside of the 8.3 scope. Also, I think I was the most vocal participant in the COPY-able sql log outputs feature discussion and therefore was planning to do what review what I can of the final patch API immediately afterwards. I try not to complain about things unless I'm willing to help fix them. Great, you're on the hook for both of those ;-) regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] strange buildfarm failures
I wrote: Hmm ... I was about to say that the postmaster never sets PG_exception_stack, but maybe an error out of a PG_TRY/PG_RE_THROW could do it? Does the postmaster ever execute PG_TRY? Doh, I bet that's it, and it's not the postmaster that's at issue but PG_TRY blocks executed during subprocess startup. Inheritance of a PG_exception_stack setting from the postmaster could only happen if the postmaster were to fork() within a PG_TRY block, which I think we can safely say it doesn't. But suppose we get an elog(ERROR) inside a PG_TRY block when there is no outermost longjmp catcher. elog.c will think it should longjmp, and that will eventually lead to executing #define PG_RE_THROW() \ siglongjmp(*PG_exception_stack, 1) with PG_exception_stack = NULL; which seems entirely likely to cause a stack smash of gruesome dimensions. What's more, nothing would have been printed to the postmaster log beforehand, agreeing with observation. Personally I think the correct fix is to make PG_RE_THROW deal sanely with the case of PG_exception_stack = NULL, that is, turn it into an elog(FATAL) with the original error text. If you try to fix it by making a setjmp occur earlier, there's still the problem of what about PG_TRY earlier than that? This might be more code than we want in a macro, though, especially since this is presumably not a performance-critical path. I'm tempted to change the macro to just call a pg_re_throw() subroutine. Thoughts? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Feature freeze progress report
Andrew Dunstan wrote: Naz Gassiep wrote: I believe the suggestion was to have an automated process that only ran on known, sane patches. How do we know in advance of reviewing them that they are sane? Same way as happens now. I would assume this mechanism would only be applied to patches that had already been approved to contrib, or some other measure that can be used to isolate only those patches that we *expect* to already be working. The intention of this mechanism, in my head, is to just help us make sure that regression issues on patches get detected sooner. What is more, we often run into situations where patch a will require changes in patch b, so testing them individually against CVS is not likely to be terribly useful. Yeap, given that this proposition is for an automated system, perhaps it could be designed to apply combinations of patches together to look for conflicts. Frankly, our problems are not primarily technological. They have to do mainly with scarcity of available time from competent reviewers. No amount of automation will fix that. I fully understand that. However I find the idea of an automated process checking for big issues while we're all sleeping to be... sexy. I'm not sure how difficult a system like this would be to set up but it doesn't seem to me to be the sort of thing that requires more than a few simple scripts. If it's not too had to set up, even if it only yields small and rare benefits, it will have been a worthwhile exercise. My 2c (adjusted for inflation). Regards, - Naz ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Feature freeze progress report
Bruce, As an example, how is patch information going to help us review HOT or group-item-index? There is frankly more information about these in the archives than someone could reasonable read. What someone needs is a summary of where we are now on the patches, and lots of time. The idea is to provide ways for other people to help where they can and to provide better feedback to patch submitters so that they fix their own issues faster. Also, lesser PostgreSQL hackers than you could take on reviewing the small patches, leaving you to devote all of your attention to the big patches. Actually, that can happen with the current system. The real blocker there is that some people, particularly Tom, work so fast that there's no chance for a new reviewer to tackle the easy stuff. Maybe the real solution is to encourage some of our other contributors to get their feet wet with easy patches so that they can help with the big ones later on? That is, if the problem is people and not tools, then what are we doing to train up the people we need? -- Josh Berkus PostgreSQL @ Sun San Francisco ---(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] Feature freeze progress report
Naz Gassiep [EMAIL PROTECTED] writes: Andrew Dunstan wrote: How do we know in advance of reviewing them that they are sane? Same way as happens now. I would assume this mechanism would only be applied to patches that had already been approved to contrib, or some other measure that can be used to isolate only those patches that we *expect* to already be working. What is approved to contrib? The problem here is that having reasonable certainty that a patch is not malicious requires having gone over it in some detail; at which point you might as well apply the thing. Or if you didn't apply it, you bounced it for reasons that are unlikely to have anything to do with needing more automated testing. ISTM this idea can only work if we have a second tier of reviewers who are considered good enough to vet patches as safe, but not quite good enough to certify them as commitable. I'm not seeing a large pool of people volunteering to hold that position --- at best it'd be a transitory state before attaining committerdom. If you are relying on a constant large influx of new people, you are doomed to failure (see Ponzi scheme for a counterexample). regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Feature freeze progress report
Josh Berkus [EMAIL PROTECTED] writes: Actually, that can happen with the current system. The real blocker there is that some people, particularly Tom, work so fast that there's no chance for a new reviewer to tackle the easy stuff. Maybe the real solution is to encourage some of our other contributors to get their feet wet with easy patches so that they can help with the big ones later on? Yeah, I hear what you say. This is particularly a problem for small bug fixes: I tend to zing small bugs quickly, first because I enjoy finding/ fixing them and second because I worry that they'll fall off the radar screen if not fixed. But I am well aware that fixing those sorts of issues is a great way to learn your way around the code (I think that's largely how I learned whatever I know about Postgres). I'd be more willing to stand aside and let someone else do it if I had confidence that issues wouldn't get forgotten. So in a roundabout way we come back to the idea that we need a bug tracker (NOT a patch tracker), plus people putting in the effort to make sure it stays a valid source of up-to-date info. Without the latter it won't really be useful. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Feature freeze progress report
What is approved to contrib? The problem here is that having reasonable certainty that a patch is not malicious requires having gone over it in some detail; at which point you might as well apply the thing. Or if you didn't apply it, you bounced it for reasons that are unlikely to have anything to do with needing more automated testing. ISTM this idea can only work if we have a second tier of reviewers who are considered good enough to vet patches as safe, but not quite good enough to certify them as commitable. I'm not seeing a large pool of people volunteering to hold that position --- at best it'd be a transitory state before attaining committerdom. If you are relying on a constant large influx of new people, you are doomed to failure (see Ponzi scheme for a counterexample). Yep. For the record, Ponzi died in poverty, so it's not a counter example, just proves that any gains that are had will be short lived and increase the size of the crash when crunch time comes. :) - Naz. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Patch queue triage
On 5/2/07, Tom Lane [EMAIL PROTECTED] wrote: * [pgsql-patches] Ctid chain following enhancement /Pavan Deolasee/ I'm not very excited about this --- it seems to me to complicate the code in some places that are not in fact performance-critical. While it doesn't seem likely to break things, I'm not in favor of reducing code readability unless a measurable performance improvement can be shown. Can we have some tests showing this is worthwhile? I am OK with dropping this for the time being. It came out of code reading. I would later run some tests to see if it really gives any performance benefit. Thanks, Pavan -- EnterpriseDB http://www.enterprisedb.com
