Re: [HACKERS] Lessons from commit fest
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Does someone want to look at improving the pgindent script itself? > > I notice that you've carefully ignored the suggestion of re-testing > GNU indent. No. Why would I carefully ignore testing GNU indent? Because I am afraid pgindent will improve? Please, folks, start taking over the things I do: FAQs, TODO, pgindent, patch queue, whatever. I am tired of veiled complaints about how I handle things. I do my best. Let someone else handle them and then I can complain too. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Lessons from commit fest
Tom Lane wrote: Bruce Momjian <[EMAIL PROTECTED]> writes: I have no problem using a URL to pull down the typedef list via wget. How is that CVS file going to be updated? I do not follow your thought process. You would rather depend on a URL that has no visible commit history? This does seem odd. Bruce if you want to use wget, point the wget at the cvsweb repo checkout. Joshua D. Drake -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Lessons from commit fest
Bruce Momjian <[EMAIL PROTECTED]> writes: > Does someone want to look at improving the pgindent script itself? I notice that you've carefully ignored the suggestion of re-testing GNU indent. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Lessons from commit fest
Bruce Momjian <[EMAIL PROTECTED]> writes: > I have no problem using a URL to pull down the typedef list via wget. > How is that CVS file going to be updated? I do not follow your thought process. You would rather depend on a URL that has no visible commit history? As I already noted elsewhere in the thread, the last thing we want is a typedef list that changes every five minutes. It *should* have adult supervision, and the effort of checking a vetted update into CVS seems entirely appropriate to me. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Lessons from commit fest
Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > It does take a while to run though ... it's not something we'll want to > > do routinely. > > Well, we're not going to want to change the reference typedef list very > often anyway, because it'd just result in whitespace-thrashing in the > repository. I'm thinking an update once or twice per major release > cycle would be enough. So a basically manual process that combines the > results from various buildfarm members, and then filters them like this, > should be workable. OK, fine, but when I do the full source tree pgindent, I will need a URL to get the list, so let's document its location in the README. Also, this improved typedef list is only making pgindent 0.2% better. Does someone want to look at improving the pgindent script itself? Might be a good time now that we have an updated typedef list for 8.4. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Lessons from commit fest
Alvaro Herrera <[EMAIL PROTECTED]> writes: > It does take a while to run though ... it's not something we'll want to > do routinely. Well, we're not going to want to change the reference typedef list very often anyway, because it'd just result in whitespace-thrashing in the repository. I'm thinking an update once or twice per major release cycle would be enough. So a basically manual process that combines the results from various buildfarm members, and then filters them like this, should be workable. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Lessons from commit fest
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> If we're going to go down this path, why would we not put the > >> "reference" typedef list into CVS? > > > Uh, I assume we don't want an automated system updating the file in CVS. > > Nowhere did I suggest that. What I suggested is that the "considered > good" reference list should be in CVS, not on some random wiki page. > In particular there's something pretty broken about the idea of a file > in CVS telling people to go to a wiki page for important data. I have no problem using a URL to pull down the typedef list via wget. How is that CVS file going to be updated? Is someone manually going to update it in CVS, and how often? -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Lessons from commit fest
Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> If we're going to go down this path, why would we not put the >> "reference" typedef list into CVS? > Uh, I assume we don't want an automated system updating the file in CVS. Nowhere did I suggest that. What I suggested is that the "considered good" reference list should be in CVS, not on some random wiki page. In particular there's something pretty broken about the idea of a file in CVS telling people to go to a wiki page for important data. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Lessons from commit fest
Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > Andrew Dunstan wrote: > >> It looks like we'll need some sort of extra filter. > > > Hmm. Wow. For example I see > > > FINDREPLACE > > FINDREPLACEA > > FINDREPLACEW > > > We use neither ... My guess is that they are used in the system DLLs or > > something like that. > > Presumably we could grep our own sources for each proposed typedef list > entry --- no hits, you don't get in. Just came up with this: > found > not-found while read line ; do echo "looking for $line" rgrep -q --exclude cscope.out --exclude pgtypedefs.bsdos --exclude tags "\<$line\>" . if [ $? == 0 ]; then echo $line >> found else echo $line >> not-found fi done < pgtypedefs.bsdos It's simple enough that there are some false matches, for example for "AV" (which is a symbol we do use, but it also appears in strings etc). But I'd say it's more than enough. It does take a while to run though ... it's not something we'll want to do routinely. Okay, it finished: $ wc -l found not-found 2035 found 592 not-found 2627 total -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Lessons from commit fest
Alvaro Herrera wrote: > Bruce Momjian wrote: > > > I have created a proper typedef file that I would normally use for a > > pgindent run of the entire tree (it has /contrib, 2628 entries). It is > > at: > > > > http://momjian.us/expire/pgtypedefs.bsdos > > Well, there are typedefs in there not used anywhere in our code, for > example ASN1_GENERALIZEDTIME ... Yep. I assume the Win32 list is longer only because the Win32 API is larger. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Lessons from commit fest
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > As soon as you have a stable typedef file we can all use please update > > the pgindent README to point to that URL. Keep the instructions of how > > to create it in our tree so we have it for future reference. > > If we're going to go down this path, why would we not put the > "reference" typedef list into CVS? Uh, I assume we don't want an automated system updating the file in CVS. I can' think of any CVS file that is updated in an automated manner like that. If a buildfarm member can't compile one day does it update with those entries missing, then re-add them the next day? -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Lessons from commit fest
Bruce Momjian wrote: > I have created a proper typedef file that I would normally use for a > pgindent run of the entire tree (it has /contrib, 2628 entries). It is > at: > > http://momjian.us/expire/pgtypedefs.bsdos Well, there are typedefs in there not used anywhere in our code, for example ASN1_GENERALIZEDTIME ... -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Lessons from commit fest
Bruce Momjian <[EMAIL PROTECTED]> writes: > As soon as you have a stable typedef file we can all use please update > the pgindent README to point to that URL. Keep the instructions of how > to create it in our tree so we have it for future reference. If we're going to go down this path, why would we not put the "reference" typedef list into CVS? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Lessons from commit fest
Andrew Dunstan wrote: > > Skimming the output it does have things like "int" and "float" but > > presumably > > we would know if that caused any problem, they wouldn't inflate the numbers > > much. > > > > > >> 2800 does seem a bit high. My buildfarm member dungbeetle just found 2482 > >> on a > >> build that is only missing the optional pam, bonjour and gssapi config > >> options. > >> > > > > The numbers going to vary heavily from OS to OS so it seems to me that these > > are a basically the same order of magnitude. > > > > It looks like Windows will blow all our existing numbers out of the > water. Here's a list generated from Cygwin with 6088 symbols. I'm > working on getting a similar list from MinGW. > > http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=brown_bat&dt=2008-04-18%20230054&stg=typedefs I have created a proper typedef file that I would normally use for a pgindent run of the entire tree (it has /contrib, 2628 entries). It is at: http://momjian.us/expire/pgtypedefs.bsdos Andrew, feel free to replace the typedef script in /tools with yours and we can all test it. I know mine worked on Ubuntu 7.10 and Alvaro got it working too. We can test your once you are ready. As soon as you have a stable typedef file we can all use please update the pgindent README to point to that URL. Keep the instructions of how to create it in our tree so we have it for future reference. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Lessons from commit fest
Alvaro Herrera <[EMAIL PROTECTED]> writes: > Andrew Dunstan wrote: >> It looks like we'll need some sort of extra filter. > Hmm. Wow. For example I see > FINDREPLACE > FINDREPLACEA > FINDREPLACEW > We use neither ... My guess is that they are used in the system DLLs or > something like that. Presumably we could grep our own sources for each proposed typedef list entry --- no hits, you don't get in. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Lessons from commit fest
Andrew Dunstan wrote: > And here are the 7625 from MinGW. > > http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=dawn_bat&dt=2008-04-19%20004514&stg=typedefs > > It looks like we'll need some sort of extra filter. Hmm. Wow. For example I see FINDREPLACE FINDREPLACEA FINDREPLACEW We use neither ... My guess is that they are used in the system DLLs or something like that. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Lessons from commit fest
Andrew Dunstan wrote: Gregory Stark wrote: "Andrew Dunstan" <[EMAIL PROTECTED]> writes: Tom Lane wrote: doxygen's 200-some is clearly an order of magnitude too low, but I wonder whether Bruce's list hasn't got some false hits ... Skimming the output it does have things like "int" and "float" but presumably we would know if that caused any problem, they wouldn't inflate the numbers much. 2800 does seem a bit high. My buildfarm member dungbeetle just found 2482 on a build that is only missing the optional pam, bonjour and gssapi config options. The numbers going to vary heavily from OS to OS so it seems to me that these are a basically the same order of magnitude. It looks like Windows will blow all our existing numbers out of the water. Here's a list generated from Cygwin with 6088 symbols. I'm working on getting a similar list from MinGW. http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=brown_bat&dt=2008-04-18%20230054&stg=typedefs And here are the 7625 from MinGW. http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=dawn_bat&dt=2008-04-19%20004514&stg=typedefs It looks like we'll need some sort of extra filter. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Improving planner variable handling
I wrote: > I've been thinking about how to improve the planner's poor handling of > variables in outer-join situations. > ... > I think the basic solution for this is that upper levels of the plan tree > should refer to the nullable output columns of an outer join using > "alias Vars" that name the join rel, not the underlying base relation, After further thought about this, and about the new "ForceToNull" expression node that I was suggesting, I have a more radical proposal in mind: let's get rid of join alias variables, instead of expanding their use. What I'm now envisioning is that the parser would generate Vars that always refer to base relations, never to join nodes; and if the reference appears above an outer join that can null the variable, plaster a ForceToNull node atop the Var. ForceToNull would carry the relid (rangetable index) of the RTE_JOIN RTE for the outer join, so that it expresses exactly which outer join has done the nulling. Actually, rather than just an index of one join RTE, ForceToNull should carry a bitmapset of relids of multiple outer joins, in case we are looking down through multiple outer joins to the base relation. The advantage of doing it that way instead of stacking several ForceToNull nodes is that the representation doesn't change if we change the order of application of the outer joins. In this approach ForceToNull is carried all the way through the parsing/planning process, rather than being inserted on-the-fly in some late stage of the planner. At the last stage of the planner (setrefs.c) we could mark it or modify it in join plan nodes to let the executor know which side of the join needs to be checked to decide whether to null at execution time. This representation has the nice property that two Var-and-optional- ForceToNull expression trees are equal() if and only if they are semantically equivalent --- a property we don't have right now, either before or after smashing join alias vars to base vars (although it's worse without doing that, which is why the planner is doing it currently). So we don't need flatten_join_alias_vars anymore. There is one corner case that doesn't fit into this nicely, which is merged output columns from FULL JOIN USING. Currently we represent those as join alias Vars initially, and expand them into "COALESCE(left-side-var, right-side-var)" during flatten_join_alias_vars. We could keep doing that, since the planner has no great intelligence about FULL JOIN anyway. But I was hoping to get rid of the flatten_join_alias_vars pass altogether. Perhaps it is worth adding a special parsetree representation for these things --- I'm imagining something roughly like ForceToNull but with two inputs not one. I think the only reason we need a special representation at all is so that ruleutils.c can decompile it as a Var reference rather than COALESCE(). This representation makes ruleutils.c's decompilation job harder, since it's no longer clear from inspection of a Var node which RTE entry it should be displayed with reference to. (If the base relation is underneath an aliased JOIN then we *must* reference the JOIN instead, not the base rel.) But it's clearly possible, and I'm happy to push complexity into decompilation if it means savings in the main parse/plan code path. Another nice thing is we won't need to widen AttrNumber; in fact, I don't think we need to permanently store any per-Var data in join RTEs, except maybe for those darn FULL JOIN USING vars. Variables' varattnos only refer to base relations and their range doesn't increase in a join nest. Comments? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Lessons from commit fest
Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: It looks like Windows will blow all our existing numbers out of the water. Here's a list generated from Cygwin with 6088 symbols. I'm working on getting a similar list from MinGW. Hmm, your toolset must be listing all typedefs present in the header files, not just those actually used? No, this is from objdump --stabs, just as find_typedefs does. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Lessons from commit fest
Andrew Dunstan <[EMAIL PROTECTED]> writes: > It looks like Windows will blow all our existing numbers out of the > water. Here's a list generated from Cygwin with 6088 symbols. I'm > working on getting a similar list from MinGW. Hmm, your toolset must be listing all typedefs present in the header files, not just those actually used? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Lessons from commit fest
Gregory Stark wrote: "Andrew Dunstan" <[EMAIL PROTECTED]> writes: Tom Lane wrote: doxygen's 200-some is clearly an order of magnitude too low, but I wonder whether Bruce's list hasn't got some false hits ... Skimming the output it does have things like "int" and "float" but presumably we would know if that caused any problem, they wouldn't inflate the numbers much. 2800 does seem a bit high. My buildfarm member dungbeetle just found 2482 on a build that is only missing the optional pam, bonjour and gssapi config options. The numbers going to vary heavily from OS to OS so it seems to me that these are a basically the same order of magnitude. It looks like Windows will blow all our existing numbers out of the water. Here's a list generated from Cygwin with 6088 symbols. I'm working on getting a similar list from MinGW. http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=brown_bat&dt=2008-04-18%20230054&stg=typedefs cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] get rid of psql welcome message
On Friday 18 April 2008 00:24, Joshua D. Drake wrote:
> On Fri, 18 Apr 2008 00:21:58 -0400
>
> Robert Treat <[EMAIL PROTECTED]> wrote:
> > > We could just do:
> > >
> > > psql 8.1.10 - postgresql server version 8.1.10
> > >
> > > Type: \h for SQL help, \? for psql help, \q to quit
> > >
> > > postgres=#
> >
> > I think it's getting overlooked because most people don't deal with
> > it, but I really think we need to keep the SSL info as is. Actually
> > I think we ought to keep the whole thing and just add the no-splash
> > option for advanced users, but barring that, the SSL info is very
> > handy when you're working on SSL enabled servers.
>
> Is it enough to say "SSL: On"? Or do you want all the cert stuff?
>
I want the cert stuff.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Lessons from commit fest
"Andrew Dunstan" <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> doxygen's 200-some is clearly an order of magnitude too low, but I >> wonder whether Bruce's list hasn't got some false hits ... Skimming the output it does have things like "int" and "float" but presumably we would know if that caused any problem, they wouldn't inflate the numbers much. > 2800 does seem a bit high. My buildfarm member dungbeetle just found 2482 on a > build that is only missing the optional pam, bonjour and gssapi config > options. The numbers going to vary heavily from OS to OS so it seems to me that these are a basically the same order of magnitude. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCHES] Coding standards
Alvaro Herrera wrote: Yes they are useful. As a new patcher, where should I look for coding standards? How about a little FAQ at the top of the CVS source tree? The developer's FAQ is supposed to contain this kind of thing, but I think it's rather thin on actual details. (Some time ago it was proposed to create a "style guide", but people here thought it was a waste of time and "it will not cover what's really important", so we're stuck with repeating the advice over and over.) As a new patcher I'm certain to look at the top of the CVS tree. I'm not so certain to actually find and read a FAQ. But I've got the advice now, so I won't make the same missteps again -Bryce Nesbitt PS: less is more, keep any guide very very short -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] get rid of psql welcome message
Tom Lane wrote: Well, in general the *variable* parts of the banner were all put there because of fairly urgent need, and I'd resist removing them. It's the unchanging boilerplate that seems open to debate. I'm +1 for cutting that down to a single line. I don't care one way or the other about providing a .psqlrc option to suppress it altogether. It could be that even optional removal of the version number is a foot-gun for users who perhaps carelessly lose track of which version they are running and do something with it (such as rsync with another server's data dir or something silly like that) expecting the wrong version. I don't see how, if it were reduced to a single line, the indication of version number could possibly be considered problematic under any circumstances. Regards, - Naz. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Lessons from commit fest
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Greg Smith wrote:
Scraping that HTML seems like it would be pretty straightforward.
It's awfully incomplete. Bruce said to me the other day on IM that the
list he was getting with the Linux version of find_typedef was something
like 2800 symbols. I checked the doxygen list and I only see about a
dozen for each letter, so there's a whole lot missing here.
[ click click... ] A quick grep counts 2154 occurrences of the word
'typedef' in our tree. Some of them are no doubt false hits
(documentation etc), but on the other hand you need to add typedefs
coming from system headers.
doxygen's 200-some is clearly an order of magnitude too low, but I
wonder whether Bruce's list hasn't got some false hits ...
2800 does seem a bit high. My buildfarm member dungbeetle just found
2482 on a build that is only missing the optional pam, bonjour and
gssapi config options.
Here's the list already loaded to the server:
http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=dungbeetle&dt=2008-04-18%20160103&stg=typedefs
I had to change the logic some - the stuff in the find_typedefs script
seemed to be quite broken on my Linux box (fairly vanilla fc6).
The relevant perl code is below.
I'll see about running this with Windows and Cygwin and I can even try OSX.
cheers
andrew
sub find_typedefs
{
my @err = `objdump -W 2>&1`;
my %syms;
my @dumpout;
my @flds;
foreach my $bin (glob("$installdir/bin/*"),
glob("$installdir/lib/*"),
glob("$installdir/lib/postgresql/*"))
{
next if $bin =~ m!bin/(ipcclean|pltcl_)!;
next unless -f $bin;
if (@err == 1) # Linux
{
@dumpout = `objdump -W $bin 2>/dev/null | egrep -A3
'(DW_TAG_typedef|DW_TAG_structure_type|DW_TAG_union_type)' 2>/dev/null`;
foreach (@dumpout)
{
@flds = split;
next if ($flds[0] ne 'DW_AT_name' || $flds[-1] =~
/^DW_FORM_str/);
$syms{$flds[-1]} =1;
}
}
else
{
@dumpout = `objdump --stabs $bin 2>/dev/null`;
foreach (@dumpout)
{
@flds = split;
next if ($flds[1] ne 'LSYM' || $flds[6] !~ /([^:]+):[tT]/);
$syms{$1} =1;
}
}
}
my @badsyms = grep { /\s/ } keys %syms;
push(@badsyms,'date','interval','timestamp','ANY');
delete @[EMAIL PROTECTED];
my @goodsyms = sort keys %syms;
map { s/$/\n/; } @goodsyms;
writelog('typedefs',[EMAIL PROTECTED]);
}
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Lessons from commit fest
Alvaro Herrera wrote: > Bruce Momjian wrote: > > > pgindent is probably 97% optimal. Getting a better typedef list will > > change that to perhaps 97.2% optimal. There is a lot of discussion > > happening to try to get that 0.2%. :-O > > If I'm allowed to make my own guesses I'd say pgindent is at about 90% > currently and we could get it to 99% or more by leveraging the > buildfarm. My point is that typedefs are only a small part of what makes pgindent less than perfect. I should have said a "perfect typedef list" would make it 97.2%. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Lessons from commit fest
Bruce Momjian wrote: > pgindent is probably 97% optimal. Getting a better typedef list will > change that to perhaps 97.2% optimal. There is a lot of discussion > happening to try to get that 0.2%. :-O If I'm allowed to make my own guesses I'd say pgindent is at about 90% currently and we could get it to 99% or more by leveraging the buildfarm. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Lessons from commit fest
Tom Lane wrote: > [ click click... ] A quick grep counts 2154 occurrences of the word > 'typedef' in our tree. Some of them are no doubt false hits > (documentation etc), but on the other hand you need to add typedefs > coming from system headers. > > doxygen's 200-some is clearly an order of magnitude too low, but I > wonder whether Bruce's list hasn't got some false hits ... You also have to account for typedefs in OpenSSL headers, Kerberos, readline, etc. Perhaps you can count them as "system headers", but then it starts to be clear that you can't just process our own source files, or any system's headers alone. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] new field content lost
Tom Lane wrote: > Gaetano Mendola <[EMAIL PROTECTED]> writes: >> since long time I have implemented a materialized view, today I had to add a >> new field and I faced the following (I believe) bug. >> The bug can be replicated on a 8.2.7 > > Cached plan for the function's UPDATE. Should work okay in 8.3 ... > It does. Regards Gaetano Mendola -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Repair two places where SIGTERM exit couldleave shared memory
On Thu, Apr 17, 2008 at 11:48:41AM -0400, Tom Lane wrote: > Martijn van Oosterhout <[EMAIL PROTECTED]> writes: > > Is this so? This happened to me the other day (hence the question about > > having COPY note failure earlier) because the disk filled up. I was > > confused because du showed nothing. Eventually I did an lsof and found > > the postgres backend had a large number of open file handles to deleted > > files (each one gigabyte). > > The backend, or the bgwriter? Please be specific. I beleive the backend, because I was using lsof -p using the pid copied from ps. But I can't be 100%. > 8.3 and HEAD should ftruncate() the first segment of a relation but I > think they just unlink the rest. Is it sane to think of ftruncate then > unlink on the non-first segments, to alleviate the disk-space issue when > someone else is holding the file open? It's possible. OTOH, if the copy error had been return in the PQputline() the driving program (which has several COPYs running at once) would have aborted and the data would have been reclaimed immediately. As it is it kept going for an hour before noticing and then dying (and cleaning everything up). The one ftruncate does explain why there was some free space, so that part is appreciated. Have a nice day, -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ > Please line up in a tree and maintain the heap invariant while > boarding. Thank you for flying nlogn airlines. signature.asc Description: Digital signature
