pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedpgindent run coming
61+ messages / 12 participants
[nested] [flat]
Commits from this thread:
2020-03-12 a493f93342 05e0aff584 d22ac5378f 4e8cad2da3 Fix nextXid tracking bug on standbys (9.5-11 only).
* pgindent run coming
@ 2009-06-09 17:21 Bruce Momjian <bruce@momjian.us>
0 siblings, 3 replies; 61+ messages in thread
From: Bruce Momjian @ 2009-06-09 17:21 UTC (permalink / raw)
To: pgsql-hackers
It is time to run pgindent on CVS HEAD for 8.4. I am thinking of
running it at zero-hour GMT tomorrow, meaning five hours from now.
Any objections?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-10 03:21 Bruce Momjian <bruce@momjian.us>
parent: Bruce Momjian <bruce@momjian.us>
2 siblings, 2 replies; 61+ messages in thread
From: Bruce Momjian @ 2009-06-10 03:21 UTC (permalink / raw)
To: pgsql-hackers
Bruce Momjian wrote:
> It is time to run pgindent on CVS HEAD for 8.4. I am thinking of
> running it at zero-hour GMT tomorrow, meaning five hours from now.
> Any objections?
I ran pgindent and was concerned enough about the results so I am
posting here rather than applying any changes. I used the old way of
generating typedefs and the new buildfarm method output from diffs from
http://www.pgbuildfarm.org/cgi-bin/typedefs.pl. The typedef lists and
diff are here:
http://momjian.us/expire/pgindent/
You can see the typedef lists are of similar size:
2775 typedefs.old
2123 typedefs.new
and the diffs generates are a similar number of lines:
133657 diff.old_typedefs
135042 diff.new_typedefs
I saw a few odd things. Most importantly, it seems 'stat' was
introduced as a typedef on _both_ lists, yielding weird changes like:
- ret = stat(indir, &st);
+ ret = stat (indir, &st);
and even odder:
- stat->weight |= 1 << 3;
+ stat ->weight |= 1 << 3;
stat was not a typedef in 8.3 or pgindent would have done this for 8.3,
but I can't figure out what has changed to make it appear for 8.4. I
see this in the objdump output (my OS has not changed from 8.3):
31357 EXCL 0 0 00003e64 97648 /usr/include/time.h
31358 EXCL 0 0 00007638 97624 /usr/include/sys/time.h
31359 EXCL 0 0 00000000 97648 /usr/include/time.h
31360 EXCL 0 0 00001dff 25540 /usr/include/fcntl.h
31361 BINCL 0 0 000144be 449667 /usr/include/sys/stat.h
31362 LSYM 0 0 00000000 449691 ostat:T(51,1)=s64st_dev:(0,9),0,16;st_ino:(9,20),32,32;st_mode:(9,22),64,16;st_nlink:(9,23),80,16;st_u
id:(0,9),96,16;st_gid:(0,9),112,16;st_rdev:(0,9),128,16;st_size:(0,3),160,32;st_atimespec:(48,2),192,64;st_mtimespec:(48,2),256,64;st_ctimespec:(4
8,2),320,64;st_blksize:(0,3),384,32;st_blocks:(0,3),416,32;st_flags:(0,5),448,32;st_gen:(0,5),480,32;;
31363 LSYM 0 0 00000000 450042 stat32:T(51,2)=s96st_dev:(9,17),0,32;st_ino:(9,20),32,32;st_mode:(9,22),64,16;st_nlink:(9,23),80,16;st
_uid:(9,28),96,32;st_gid:(9,19),128,32;st_rdev:(9,17),160,32;st_atimespec:(48,2),192,64;st_mtimespec:(48,2),256,64;st_ctimespec:(48,2),320,64;st_s
ize:(0,3),384,32;st_size1:(0,3),416,32;st_blocks:(0,3),448,32;st_blocks1:(0,3),480,32;st_blksize:(0,5),512,32;st_flags:(0,5),544,32;st_gen:(0,5),5
76,32;st_lspare:(0,3),608,32;st_qspare:(51,3)=ar(0,1);0;3;(0,3),640,128;;
--> 31364 LSYM 0 0 00000000 450510 stat:T(51,4)=s96st_dev:(9,17),0,32;st_ino:(9,20),32,32;st_mode:(9,22),64,16;st_nlink:(9,23),80,16;st_u
id:(9,28),96,32;st_gid:(9,19),128,32;st_rdev:(9,17),160,32;st_atimespec:(48,2),192,64;st_mtimespec:(48,2),256,64;st_ctimespec:(48,2),320,64;st_siz
e:(9,24),384,64;st_blocks:(9,8),448,64;st_blksize:(0,5),512,32;st_flags:(0,5),544,32;st_gen:(0,5),576,32;st_lspare:(0,3),608,32;st_qspare:(51,5)=a
r(0,1);0;1;(9,8),640,128;;
It is coming from the postgres binary.
The typedef is coming from the indicated line, and from
/usr/include/sys/stat.h, where there is no typedef for stat. Obviously
Linux or the buildfarm is finding the same issue, but I have no idea
why.
My only guess right now is that we are linking postgres differently than
we did for 8.3 and that is bringing in new wrong typedef symbols.
I will have to research this further tomorrow.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-10 03:30 Bruce Momjian <bruce@momjian.us>
parent: Bruce Momjian <bruce@momjian.us>
1 sibling, 0 replies; 61+ messages in thread
From: Bruce Momjian @ 2009-06-10 03:30 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: pgsql-hackers
Bruce Momjian wrote:
> The typedef is coming from the indicated line, and from
> /usr/include/sys/stat.h, where there is no typedef for stat. Obviously
> Linux or the buildfarm is finding the same issue, but I have no idea
> why.
>
> My only guess right now is that we are linking postgres differently than
> we did for 8.3 and that is bringing in new wrong typedef symbols.
>
> I will have to research this further tomorrow.
I was able to reproduce the incorrect stat typedef here in a small test
program by just including "sys/stat.h" so I will research tomorrow how
to fix this.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-10 03:33 Tom Lane <tgl@sss.pgh.pa.us>
parent: Bruce Momjian <bruce@momjian.us>
1 sibling, 3 replies; 61+ messages in thread
From: Tom Lane @ 2009-06-10 03:33 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
> I saw a few odd things. Most importantly, it seems 'stat' was
> introduced as a typedef on _both_ lists, yielding weird changes like:
The standard headers do define "struct stat". I wonder whether the
objdump kluge we are using is unable to distinguish typedef names
from struct tags.
> I will have to research this further tomorrow.
We don't have a lot of time for research. Maybe the best thing is to
just manually remove stat from the typedef list (along with anything
else that clearly shouldn't be there)?
regards, tom lane
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-10 03:36 Bruce Momjian <bruce@momjian.us>
parent: Tom Lane <tgl@sss.pgh.pa.us>
2 siblings, 1 reply; 61+ messages in thread
From: Bruce Momjian @ 2009-06-10 03:36 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > I saw a few odd things. Most importantly, it seems 'stat' was
> > introduced as a typedef on _both_ lists, yielding weird changes like:
>
> The standard headers do define "struct stat". I wonder whether the
> objdump kluge we are using is unable to distinguish typedef names
> from struct tags.
>
> > I will have to research this further tomorrow.
>
> We don't have a lot of time for research. Maybe the best thing is to
> just manually remove stat from the typedef list (along with anything
> else that clearly shouldn't be there)?
The problem is that there are other symbols I don't know about and the
diff is very large. I have found that the problem was caused when we
added Linux support to find_typedef and I have a way to get an accurate
list on my machine.
I will generate a proper list on my machine tomorrow then test Linux
here to see if I can get it to generate the right list too. But odds
are we are not going to have time to re-run the list on the build farm
even if I can get Linux working here.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-10 03:40 Bruce Momjian <bruce@momjian.us>
parent: Tom Lane <tgl@sss.pgh.pa.us>
2 siblings, 1 reply; 61+ messages in thread
From: Bruce Momjian @ 2009-06-10 03:40 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > I saw a few odd things. Most importantly, it seems 'stat' was
> > introduced as a typedef on _both_ lists, yielding weird changes like:
>
> The standard headers do define "struct stat". I wonder whether the
> objdump kluge we are using is unable to distinguish typedef names
> from struct tags.
>
> > I will have to research this further tomorrow.
>
> We don't have a lot of time for research. Maybe the best thing is to
> just manually remove stat from the typedef list (along with anything
> else that clearly shouldn't be there)?
Do you want me to just run with my old typedef list now and apply it?
We an always rerun tomorrow if we get a better typedef list.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-10 03:46 Tom Lane <tgl@sss.pgh.pa.us>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 61+ messages in thread
From: Tom Lane @ 2009-06-10 03:46 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
> Tom Lane wrote:
>> We don't have a lot of time for research. Maybe the best thing is to
>> just manually remove stat from the typedef list (along with anything
>> else that clearly shouldn't be there)?
> Do you want me to just run with my old typedef list now and apply it?
> We an always rerun tomorrow if we get a better typedef list.
I'd rather have *one* run with the final typedef list. If you don't
have that list yet, wait till you do.
regards, tom lane
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-10 03:48 Bruce Momjian <bruce@momjian.us>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 61+ messages in thread
From: Bruce Momjian @ 2009-06-10 03:48 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers; Andrew Dunstan <andrew@dunslane.net>
Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Tom Lane wrote:
> >> We don't have a lot of time for research. Maybe the best thing is to
> >> just manually remove stat from the typedef list (along with anything
> >> else that clearly shouldn't be there)?
>
> > Do you want me to just run with my old typedef list now and apply it?
> > We an always rerun tomorrow if we get a better typedef list.
>
> I'd rather have *one* run with the final typedef list. If you don't
> have that list yet, wait till you do.
OK, Andrew, would you use the find_typedef file that is in CVS HEAD and
run that. I think that will fix our problem and then I can use the
buildfarm version. How often does that run and does it pull the script
from CVS HEAD?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-10 04:12 Andrew Dunstan <andrew@dunslane.net>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 61+ messages in thread
From: Andrew Dunstan @ 2009-06-10 04:12 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-hackers
Bruce Momjian wrote:
> OK, Andrew, would you use the find_typedef file that is in CVS HEAD and
> run that. I think that will fix our problem and then I can use the
> buildfarm version. How often does that run and does it pull the script
> from CVS HEAD?
>
>
The buildfarm does not run the find-typedefs script. Its code for this
is below. My Unix machine runs this once a day. I can do runs on Windows
and Cygwin manually.
If there is changed logic tell me what it is and I'll try to get it done.
cheers
andrew
-----------------
sub find_typedefs
{
my @err = `objdump -W 2>&1`;
@err = () if `uname -s 2>&1` =~ /CYGWIN/i;
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] 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 < 7);
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 @syms{@badsyms};
my @goodsyms = sort keys %syms;
my @foundsyms;
my %foundwords;
my $setfound = sub
{
return unless (-f $_ && /^.*\.[chly]\z/);
my @lines;
my $handle;
open ($handle,$_);
while (my $line=<$handle>)
{
foreach my $word (split(/\W+/,$line))
{
$foundwords{$word} = 1;
}
}
close($handle);
};
File::Find::find($setfound,"$branch_root/pgsql");
foreach my $sym (@goodsyms)
{
push(@foundsyms,"$sym\n") if exists $foundwords{$sym};
}
writelog('typedefs',\@foundsyms);
$steps_completed .= " find-typedefs";
}
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-10 06:18 Simon Riggs <simon@2ndQuadrant.com>
parent: Bruce Momjian <bruce@momjian.us>
2 siblings, 1 reply; 61+ messages in thread
From: Simon Riggs @ 2009-06-10 06:18 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: pgsql-hackers
On Tue, 2009-06-09 at 13:21 -0400, Bruce Momjian wrote:
> It is time to run pgindent on CVS HEAD for 8.4. I am thinking of
> running it at zero-hour GMT tomorrow, meaning five hours from now.
> Any objections?
Why don't we do this automatically after each individual commit? That
way each commit would be associated directly with any required tidy-up
that must occur because of it.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-10 13:43 Bruce Momjian <bruce@momjian.us>
parent: Andrew Dunstan <andrew@dunslane.net>
0 siblings, 1 reply; 61+ messages in thread
From: Bruce Momjian @ 2009-06-10 13:43 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-hackers
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
> > OK, Andrew, would you use the find_typedef file that is in CVS HEAD and
> > run that. I think that will fix our problem and then I can use the
> > buildfarm version. How often does that run and does it pull the script
> > from CVS HEAD?
> >
> >
>
> The buildfarm does not run the find-typedefs script. Its code for this
> is below. My Unix machine runs this once a day. I can do runs on Windows
> and Cygwin manually.
>
> If there is changed logic tell me what it is and I'll try to get it done.
Yes, please make the attached change, and rerun the script. This change
reflects the changes I made in src/tools/find_typedef.
What value is there if the URL I have just runs on Linux? It probably
has the same coverage I have for BSD. I asked for something that was
automated for more platforms a year ago and I still don't have it? I
might as well just use the same method I have have used for years.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Attachments:
/rtmp/diff (text/x-diff, 389B) download
*** ./script.pl.orig Wed Jun 10 09:39:27 2009
--- ./script.pl Wed Jun 10 09:39:39 2009
***************
*** 30,36 ****
{
@flds = split;
next if (@flds < 7);
! next if ($flds[1] ne 'LSYM' || $flds[6] !~ /([^:]+):[tT]/);
$syms{$1} =1;
}
}
--- 30,36 ----
{
@flds = split;
next if (@flds < 7);
! next if ($flds[1] ne 'LSYM' || $flds[6] !~ /([^:]+):t/);
$syms{$1} =1;
}
}
* Re: pgindent run coming
@ 2009-06-10 13:45 Tom Lane <tgl@sss.pgh.pa.us>
parent: Simon Riggs <simon@2ndQuadrant.com>
0 siblings, 0 replies; 61+ messages in thread
From: Tom Lane @ 2009-06-10 13:45 UTC (permalink / raw)
To: Simon Riggs <simon@2ndQuadrant.com>; +Cc: Bruce Momjian <bruce@momjian.us>; pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes:
> On Tue, 2009-06-09 at 13:21 -0400, Bruce Momjian wrote:
>> It is time to run pgindent on CVS HEAD for 8.4. I am thinking of
>> running it at zero-hour GMT tomorrow, meaning five hours from now.
> Why don't we do this automatically after each individual commit?
It's not very practical until the typedef extraction stuff is fully
automatic and fully trustworthy; right now some manual review and
intervention still seems like a good idea.
Also, that would risk breaking series of interdependent patches.
regards, tom lane
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-10 14:42 Bruce Momjian <bruce@momjian.us>
parent: Tom Lane <tgl@sss.pgh.pa.us>
2 siblings, 1 reply; 61+ messages in thread
From: Bruce Momjian @ 2009-06-10 14:42 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > I saw a few odd things. Most importantly, it seems 'stat' was
> > introduced as a typedef on _both_ lists, yielding weird changes like:
>
> The standard headers do define "struct stat". I wonder whether the
> objdump kluge we are using is unable to distinguish typedef names
> from struct tags.
>
> > I will have to research this further tomorrow.
>
> We don't have a lot of time for research. Maybe the best thing is to
> just manually remove stat from the typedef list (along with anything
> else that clearly shouldn't be there)?
I agree we are running out of time so I will be running pgindent in one
hour using the same BSD-based typedef method I have used in the past.
If a better typedef list appears, we can always rerun pgindent.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-10 14:48 Tom Lane <tgl@sss.pgh.pa.us>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 0 replies; 61+ messages in thread
From: Tom Lane @ 2009-06-10 14:48 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
> Tom Lane wrote:
>> We don't have a lot of time for research. Maybe the best thing is to
>> just manually remove stat from the typedef list (along with anything
>> else that clearly shouldn't be there)?
> I agree we are running out of time so I will be running pgindent in one
> hour using the same BSD-based typedef method I have used in the past.
> If a better typedef list appears, we can always rerun pgindent.
Why not compare the BSD list with the new one and adopt anything that
seems sane? We know that your old method misses quite a lot of typedefs.
regards, tom lane
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-10 15:00 Andrew Dunstan <andrew@dunslane.net>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 61+ messages in thread
From: Andrew Dunstan @ 2009-06-10 15:00 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-hackers
Bruce Momjian wrote:
> Andrew Dunstan wrote:
>
>> Bruce Momjian wrote:
>>
>>> OK, Andrew, would you use the find_typedef file that is in CVS HEAD and
>>> run that. I think that will fix our problem and then I can use the
>>> buildfarm version. How often does that run and does it pull the script
>>> from CVS HEAD?
>>>
>>>
>>>
>> The buildfarm does not run the find-typedefs script. Its code for this
>> is below. My Unix machine runs this once a day. I can do runs on Windows
>> and Cygwin manually.
>>
>> If there is changed logic tell me what it is and I'll try to get it done.
>>
>
> Yes, please make the attached change, and rerun the script. This change
> reflects the changes I made in src/tools/find_typedef.
>
> What value is there if the URL I have just runs on Linux? It probably
> has the same coverage I have for BSD. I asked for something that was
> automated for more platforms a year ago and I still don't have it? I
> might as well just use the same method I have have used for years.
>
>
Well, sometimes I build it and they don't come ;-).
I don't have every platform under the sun that I can run this on,
although I do now have an FBSD VM that I didn't have when I worked on
this previously. If you're actually going to use it I'll set it up as a
buildfarm member and run the find-typedefs there.
I will make the change you request and rerun the stuff on the platforms
I have that are currently buildfarm members, but AFAICT the Linux output
will still include the stat symbol (your change doesn't affect the Linux
branch at all).
Both my version and yours contains provision for filtering out certain
symbols ('timestamp' etc). Maybe we need to add 'stat' to that list.
cheers
andrew
> ------------------------------------------------------------------------
>
> *** ./script.pl.orig Wed Jun 10 09:39:27 2009
> --- ./script.pl Wed Jun 10 09:39:39 2009
> ***************
> *** 30,36 ****
> {
> @flds = split;
> next if (@flds < 7);
> ! next if ($flds[1] ne 'LSYM' || $flds[6] !~ /([^:]+):[tT]/);
> $syms{$1} =1;
> }
> }
> --- 30,36 ----
> {
> @flds = split;
> next if (@flds < 7);
> ! next if ($flds[1] ne 'LSYM' || $flds[6] !~ /([^:]+):t/);
> $syms{$1} =1;
> }
> }
>
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-10 15:11 Bruce Momjian <bruce@momjian.us>
parent: Andrew Dunstan <andrew@dunslane.net>
0 siblings, 1 reply; 61+ messages in thread
From: Bruce Momjian @ 2009-06-10 15:11 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-hackers
Andrew Dunstan wrote:
> Well, sometimes I build it and they don't come ;-).
>
> I don't have every platform under the sun that I can run this on,
> although I do now have an FBSD VM that I didn't have when I worked on
> this previously. If you're actually going to use it I'll set it up as a
> buildfarm member and run the find-typedefs there.
>
> I will make the change you request and rerun the stuff on the platforms
> I have that are currently buildfarm members, but AFAICT the Linux output
> will still include the stat symbol (your change doesn't affect the Linux
> branch at all).
Good point. Here is another diff I need you to make to the pl file.
If you want to make your pl file the official version and replace the
shell script in CVS, that is fine with me. Do you want me to do that?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Attachments:
/rtmp/diff (text/x-diff, 492B) download
*** ./script.pl.orig Wed Jun 10 09:39:27 2009
--- ./script.pl Wed Jun 10 11:09:36 2009
***************
*** 14,20 ****
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;
--- 14,20 ----
if (@err == 1) # Linux
{
@dumpout = `objdump -W $bin 2>/dev/null | egrep -A3
! 'DW_TAG_typedef' 2>/dev/null`;
foreach (@dumpout)
{
@flds = split;
* Re: pgindent run coming
@ 2009-06-10 15:33 Andrew Dunstan <andrew@dunslane.net>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 61+ messages in thread
From: Andrew Dunstan @ 2009-06-10 15:33 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-hackers
Bruce Momjian wrote:
>
> Good point. Here is another diff I need you to make to the pl file.
>
Done. Linux run under way.
> If you want to make your pl file the official version and replace the
> shell script in CVS, that is fine with me. Do you want me to do that?
>
>
It needs to be done in two pieces, I think: a perl module that exports a
function that can be called from the buildfarm, and program that calls
it so it can be run standalone. The function needs two inputs: an
installation directory and a source directory. Then we will be able to
stay in sync nicely. I will try to do that over the next day or so if
you like.
Or we can just wing it for now and do this after the release.
cheers
andrew
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-10 16:01 Bruce Momjian <bruce@momjian.us>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 61+ messages in thread
From: Bruce Momjian @ 2009-06-10 16:01 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <bruce@momjian.us> writes:
> > > I saw a few odd things. Most importantly, it seems 'stat' was
> > > introduced as a typedef on _both_ lists, yielding weird changes like:
> >
> > The standard headers do define "struct stat". I wonder whether the
> > objdump kluge we are using is unable to distinguish typedef names
> > from struct tags.
> >
> > > I will have to research this further tomorrow.
> >
> > We don't have a lot of time for research. Maybe the best thing is to
> > just manually remove stat from the typedef list (along with anything
> > else that clearly shouldn't be there)?
>
> The problem is that there are other symbols I don't know about and the
> diff is very large. I have found that the problem was caused when we
> added Linux support to find_typedef and I have a way to get an accurate
> list on my machine.
OK, I have found the cause of the script error, and it was my fault. A
month after we ran pgindent for 8.3 (December 2007), I received this
issue from Tom:
http://archives.postgresql.org/pgsql-hackers/2007-12/msg00800.php
> Something I noticed the other day is that pgindent doesn't seem to treat
> "struct foo" or "union foo" as a type name, which is pretty silly
> because no context is needed at all to recognize that. We tend not to
> do that too much --- the project style is to use a typedef name --- but
> there are some places that do it, particularly the regex code. For
> instance there are extra spaces here:
>
> static void
> cmtreefree(struct colormap * cm,
> union tree * tree,
> int level) /* level number (top == 0) of this
> block */
> {
>
> Fixable?
Not understanding the ramifications of adding struct and union tags to
the typedef list, I modified the BSD code:
http://archives.postgresql.org/pgsql-hackers/2007-12/msg00810.php
> Yes, I found those are 't' STABS rather than "T" which are used in cases
> where you do typedef struct {} name. The next pgindent will have those
> typedefs you want.
and that modification was propogated to the Linux code.
This has now been fixed in the BSD and Linux code (and Perl script) and
we can move forward with running pgindent once Andrew has lists for all
the platforms he wants.
As for Tom's original complaint about, it seems BSD indent is just not
smart enough about struct/union tags. I will look into fixing that
after 8.4 pgindent is run.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-10 16:02 Bruce Momjian <bruce@momjian.us>
parent: Andrew Dunstan <andrew@dunslane.net>
0 siblings, 0 replies; 61+ messages in thread
From: Bruce Momjian @ 2009-06-10 16:02 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-hackers
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
> >
> > Good point. Here is another diff I need you to make to the pl file.
> >
>
> Done. Linux run under way.
>
> > If you want to make your pl file the official version and replace the
> > shell script in CVS, that is fine with me. Do you want me to do that?
> >
> >
>
> It needs to be done in two pieces, I think: a perl module that exports a
> function that can be called from the buildfarm, and program that calls
> it so it can be run standalone. The function needs two inputs: an
> installation directory and a source directory. Then we will be able to
> stay in sync nicely. I will try to do that over the next day or so if
> you like.
>
> Or we can just wing it for now and do this after the release.
We have to wing it for now. Please let me know when whatever lists you
can generate are ready, hopefully in the next few hours.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-10 16:18 Tom Lane <tgl@sss.pgh.pa.us>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 61+ messages in thread
From: Tom Lane @ 2009-06-10 16:18 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
> OK, I have found the cause of the script error, and it was my fault. A
> month after we ran pgindent for 8.3 (December 2007), I received this
> issue from Tom:
> http://archives.postgresql.org/pgsql-hackers/2007-12/msg00800.php
>> Something I noticed the other day is that pgindent doesn't seem to treat
>> "struct foo" or "union foo" as a type name, which is pretty silly
>> because no context is needed at all to recognize that.
Ah. So really the point here is that we want to specifically exclude
"struct stat" because there are too many places in our code where "stat"
is used as a regular identifier. Are there any other special cases like
that?
regards, tom lane
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-10 18:24 Bruce Momjian <bruce@momjian.us>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 61+ messages in thread
From: Bruce Momjian @ 2009-06-10 18:24 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > OK, I have found the cause of the script error, and it was my fault. A
> > month after we ran pgindent for 8.3 (December 2007), I received this
> > issue from Tom:
>
> > http://archives.postgresql.org/pgsql-hackers/2007-12/msg00800.php
> >> Something I noticed the other day is that pgindent doesn't seem to treat
> >> "struct foo" or "union foo" as a type name, which is pretty silly
> >> because no context is needed at all to recognize that.
>
> Ah. So really the point here is that we want to specifically exclude
> "struct stat" because there are too many places in our code where "stat"
> is used as a regular identifier. Are there any other special cases like
> that?
Yep, lots. I see "option" also doing strange things, and some others.
You can see the diff here:
http://momjian.us/expire/pgindent/http://momjian.us/expire/pgindent/
Basically that list is meant for typedefs, not struct or union tags.
The BSD indent manual page says:
-Ttypename Adds typename to the list of type keywords. Names accu-
mulate: -T can be specified more than once. You need to
specify all the typenames that appear in your program
that are defined by typedef - nothing will be harmed if
you miss a few, but the program won't be formatted as
nicely as it should. This sounds like a painful thing to
have to do, but it's really a symptom of a problem in C:
typedef causes a syntactic change in the language and
indent can't find all instances of typedef.
I am unclear why struct pointers are not being formatted properly in
function headers but will research it.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-10 18:29 Tom Lane <tgl@sss.pgh.pa.us>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 2 replies; 61+ messages in thread
From: Tom Lane @ 2009-06-10 18:29 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
> I am unclear why struct pointers are not being formatted properly in
> function headers but will research it.
Yeah, if we can fix that directly without adding the names to the
typedef list, it would be better. But not something to do right now.
Have you started the pgindent run yet? I have a patch ready for
the cursor stability issue, but will hold off committing if it might
create a merge problem for you.
regards, tom lane
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-10 18:51 Bruce Momjian <bruce@momjian.us>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 61+ messages in thread
From: Bruce Momjian @ 2009-06-10 18:51 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > I am unclear why struct pointers are not being formatted properly in
> > function headers but will research it.
>
> Yeah, if we can fix that directly without adding the names to the
> typedef list, it would be better. But not something to do right now.
>
> Have you started the pgindent run yet? I have a patch ready for
> the cursor stability issue, but will hold off committing if it might
> create a merge problem for you.
I am waiting for Andrew to tell me he is ready with updated lists for
his platforms. His CGI output is now _not_ showing stat so I am
comparing the lists now.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-10 18:52 Tom Lane <tgl@sss.pgh.pa.us>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 0 replies; 61+ messages in thread
From: Tom Lane @ 2009-06-10 18:52 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
>> Have you started the pgindent run yet? I have a patch ready for
>> the cursor stability issue, but will hold off committing if it might
>> create a merge problem for you.
> I am waiting for Andrew to tell me he is ready with updated lists for
> his platforms. His CGI output is now _not_ showing stat so I am
> comparing the lists now.
OK, I'll commit now and then stay out of your way.
regards, tom lane
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-10 18:54 Andrew Dunstan <andrew@dunslane.net>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 2 replies; 61+ messages in thread
From: Andrew Dunstan @ 2009-06-10 18:54 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Bruce Momjian <bruce@momjian.us>; pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
>
>> I am unclear why struct pointers are not being formatted properly in
>> function headers but will research it.
>>
>
> Yeah, if we can fix that directly without adding the names to the
> typedef list, it would be better. But not something to do right now.
>
> Have you started the pgindent run yet? I have a patch ready for
> the cursor stability issue, but will hold off committing if it might
> create a merge problem for you.
>
>
>
I am doing runs as requested on various platforms to extract the typedef
lists. Linux is done, Windows (mingw) is running, FBSD and Cygwin to come.
Results in a few hours. The buildfarm will have a consolidated list.
cheers
andrew
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-10 19:04 Bruce Momjian <bruce@momjian.us>
parent: Andrew Dunstan <andrew@dunslane.net>
1 sibling, 2 replies; 61+ messages in thread
From: Bruce Momjian @ 2009-06-10 19:04 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-hackers
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
> > Bruce Momjian <bruce@momjian.us> writes:
> >
> >> I am unclear why struct pointers are not being formatted properly in
> >> function headers but will research it.
> >>
> >
> > Yeah, if we can fix that directly without adding the names to the
> > typedef list, it would be better. But not something to do right now.
> >
> > Have you started the pgindent run yet? I have a patch ready for
> > the cursor stability issue, but will hold off committing if it might
> > create a merge problem for you.
> >
> >
> >
>
> I am doing runs as requested on various platforms to extract the typedef
> lists. Linux is done, Windows (mingw) is running, FBSD and Cygwin to come.
>
> Results in a few hours. The buildfarm will have a consolidated list.
OK, good. However, I am seeing missing typedefs in the Linux list you
posted at:
http://www.pgbuildfarm.org/cgi-bin/typedefs.pl
I pulled this list 20 minutes ago. I compared your list to the BSD list
I usually used and found that the Linux list had fewer typedefs:
2270 typedefs.old
1848 typedefs.new
I did a diff, attached, and found some typedefs that don't appear, like
PortalData. That is defined in our code as:
typedef struct PortalData *Portal;
typedef struct PortalData
{
/* Bookkeeping data */
...
bool visible; /* include this portal in pg_cursors? */
} PortalData;
I will try to build on Linux here and see how objdump displays that,
unless you can get me the output.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Attachments:
/rtmp/diff (text/x-diff, 10.0K) download
5,16d4
< AMT
< AMTS
< ASN1_BIT_STRING
< ASN1_BMPSTRING
< ASN1_BOOLEAN
< ASN1_CTX
< ASN1_ENCODING
< ASN1_ENUMERATED
< ASN1_GENERALIZEDTIME
< ASN1_GENERALSTRING
< ASN1_HEADER
< ASN1_IA5STRING
18,24d5
< ASN1_ITEM
< ASN1_ITEM_EXP
< ASN1_METHOD
< ASN1_NULL
< ASN1_OBJECT
< ASN1_OCTET_STRING
< ASN1_PRINTABLESTRING
26,36d6
< ASN1_STRING_TABLE
< ASN1_T61STRING
< ASN1_TEMPLATE
< ASN1_TIME
< ASN1_TLC
< ASN1_TYPE
< ASN1_UNIVERSALSTRING
< ASN1_UTCTIME
< ASN1_UTF8STRING
< ASN1_VALUE
< ASN1_VISIBLESTRING
59d28
< AfterTriggerEventDataOneCtid
68d36
< AggHashEntryData
72d39
< AggStatePerAggData
80d46
< AllocBlockData
82d47
< AllocChunkData
142d106
< AutoVacuumSignal
149d112
< BINOP
151d113
< BIO_F_BUFFER_CTX
153d114
< BIO_dummy
156,157d116
< BIT_STRING_BITNAME
< BLOCK
159d117
< BN_BLINDING
161,162d118
< BN_MONT_CTX
< BN_RECP_CTX
175d130
< BTScanPos
184d138
< BUF_MEM
187d140
< BackslashQuoteType
212d164
< BoolPtr
221d172
< BufferAccessStrategyData
231,233d181
< BulkInsertStateData
< Byte
< Bytef
241,259d188
< COMP_CTX
< COMP_METHOD
< CONDOP
< CONF
< CONF_IMODULE
< CONF_METHOD
< CONF_MODULE
< CONF_VALUE
< COP
< CPFunction
< CPPFunction
< CRYPTO_EX_DATA
< CRYPTO_EX_DATA_FUNCS
< CRYPTO_EX_DATA_IMPL
< CRYPTO_EX_dup
< CRYPTO_EX_free
< CRYPTO_EX_new
< CRYPTO_MEM_LEAK_CB
< CRYPTO_dynlock
261d189
< CURCUR
298d225
< CoercionCodes
301d227
< CoercionMethod
326d251
< ConstraintExclusionType
360d284
< CreateStmtLikeOption
365d288
< Cred
376d298
< DCH_poz
381d302
< DH_METHOD
388,389d308
< DSA_METHOD
< DSA_SIG
395d313
< DatumPtr
417d334
< Dl_info
442,448d358
< ENGINE_CIPHERS_PTR
< ENGINE_CMD_DEFN
< ENGINE_CTRL_FUNC_PTR
< ENGINE_DIGESTS_PTR
< ENGINE_GEN_FUNC_PTR
< ENGINE_GEN_INT_FUNC_PTR
< ENGINE_LOAD_KEY_PTR
450,452d359
< ERR_FNS
< ERR_STATE
< ERR_STRING_DATA
454,457d360
< EVP_CIPHER
< EVP_CIPHER_CTX
< EVP_CIPHER_INFO
< EVP_ENCODE_CTX
460d362
< EVP_PBE_KEYGEN
495d396
< FF
500d400
< FUNMAP
535d434
< FormData_pg_description
553d451
< FormData_pg_shdescription
578d475
< Form_pg_description
596d492
< Form_pg_shdescription
618d513
< Function
629d523
< GEN_SESSION_CB
642,644d535
< GP
< GV
< GVOP
647d537
< GenericOptionFlags
660d549
< GinScanEntryData
676d564
< GlobalTransactionData
701,702d588
< HE
< HEK
704d589
< HISTORY_STATE
721d605
< HashJoinTableData
723d606
< HashJoinTupleData
740d622
< HeapScanDescData
747d628
< I16
749d629
< I8
751d630
< IO
755d633
< IV64
759,760d636
< IndexAttributeBitMap
< IndexAttributeBitMapData
773d648
< IndexScanDescData
784d658
< InhPaths
805,806d678
< ItemLength
< ItemOffset
810d681
< JMPENV
818,819d688
< KEYMAP_ENTRY
< KEYMAP_ENTRY_ARRAY
822,828c691,693
< Keymap
< LHASH
< LHASH_COMP_FN_TYPE
< LHASH_DOALL_ARG_FN_TYPE
< LHASH_DOALL_FN_TYPE
< LHASH_HASH_FN_TYPE
< LHASH_NODE
---
> LDAP
> LDAPMessage
> LDAP_TIMEVAL
830d694
< LISTOP
839,840d702
< LOGOP
< LOOP
870d731
< LockInfo
876d736
< LockTagType
882d741
< MAGIC
884,888d742
< MD2_CTX
< MD4_CTX
< MD5_CTX
< MDC2_CTX
< MGVTBL
898d751
< MergeJoinClauseData
914,916d766
< NETSCAPE_CERT_SEQUENCE
< NETSCAPE_SPKAC
< NETSCAPE_SPKI
921d770
< NUM_poz
944c793
< OBJ_NAME
---
> OM_uint32
976d824
< Outrec
979d826
< PADOFFSET
981,988d827
< PBE2PARAM
< PBEPARAM
< PBKDF2PARAM
< PEM_CTX
< PEM_ENCODE_SEAL_CTX
< PEM_USER
< PERL_CONTEXT
< PERL_SI
992d830
< PGErrorVerbosity
1018d855
< PGSSTrackLevel
1037,1047d873
< PKCS7
< PKCS7_DIGEST
< PKCS7_ENCRYPT
< PKCS7_ENC_CONTENT
< PKCS7_ENVELOPE
< PKCS7_ISSUER_AND_SERIAL
< PKCS7_RECIP_INFO
< PKCS7_SIGNED
< PKCS7_SIGNER_INFO
< PKCS7_SIGN_ENVELOPE
< PKCS8_PRIV_KEY_INFO
1097c923,933
< PMOP
---
> PLyDatumToOb
> PLyDatumToObFunc
> PLyObToDatum
> PLyObToTuple
> PLyPlanObject
> PLyProcedure
> PLyResultObject
> PLyTupleToOb
> PLyTypeInfo
> PLyTypeInput
> PLyTypeOutput
1117d952
< PV
1119d953
< PVOP
1125d958
< PacketLen
1157d989
< PerlExitListEntry
1206d1037
< PortalData
1233d1063
< PsqlScanStateData
1239a1070,1074
> PyMethodDef
> PyObject
> PySequenceMethods
> PyTypeObject
> Py_ssize_t
1256,1260d1090
< RAND_METHOD
< RC2_KEY
< RC4_KEY
< REGEXP
< RIPEMD160_CTX
1268d1097
< RSA_METHOD
1271d1099
< RUHashEntryData
1316d1143
< ResourceOwnerData
1330d1156
< RewriteStateData
1344,1348d1169
< SHA224_CTX
< SHA256_CTX
< SHA384_CTX
< SHA512_CTX
< SHA_CTX
1362,1367d1182
< SSL2_STATE
< SSL3_BUFFER
< SSL3_RECORD
< SSL3_STATE
< SSL_CIPHER
< SSL_COMP
1369,1370d1183
< SSL_METHOD
< SSL_SESSION
1373d1185
< SUBLEXINFO
1375d1186
< SVOP
1377d1187
< SaveArchivePtr
1398d1207
< SetConstraintTrigger
1404d1212
< SetOpHashEntryData
1420,1421d1227
< SigHandler
< Sighandler_t
1423d1228
< Sigsave_t
1478d1282
< SysScanDescData
1520,1537d1323
< TclStubHooks
< TclStubs
< Tcl_AppInitProc
< Tcl_AsyncHandler
< Tcl_AsyncProc
< Tcl_CallFrame
< Tcl_Channel
< Tcl_ChannelProc
< Tcl_ChannelType
< Tcl_ChannelTypeVersion
< Tcl_CloseProc
< Tcl_CmdDeleteProc
< Tcl_CmdInfo
< Tcl_CmdProc
< Tcl_CmdTraceProc
< Tcl_Command
< Tcl_Condition
< Tcl_CreateFileHandlerProc
1539,1565d1324
< Tcl_DeleteFileHandlerProc
< Tcl_DriverBlockModeProc
< Tcl_DriverClose2Proc
< Tcl_DriverCloseProc
< Tcl_DriverFlushProc
< Tcl_DriverGetHandleProc
< Tcl_DriverGetOptionProc
< Tcl_DriverHandlerProc
< Tcl_DriverInputProc
< Tcl_DriverOutputProc
< Tcl_DriverSeekProc
< Tcl_DriverSetOptionProc
< Tcl_DriverWatchProc
< Tcl_DupInternalRepProc
< Tcl_Encoding
< Tcl_EncodingConvertProc
< Tcl_EncodingFreeProc
< Tcl_EncodingState
< Tcl_EncodingType
< Tcl_EolTranslation
< Tcl_Event
< Tcl_EventCheckProc
< Tcl_EventDeleteProc
< Tcl_EventProc
< Tcl_EventSetupProc
< Tcl_ExitProc
< Tcl_FileFreeProc
1567,1568d1325
< Tcl_FreeInternalRepProc
< Tcl_FreeProc
1570d1326
< Tcl_HashSearch
1572d1327
< Tcl_IdleProc
1574,1579d1328
< Tcl_InterpDeleteProc
< Tcl_MainLoopProc
< Tcl_MathProc
< Tcl_Mutex
< Tcl_Namespace
< Tcl_NamespaceDeleteProc
1581,1600d1329
< Tcl_Obj
< Tcl_ObjCmdProc
< Tcl_ObjType
< Tcl_PackageInitProc
< Tcl_PanicProc
< Tcl_Parse
< Tcl_PathType
< Tcl_Pid
< Tcl_QueuePosition
< Tcl_RegExp
< Tcl_RegExpIndices
< Tcl_RegExpInfo
< Tcl_SavedResult
< Tcl_SetFromAnyProc
< Tcl_SetTimerProc
< Tcl_Stat_
< Tcl_TcpAcceptProc
< Tcl_ThreadCreateProc
< Tcl_ThreadDataKey
< Tcl_ThreadId
1602,1612d1330
< Tcl_TimerProc
< Tcl_TimerToken
< Tcl_Token
< Tcl_Trace
< Tcl_UniChar
< Tcl_UpdateStringProc
< Tcl_Value
< Tcl_ValueType
< Tcl_Var
< Tcl_VarTraceProc
< Tcl_WaitForEventProc
1618d1335
< Thread
1634d1350
< TrackFunctionsLevel
1659d1374
< TupleHashTableData
1680d1394
< U16
1682,1687d1395
< U8
< UI
< UI_METHOD
< UI_STRING
< UNDO_LIST
< UNOP
1699d1406
< VFunction
1741d1447
< WindowObjectData
1745d1450
< WindowStatePerFuncData
1754d1458
< WorkerInfoData
1761,1772d1464
< X509_ALGOR
< X509_ATTRIBUTE
< X509_CERT_AUX
< X509_CERT_FILE_CTX
< X509_CINF
< X509_CRL
< X509_CRL_INFO
< X509_EXTENSION
< X509_HASH_DIR_CTX
< X509_INFO
< X509_LOOKUP
< X509_LOOKUP_METHOD
1775,1782d1466
< X509_OBJECT
< X509_OBJECTS
< X509_PKEY
< X509_PUBKEY
< X509_REQ
< X509_REQ_INFO
< X509_REVOKED
< X509_SIG
1785,1786d1468
< X509_TRUST
< X509_VAL
1800,1813d1481
< XPV
< XPVAV
< XPVBM
< XPVCV
< XPVFM
< XPVGV
< XPVHV
< XPVIO
< XPVIV
< XPVLV
< XPVMG
< XPVNV
< XPVUV
< XRV
1818d1485
< XmlBinaryType
1824d1490
< XmlStandaloneType
1829,1832d1494
< _LIB_VERSION_TYPE
< _RuneEntry
< _RuneLocale
< _RuneRange
1835,1836d1496
< _ossl_old_des_cblock
< _ossl_old_des_key_schedule
1838d1497
< alloc_func
1840d1498
< assoc_list
1849d1506
< bio_info_cb
1858d1514
< caddr_t
1860d1515
< cc_t
1862,1863d1516
< char
< charf
1868d1520
< clockid_t
1869a1522
> cmpfunc
1870a1524
> coercion
1872,1875d1525
< comment_t
< conf_finish_func
< conf_init_func
< const_DES_cblock
1882,1883d1531
< cv_flags_t
< daddr_t
1888a1537
> destructor
1891,1892d1539
< div_t
< double
1894,1906d1540
< dyn_MEM_free_cb
< dyn_MEM_malloc_cb
< dyn_MEM_realloc_cb
< dyn_dynlock_create_cb
< dyn_dynlock_destroy_cb
< dyn_dynlock_lock_cb
< dyn_lock_add_lock_cb
< dyn_lock_locking_cb
< dynamic_LOCK_fns
< dynamic_MEM_fns
< dynamic_bind_engine
< dynamic_fns
< dynamic_v_check_fn
1912d1545
< expectation
1915d1547
< fd_mask
1917d1548
< filter_t
1924d1554
< fixpt_t
1926d1555
< float
1932,1936c1561
< fmStringInfo
< formarray
< formfloat
< fpos_t
< free_func
---
> freefunc
1964a1590,1594
> gss_OID
> gss_buffer_desc
> gss_cred_id_t
> gss_ctx_id_t
> gss_name_t
1965a1596
> hashfunc
1971,1972d1601
< in_addr_t
< in_port_t
1977d1605
< init_f
1978a1607
> inquiry
1980d1608
< int
1983,1984d1610
< int16_t
< int16m_t
1990d1615
< int32m_t
1994,1995d1618
< int64_t
< int64m_t
1997,1999d1619
< int8_t
< int8m_t
< intf
2003d1622
< jmp_buf
2005a1625,1632
> krb5_auth_context
> krb5_ccache
> krb5_context
> krb5_error
> krb5_error_code
> krb5_keytab
> krb5_principal
> krb5_ticket
2008d1634
< ldiv_t
2033d1658
< nlink_t
2042,2045d1666
< op_tr_array
< opcode
< opindex
< optType
2046a1668
> pam_handle_t
2048d1669
< pem_password_cb
2056a1678
> pg_gssinfo
2097,2105d1718
< pthread_attr_t
< pthread_cond_t
< pthread_condattr_t
< pthread_key_t
< pthread_mutex_t
< pthread_mutexattr_t
< pthread_once_t
< pthread_t
< ptrdiff_t
2108,2110d1720
< pvcontents
< q128_t
< qaddr_t
2112d1721
< quad_t
2116d1724
< regcomp_t
2118d1725
< regexec_t
2121d1727
< register_t
2123d1728
< regnode
2141,2143d1745
< rune_t
< runops_proc_t
< sa_family_t
2145d1746
< segsz_t
2149,2150d1749
< sig_t
< sighandler_cxt
2152d1750
< signedbitmapword
2157,2158d1754
< socklen_t
< speed_t
2165,2166d1760
< ssl_crock_st
< stack_t
2169d1762
< strconst
2173,2175d1765
< svindex
< svtype
< swblk_t
2177,2178d1766
< tcflag_t
< tcp_seq
2192,2195d1779
< uInt
< uIntf
< uLong
< uLongf
2198,2208d1781
< u_int16_t
< u_int16m_t
< u_int32_t
< u_int32m_t
< u_int64_t
< u_int64m_t
< u_int8_t
< u_int8m_t
< u_long
< u_quad_t
< u_short
2211d1783
< uint
2213a1786
> uint32_t
2216,2217c1789,1790
< unknown
< ushort
---
> uuid_rc_t
> uuid_t
2221d1793
< varattrib_1b
2223,2228d1794
< varattrib_4b
< vm_offset_t
< vm_size_t
< void
< voidp
< voidpf
2230,2231d1795
< wctype_t
< wint_t
2240d1803
< xl_dbase_create_rec_old
2242d1804
< xl_dbase_drop_rec_old
2264a1827,1838
> xmlBuffer
> xmlBufferPtr
> xmlChar
> xmlDocPtr
> xmlNodePtr
> xmlNodeSetPtr
> xmlParserCtxtPtr
> xmlTextWriter
> xmlTextWriterPtr
> xmlXPathCompExprPtr
> xmlXPathContextPtr
> xmlXPathObjectPtr
2265a1840
> xsltStylesheetPtr
2268c1843,1846
< yysigned_char
---
> yytype_int16
> yytype_int8
> yytype_uint16
> yytype_uint8
* Re: pgindent run coming
@ 2009-06-10 19:10 Greg Stark <stark@enterprisedb.com>
parent: Bruce Momjian <bruce@momjian.us>
1 sibling, 1 reply; 61+ messages in thread
From: Greg Stark @ 2009-06-10 19:10 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Andrew Dunstan <andrew@dunslane.net>; Tom Lane <tgl@sss.pgh.pa.us>; pgsql-hackers
Out of curiosity how different is the output if we don't pass the
typedef list at all? I'm wondering if the formatting differences are
things we actually care much about anyways.
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-10 19:13 Andrew Dunstan <andrew@dunslane.net>
parent: Bruce Momjian <bruce@momjian.us>
1 sibling, 1 reply; 61+ messages in thread
From: Andrew Dunstan @ 2009-06-10 19:13 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-hackers
Bruce Momjian wrote:
> I did a diff, attached, and found some typedefs that don't appear, like
> PortalData. That is defined in our code as:
>
> typedef struct PortalData *Portal;
>
> typedef struct PortalData
> {
> /* Bookkeeping data */
> ...
> bool visible; /* include this portal in pg_cursors? */
> } PortalData;
>
> I will try to build on Linux here and see how objdump displays that,
> unless you can get me the output.
>
Well, that is almost certainly a result of the change you asked me to
make :-)
The symbol is in the run done early this morning before those changes.
See
<http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=dungbeetle&dt=2009-06-10%20064401&st...;
So we need to look and see what tag that symbol has in the objdump output.
cheers
andrew
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-10 19:16 Tom Lane <tgl@sss.pgh.pa.us>
parent: Greg Stark <stark@enterprisedb.com>
0 siblings, 1 reply; 61+ messages in thread
From: Tom Lane @ 2009-06-10 19:16 UTC (permalink / raw)
To: Greg Stark <stark@enterprisedb.com>; +Cc: Bruce Momjian <bruce@momjian.us>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Greg Stark <stark@enterprisedb.com> writes:
> Out of curiosity how different is the output if we don't pass the
> typedef list at all? I'm wondering if the formatting differences are
> things we actually care much about anyways.
It tends to put extra spaces in variable declarations that are using
the typedef. Not sure about other effects, but it is kinda ugly when
you are used to it being right.
regards, tom lane
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-10 19:39 Peter Eisentraut <peter_e@gmx.net>
parent: Bruce Momjian <bruce@momjian.us>
2 siblings, 1 reply; 61+ messages in thread
From: Peter Eisentraut @ 2009-06-10 19:39 UTC (permalink / raw)
To: pgsql-hackers; +Cc: Bruce Momjian <bruce@momjian.us>
On Tuesday 09 June 2009 20:21:35 Bruce Momjian wrote:
> It is time to run pgindent on CVS HEAD for 8.4. I am thinking of
> running it at zero-hour GMT tomorrow, meaning five hours from now.
> Any objections?
Btw., can you make pgindent remove whitespace at the end of lines?
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-10 19:45 Tom Lane <tgl@sss.pgh.pa.us>
parent: Peter Eisentraut <peter_e@gmx.net>
0 siblings, 1 reply; 61+ messages in thread
From: Tom Lane @ 2009-06-10 19:45 UTC (permalink / raw)
To: Peter Eisentraut <peter_e@gmx.net>; +Cc: pgsql-hackers@postgresql.org, Bruce Momjian <bruce@momjian.us>
Peter Eisentraut <peter_e@gmx.net> writes:
> Btw., can you make pgindent remove whitespace at the end of lines?
I think it usually does that already ...
regards, tom lane
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-10 19:49 Bruce Momjian <bruce@momjian.us>
parent: Andrew Dunstan <andrew@dunslane.net>
0 siblings, 0 replies; 61+ messages in thread
From: Bruce Momjian @ 2009-06-10 19:49 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-hackers
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
> > I did a diff, attached, and found some typedefs that don't appear, like
> > PortalData. That is defined in our code as:
> >
> > typedef struct PortalData *Portal;
> >
> > typedef struct PortalData
> > {
> > /* Bookkeeping data */
> > ...
> > bool visible; /* include this portal in pg_cursors? */
> > } PortalData;
> >
> > I will try to build on Linux here and see how objdump displays that,
> > unless you can get me the output.
> >
>
>
> Well, that is almost certainly a result of the change you asked me to
> make :-)
>
> The symbol is in the run done early this morning before those changes.
> See
> <http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=dungbeetle&dt=2009-06-10%20064401&st...;
>
> So we need to look and see what tag that symbol has in the objdump output.
OK, I got the answer for Linux. I built 8.4 RC2 and ran:
objdump -W postgres |grep -3 PortalData
and the output is attached. You will notice every mention of PortalData
has 'DW_TAG_structure_type' (stucture member) above it, and none have
DW_TAG_typedef (typedef tag). This is caused by this documented
behavior from find_typedef:
# Linux
# Unfortunately the Linux version doesn't show unreferenced typedefs.
# The problem is that they are still in the source code so should be
# indented properly. However, I think pgindent only cares about
# the typedef references, not the definitions, so I think it might
# be fine
So that is why the Linux list is shorter, but again, I think that is fine.
Andrew, let me know when your list is ready.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Attachments:
/rtmp/a (text/plain, 3.9K) download
<8db7> DW_AT_byte_size : 4
<8db8> DW_AT_type : <8dbc>
<1><8dbc>: Abbrev Number: 24 (DW_TAG_structure_type)
<8dbd> DW_AT_name : PortalData
<8dc8> DW_AT_byte_size : 96
<8dc9> DW_AT_decl_file : 40
<8dca> DW_AT_decl_line : 105
--
<14706e> DW_AT_byte_size : 4
<14706f> DW_AT_type : <147073>
<1><147073>: Abbrev Number: 24 (DW_TAG_structure_type)
<147074> DW_AT_name : PortalData
<14707f> DW_AT_byte_size : 96
<147080> DW_AT_decl_file : 43
<147081> DW_AT_decl_line : 105
--
<20dd10> DW_AT_byte_size : 4
<20dd11> DW_AT_type : <20dd15>
<1><20dd15>: Abbrev Number: 17 (DW_TAG_structure_type)
<20dd16> DW_AT_name : PortalData
<20dd21> DW_AT_byte_size : 96
<20dd22> DW_AT_decl_file : 46
<20dd23> DW_AT_decl_line : 105
--
<2144bc> DW_AT_byte_size : 4
<2144bd> DW_AT_type : <2144c1>
<1><2144c1>: Abbrev Number: 16 (DW_TAG_structure_type)
<2144c2> DW_AT_name : PortalData
<2144cd> DW_AT_byte_size : 96
<2144ce> DW_AT_decl_file : 46
<2144cf> DW_AT_decl_line : 105
--
<273c96> DW_AT_byte_size : 4
<273c97> DW_AT_type : <273c9b>
<1><273c9b>: Abbrev Number: 19 (DW_TAG_structure_type)
<273c9c> DW_AT_name : PortalData
<273ca7> DW_AT_byte_size : 96
<273ca8> DW_AT_decl_file : 40
<273ca9> DW_AT_decl_line : 105
--
<348c3f> DW_AT_byte_size : 4
<348c40> DW_AT_type : <348c44>
<1><348c44>: Abbrev Number: 20 (DW_TAG_structure_type)
<348c45> DW_AT_name : PortalData
<348c50> DW_AT_byte_size : 96
<348c51> DW_AT_decl_file : 42
<348c52> DW_AT_decl_line : 105
--
<4b0f00> DW_AT_byte_size : 4
<4b0f01> DW_AT_type : <4b0f05>
<1><4b0f05>: Abbrev Number: 7 (DW_TAG_structure_type)
<4b0f06> DW_AT_name : PortalData
<4b0f11> DW_AT_byte_size : 96
<4b0f12> DW_AT_decl_file : 57
<4b0f13> DW_AT_decl_line : 105
--
<4b9974> DW_AT_byte_size : 4
<4b9975> DW_AT_type : <4b9979>
<1><4b9979>: Abbrev Number: 17 (DW_TAG_structure_type)
<4b997a> DW_AT_name : PortalData
<4b9985> DW_AT_byte_size : 96
<4b9986> DW_AT_decl_file : 47
<4b9987> DW_AT_decl_line : 105
--
<4c28e3> DW_AT_byte_size : 4
<4c28e4> DW_AT_type : <4c28e8>
<1><4c28e8>: Abbrev Number: 22 (DW_TAG_structure_type)
<4c28e9> DW_AT_name : PortalData
<4c28f4> DW_AT_byte_size : 96
<4c28f5> DW_AT_decl_file : 42
<4c28f6> DW_AT_decl_line : 105
--
<5d8c98> DW_AT_byte_size : 4
<5d8c99> DW_AT_type : <5d8c9d>
<1><5d8c9d>: Abbrev Number: 26 (DW_TAG_structure_type)
<5d8c9e> DW_AT_name : PortalData
<5d8ca9> DW_AT_byte_size : 96
<5d8caa> DW_AT_decl_file : 39
<5d8cab> DW_AT_decl_line : 105
--
<5e42f0> DW_AT_byte_size : 4
<5e42f1> DW_AT_type : <5e42f5>
<1><5e42f5>: Abbrev Number: 26 (DW_TAG_structure_type)
<5e42f6> DW_AT_name : PortalData
<5e4301> DW_AT_byte_size : 96
<5e4302> DW_AT_decl_file : 40
<5e4303> DW_AT_decl_line : 105
--
<5f681d> DW_AT_byte_size : 4
<5f681e> DW_AT_type : <5f6822>
<1><5f6822>: Abbrev Number: 17 (DW_TAG_structure_type)
<5f6823> DW_AT_name : PortalData
<5f682e> DW_AT_byte_size : 96
<5f682f> DW_AT_decl_file : 45
<5f6830> DW_AT_decl_line : 105
--
<668927> DW_AT_byte_size : 4
<668928> DW_AT_type : <66892c>
<1><66892c>: Abbrev Number: 16 (DW_TAG_structure_type)
<66892d> DW_AT_name : PortalData
<668938> DW_AT_byte_size : 96
<668939> DW_AT_decl_file : 43
<66893a> DW_AT_decl_line : 105
* Re: pgindent run coming
@ 2009-06-10 19:50 Bruce Momjian <bruce@momjian.us>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 61+ messages in thread
From: Bruce Momjian @ 2009-06-10 19:50 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Peter Eisentraut <peter_e@gmx.net>; pgsql-hackers
Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Btw., can you make pgindent remove whitespace at the end of lines?
>
> I think it usually does that already ...
Yes.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-10 19:54 Bruce Momjian <bruce@momjian.us>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 61+ messages in thread
From: Bruce Momjian @ 2009-06-10 19:54 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Greg Stark <stark@enterprisedb.com>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Tom Lane wrote:
> Greg Stark <stark@enterprisedb.com> writes:
> > Out of curiosity how different is the output if we don't pass the
> > typedef list at all? I'm wondering if the formatting differences are
> > things we actually care much about anyways.
>
> It tends to put extra spaces in variable declarations that are using
> the typedef. Not sure about other effects, but it is kinda ugly when
> you are used to it being right.
Yea, I used a short pgindent typedef list once and people noticed right
away so I had to rerun.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-10 20:44 Peter Eisentraut <peter_e@gmx.net>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 61+ messages in thread
From: Peter Eisentraut @ 2009-06-10 20:44 UTC (permalink / raw)
To: pgsql-hackers; +Cc: Bruce Momjian <bruce@momjian.us>; Tom Lane <tgl@sss.pgh.pa.us>
On Wednesday 10 June 2009 22:50:15 Bruce Momjian wrote:
> Tom Lane wrote:
> > Peter Eisentraut <peter_e@gmx.net> writes:
> > > Btw., can you make pgindent remove whitespace at the end of lines?
> >
> > I think it usually does that already ...
>
> Yes.
Um, attached you will find a bunch of counterexamples.
Attachments:
whitespace.diff (text/x-patch, 53.0K) download
Index: src/bin/initdb/initdb.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/initdb/initdb.c,v
retrieving revision 1.171
diff -u -3 -p -r1.171 initdb.c
--- src/bin/initdb/initdb.c 3 Jun 2009 16:17:49 -0000 1.171
+++ src/bin/initdb/initdb.c 10 Jun 2009 20:42:32 -0000
@@ -1356,9 +1356,9 @@ bootstrap_template1(char *short_version)
bki_lines = replace_token(bki_lines, "ENCODING", encodingid);
bki_lines = replace_token(bki_lines, "LC_COLLATE", lc_collate);
-
+
bki_lines = replace_token(bki_lines, "LC_CTYPE", lc_ctype);
-
+
/*
* Pass correct LC_xxx environment to bootstrap.
*
Index: src/bin/pg_ctl/pg_ctl.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/pg_ctl/pg_ctl.c,v
retrieving revision 1.110
diff -u -3 -p -r1.110 pg_ctl.c
--- src/bin/pg_ctl/pg_ctl.c 5 Apr 2009 04:19:58 -0000 1.110
+++ src/bin/pg_ctl/pg_ctl.c 10 Jun 2009 20:42:32 -0000
@@ -1486,9 +1486,9 @@ CreateRestrictedProcess(char *cmd, PROCE
}
#ifndef __CYGWIN__
- AddUserToDacl(processInfo->hProcess);
+ AddUserToDacl(processInfo->hProcess);
#endif
-
+
CloseHandle(restrictedToken);
ResumeThread(processInfo->hThread);
Index: src/bin/pg_dump/dumputils.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/pg_dump/dumputils.c,v
retrieving revision 1.45
diff -u -3 -p -r1.45 dumputils.c
--- src/bin/pg_dump/dumputils.c 11 Mar 2009 03:33:29 -0000 1.45
+++ src/bin/pg_dump/dumputils.c 10 Jun 2009 20:42:33 -0000
@@ -59,7 +59,7 @@ init_parallel_dump_utils(void)
const char *
fmtId(const char *rawid)
{
- /*
+ /*
* The Tls code goes awry if we use a static var, so we provide for both
* static and auto, and omit any use of the static var when using Tls.
*/
@@ -87,7 +87,7 @@ fmtId(const char *rawid)
{
/* new buffer */
id_return = createPQExpBuffer();
-#ifdef WIN32
+#ifdef WIN32
if (parallel_init_done)
TlsSetValue(tls_index,id_return);
else
@@ -95,7 +95,7 @@ fmtId(const char *rawid)
#else
s_id_return = id_return;
#endif
-
+
}
/*
Index: src/bin/pg_dump/keywords.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/pg_dump/keywords.c,v
retrieving revision 1.2
diff -u -3 -p -r1.2 keywords.c
--- src/bin/pg_dump/keywords.c 8 Mar 2009 16:53:30 -0000 1.2
+++ src/bin/pg_dump/keywords.c 10 Jun 2009 20:42:33 -0000
@@ -18,7 +18,7 @@
#include "parser/keywords.h"
/*
- * We don't need the token number, so leave it out to avoid requiring other
+ * We don't need the token number, so leave it out to avoid requiring other
* backend headers.
*/
#define PG_KEYWORD(a,b,c) {a,0,c},
Index: src/bin/pg_dump/pg_backup_archiver.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/pg_dump/pg_backup_archiver.c,v
retrieving revision 1.171
diff -u -3 -p -r1.171 pg_backup_archiver.c
--- src/bin/pg_dump/pg_backup_archiver.c 4 Jun 2009 19:16:48 -0000 1.171
+++ src/bin/pg_dump/pg_backup_archiver.c 10 Jun 2009 20:42:33 -0000
@@ -3487,12 +3487,12 @@ parallel_restore(RestoreArgs *args)
/*
* Close and reopen the input file so we have a private file pointer
- * that doesn't stomp on anyone else's file pointer, if we're actually
+ * that doesn't stomp on anyone else's file pointer, if we're actually
* going to need to read from the file. Otherwise, just close it
* except on Windows, where it will possibly be needed by other threads.
*
* Note: on Windows, since we are using threads not processes, the
- * reopen call *doesn't* close the original file pointer but just open
+ * reopen call *doesn't* close the original file pointer but just open
* a new one.
*/
if (te->section == SECTION_DATA )
@@ -3870,7 +3870,7 @@ CloneArchive(ArchiveHandle *AH)
ArchiveHandle *clone;
/* Make a "flat" copy */
- clone = (ArchiveHandle *) malloc(sizeof(ArchiveHandle));
+ clone = (ArchiveHandle *) malloc(sizeof(ArchiveHandle));
if (clone == NULL)
die_horribly(AH, modulename, "out of memory\n");
memcpy(clone, AH, sizeof(ArchiveHandle));
Index: src/bin/pg_dump/pg_backup_custom.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/pg_dump/pg_backup_custom.c,v
retrieving revision 1.41
diff -u -3 -p -r1.41 pg_backup_custom.c
--- src/bin/pg_dump/pg_backup_custom.c 2 Feb 2009 20:07:37 -0000 1.41
+++ src/bin/pg_dump/pg_backup_custom.c 10 Jun 2009 20:42:33 -0000
@@ -133,8 +133,8 @@ InitArchiveFmt_Custom(ArchiveHandle *AH)
AH->StartBlobPtr = _StartBlob;
AH->EndBlobPtr = _EndBlob;
AH->EndBlobsPtr = _EndBlobs;
- AH->ClonePtr = _Clone;
- AH->DeClonePtr = _DeClone;
+ AH->ClonePtr = _Clone;
+ AH->DeClonePtr = _DeClone;
/*
* Set up some special context used in compressing data.
@@ -842,7 +842,7 @@ _CloseArchive(ArchiveHandle *AH)
* is because on Windows, this is used within a multithreading context,
* and we don't want a thread closing the parent file handle.)
*/
-static void
+static void
_ReopenArchive(ArchiveHandle *AH)
{
lclContext *ctx = (lclContext *) AH->formatData;
@@ -858,12 +858,12 @@ _ReopenArchive(ArchiveHandle *AH)
errno = 0;
tpos = ftello(AH->FH);
if (errno)
- die_horribly(AH, modulename, "could not determine seek position in archive file: %s\n",
+ die_horribly(AH, modulename, "could not determine seek position in archive file: %s\n",
strerror(errno));
#ifndef WIN32
if (fclose(AH->FH) != 0)
- die_horribly(AH, modulename, "could not close archive file: %s\n",
+ die_horribly(AH, modulename, "could not close archive file: %s\n",
strerror(errno));
#endif
@@ -873,7 +873,7 @@ _ReopenArchive(ArchiveHandle *AH)
AH->fSpec, strerror(errno));
if (fseeko(AH->FH, tpos, SEEK_SET) != 0)
- die_horribly(AH, modulename, "could not set seek position in archive file: %s\n",
+ die_horribly(AH, modulename, "could not set seek position in archive file: %s\n",
strerror(errno));
}
@@ -1096,7 +1096,7 @@ static void
_DeClone(ArchiveHandle *AH)
{
lclContext *ctx = (lclContext *) AH->formatData;
-
+
free(ctx->zlibOut);
free(ctx->zlibIn);
free(ctx->zp);
Index: src/bin/pg_dump/pg_dump.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/pg_dump/pg_dump.c,v
retrieving revision 1.538
diff -u -3 -p -r1.538 pg_dump.c
--- src/bin/pg_dump/pg_dump.c 27 May 2009 20:42:29 -0000 1.538
+++ src/bin/pg_dump/pg_dump.c 10 Jun 2009 20:42:34 -0000
@@ -1739,7 +1739,7 @@ dumpDatabase(Archive *AH)
appendStringLiteralAH(creaQry, datname, AH);
appendPQExpBuffer(creaQry, ";\n");
}
-
+
appendPQExpBuffer(delQry, "DROP DATABASE %s;\n",
fmtId(datname));
@@ -4815,7 +4815,7 @@ getTableAttrs(TableInfo *tblinfo, int nu
tbinfo->atttypnames[j] = strdup("TEXT");
}
}
-
+
/*
* Get info about column defaults
*/
@@ -9940,7 +9940,7 @@ dumpTableSchema(Archive *fout, TableInfo
"(SELECT oid FROM pg_namespace "
"WHERE nspname = CURRENT_SCHEMA);\n");
}
-
+
/* Loop dumping statistics and storage statements */
for (j = 0; j < tbinfo->numatts; j++)
{
Index: src/bin/pg_dump/pg_dumpall.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/pg_dump/pg_dumpall.c,v
retrieving revision 1.125
diff -u -3 -p -r1.125 pg_dumpall.c
--- src/bin/pg_dump/pg_dumpall.c 10 May 2009 02:51:44 -0000 1.125
+++ src/bin/pg_dump/pg_dumpall.c 10 Jun 2009 20:42:35 -0000
@@ -279,7 +279,7 @@ main(int argc, char *argv[])
disable_dollar_quoting = 1;
else if (strcmp(optarg, "disable-triggers") == 0)
disable_triggers = 1;
- else if (strcmp(optarg, "no-tablespaces") == 0)
+ else if (strcmp(optarg, "no-tablespaces") == 0)
no_tablespaces = 1;
else if (strcmp(optarg, "use-set-session-authorization") == 0)
use_setsessauth = 1;
Index: src/bin/pg_dump/pg_restore.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/pg_dump/pg_restore.c,v
retrieving revision 1.99
diff -u -3 -p -r1.99 pg_restore.c
--- src/bin/pg_dump/pg_restore.c 14 Apr 2009 00:06:35 -0000 1.99
+++ src/bin/pg_dump/pg_restore.c 10 Jun 2009 20:42:35 -0000
@@ -278,9 +278,9 @@ main(int argc, char **argv)
break;
case 0:
- /*
- * This covers the long options without a short equivalent,
- * including those equivalent to -X xxx.
+ /*
+ * This covers the long options without a short equivalent,
+ * including those equivalent to -X xxx.
*/
break;
Index: src/bin/psql/command.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/psql/command.c,v
retrieving revision 1.205
diff -u -3 -p -r1.205 command.c
--- src/bin/psql/command.c 21 Apr 2009 15:49:06 -0000 1.205
+++ src/bin/psql/command.c 10 Jun 2009 20:42:35 -0000
@@ -1341,7 +1341,7 @@ connection_warnings(void)
server_version = server_ver_str;
}
- printf(_("%s (%s, server %s)\n"),
+ printf(_("%s (%s, server %s)\n"),
pset.progname, PG_VERSION, server_version);
}
else
Index: src/bin/psql/describe.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/psql/describe.c,v
retrieving revision 1.214
diff -u -3 -p -r1.214 describe.c
--- src/bin/psql/describe.c 4 Jun 2009 19:17:39 -0000 1.214
+++ src/bin/psql/describe.c 10 Jun 2009 20:42:35 -0000
@@ -811,7 +811,7 @@ objectDescription(const char *pattern, b
if (!showSystem && !pattern)
appendPQExpBuffer(&buf, "WHERE n.nspname <> 'pg_catalog'\n"
" AND n.nspname <> 'information_schema'\n");
-
+
processSQLNamePattern(pset.db, &buf, pattern, !showSystem && !pattern, false,
"n.nspname", "o.oprname", NULL,
"pg_catalog.pg_operator_is_visible(o.oid)");
@@ -1123,7 +1123,7 @@ describeOneTableDetails(const char *sche
atooid(PQgetvalue(res, 0, 7)) : 0;
PQclear(res);
res = NULL;
-
+
/*
* If it's a sequence, fetch its values and store into an
* array that will be used later.
@@ -1131,7 +1131,7 @@ describeOneTableDetails(const char *sche
if (tableinfo.relkind == 'S')
{
PGresult *result;
-
+
#define SEQ_NUM_COLS 10
printfPQExpBuffer(&buf,
"SELECT sequence_name, last_value,\n"
@@ -1142,16 +1142,16 @@ describeOneTableDetails(const char *sche
fmtId(schemaname));
/* must be separate because fmtId isn't reentrant */
appendPQExpBuffer(&buf, ".%s", fmtId(relationname));
-
+
result = PSQLexec(buf.data, false);
if (!result)
goto error_return;
-
+
seq_values = pg_malloc_zero((SEQ_NUM_COLS+1) * sizeof(*seq_values));
-
- for (i = 0; i < SEQ_NUM_COLS; i++)
+
+ for (i = 0; i < SEQ_NUM_COLS; i++)
seq_values[i] = pg_strdup(PQgetvalue(result, 0, i));
-
+
PQclear(result);
}
@@ -1230,13 +1230,13 @@ describeOneTableDetails(const char *sche
if (tableinfo.relkind == 'S')
headers[cols++] = gettext_noop("Value");
-
+
if (verbose)
{
headers[cols++] = gettext_noop("Storage");
headers[cols++] = gettext_noop("Description");
}
-
+
printTableInit(&cont, &myopt, title.data, cols, numrows);
printTableInitialized = true;
@@ -1851,14 +1851,14 @@ error_return:
termPQExpBuffer(&buf);
termPQExpBuffer(&title);
termPQExpBuffer(&tmpbuf);
-
+
if (seq_values)
{
for (ptr = seq_values; *ptr; ptr++)
free(*ptr);
free(seq_values);
}
-
+
if (modifiers)
{
for (ptr = modifiers; *ptr; ptr++)
Index: src/bin/psql/print.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/psql/print.c,v
retrieving revision 1.114
diff -u -3 -p -r1.114 print.c
--- src/bin/psql/print.c 4 Jun 2009 19:17:39 -0000 1.114
+++ src/bin/psql/print.c 10 Jun 2009 20:42:36 -0000
@@ -520,7 +520,7 @@ print_aligned_text(const printTableConte
if (col_count != 0 && cell_count != 0)
{
int rows = cell_count / col_count;
-
+
for (i = 0; i < col_count; i++)
width_average[i] /= rows;
}
@@ -640,7 +640,7 @@ print_aligned_text(const printTableConte
fout = PageOutput(INT_MAX, cont->opt->pager); /* force pager */
is_pager = true;
}
-
+
/* Check if newlines or our wrapping now need the pager */
if (!is_pager)
{
@@ -650,12 +650,12 @@ print_aligned_text(const printTableConte
int width,
nl_lines,
bytes_required;
-
+
pg_wcssize((unsigned char *) *ptr, strlen(*ptr), encoding,
&width, &nl_lines, &bytes_required);
if (opt_numeric_locale && cont->align[i] == 'r')
width += additional_numeric_locale_len(*ptr);
-
+
/*
* A row can have both wrapping and newlines that cause
* it to display across multiple lines. We check
@@ -681,7 +681,7 @@ print_aligned_text(const printTableConte
}
IsPagerNeeded(cont, extra_output_lines, &fout, &is_pager);
}
-
+
/* time to output */
if (cont->opt->start_table)
{
@@ -2208,7 +2208,7 @@ void
printTable(const printTableContent *cont, FILE *fout, FILE *flog)
{
bool is_pager = false;
-
+
if (cancel_pressed)
return;
@@ -2412,11 +2412,11 @@ strlen_max_width(unsigned char *str, int
break;
curr_width += char_width;
-
+
str += PQmblen((char *) str, encoding);
}
*target_width = curr_width;
-
+
return str - start;
}
Index: src/bin/psql/print.h
===================================================================
RCS file: /cvsroot/pgsql/src/bin/psql/print.h,v
retrieving revision 1.39
diff -u -3 -p -r1.39 print.h
--- src/bin/psql/print.h 1 Jan 2009 17:23:55 -0000 1.39
+++ src/bin/psql/print.h 10 Jun 2009 20:42:36 -0000
@@ -103,13 +103,13 @@ extern void html_escaped_print(const cha
extern void printTableInit(printTableContent *const content,
const printTableOpt *opt, const char *title,
const int ncolumns, const int nrows);
-extern void printTableAddHeader(printTableContent *const content,
+extern void printTableAddHeader(printTableContent *const content,
const char *header, const bool translate, const char align);
-extern void printTableAddCell(printTableContent *const content,
+extern void printTableAddCell(printTableContent *const content,
const char *cell, const bool translate);
-extern void printTableAddFooter(printTableContent *const content,
+extern void printTableAddFooter(printTableContent *const content,
const char *footer);
-extern void printTableSetFooter(printTableContent *const content,
+extern void printTableSetFooter(printTableContent *const content,
const char *footer);
extern void printTableCleanup(printTableContent *const content);
extern void printTable(const printTableContent *cont, FILE *fout, FILE *flog);
Index: src/include/c.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/c.h,v
retrieving revision 1.235
diff -u -3 -p -r1.235 c.h
--- src/include/c.h 26 Mar 2009 22:26:07 -0000 1.235
+++ src/include/c.h 10 Jun 2009 20:42:36 -0000
@@ -842,7 +842,7 @@ extern int fdatasync(int fildes);
#if defined(HAVE_WCSTOMBS) && defined(HAVE_TOWLOWER)
#define USE_WIDE_UPPER_LOWER
#endif
-
+
/* EXEC_BACKEND defines */
#ifdef EXEC_BACKEND
#define NON_EXEC_STATIC
Index: src/include/miscadmin.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/miscadmin.h,v
retrieving revision 1.210
diff -u -3 -p -r1.210 miscadmin.h
--- src/include/miscadmin.h 5 May 2009 19:59:00 -0000 1.210
+++ src/include/miscadmin.h 10 Jun 2009 20:42:36 -0000
@@ -192,7 +192,7 @@ extern PGDLLIMPORT Oid MyDatabaseTableSp
extern int DateStyle;
extern int DateOrder;
-
+
/*
* IntervalStyles
* INTSTYLE_POSTGRES Like Postgres < 8.4 when DateStyle = 'iso'
Index: src/include/port.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/port.h,v
retrieving revision 1.124
diff -u -3 -p -r1.124 port.h
--- src/include/port.h 7 Jan 2009 03:39:33 -0000 1.124
+++ src/include/port.h 10 Jun 2009 20:42:36 -0000
@@ -281,7 +281,7 @@ extern void copydir(char *fromdir, char
extern bool rmtree(const char *path, bool rmtopdir);
-/*
+/*
* stat() is not guaranteed to set the st_size field on win32, so we
* redefine it to our own implementation that is.
*
Index: src/include/access/clog.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/access/clog.h,v
retrieving revision 1.23
diff -u -3 -p -r1.23 clog.h
--- src/include/access/clog.h 1 Jan 2009 17:23:55 -0000 1.23
+++ src/include/access/clog.h 10 Jun 2009 20:42:36 -0000
@@ -32,7 +32,7 @@ typedef int XidStatus;
#define NUM_CLOG_BUFFERS 8
-extern void TransactionIdSetTreeStatus(TransactionId xid, int nsubxids,
+extern void TransactionIdSetTreeStatus(TransactionId xid, int nsubxids,
TransactionId *subxids, XidStatus status, XLogRecPtr lsn);
extern XidStatus TransactionIdGetStatus(TransactionId xid, XLogRecPtr *lsn);
Index: src/include/access/nbtree.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/access/nbtree.h,v
retrieving revision 1.123
diff -u -3 -p -r1.123 nbtree.h
--- src/include/access/nbtree.h 1 Jan 2009 17:23:56 -0000 1.123
+++ src/include/access/nbtree.h 10 Jun 2009 20:42:36 -0000
@@ -287,7 +287,7 @@ typedef struct xl_btree_split
* than BlockNumber for alignment reasons: SizeOfBtreeSplit is only 16-bit
* aligned.)
*
- * If level > 0, an IndexTuple representing the HIKEY of the left page
+ * If level > 0, an IndexTuple representing the HIKEY of the left page
* follows. We don't need this on leaf pages, because it's the same
* as the leftmost key in the new right page. Also, it's suppressed if
* XLogInsert chooses to store the left page's whole page image.
Index: src/include/catalog/genbki.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/catalog/genbki.h,v
retrieving revision 1.2
diff -u -3 -p -r1.2 genbki.h
--- src/include/catalog/genbki.h 1 Jan 2009 17:23:56 -0000 1.2
+++ src/include/catalog/genbki.h 10 Jun 2009 20:42:36 -0000
@@ -16,7 +16,7 @@
*
*-------------------------------------------------------------------------
*/
-#ifndef GENBKI_H
+#ifndef GENBKI_H
#define GENBKI_H
/* Introduces a catalog's structure definition */
Index: src/include/commands/comment.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/commands/comment.h,v
retrieving revision 1.23
diff -u -3 -p -r1.23 comment.h
--- src/include/commands/comment.h 1 Jan 2009 17:23:58 -0000 1.23
+++ src/include/commands/comment.h 10 Jun 2009 20:42:36 -0000
@@ -1,5 +1,5 @@
/*
- * $PostgreSQL: pgsql/src/include/commands/comment.h,v 1.23 2009/01/01 17:23:58 momjian Exp $
+ * $PostgreSQL: pgsql/src/include/commands/comment.h,v 1.23 2009/01/01 17:23:58 momjian Exp $
*
*-------------------------------------------------------------------------
*
Index: src/include/commands/proclang.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/commands/proclang.h,v
retrieving revision 1.14
diff -u -3 -p -r1.14 proclang.h
--- src/include/commands/proclang.h 17 May 2008 01:28:24 -0000 1.14
+++ src/include/commands/proclang.h 10 Jun 2009 20:42:36 -0000
@@ -1,5 +1,5 @@
/*
- * $PostgreSQL: pgsql/src/include/commands/proclang.h,v 1.14 2008/05/17 01:28:24 adunstan Exp $
+ * $PostgreSQL: pgsql/src/include/commands/proclang.h,v 1.14 2008/05/17 01:28:24 adunstan Exp $
*
*-------------------------------------------------------------------------
*
Index: src/include/commands/trigger.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/commands/trigger.h,v
retrieving revision 1.72
diff -u -3 -p -r1.72 trigger.h
--- src/include/commands/trigger.h 22 Jan 2009 20:16:09 -0000 1.72
+++ src/include/commands/trigger.h 10 Jun 2009 20:42:36 -0000
@@ -39,7 +39,7 @@ typedef struct TriggerData
} TriggerData;
/*
- * TriggerEvent bit flags
+ * TriggerEvent bit flags
*
* Note that we assume different event types (INSERT/DELETE/UPDATE/TRUNCATE)
* can't be OR'd together in a single TriggerEvent. This is unlike the
Index: src/include/libpq/hba.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/libpq/hba.h,v
retrieving revision 1.55
diff -u -3 -p -r1.55 hba.h
--- src/include/libpq/hba.h 7 Jan 2009 13:09:21 -0000 1.55
+++ src/include/libpq/hba.h 10 Jun 2009 20:42:36 -0000
@@ -38,7 +38,7 @@ typedef enum ConnType
ctHostNoSSL
} ConnType;
-typedef struct
+typedef struct
{
int linenumber;
ConnType conntype;
Index: src/include/nodes/execnodes.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/nodes/execnodes.h,v
retrieving revision 1.204
diff -u -3 -p -r1.204 execnodes.h
--- src/include/nodes/execnodes.h 8 Apr 2009 21:51:38 -0000 1.204
+++ src/include/nodes/execnodes.h 10 Jun 2009 20:42:36 -0000
@@ -18,8 +18,8 @@
#include "access/heapam.h"
#include "access/skey.h"
#include "nodes/params.h"
-#include "nodes/plannodes.h"
-#include "nodes/tidbitmap.h"
+#include "nodes/plannodes.h"
+#include "nodes/tidbitmap.h"
#include "utils/hsearch.h"
#include "utils/rel.h"
#include "utils/snapshot.h"
Index: src/include/port/aix.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/port/aix.h,v
retrieving revision 1.12
diff -u -3 -p -r1.12 aix.h
--- src/include/port/aix.h 17 May 2008 01:28:24 -0000 1.12
+++ src/include/port/aix.h 10 Jun 2009 20:42:36 -0000
@@ -1,5 +1,5 @@
/*
- * $PostgreSQL: pgsql/src/include/port/aix.h,v 1.12 2008/05/17 01:28:24 adunstan Exp $
+ * $PostgreSQL: pgsql/src/include/port/aix.h,v 1.12 2008/05/17 01:28:24 adunstan Exp $
*/
#define CLASS_CONFLICT
#define DISABLE_XOPEN_NLS
Index: src/include/port/bsdi.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/port/bsdi.h,v
retrieving revision 1.14
diff -u -3 -p -r1.14 bsdi.h
--- src/include/port/bsdi.h 17 May 2008 01:28:24 -0000 1.14
+++ src/include/port/bsdi.h 10 Jun 2009 20:42:36 -0000
@@ -1,4 +1,4 @@
/*
- * $PostgreSQL: pgsql/src/include/port/bsdi.h,v 1.14 2008/05/17 01:28:24 adunstan Exp $
+ * $PostgreSQL: pgsql/src/include/port/bsdi.h,v 1.14 2008/05/17 01:28:24 adunstan Exp $
*/
Index: src/include/port/sco.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/port/sco.h,v
retrieving revision 1.18
diff -u -3 -p -r1.18 sco.h
--- src/include/port/sco.h 17 May 2008 01:28:24 -0000 1.18
+++ src/include/port/sco.h 10 Jun 2009 20:42:36 -0000
@@ -1,5 +1,5 @@
/*
- * $PostgreSQL: pgsql/src/include/port/sco.h,v 1.18 2008/05/17 01:28:24 adunstan Exp $
+ * $PostgreSQL: pgsql/src/include/port/sco.h,v 1.18 2008/05/17 01:28:24 adunstan Exp $
*
* see src/backend/libpq/pqcomm.c */
#define SCO_ACCEPT_BUG
Index: src/include/port/sunos4.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/port/sunos4.h,v
retrieving revision 1.11
diff -u -3 -p -r1.11 sunos4.h
--- src/include/port/sunos4.h 11 Dec 2008 09:17:07 -0000 1.11
+++ src/include/port/sunos4.h 10 Jun 2009 20:42:36 -0000
@@ -1,5 +1,5 @@
/*
- * $PostgreSQL: pgsql/src/include/port/sunos4.h,v 1.11 2008/12/11 09:17:07 petere Exp $
+ * $PostgreSQL: pgsql/src/include/port/sunos4.h,v 1.11 2008/12/11 09:17:07 petere Exp $
*
* sprintf() returns char *, not int, on SunOS 4.1.x */
#define SPRINTF_CHAR
Index: src/include/port/ultrix4.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/port/ultrix4.h,v
retrieving revision 1.12
diff -u -3 -p -r1.12 ultrix4.h
--- src/include/port/ultrix4.h 17 May 2008 01:28:24 -0000 1.12
+++ src/include/port/ultrix4.h 10 Jun 2009 20:42:36 -0000
@@ -1,5 +1,5 @@
/*
- * $PostgreSQL: pgsql/src/include/port/ultrix4.h,v 1.12 2008/05/17 01:28:24 adunstan Exp $
+ * $PostgreSQL: pgsql/src/include/port/ultrix4.h,v 1.12 2008/05/17 01:28:24 adunstan Exp $
*/
#define NOFIXADE
#define NEED_STRDUP
Index: src/include/port/univel.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/port/univel.h,v
retrieving revision 1.24
diff -u -3 -p -r1.24 univel.h
--- src/include/port/univel.h 17 May 2008 01:28:24 -0000 1.24
+++ src/include/port/univel.h 10 Jun 2009 20:42:36 -0000
@@ -1,5 +1,5 @@
/*
- * $PostgreSQL: pgsql/src/include/port/univel.h,v 1.24 2008/05/17 01:28:24 adunstan Exp $
+ * $PostgreSQL: pgsql/src/include/port/univel.h,v 1.24 2008/05/17 01:28:24 adunstan Exp $
*
***************************************
* Define this if you are compiling with
Index: src/include/port/unixware.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/port/unixware.h,v
retrieving revision 1.18
diff -u -3 -p -r1.18 unixware.h
--- src/include/port/unixware.h 17 May 2008 01:28:24 -0000 1.18
+++ src/include/port/unixware.h 10 Jun 2009 20:42:36 -0000
@@ -1,5 +1,5 @@
/*
- * $PostgreSQL: pgsql/src/include/port/unixware.h,v 1.18 2008/05/17 01:28:24 adunstan Exp $
+ * $PostgreSQL: pgsql/src/include/port/unixware.h,v 1.18 2008/05/17 01:28:24 adunstan Exp $
*
* see src/backend/libpq/pqcomm.c */
#define SCO_ACCEPT_BUG
Index: src/include/port/win32/pwd.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/port/win32/pwd.h,v
retrieving revision 1.3
diff -u -3 -p -r1.3 pwd.h
--- src/include/port/win32/pwd.h 17 May 2008 01:28:25 -0000 1.3
+++ src/include/port/win32/pwd.h 10 Jun 2009 20:42:36 -0000
@@ -1,4 +1,4 @@
/*
- * $PostgreSQL: pgsql/src/include/port/win32/pwd.h,v 1.3 2008/05/17 01:28:25 adunstan Exp $
+ * $PostgreSQL: pgsql/src/include/port/win32/pwd.h,v 1.3 2008/05/17 01:28:25 adunstan Exp $
*/
Index: src/include/port/win32/sys/wait.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/port/win32/sys/wait.h,v
retrieving revision 1.3
diff -u -3 -p -r1.3 wait.h
--- src/include/port/win32/sys/wait.h 17 May 2008 01:28:25 -0000 1.3
+++ src/include/port/win32/sys/wait.h 10 Jun 2009 20:42:37 -0000
@@ -1,4 +1,4 @@
/*
- * $PostgreSQL: pgsql/src/include/port/win32/sys/wait.h,v 1.3 2008/05/17 01:28:25 adunstan Exp $
+ * $PostgreSQL: pgsql/src/include/port/win32/sys/wait.h,v 1.3 2008/05/17 01:28:25 adunstan Exp $
*/
Index: src/include/storage/bufmgr.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/storage/bufmgr.h,v
retrieving revision 1.120
diff -u -3 -p -r1.120 bufmgr.h
--- src/include/storage/bufmgr.h 12 Jan 2009 05:10:45 -0000 1.120
+++ src/include/storage/bufmgr.h 10 Jun 2009 20:42:37 -0000
@@ -189,7 +189,7 @@ extern void DropDatabaseBuffers(Oid dbid
extern void PrintPinnedBufs(void);
#endif
extern Size BufferShmemSize(void);
-extern void BufferGetTag(Buffer buffer, RelFileNode *rnode,
+extern void BufferGetTag(Buffer buffer, RelFileNode *rnode,
ForkNumber *forknum, BlockNumber *blknum);
extern void SetBufferCommitInfoNeedsSave(Buffer buffer);
Index: src/include/storage/s_lock.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/storage/s_lock.h,v
retrieving revision 1.166
diff -u -3 -p -r1.166 s_lock.h
--- src/include/storage/s_lock.h 1 Jan 2009 17:24:01 -0000 1.166
+++ src/include/storage/s_lock.h 10 Jun 2009 20:42:37 -0000
@@ -815,7 +815,7 @@ spin_delay(void)
#endif
-
+
#endif /* !defined(HAS_TEST_AND_SET) */
Index: src/include/storage/sinvaladt.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/storage/sinvaladt.h,v
retrieving revision 1.50
diff -u -3 -p -r1.50 sinvaladt.h
--- src/include/storage/sinvaladt.h 1 Jan 2009 17:24:01 -0000 1.50
+++ src/include/storage/sinvaladt.h 10 Jun 2009 20:42:37 -0000
@@ -8,7 +8,7 @@
* must be delivered to all already-running backends before it can be
* forgotten. (If we run out of space, we instead deliver a "RESET"
* message to backends that have fallen too far behind.)
- *
+ *
* The struct type SharedInvalidationMessage, defining the contents of
* a single message, is defined in sinval.h.
*
Index: src/include/storage/smgr.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/storage/smgr.h,v
retrieving revision 1.66
diff -u -3 -p -r1.66 smgr.h
--- src/include/storage/smgr.h 12 Jan 2009 05:10:45 -0000 1.66
+++ src/include/storage/smgr.h 10 Jun 2009 20:42:37 -0000
@@ -68,7 +68,7 @@ extern void smgrclosenode(RelFileNode rn
extern void smgrcreate(SMgrRelation reln, ForkNumber forknum, bool isRedo);
extern void smgrdounlink(SMgrRelation reln, ForkNumber forknum,
bool isTemp, bool isRedo);
-extern void smgrextend(SMgrRelation reln, ForkNumber forknum,
+extern void smgrextend(SMgrRelation reln, ForkNumber forknum,
BlockNumber blocknum, char *buffer, bool isTemp);
extern void smgrprefetch(SMgrRelation reln, ForkNumber forknum,
BlockNumber blocknum);
Index: src/include/tsearch/ts_public.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/tsearch/ts_public.h,v
retrieving revision 1.13
diff -u -3 -p -r1.13 ts_public.h
--- src/include/tsearch/ts_public.h 15 Jan 2009 16:33:59 -0000 1.13
+++ src/include/tsearch/ts_public.h 10 Jun 2009 20:42:37 -0000
@@ -56,7 +56,7 @@ typedef struct
char *fragdelim;
int2 startsellen;
int2 stopsellen;
- int2 fragdelimlen;
+ int2 fragdelimlen;
} HeadlineParsedText;
/*
Index: src/include/utils/cash.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/utils/cash.h,v
retrieving revision 1.26
diff -u -3 -p -r1.26 cash.h
--- src/include/utils/cash.h 17 May 2008 01:28:25 -0000 1.26
+++ src/include/utils/cash.h 10 Jun 2009 20:42:37 -0000
@@ -1,5 +1,5 @@
/*
- * $PostgreSQL: pgsql/src/include/utils/cash.h,v 1.26 2008/05/17 01:28:25 adunstan Exp $
+ * $PostgreSQL: pgsql/src/include/utils/cash.h,v 1.26 2008/05/17 01:28:25 adunstan Exp $
*
*
* cash.h
Index: src/interfaces/ecpg/ecpglib/connect.c
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/ecpg/ecpglib/connect.c,v
retrieving revision 1.53
diff -u -3 -p -r1.53 connect.c
--- src/interfaces/ecpg/ecpglib/connect.c 15 Jan 2009 11:52:55 -0000 1.53
+++ src/interfaces/ecpg/ecpglib/connect.c 10 Jun 2009 20:42:37 -0000
@@ -497,7 +497,7 @@ ECPGconnect(int lineno, int c, const cha
user ? "user=" : "", user ? user : "",
passwd ? "password=" : "", passwd ? passwd : "",
options ? options : "");
-
+
/* this is deprecated
* this->connection = PQsetdbLogin(host, port, options, NULL, realname, user, passwd);*/
this->connection = PQconnectdb(connect_string);
@@ -594,7 +594,7 @@ PGconn* ECPGget_PGconn(const char *conne
struct connection * con;
con=ecpg_get_connection(connection_name);
- if (con==NULL) return NULL;
+ if (con==NULL) return NULL;
return con->connection;
}
Index: src/interfaces/ecpg/ecpglib/error.c
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/ecpg/ecpglib/error.c,v
retrieving revision 1.22
diff -u -3 -p -r1.22 error.c
--- src/interfaces/ecpg/ecpglib/error.c 16 Jan 2009 09:15:03 -0000 1.22
+++ src/interfaces/ecpg/ecpglib/error.c 10 Jun 2009 20:42:37 -0000
@@ -21,56 +21,56 @@ ecpg_raise(int line, int code, const cha
{
case ECPG_NOT_FOUND:
snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
- /* translator: this string will be truncated at 149
+ /* translator: this string will be truncated at 149
characters expanded. */
ecpg_gettext("no data found on line %d"), line);
break;
case ECPG_OUT_OF_MEMORY:
snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
- /* translator: this string will be truncated at 149
+ /* translator: this string will be truncated at 149
characters expanded. */
ecpg_gettext("out of memory on line %d"), line);
break;
case ECPG_UNSUPPORTED:
snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
- /* translator: this string will be truncated at 149
+ /* translator: this string will be truncated at 149
characters expanded. */
ecpg_gettext("unsupported type \"%s\" on line %d"), str, line);
break;
case ECPG_TOO_MANY_ARGUMENTS:
snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
- /* translator: this string will be truncated at 149
+ /* translator: this string will be truncated at 149
characters expanded. */
ecpg_gettext("too many arguments on line %d"), line);
break;
case ECPG_TOO_FEW_ARGUMENTS:
snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
- /* translator: this string will be truncated at 149
+ /* translator: this string will be truncated at 149
characters expanded. */
ecpg_gettext("too few arguments on line %d"), line);
break;
case ECPG_INT_FORMAT:
snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
- /* translator: this string will be truncated at 149
+ /* translator: this string will be truncated at 149
characters expanded. */
ecpg_gettext("invalid input syntax for type int: \"%s\", on line %d"), str, line);
break;
case ECPG_UINT_FORMAT:
snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
- /* translator: this string will be truncated at 149
+ /* translator: this string will be truncated at 149
characters expanded. */
ecpg_gettext("invalid input syntax for type unsigned int: \"%s\", on line %d"), str, line);
break;
case ECPG_FLOAT_FORMAT:
snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
- /* translator: this string will be truncated at 149
+ /* translator: this string will be truncated at 149
characters expanded. */
ecpg_gettext("invalid input syntax for floating-point type: \"%s\", on line %d"), str, line);
break;
@@ -78,124 +78,124 @@ ecpg_raise(int line, int code, const cha
case ECPG_CONVERT_BOOL:
if (str)
snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
- /* translator: this string will be truncated at 149
+ /* translator: this string will be truncated at 149
characters expanded. */
ecpg_gettext("invalid syntax for type boolean: \"%s\", on line %d"), str, line);
else
snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
- /* translator: this string will be truncated at 149
+ /* translator: this string will be truncated at 149
characters expanded. */
ecpg_gettext("could not convert boolean value: size mismatch, on line %d"), line);
break;
case ECPG_EMPTY:
snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
- /* translator: this string will be truncated at 149
+ /* translator: this string will be truncated at 149
characters expanded. */
ecpg_gettext("empty query on line %d"), line);
break;
case ECPG_MISSING_INDICATOR:
snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
- /* translator: this string will be truncated at 149
+ /* translator: this string will be truncated at 149
characters expanded. */
ecpg_gettext("null value without indicator on line %d"), line);
break;
case ECPG_NO_ARRAY:
snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
- /* translator: this string will be truncated at 149
+ /* translator: this string will be truncated at 149
characters expanded. */
ecpg_gettext("variable does not have an array type on line %d"), line);
break;
case ECPG_DATA_NOT_ARRAY:
snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
- /* translator: this string will be truncated at 149
+ /* translator: this string will be truncated at 149
characters expanded. */
ecpg_gettext("data read from server is not an array on line %d"), line);
break;
case ECPG_ARRAY_INSERT:
snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
- /* translator: this string will be truncated at 149
+ /* translator: this string will be truncated at 149
characters expanded. */
ecpg_gettext("inserting an array of variables is not supported on line %d"), line);
break;
case ECPG_NO_CONN:
snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
- /* translator: this string will be truncated at 149
+ /* translator: this string will be truncated at 149
characters expanded. */
ecpg_gettext("connection \"%s\" does not exist on line %d"), str, line);
break;
case ECPG_NOT_CONN:
snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
- /* translator: this string will be truncated at 149
+ /* translator: this string will be truncated at 149
characters expanded. */
ecpg_gettext("not connected to connection \"%s\" on line %d"), str, line);
break;
case ECPG_INVALID_STMT:
snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
- /* translator: this string will be truncated at 149
+ /* translator: this string will be truncated at 149
characters expanded. */
ecpg_gettext("invalid statement name \"%s\" on line %d"), str, line);
break;
case ECPG_UNKNOWN_DESCRIPTOR:
snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
- /* translator: this string will be truncated at 149
+ /* translator: this string will be truncated at 149
characters expanded. */
ecpg_gettext("descriptor \"%s\" not found on line %d"), str, line);
break;
case ECPG_INVALID_DESCRIPTOR_INDEX:
snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
- /* translator: this string will be truncated at 149
+ /* translator: this string will be truncated at 149
characters expanded. */
ecpg_gettext("descriptor index out of range on line %d"), line);
break;
case ECPG_UNKNOWN_DESCRIPTOR_ITEM:
snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
- /* translator: this string will be truncated at 149
+ /* translator: this string will be truncated at 149
characters expanded. */
ecpg_gettext("unrecognized descriptor item \"%s\" on line %d"), str, line);
break;
case ECPG_VAR_NOT_NUMERIC:
snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
- /* translator: this string will be truncated at 149
+ /* translator: this string will be truncated at 149
characters expanded. */
ecpg_gettext("variable does not have a numeric type on line %d"), line);
break;
case ECPG_VAR_NOT_CHAR:
snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
- /* translator: this string will be truncated at 149
+ /* translator: this string will be truncated at 149
characters expanded. */
ecpg_gettext("variable does not have a character type on line %d"), line);
break;
case ECPG_TRANS:
snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
- /* translator: this string will be truncated at 149
+ /* translator: this string will be truncated at 149
characters expanded. */
ecpg_gettext("error in transaction processing on line %d"), line);
break;
case ECPG_CONNECT:
snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
- /* translator: this string will be truncated at 149
+ /* translator: this string will be truncated at 149
characters expanded. */
ecpg_gettext("could not connect to database \"%s\" on line %d"), str, line);
break;
default:
snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
- /* translator: this string will be truncated at 149
+ /* translator: this string will be truncated at 149
characters expanded. */
ecpg_gettext("SQL error %d on line %d"), code, line);
break;
Index: src/interfaces/ecpg/ecpglib/execute.c
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/ecpg/ecpglib/execute.c,v
retrieving revision 1.84
diff -u -3 -p -r1.84 execute.c
--- src/interfaces/ecpg/ecpglib/execute.c 20 May 2009 16:49:23 -0000 1.84
+++ src/interfaces/ecpg/ecpglib/execute.c 10 Jun 2009 20:42:37 -0000
@@ -353,7 +353,7 @@ ecpg_store_result(const PGresult *result
{
int len = 0;
- if (!PQfformat(results, act_field))
+ if (!PQfformat(results, act_field))
{
switch (var->type)
{
@@ -1193,7 +1193,7 @@ ecpg_execute(struct statement * stmt)
return false;
}
- /*
+ /*
* if var->type=ECPGt_char_variable we have a dynamic cursor we have
* to simulate a dynamic cursor because there is no backend
* functionality for it
@@ -1213,7 +1213,7 @@ ecpg_execute(struct statement * stmt)
* if the placeholder is '$0' we have to replace it on the client side
* this is for places we want to support variables at that are not supported in the backend
*/
- else if (stmt->command[position] == '0' )
+ else if (stmt->command[position] == '0' )
{
if (!insert_tobeinserted(position, 2, stmt, tobeinserted))
{
Index: src/interfaces/ecpg/include/decimal.h
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/ecpg/include/decimal.h,v
retrieving revision 1.18
diff -u -3 -p -r1.18 decimal.h
--- src/interfaces/ecpg/include/decimal.h 17 Feb 2008 18:14:29 -0000 1.18
+++ src/interfaces/ecpg/include/decimal.h 10 Jun 2009 20:42:37 -0000
@@ -6,7 +6,7 @@
#include <ecpg_informix.h>
#ifndef _ECPGLIB_H /* source created by ecpg which defines this symbol */
-typedef decimal dec_t;
+typedef decimal dec_t;
#endif /* ndef _ECPGLIB_H */
#endif /* ndef _ECPG_DECIMAL_H */
Index: src/interfaces/ecpg/include/sqlda.h
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/ecpg/include/sqlda.h,v
retrieving revision 1.3
diff -u -3 -p -r1.3 sqlda.h
--- src/interfaces/ecpg/include/sqlda.h 17 May 2008 01:28:25 -0000 1.3
+++ src/interfaces/ecpg/include/sqlda.h 10 Jun 2009 20:42:37 -0000
@@ -1,4 +1,4 @@
/*
- * $PostgreSQL: pgsql/src/interfaces/ecpg/include/sqlda.h,v 1.3 2008/05/17 01:28:25 adunstan Exp $
+ * $PostgreSQL: pgsql/src/interfaces/ecpg/include/sqlda.h,v 1.3 2008/05/17 01:28:25 adunstan Exp $
*/
Index: src/interfaces/ecpg/include/sqltypes.h
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/ecpg/include/sqltypes.h,v
retrieving revision 1.8
diff -u -3 -p -r1.8 sqltypes.h
--- src/interfaces/ecpg/include/sqltypes.h 17 May 2008 01:28:25 -0000 1.8
+++ src/interfaces/ecpg/include/sqltypes.h 10 Jun 2009 20:42:37 -0000
@@ -1,5 +1,5 @@
/*
- * $PostgreSQL: pgsql/src/interfaces/ecpg/include/sqltypes.h,v 1.8 2008/05/17 01:28:25 adunstan Exp $
+ * $PostgreSQL: pgsql/src/interfaces/ecpg/include/sqltypes.h,v 1.8 2008/05/17 01:28:25 adunstan Exp $
*/
#ifndef ECPG_SQLTYPES_H
#define ECPG_SQLTYPES_H
Index: src/interfaces/ecpg/pgtypeslib/interval.c
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/ecpg/pgtypeslib/interval.c,v
retrieving revision 1.40
diff -u -3 -p -r1.40 interval.c
--- src/interfaces/ecpg/pgtypeslib/interval.c 20 May 2009 16:13:18 -0000 1.40
+++ src/interfaces/ecpg/pgtypeslib/interval.c 10 Jun 2009 20:42:37 -0000
@@ -28,7 +28,7 @@ strtoi(const char *nptr, char **endptr,
return (int) val;
}
-/* copy&pasted from .../src/backend/utils/adt/datetime.c
+/* copy&pasted from .../src/backend/utils/adt/datetime.c
* and changesd struct pg_tm to struct tm
*/
static void
@@ -50,7 +50,7 @@ AdjustFractSeconds(double frac, struct /
}
-/* copy&pasted from .../src/backend/utils/adt/datetime.c
+/* copy&pasted from .../src/backend/utils/adt/datetime.c
* and changesd struct pg_tm to struct tm
*/
static void
@@ -103,10 +103,10 @@ ISO8601IntegerWidth(char *fieldstart)
}
-/* copy&pasted from .../src/backend/utils/adt/datetime.c
+/* copy&pasted from .../src/backend/utils/adt/datetime.c
* and changesd struct pg_tm to struct tm
*/
-static inline void
+static inline void
ClearPgTm(struct /*pg_*/tm *tm, fsec_t *fsec)
{
tm->tm_year = 0;
@@ -118,10 +118,10 @@ ClearPgTm(struct /*pg_*/tm *tm, fsec_t *
*fsec = 0;
}
-/* copy&pasted from .../src/backend/utils/adt/datetime.c
- *
+/* copy&pasted from .../src/backend/utils/adt/datetime.c
+ *
* * changesd struct pg_tm to struct tm
- *
+ *
* * Made the function static
*/
static int
@@ -231,7 +231,7 @@ DecodeISO8601Interval(char *str,
if (*str != '-')
return DTERR_BAD_FORMAT;
str++;
-
+
dterr = ParseISO8601Number(str, &str, &val, &fval);
if (dterr)
return dterr;
@@ -285,7 +285,7 @@ DecodeISO8601Interval(char *str,
AdjustFractSeconds(fval, tm, fsec, SECS_PER_HOUR);
if (unit == '\0')
return 0;
-
+
dterr = ParseISO8601Number(str, &str, &val, &fval);
if (dterr)
return dterr;
@@ -296,7 +296,7 @@ DecodeISO8601Interval(char *str,
if (*str != ':')
return DTERR_BAD_FORMAT;
str++;
-
+
dterr = ParseISO8601Number(str, &str, &val, &fval);
if (dterr)
return dterr;
@@ -791,7 +791,7 @@ AppendSeconds(char *cp, int sec, fsec_t
/* copy&pasted from .../src/backend/utils/adt/datetime.c
- *
+ *
* Change pg_tm to tm
*/
Index: src/interfaces/ecpg/pgtypeslib/timestamp.c
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/ecpg/pgtypeslib/timestamp.c,v
retrieving revision 1.44
diff -u -3 -p -r1.44 timestamp.c
--- src/interfaces/ecpg/pgtypeslib/timestamp.c 20 May 2009 16:13:18 -0000 1.44
+++ src/interfaces/ecpg/pgtypeslib/timestamp.c 10 Jun 2009 20:42:37 -0000
@@ -1,5 +1,5 @@
/*
- * $PostgreSQL: pgsql/src/interfaces/ecpg/pgtypeslib/timestamp.c,v 1.44 2009/05/20 16:13:18 meskes Exp $
+ * $PostgreSQL: pgsql/src/interfaces/ecpg/pgtypeslib/timestamp.c,v 1.44 2009/05/20 16:13:18 meskes Exp $
*/
#include "postgres_fe.h"
Index: src/interfaces/ecpg/preproc/ecpg.c
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/ecpg/preproc/ecpg.c,v
retrieving revision 1.109
diff -u -3 -p -r1.109 ecpg.c
--- src/interfaces/ecpg/preproc/ecpg.c 25 Feb 2009 13:03:07 -0000 1.109
+++ src/interfaces/ecpg/preproc/ecpg.c 10 Jun 2009 20:42:37 -0000
@@ -455,7 +455,7 @@ main(int argc, char *const argv[])
/* and parse the source */
base_yyparse();
- /*
+ /*
* Check whether all cursors were indeed opened. It
* does not really make sense to declare a cursor but
* not open it.
Index: src/interfaces/ecpg/preproc/output.c
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/ecpg/preproc/output.c,v
retrieving revision 1.24
diff -u -3 -p -r1.24 output.c
--- src/interfaces/ecpg/preproc/output.c 20 Mar 2008 15:56:59 -0000 1.24
+++ src/interfaces/ecpg/preproc/output.c 10 Jun 2009 20:42:37 -0000
@@ -195,8 +195,8 @@ output_escaped_str(char *str, bool quote
else if (str[i] == '\\')
{
int j = i;
-
- /* check whether this is a continuation line
+
+ /* check whether this is a continuation line
* if it is, do not output anything because newlines are escaped anyway */
/* accept blanks after the '\' as some other compilers do too */
Index: src/interfaces/ecpg/preproc/type.c
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/ecpg/preproc/type.c,v
retrieving revision 1.82
diff -u -3 -p -r1.82 type.c
--- src/interfaces/ecpg/preproc/type.c 23 Jan 2009 12:43:32 -0000 1.82
+++ src/interfaces/ecpg/preproc/type.c 10 Jun 2009 20:42:38 -0000
@@ -329,7 +329,7 @@ ECPGdump_a_simple(FILE *o, const char *n
{
char *variable = (char *) mm_alloc(strlen(name) + ((prefix == NULL) ? 0 : strlen(prefix)) + 4);
char *offset = (char *) mm_alloc(strlen(name) + strlen("sizeof(struct varchar_)") + 1 + strlen(varcharsize) + sizeof(int) * CHAR_BIT * 10 / 3);
- char *var_name, *ptr;
+ char *var_name, *ptr;
switch (type)
{
Index: src/interfaces/ecpg/preproc/type.h
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/ecpg/preproc/type.h,v
retrieving revision 1.50
diff -u -3 -p -r1.50 type.h
--- src/interfaces/ecpg/preproc/type.h 20 May 2008 23:17:32 -0000 1.50
+++ src/interfaces/ecpg/preproc/type.h 10 Jun 2009 20:42:38 -0000
@@ -1,5 +1,5 @@
/*
- * $PostgreSQL: pgsql/src/interfaces/ecpg/preproc/type.h,v 1.50 2008/05/20 23:17:32 meskes Exp $
+ * $PostgreSQL: pgsql/src/interfaces/ecpg/preproc/type.h,v 1.50 2008/05/20 23:17:32 meskes Exp $
*/
#ifndef _ECPG_PREPROC_TYPE_H
#define _ECPG_PREPROC_TYPE_H
Index: src/interfaces/libpq/fe-secure.c
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/libpq/fe-secure.c,v
retrieving revision 1.125
diff -u -3 -p -r1.125 fe-secure.c
--- src/interfaces/libpq/fe-secure.c 3 May 2009 17:16:58 -0000 1.125
+++ src/interfaces/libpq/fe-secure.c 10 Jun 2009 20:42:38 -0000
@@ -180,7 +180,7 @@ PQinitSSL(int do_init)
* Exported function to allow application to tell us it's already
* initialized OpenSSL and/or libcrypto.
*/
-void
+void
PQinitOpenSSL(int do_ssl, int do_crypto)
{
#ifdef USE_SSL
Index: src/interfaces/libpq/win32.c
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/libpq/win32.c,v
retrieving revision 1.25
diff -u -3 -p -r1.25 win32.c
--- src/interfaces/libpq/win32.c 1 Jan 2009 17:24:03 -0000 1.25
+++ src/interfaces/libpq/win32.c 10 Jun 2009 20:42:38 -0000
@@ -1,5 +1,5 @@
/*
- * $PostgreSQL: pgsql/src/interfaces/libpq/win32.c,v 1.25 2009/01/01 17:24:03 momjian Exp $
+ * $PostgreSQL: pgsql/src/interfaces/libpq/win32.c,v 1.25 2009/01/01 17:24:03 momjian Exp $
*
*
* FILE
Index: src/interfaces/libpq/win32.h
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/libpq/win32.h,v
retrieving revision 1.29
diff -u -3 -p -r1.29 win32.h
--- src/interfaces/libpq/win32.h 17 May 2008 01:28:25 -0000 1.29
+++ src/interfaces/libpq/win32.h 10 Jun 2009 20:42:38 -0000
@@ -1,5 +1,5 @@
/*
- * $PostgreSQL: pgsql/src/interfaces/libpq/win32.h,v 1.29 2008/05/17 01:28:25 adunstan Exp $
+ * $PostgreSQL: pgsql/src/interfaces/libpq/win32.h,v 1.29 2008/05/17 01:28:25 adunstan Exp $
*/
#ifndef __win32_h_included
#define __win32_h_included
Index: src/pl/plperl/plperl.c
===================================================================
RCS file: /cvsroot/pgsql/src/pl/plperl/plperl.c,v
retrieving revision 1.149
diff -u -3 -p -r1.149 plperl.c
--- src/pl/plperl/plperl.c 6 Jun 2009 03:45:36 -0000 1.149
+++ src/pl/plperl/plperl.c 10 Jun 2009 20:42:38 -0000
@@ -273,7 +273,7 @@ _PG_init(void)
#define SAFE_MODULE \
"require Safe; $Safe::VERSION"
-/*
+/*
* The temporary enabling of the caller opcode here is to work around a
* bug in perl 5.10, which unkindly changed the way its Safe.pm works, without
* notice. It is quite safe, as caller is informational only, and in any case
@@ -455,7 +455,7 @@ plperl_init_interp(void)
/* only call this the first time through, as per perlembed man page */
if (interp_state == INTERP_NONE)
{
- char *dummy_env[1] = { NULL };
+ char *dummy_env[1] = { NULL };
PERL_SYS_INIT3(&nargs, (char ***) &embedding, (char ***) &dummy_env);
}
@@ -548,14 +548,14 @@ plperl_safe_init(void)
eval_pv(SAFE_OK, FALSE);
if (GetDatabaseEncoding() == PG_UTF8)
{
- /*
+ /*
* Fill in just enough information to set up this perl
* function in the safe container and call it.
* For some reason not entirely clear, it prevents errors that
* can arise from the regex code later trying to load
* utf8 modules.
*/
- plperl_proc_desc desc;
+ plperl_proc_desc desc;
FunctionCallInfoData fcinfo;
SV *ret;
SV *func;
@@ -576,7 +576,7 @@ plperl_safe_init(void)
fcinfo.arg[0] = CStringGetTextDatum("a");
fcinfo.argnull[0] = false;
-
+
/* and make the call */
ret = plperl_call_perl_func(&desc, &fcinfo);
}
Index: src/pl/plperl/spi_internal.c
===================================================================
RCS file: /cvsroot/pgsql/src/pl/plperl/spi_internal.c,v
retrieving revision 1.9
diff -u -3 -p -r1.9 spi_internal.c
--- src/pl/plperl/spi_internal.c 17 May 2008 01:28:25 -0000 1.9
+++ src/pl/plperl/spi_internal.c 10 Jun 2009 20:42:38 -0000
@@ -1,5 +1,5 @@
/*
- * $PostgreSQL: pgsql/src/pl/plperl/spi_internal.c,v 1.9 2008/05/17 01:28:25 adunstan Exp $
+ * $PostgreSQL: pgsql/src/pl/plperl/spi_internal.c,v 1.9 2008/05/17 01:28:25 adunstan Exp $
*
*
* This kludge is necessary because of the conflicting
Index: src/pl/plpython/plpython.c
===================================================================
RCS file: /cvsroot/pgsql/src/pl/plpython/plpython.c,v
retrieving revision 1.121
diff -u -3 -p -r1.121 plpython.c
--- src/pl/plpython/plpython.c 4 Jun 2009 18:33:08 -0000 1.121
+++ src/pl/plpython/plpython.c 10 Jun 2009 20:42:38 -0000
@@ -493,7 +493,7 @@ PLy_modify_tuple(PLyProcedure * proc, Py
PG_TRY();
{
if ((plntup = PyDict_GetItemString(pltd, "new")) == NULL)
- ereport(ERROR,
+ ereport(ERROR,
(errmsg("TD[\"new\"] deleted, cannot modify row")));
if (!PyDict_Check(plntup))
ereport(ERROR,
* Re: pgindent run coming
@ 2009-06-10 20:54 Tom Lane <tgl@sss.pgh.pa.us>
parent: Peter Eisentraut <peter_e@gmx.net>
0 siblings, 2 replies; 61+ messages in thread
From: Tom Lane @ 2009-06-10 20:54 UTC (permalink / raw)
To: Peter Eisentraut <peter_e@gmx.net>; +Cc: pgsql-hackers@postgresql.org, Bruce Momjian <bruce@momjian.us>
Peter Eisentraut <peter_e@gmx.net> writes:
>>> I think it usually does that already ...
> Um, attached you will find a bunch of counterexamples.
At a quick look, I'm not sure that any of these are in code that hasn't
been edited since the 8.3 pgindent run.
regards, tom lane
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-10 20:58 Greg Stark <stark@enterprisedb.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 61+ messages in thread
From: Greg Stark @ 2009-06-10 20:58 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Peter Eisentraut <peter_e@gmx.net>; pgsql-hackers@postgresql.org, Bruce Momjian <bruce@momjian.us>
On Wed, Jun 10, 2009 at 9:54 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
>>>> I think it usually does that already ...
>
>> Um, attached you will find a bunch of counterexamples.
>
> At a quick look, I'm not sure that any of these are in code that hasn't
> been edited since the 8.3 pgindent run.
On a tangent: git warns about or fixes up white-space problems like
that when you're applying a patch.
I've actually found this to be a bit of a dilemma though. For code i
want it to just go ahead and fix up anything it finds. But for
regression test expected output files I don't want it to. I don't
think you can control it per-directory though.
--
Gregory Stark
http://mit.edu/~gsstark/resume.pdf
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-11 02:30 Andrew Dunstan <andrew@dunslane.net>
parent: Andrew Dunstan <andrew@dunslane.net>
1 sibling, 1 reply; 61+ messages in thread
From: Andrew Dunstan @ 2009-06-11 02:30 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-hackers
Andrew Dunstan wrote:
>
>
> I am doing runs as requested on various platforms to extract the
> typedef lists. Linux is done, Windows (mingw) is running, FBSD and
> Cygwin to come.
>
> Results in a few hours. The buildfarm will have a consolidated list.
>
>
The consolidated list comes from Windows(mingw) and Linux. My Cygwin
run broke for some reason, and 'objdump --stabs' doesn't seem to do what
we need on FBSD, so the output there was empty. If someone knows how to
get the typedefs out via objdump on FBSD would they please let us know ASAP?
Bruce, I think that's the best I can do today.
thanks
andrew
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-11 02:50 Bruce Momjian <bruce@momjian.us>
parent: Andrew Dunstan <andrew@dunslane.net>
0 siblings, 1 reply; 61+ messages in thread
From: Bruce Momjian @ 2009-06-11 02:50 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-hackers
Andrew Dunstan wrote:
>
>
> Andrew Dunstan wrote:
> >
> >
> > I am doing runs as requested on various platforms to extract the
> > typedef lists. Linux is done, Windows (mingw) is running, FBSD and
> > Cygwin to come.
> >
> > Results in a few hours. The buildfarm will have a consolidated list.
> >
> >
>
> The consolidated list comes from Windows(mingw) and Linux. My Cygwin
> run broke for some reason, and 'objdump --stabs' doesn't seem to do what
> we need on FBSD, so the output there was empty. If someone knows how to
> get the typedefs out via objdump on FBSD would they please let us know ASAP?
I will check on our Postgres shell server right away.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-11 05:05 Andrew Dunstan <andrew@dunslane.net>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 2 replies; 61+ messages in thread
From: Andrew Dunstan @ 2009-06-11 05:05 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-hackers
Bruce Momjian wrote:
>> The consolidated list comes from Windows(mingw) and Linux. My Cygwin
>> run broke for some reason, and 'objdump --stabs' doesn't seem to do what
>> we need on FBSD, so the output there was empty. If someone knows how to
>> get the typedefs out via objdump on FBSD would they please let us know ASAP?
>>
>
> I will check on our Postgres shell server right away.
>
OK, so we got that working, and the consolidated list now contains FBSD
data as well.
cheers
andrew
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-11 05:16 Tom Lane <tgl@sss.pgh.pa.us>
parent: Andrew Dunstan <andrew@dunslane.net>
1 sibling, 1 reply; 61+ messages in thread
From: Tom Lane @ 2009-06-11 05:16 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; +Cc: Bruce Momjian <bruce@momjian.us>; pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> Bruce Momjian wrote:
>> I will check on our Postgres shell server right away.
> OK, so we got that working, and the consolidated list now contains FBSD
> data as well.
Um, let's *go* guys. RC1 wrap is scheduled for 18 hours from now.
That means it is already too late to be sure that we'll have a full
cycle of buildfarm checks on the pgindent run. Quit fooling around
and get it done.
regards, tom lane
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-11 13:44 Bruce Momjian <bruce@momjian.us>
parent: Andrew Dunstan <andrew@dunslane.net>
1 sibling, 1 reply; 61+ messages in thread
From: Bruce Momjian @ 2009-06-11 13:44 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-hackers
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
> >> The consolidated list comes from Windows(mingw) and Linux. My Cygwin
> >> run broke for some reason, and 'objdump --stabs' doesn't seem to do what
> >> we need on FBSD, so the output there was empty. If someone knows how to
> >> get the typedefs out via objdump on FBSD would they please let us know ASAP?
> >>
> >
> > I will check on our Postgres shell server right away.
> >
>
> OK, so we got that working, and the consolidated list now contains FBSD
> data as well.
And where do I get the consolodated list? From?
http://www.pgbuildfarm.org/cgi-bin/typedefs.pl
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-11 14:12 Andrew Dunstan <andrew@dunslane.net>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 61+ messages in thread
From: Andrew Dunstan @ 2009-06-11 14:12 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-hackers
Bruce Momjian wrote:
> Andrew Dunstan wrote:
>
>> Bruce Momjian wrote:
>>
>>>> The consolidated list comes from Windows(mingw) and Linux. My Cygwin
>>>> run broke for some reason, and 'objdump --stabs' doesn't seem to do what
>>>> we need on FBSD, so the output there was empty. If someone knows how to
>>>> get the typedefs out via objdump on FBSD would they please let us know ASAP?
>>>>
>>>>
>>> I will check on our Postgres shell server right away.
>>>
>>>
>> OK, so we got that working, and the consolidated list now contains FBSD
>> data as well.
>>
>
> And where do I get the consolodated list? From?
>
> http://www.pgbuildfarm.org/cgi-bin/typedefs.pl
>
yes. As previously advertised.
If you want to see the individual components, use
<http://www.pgbuildfarm.org/cgi-bin/typedefs.pl?show_list=1;
cheers
andrew
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-11 14:50 Bruce Momjian <bruce@momjian.us>
parent: Andrew Dunstan <andrew@dunslane.net>
0 siblings, 1 reply; 61+ messages in thread
From: Bruce Momjian @ 2009-06-11 14:50 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-hackers
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
> > Andrew Dunstan wrote:
> >
> >> Bruce Momjian wrote:
> >>
> >>>> The consolidated list comes from Windows(mingw) and Linux. My Cygwin
> >>>> run broke for some reason, and 'objdump --stabs' doesn't seem to do what
> >>>> we need on FBSD, so the output there was empty. If someone knows how to
> >>>> get the typedefs out via objdump on FBSD would they please let us know ASAP?
> >>>>
> >>>>
> >>> I will check on our Postgres shell server right away.
> >>>
> >>>
> >> OK, so we got that working, and the consolidated list now contains FBSD
> >> data as well.
> >>
> >
> > And where do I get the consolodated list? From?
> >
> > http://www.pgbuildfarm.org/cgi-bin/typedefs.pl
> >
>
> yes. As previously advertised.
>
> If you want to see the individual components, use
> <http://www.pgbuildfarm.org/cgi-bin/typedefs.pl?show_list=1;
OK, pgindent run with updated list and applied to CVS HEAD. I eyeballed
the patch and it looked clean, and it tested successfully. Thanks.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-11 15:00 Tom Lane <tgl@sss.pgh.pa.us>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 61+ messages in thread
From: Tom Lane @ 2009-06-11 15:00 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
> OK, pgindent run with updated list and applied to CVS HEAD. I eyeballed
> the patch and it looked clean, and it tested successfully. Thanks.
Do we have any TODO items concerning pgindent at this point? You had
mentioned wanting to research its behavior for 'struct foo var'
declarations, and I'm not too clear about whether we're happy with the
typedef collection code yet.
regards, tom lane
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-11 15:10 Andrew Dunstan <andrew@dunslane.net>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 61+ messages in thread
From: Andrew Dunstan @ 2009-06-11 15:10 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Bruce Momjian <bruce@momjian.us>; pgsql-hackers
Tom Lane wrote:
> Do we have any TODO items concerning pgindent at this point? Y
>
Yes, we will make the buildfarm and standalone find-typedefs run from a
common pieces of code so they are always in sync.
cheers
andrew
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-11 15:18 Alvaro Herrera <alvherre@commandprompt.com>
parent: Andrew Dunstan <andrew@dunslane.net>
0 siblings, 1 reply; 61+ messages in thread
From: Alvaro Herrera @ 2009-06-11 15:18 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Bruce Momjian <bruce@momjian.us>; pgsql-hackers
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>> Do we have any TODO items concerning pgindent at this point? Y
>>
>
> Yes, we will make the buildfarm and standalone find-typedefs run from a
> common pieces of code so they are always in sync.
BTW if we had an "official" typedef list that could be used for the
length of a whole major release, we could run pgindent on a regular
basis (say fortnightly or monthly); patch submitters would just need to
run it on their own trees to avoid merge conflicts.
(Hmm, but I'm unsure how would that work with git merge etc).
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-11 17:10 Andrew Dunstan <andrew@dunslane.net>
parent: Alvaro Herrera <alvherre@commandprompt.com>
0 siblings, 0 replies; 61+ messages in thread
From: Andrew Dunstan @ 2009-06-11 17:10 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@commandprompt.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Bruce Momjian <bruce@momjian.us>; pgsql-hackers
Alvaro Herrera wrote:
> BTW if we had an "official" typedef list that could be used for the
> length of a whole major release, we could run pgindent on a regular
> basis (say fortnightly or monthly); patch submitters would just need to
> run it on their own trees to avoid merge conflicts.
>
> (Hmm, but I'm unsure how would that work with git merge etc).
>
>
Well, step one was finding a way to get a more comprehensive typedef
list. Now we have some sort of mechanism for doing that, we can look at
regularly pulling the list into the source, I guess. Maybe then we could
look at either regular runs or even making it a part of a commit to the
central repo, if we trust it enough. That would have the advantage of
avoiding any later merge problems.
After the release, we can play around some more.
cheers
andrew
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-11 18:13 Tom Lane <tgl@sss.pgh.pa.us>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 61+ messages in thread
From: Tom Lane @ 2009-06-11 18:13 UTC (permalink / raw)
To: Merlin Moncure <mmoncure@gmail.com>; +Cc: pgsql-hackers
Merlin Moncure <mmoncure@gmail.com> writes:
> I confirmed the aix problem on 4.3.3. Installed the patches and
> updated postgres 8.4b2 removing the aix hack. Server starts fine:
> $ LOG: could not bind IPv6 socket: Addr family not supported by protocol
> HINT: Is another postmaster already running on port 5432? If not,
> wait a few seconds and retry.
> LOG: database system was shut down at 2009-06-11 13:23:32 EDT
> LOG: autovacuum launcher started
> LOG: database system is ready to accept connection
> psql logs in. I don't know if the problem we identified this sprint
> is still present...not too concered about that. pull the AIX
> getaddrinfo check and go with it... no problems as best I can tell.
> (out of time for this today).
OK, we'll go with that for RC1. I'll put a nonspecific note into the
docs suggesting a system update if trouble is encountered, but it would
be nice if we could add some information about exactly which fixes are
needed.
regards, tom lane
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-11 18:18 Merlin Moncure <mmoncure@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 61+ messages in thread
From: Merlin Moncure @ 2009-06-11 18:18 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers
On Thu, Jun 11, 2009 at 2:13 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> Merlin Moncure <mmoncure@gmail.com> writes:
>> I confirmed the aix problem on 4.3.3. Installed the patches and
>> updated postgres 8.4b2 removing the aix hack. Server starts fine:
>
>> $ LOG: could not bind IPv6 socket: Addr family not supported by protocol
>> HINT: Is another postmaster already running on port 5432? If not,
>> wait a few seconds and retry.
>> LOG: database system was shut down at 2009-06-11 13:23:32 EDT
>> LOG: autovacuum launcher started
>> LOG: database system is ready to accept connection
>
>> psql logs in. I don't know if the problem we identified this sprint
>> is still present...not too concered about that. pull the AIX
>> getaddrinfo check and go with it... no problems as best I can tell.
>> (out of time for this today).
>
> OK, we'll go with that for RC1. I'll put a nonspecific note into the
> docs suggesting a system update if trouble is encountered, but it would
> be nice if we could add some information about exactly which fixes are
> needed.
I just pulled the aix rollup pack...and would expect others to do the
same. It hasn't been updated since 2004-ish.
merlin
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-13 13:13 Peter Eisentraut <peter_e@gmx.net>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 61+ messages in thread
From: Peter Eisentraut @ 2009-06-13 13:13 UTC (permalink / raw)
To: pgsql-hackers; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Bruce Momjian <bruce@momjian.us>
On Wednesday 10 June 2009 23:54:41 Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> >>> I think it usually does that already ...
> >
> > Um, attached you will find a bunch of counterexamples.
>
> At a quick look, I'm not sure that any of these are in code that hasn't
> been edited since the 8.3 pgindent run.
So what does that mean then? Surely pgindent doesn't keep track of what has
been edited when?
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-13 13:33 Andrew Dunstan <andrew@dunslane.net>
parent: Peter Eisentraut <peter_e@gmx.net>
0 siblings, 1 reply; 61+ messages in thread
From: Andrew Dunstan @ 2009-06-13 13:33 UTC (permalink / raw)
To: Peter Eisentraut <peter_e@gmx.net>; +Cc: pgsql-hackers@postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>; Bruce Momjian <bruce@momjian.us>
Peter Eisentraut wrote:
> On Wednesday 10 June 2009 23:54:41 Tom Lane wrote:
>
>> Peter Eisentraut <peter_e@gmx.net> writes:
>>
>>>>> I think it usually does that already ...
>>>>>
>>> Um, attached you will find a bunch of counterexamples.
>>>
>> At a quick look, I'm not sure that any of these are in code that hasn't
>> been edited since the 8.3 pgindent run.
>>
>
> So what does that mean then? Surely pgindent doesn't keep track of what has
> been edited when?
>
>
If the code has been edited since the last pgindent run, then pgindent
hasn't had a chance to adjust it, no?
cheers
andrew
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: pgindent run coming
@ 2009-06-13 13:57 Tom Lane <tgl@sss.pgh.pa.us>
parent: Andrew Dunstan <andrew@dunslane.net>
0 siblings, 0 replies; 61+ messages in thread
From: Tom Lane @ 2009-06-13 13:57 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; +Cc: Peter Eisentraut <peter_e@gmx.net>; pgsql-hackers@postgresql.org, Bruce Momjian <bruce@momjian.us>
Andrew Dunstan <andrew@dunslane.net> writes:
> Peter Eisentraut wrote:
>> On Wednesday 10 June 2009 23:54:41 Tom Lane wrote:
>>> At a quick look, I'm not sure that any of these are in code that hasn't
>>> been edited since the 8.3 pgindent run.
>>
>> So what does that mean then? Surely pgindent doesn't keep track of what has
>> been edited when?
> If the code has been edited since the last pgindent run, then pgindent
> hasn't had a chance to adjust it, no?
Right. Those extra spaces all represent manual editing sloppiness.
I have not done a complete check, but I looked at the first couple of
examples you cited and verified that pgindent did remove those spaces.
regards, tom lane
^ permalink raw reply [nested|flat] 61+ messages in thread
* [PATCH] Replica sends an incorrect epoch in its hot standby feedback to the Master
@ 2020-02-06 23:51 Palamadai, Eka <ekanatha@amazon.com>
0 siblings, 1 reply; 61+ messages in thread
From: Palamadai, Eka @ 2020-02-06 23:51 UTC (permalink / raw)
To: pgsql-hackers
Hello Postgres hackers,
The below problem occurs in Postgres versions 11, 10, and 9.6. However, it doesn’t occur since Postgres version 12, since the commit [6] to add basic infrastructure for 64-bit transaction IDs indirectly fixed it.
Problem
The replica sends an incorrect epoch in its hot standby feedback to the master in the scenario outlined below, where a checkpoint is interleaved with the execution of 2 transactions at the master. The incorrect epoch in the feedback causes the master to ignore the “oldest Xmin” X sent by the replica. If a heap page prune[1] or vacuum were executed at the master immediately thereafter, they may use a newer “oldest Xmin” Y > X, and prematurely delete a tuple T such that X < t_xmax (T) < Y, which is still in use at the replica as part of a long running read query Q. Subsequently, when the replica replays the deletion of T as part of its WAL replay, it cancels the long running query Q causing unnecessary pain to customers.
Scenario
The experimental setup is to start 2 write transactions and get their transaction ids, then create a checkpoint, and then have the oldest of the 2 transactions perform a write operation. The WAL replay of that write operation breaks the monotonically increasing property of “nextXid” tracked by the replica, and causes it to send a wrong epoch in its next feedback.
1. Set the following parameters on the replica and the master.
* replica:
i. set hot_standby = on and hot_standby_feedback = on to provide hot standby feedback.
ii. set log_min_messages = DEBUG2 so that hot standby feedback[2] gets logged.
* master:
i. set checkpoint_timeout = 3600 (1 hour) to turn off automatic checkpoints during the experiment.
ii. set autovacuum = off to avoid interference from the vacuum process.
1. Make sure no other read/write queries get executed on the replica and the master during this experiment, since they might change the nextXid on the replica. To achieve this, I set up a master and replica running Postgres 11 “locally” on my desktop, with the above parameter settings.
2. Start a psql client to the master, and do the following:
a. Create a test table, say “test_epoch_table”. Execute “CREATE TABLE test_epoch_table(id INT, description CHAR(200));”.
b. Begin a transaction, say A, and get the current transaction ID. Execute “begin; select txid_current();”.
1. Start a second psql client to the master. Begin a transaction, say B, and get the current transaction ID. Execute “begin; select txid_current();”.
2. Start a third psql client to the master, and create a checkpoint. Execute “checkpoint;”.
3. From transaction A, insert a tuple into “test_epoch_table”. Execute “insert into test_epoch_table(id, description) values(1, 'one');”
4. Open the Postgres log file on the replica and look for the latest hot standby feedback. The log message will show that the replica sent an incorrect epoch of 1, instead of 0.
Analysis
The variable “ShmemVariableCache->nextXid” (or “nextXid” for short) should be monotonically increasing unless it wraps around to the next epoch. However, in the above sequence, this property is violated on the replica in the function “RecordKnownAssignedTransactionIds”[3], when the WAL replay for the insertion at step 6 is executed at the replica.
For example, before step 3b is executed, suppose the nextXid at the replica and master is 100, and that the variable “latestObservedXid”, which tracks the latest observed Xid at the replica, is 99. Now, suppose the Xid for transaction A is 100, and that for transaction B is 101. After step 4 is executed, the latestObservedXid at the replica still remains at 99, since the WAL replay for RUNNING_XACTS doesn’t advance latestObservedXid, once the replica reaches the STANDBY_SNAPSHOT_READY state. See [4] for reference. After step 5 is executed, the WAL replay of the checkpoint advances nextXid at the replica to 102, but doesn’t invoke RecordKnownAssignedTransactionIds, and hence latestObservedXid still remains 99. After step 6 is executed, the WAL replay of the insertion invokes RecordKnownAssignedTransactionIds with an input Xid of 100, advances latestObservedXid to 100, and sets nextXid at the replica to 101 (at line [3]) breaking its monotonicity. The hot standby feedback, which is generated immediately after the WAL replay of the insertion, invokes the function “GetNextXidAndEpoch”, which incorrectly calculates the epoch [5].
Versions impacted by this problem: 11, 10, and 9.6
Attached is the git diff of the patch for version 11, which is a 1-line change excluding the curly braces. Patch for versions 10 and 9.6 involve the same change.
Please let me know if you have any questions.
Thanks,
Eka Palamadai
Amazon Web Services
[1] https://github.com/postgres/postgres/blob/REL_11_STABLE/src/backend/access/heap/pruneheap.c#L74
[2] https://github.com/postgres/postgres/blob/REL_11_STABLE/src/backend/replication/walreceiver.c#L1244
[3] https://github.com/postgres/postgres/blob/REL_11_STABLE/src/backend/storage/ipc/procarray.c#L3259
[4] https://github.com/postgres/postgres/blob/REL_11_STABLE/src/backend/storage/ipc/procarray.c#L693
[5] https://github.com/postgres/postgres/blob/REL_11_STABLE/src/backend/access/transam/xlog.c#L8444
[6] https://github.com/postgres/postgres/commit/2fc7af5e966043a412e8e69c135fae55a2db6d4f
Attachments:
git_diff (application/octet-stream, 642B) download
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: [PATCH] Replica sends an incorrect epoch in its hot standby feedback to the Master
@ 2020-02-12 04:27 Thomas Munro <thomas.munro@gmail.com>
parent: Palamadai, Eka <ekanatha@amazon.com>
0 siblings, 1 reply; 61+ messages in thread
From: Thomas Munro @ 2020-02-12 04:27 UTC (permalink / raw)
To: Palamadai, Eka <ekanatha@amazon.com>; +Cc: pgsql-hackers
On Fri, Feb 7, 2020 at 1:03 PM Palamadai, Eka <ekanatha@amazon.com> wrote:
> The below problem occurs in Postgres versions 11, 10, and 9.6. However, it doesn’t occur since Postgres version 12, since the commit [6] to add basic infrastructure for 64-bit transaction IDs indirectly fixed it.
I'm happy that that stuff is already fixing bugs we didn't know we
had, but, yeah, it looks like it really only fixed it incidentally by
moving all the duplicated "assign if higher" code into a function, not
through the magical power of 64 bit xids.
> The replica sends an incorrect epoch in its hot standby feedback to the master in the scenario outlined below, where a checkpoint is interleaved with the execution of 2 transactions at the master. The incorrect epoch in the feedback causes the master to ignore the “oldest Xmin” X sent by the replica. If a heap page prune[1] or vacuum were executed at the master immediately thereafter, they may use a newer “oldest Xmin” Y > X, and prematurely delete a tuple T such that X < t_xmax (T) < Y, which is still in use at the replica as part of a long running read query Q. Subsequently, when the replica replays the deletion of T as part of its WAL replay, it cancels the long running query Q causing unnecessary pain to customers.
Ouch. Thanks for this analysis!
> The variable “ShmemVariableCache->nextXid” (or “nextXid” for short) should be monotonically increasing unless it wraps around to the next epoch. However, in the above sequence, this property is violated on the replica in the function “RecordKnownAssignedTransactionIds”[3], when the WAL replay for the insertion at step 6 is executed at the replica.
I haven't tried your repro or studied this closely yet, but yes, that
assignment to nextXid does indeed look pretty fishy. Other similar
code elsewhere always does a check like in your patch, before
clobbering nextXid.
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: [PATCH] Replica sends an incorrect epoch in its hot standby feedback to the Master
@ 2020-02-21 17:10 Palamadai, Eka <ekanatha@amazon.com>
parent: Thomas Munro <thomas.munro@gmail.com>
0 siblings, 2 replies; 61+ messages in thread
From: Palamadai, Eka @ 2020-02-21 17:10 UTC (permalink / raw)
To: pgsql-hackers; Thomas Munro <thomas.munro@gmail.com>
Thanks a lot for the feedback. Please let me know if you have any further comments. Meanwhile, I have also added this patch to "Commitfest 2020-03" at https://commitfest.postgresql.org/27/2464.
Thanks,
Eka Palamadai
Amazon Web Services
On 2/11/20, 11:28 PM, "Thomas Munro" <thomas.munro@gmail.com> wrote:
On Fri, Feb 7, 2020 at 1:03 PM Palamadai, Eka <ekanatha@amazon.com> wrote:
> The below problem occurs in Postgres versions 11, 10, and 9.6. However, it doesn’t occur since Postgres version 12, since the commit [6] to add basic infrastructure for 64-bit transaction IDs indirectly fixed it.
I'm happy that that stuff is already fixing bugs we didn't know we
had, but, yeah, it looks like it really only fixed it incidentally by
moving all the duplicated "assign if higher" code into a function, not
through the magical power of 64 bit xids.
> The replica sends an incorrect epoch in its hot standby feedback to the master in the scenario outlined below, where a checkpoint is interleaved with the execution of 2 transactions at the master. The incorrect epoch in the feedback causes the master to ignore the “oldest Xmin” X sent by the replica. If a heap page prune[1] or vacuum were executed at the master immediately thereafter, they may use a newer “oldest Xmin” Y > X, and prematurely delete a tuple T such that X < t_xmax (T) < Y, which is still in use at the replica as part of a long running read query Q. Subsequently, when the replica replays the deletion of T as part of its WAL replay, it cancels the long running query Q causing unnecessary pain to customers.
Ouch. Thanks for this analysis!
> The variable “ShmemVariableCache->nextXid” (or “nextXid” for short) should be monotonically increasing unless it wraps around to the next epoch. However, in the above sequence, this property is violated on the replica in the function “RecordKnownAssignedTransactionIds”[3], when the WAL replay for the insertion at step 6 is executed at the replica.
I haven't tried your repro or studied this closely yet, but yes, that
assignment to nextXid does indeed look pretty fishy. Other similar
code elsewhere always does a check like in your patch, before
clobbering nextXid.
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: [PATCH] Replica sends an incorrect epoch in its hot standby feedback to the Master
@ 2020-03-02 15:33 Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>
parent: Palamadai, Eka <ekanatha@amazon.com>
1 sibling, 1 reply; 61+ messages in thread
From: Juan José Santamaría Flecha @ 2020-03-02 15:33 UTC (permalink / raw)
To: Palamadai, Eka <ekanatha@amazon.com>; +Cc: pgsql-hackers; Thomas Munro <thomas.munro@gmail.com>
On Fri, Feb 21, 2020 at 8:15 PM Palamadai, Eka <ekanatha@amazon.com> wrote:
Please, do not top post on this list.
Thanks a lot for the feedback. Please let me know if you have any further
> comments. Meanwhile, I have also added this patch to "Commitfest 2020-03"
> at https://commitfest.postgresql.org/27/2464.
>
Apparently, there are a couple of duplicate entries in the commitfest as:
https://commitfest.postgresql.org/27/2463/ and
https://commitfest.postgresql.org/27/2462/
Could close those as "withdrawn"?
Regards,
Juan José Santamaría Flecha
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: [PATCH] Replica sends an incorrect epoch in its hot standby feedback to the Master
@ 2020-03-03 13:02 David Steele <david@pgmasters.net>
parent: Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>
0 siblings, 0 replies; 61+ messages in thread
From: David Steele @ 2020-03-03 13:02 UTC (permalink / raw)
To: Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>; Palamadai, Eka <ekanatha@amazon.com>; +Cc: pgsql-hackers; Thomas Munro <thomas.munro@gmail.com>
On 3/2/20 10:33 AM, Juan José Santamaría Flecha wrote:
> On Fri, Feb 21, 2020 at 8:15 PM Palamadai, Eka <ekanatha@amazon.com
> <mailto:ekanatha@amazon.com>> wrote:
>
> Please, do not top post on this list.
>
> Thanks a lot for the feedback. Please let me know if you have any
> further comments. Meanwhile, I have also added this patch to
> "Commitfest 2020-03" at https://commitfest.postgresql.org/27/2464.
>
>
> Apparently, there are a couple of duplicate entries in the commitfest
> as: https://commitfest.postgresql.org/27/2463/ and
> https://commitfest.postgresql.org/27/2462/
>
> Could close those as "withdrawn"?
I have marked the duplicate entries 2462 and 2463 as withdrawn.
--
-David
david@pgmasters.net
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: [PATCH] Replica sends an incorrect epoch in its hot standby feedback to the Master
@ 2020-03-11 06:47 Thomas Munro <thomas.munro@gmail.com>
parent: Palamadai, Eka <ekanatha@amazon.com>
1 sibling, 1 reply; 61+ messages in thread
From: Thomas Munro @ 2020-03-11 06:47 UTC (permalink / raw)
To: Palamadai, Eka <ekanatha@amazon.com>; +Cc: pgsql-hackers
On Sat, Feb 22, 2020 at 6:10 AM Palamadai, Eka <ekanatha@amazon.com> wrote:
> Thanks a lot for the feedback. Please let me know if you have any further comments. Meanwhile, I have also added this patch to "Commitfest 2020-03" at https://commitfest.postgresql.org/27/2464.
Thanks for the excellent reproducer for this obscure bug. You said
the problem exists in 9.6-11, but I'm also able to reproduce it in
9.5. That's the oldest supported release, but it probably goes back
further. I confirmed that this patch fixes the immediate problem.
I've attached a version of your patch with a commit message, to see if
anyone has more feedback on this.
Attachments:
0001-Fix-nextXid-tracking-bug-on-standbys-9.5-11-only.patch (text/x-patch, 1.7K) download
From 26740a9a670161f27c07c3c83c1056f8b4373d35 Mon Sep 17 00:00:00 2001
From: Thomas Munro <thomas.munro@gmail.com>
Date: Wed, 11 Mar 2020 17:02:02 +1300
Subject: [PATCH] Fix nextXid tracking bug on standbys (9.5-11 only).
RecordKnownAssignedTransactionIds() should never move
nextXid backwards. Before this commit, that could happen
if some other code path had advanced it without advancing
latestObservedXid.
One consequence is that a well timed XLOG_CHECKPOINT_ONLINE
could cause hot standby feedback messages to get confused
and report an xmin from a future epoch, potentially allowing
vacuum to run too soon on the primary.
Repair, by making sure RecordKnownAssignedTransactionIds()
can only move nextXid forwards.
In release 12 and master, this was already done by commit
2fc7af5e, which consolidated similar code and straightened
out this bug. Back-patch to supported releases before that.
Author: Eka Palamadai
Discussion: https://postgr.es/m/98BB4805-D0A2-48E1-96F4-15014313EADC@amazon.com
---
src/backend/storage/ipc/procarray.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c
index ddd3461d56..50b9aea683 100644
--- a/src/backend/storage/ipc/procarray.c
+++ b/src/backend/storage/ipc/procarray.c
@@ -3256,7 +3256,8 @@ RecordKnownAssignedTransactionIds(TransactionId xid)
next_expected_xid = latestObservedXid;
TransactionIdAdvance(next_expected_xid);
LWLockAcquire(XidGenLock, LW_EXCLUSIVE);
- ShmemVariableCache->nextXid = next_expected_xid;
+ if (TransactionIdFollows(next_expected_xid, ShmemVariableCache->nextXid))
+ ShmemVariableCache->nextXid = next_expected_xid;
LWLockRelease(XidGenLock);
}
}
--
2.20.1
* Re: [PATCH] Replica sends an incorrect epoch in its hot standby feedback to the Master
@ 2020-03-12 05:21 Thomas Munro <thomas.munro@gmail.com>
parent: Thomas Munro <thomas.munro@gmail.com>
0 siblings, 0 replies; 61+ messages in thread
From: Thomas Munro @ 2020-03-12 05:21 UTC (permalink / raw)
To: Palamadai, Eka <ekanatha@amazon.com>; +Cc: pgsql-hackers
On Wed, Mar 11, 2020 at 7:47 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> On Sat, Feb 22, 2020 at 6:10 AM Palamadai, Eka <ekanatha@amazon.com> wrote:
> > Thanks a lot for the feedback. Please let me know if you have any further comments. Meanwhile, I have also added this patch to "Commitfest 2020-03" at https://commitfest.postgresql.org/27/2464.
>
> Thanks for the excellent reproducer for this obscure bug. You said
> the problem exists in 9.6-11, but I'm also able to reproduce it in
> 9.5. That's the oldest supported release, but it probably goes back
> further. I confirmed that this patch fixes the immediate problem.
> I've attached a version of your patch with a commit message, to see if
> anyone has more feedback on this.
Pushed.
^ permalink raw reply [nested|flat] 61+ messages in thread
* Re: [PATCH] Replica sends an incorrect epoch in its hot standby feedback to the Master
@ 2020-03-12 14:55 Palamadai, Eka <ekanatha@amazon.com>
0 siblings, 0 replies; 61+ messages in thread
From: Palamadai, Eka @ 2020-03-12 14:55 UTC (permalink / raw)
To: Thomas Munro <thomas.munro@gmail.com>; +Cc: pgsql-hackers
Thanks a lot for reviewing and pushing this.
Eka
On 3/12/20, 1:23 AM, "Thomas Munro" <thomas.munro@gmail.com> wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
On Wed, Mar 11, 2020 at 7:47 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> On Sat, Feb 22, 2020 at 6:10 AM Palamadai, Eka <ekanatha@amazon.com> wrote:
> > Thanks a lot for the feedback. Please let me know if you have any further comments. Meanwhile, I have also added this patch to "Commitfest 2020-03" at https://commitfest.postgresql.org/27/2464.
>
> Thanks for the excellent reproducer for this obscure bug. You said
> the problem exists in 9.6-11, but I'm also able to reproduce it in
> 9.5. That's the oldest supported release, but it probably goes back
> further. I confirmed that this patch fixes the immediate problem.
> I've attached a version of your patch with a commit message, to see if
> anyone has more feedback on this.
Pushed.
^ permalink raw reply [nested|flat] 61+ messages in thread
end of thread, other threads:[~2020-03-12 14:55 UTC | newest]
Thread overview: 61+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2009-06-09 17:21 pgindent run coming Bruce Momjian <bruce@momjian.us>
2009-06-10 03:21 ` Bruce Momjian <bruce@momjian.us>
2009-06-10 03:30 ` Bruce Momjian <bruce@momjian.us>
2009-06-10 03:33 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 03:36 ` Bruce Momjian <bruce@momjian.us>
2009-06-10 16:01 ` Bruce Momjian <bruce@momjian.us>
2009-06-10 16:18 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 18:24 ` Bruce Momjian <bruce@momjian.us>
2009-06-10 18:29 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 18:51 ` Bruce Momjian <bruce@momjian.us>
2009-06-10 18:52 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 18:54 ` Andrew Dunstan <andrew@dunslane.net>
2009-06-10 19:04 ` Bruce Momjian <bruce@momjian.us>
2009-06-10 19:10 ` Greg Stark <stark@enterprisedb.com>
2009-06-10 19:16 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 19:54 ` Bruce Momjian <bruce@momjian.us>
2009-06-10 19:13 ` Andrew Dunstan <andrew@dunslane.net>
2009-06-10 19:49 ` Bruce Momjian <bruce@momjian.us>
2009-06-11 02:30 ` Andrew Dunstan <andrew@dunslane.net>
2009-06-11 02:50 ` Bruce Momjian <bruce@momjian.us>
2009-06-11 05:05 ` Andrew Dunstan <andrew@dunslane.net>
2009-06-11 05:16 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-11 18:13 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-11 18:18 ` Merlin Moncure <mmoncure@gmail.com>
2009-06-11 13:44 ` Bruce Momjian <bruce@momjian.us>
2009-06-11 14:12 ` Andrew Dunstan <andrew@dunslane.net>
2009-06-11 14:50 ` Bruce Momjian <bruce@momjian.us>
2009-06-11 15:00 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-11 15:10 ` Andrew Dunstan <andrew@dunslane.net>
2009-06-11 15:18 ` Alvaro Herrera <alvherre@commandprompt.com>
2009-06-11 17:10 ` Andrew Dunstan <andrew@dunslane.net>
2009-06-10 03:40 ` Bruce Momjian <bruce@momjian.us>
2009-06-10 03:46 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 03:48 ` Bruce Momjian <bruce@momjian.us>
2009-06-10 04:12 ` Andrew Dunstan <andrew@dunslane.net>
2009-06-10 13:43 ` Bruce Momjian <bruce@momjian.us>
2009-06-10 15:00 ` Andrew Dunstan <andrew@dunslane.net>
2009-06-10 15:11 ` Bruce Momjian <bruce@momjian.us>
2009-06-10 15:33 ` Andrew Dunstan <andrew@dunslane.net>
2009-06-10 16:02 ` Bruce Momjian <bruce@momjian.us>
2009-06-10 14:42 ` Bruce Momjian <bruce@momjian.us>
2009-06-10 14:48 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 06:18 ` Simon Riggs <simon@2ndQuadrant.com>
2009-06-10 13:45 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 19:39 ` Peter Eisentraut <peter_e@gmx.net>
2009-06-10 19:45 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 19:50 ` Bruce Momjian <bruce@momjian.us>
2009-06-10 20:44 ` Peter Eisentraut <peter_e@gmx.net>
2009-06-10 20:54 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 20:58 ` Greg Stark <stark@enterprisedb.com>
2009-06-13 13:13 ` Peter Eisentraut <peter_e@gmx.net>
2009-06-13 13:33 ` Andrew Dunstan <andrew@dunslane.net>
2009-06-13 13:57 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-02-06 23:51 [PATCH] Replica sends an incorrect epoch in its hot standby feedback to the Master Palamadai, Eka <ekanatha@amazon.com>
2020-02-12 04:27 ` Re: [PATCH] Replica sends an incorrect epoch in its hot standby feedback to the Master Thomas Munro <thomas.munro@gmail.com>
2020-02-21 17:10 ` Re: [PATCH] Replica sends an incorrect epoch in its hot standby feedback to the Master Palamadai, Eka <ekanatha@amazon.com>
2020-03-02 15:33 ` Re: [PATCH] Replica sends an incorrect epoch in its hot standby feedback to the Master Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>
2020-03-03 13:02 ` Re: [PATCH] Replica sends an incorrect epoch in its hot standby feedback to the Master David Steele <david@pgmasters.net>
2020-03-11 06:47 ` Re: [PATCH] Replica sends an incorrect epoch in its hot standby feedback to the Master Thomas Munro <thomas.munro@gmail.com>
2020-03-12 05:21 ` Re: [PATCH] Replica sends an incorrect epoch in its hot standby feedback to the Master Thomas Munro <thomas.munro@gmail.com>
2020-03-12 14:55 Re: [PATCH] Replica sends an incorrect epoch in its hot standby feedback to the Master Palamadai, Eka <ekanatha@amazon.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox