Re: [COMMITTERS] pgsql: pgindent run for 9.0, second run

Log Message:
-----------
pgindent run for 9.0, second run

Modified Files:
--------------
pgsql/contrib/dblink:
dblink.c (r1.98 -> r1.99)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/contrib/dblink/dblink.c?r1=1.98&r2=1.99)
pgsql/contrib/fuzzystrmatch:
dmetaphone.c (r1.14 -> r1.15)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/contrib/fuzzystrmatch/dmetaphone.c?r1=1.14&r2=1.15)
pgsql/contrib/pg_archivecleanup:
pg_archivecleanup.c (r1.2 -> r1.3)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/contrib/pg_archivecleanup/pg_archivecleanup.c?r1=1.2&r2=1.3)
pgsql/contrib/pg_upgrade:
check.c (r1.10 -> r1.11)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/contrib/pg_upgrade/check.c?r1=1.10&r2=1.11)
controldata.c (r1.8 -> r1.9)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/contrib/pg_upgrade/controldata.c?r1=1.8&r2=1.9)
dump.c (r1.6 -> r1.7)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/contrib/pg_upgrade/dump.c?r1=1.6&r2=1.7)
exec.c (r1.7 -> r1.8)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/contrib/pg_upgrade/exec.c?r1=1.7&r2=1.8)
file.c (r1.12 -> r1.13)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/contrib/pg_upgrade/file.c?r1=1.12&r2=1.13)
info.c (r1.10 -> r1.11)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/contrib/pg_upgrade/info.c?r1=1.10&r2=1.11)
option.c (r1.11 -> r1.12)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/contrib/pg_upgrade/option.c?r1=1.11&r2=1.12)
pg_upgrade.c (r1.9 -> r1.10)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/contrib/pg_upgrade/pg_upgrade.c?r1=1.9&r2=1.10)
pg_upgrade.h (r1.14 -> r1.15)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/contrib/pg_upgrade/pg_upgrade.h?r1=1.14&r2=1.15)
relfilenode.c (r1.7 -> r1.8)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/contrib/pg_upgrade/relfilenode.c?r1=1.7&r2=1.8)
server.c (r1.7 -> r1.8)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/contrib/pg_upgrade/server.c?r1=1.7&r2=1.8)
tablespace.c (r1.5 -> r1.6)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/contrib/pg_upgrade/tablespace.c?r1=1.5&r2=1.6)
util.c (r1.4 -> r1.5)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/contrib/pg_upgrade/util.c?r1=1.4&r2=1.5)
pgsql/contrib/pg_upgrade_support:
pg_upgrade_support.c (r1.4 -> r1.5)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/contrib/pg_upgrade_support/pg_upgrade_support.c?r1=1.4&r2=1.5)
pgsql/contrib/pgbench:
pgbench.c (r1.98 -> r1.99)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/contrib/pgbench/pgbench.c?r1=1.98&r2=1.99)
pgsql/contrib/pgcrypto:
sha2.c (r1.12 -> r1.13)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/contrib/pgcrypto/sha2.c?r1=1.12&r2=1.13)
pgsql/contrib/xml2:
xpath.c (r1.29 -> r1.30)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/contrib/xml2/xpath.c?r1=1.29&r2=1.30)
xslt_proc.c (r1.20 -> r1.21)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/contrib/xml2/xslt_proc.c?r1=1.20&r2=1.21)
pgsql/src/backend/access/heap:
heapam.c (r1.291 -> r1.292)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/heap/heapam.c?r1=1.291&r2=1.292)
pruneheap.c (r1.24 -> r1.25)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/heap/pruneheap.c?r1=1.24&r2=1.25)
pgsql/src/backend/access/nbtree:
nbtpage.c (r1.122 -> r1.123)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/nbtree/nbtpage.c?r1=1.122&r2=1.123)
nbtxlog.c (r1.68 -> r1.69)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/nbtree/nbtxlog.c?r1=1.68&r2=1.69)
pgsql/src/backend/access/transam:
twophase.c (r1.61 -> r1.62)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/twophase.c?r1=1.61&r2=1.62)
xact.c (r1.292 -> r1.293)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/xact.c?r1=1.292&r2=1.293)
xlog.c (r1.429 -> r1.430)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/xlog.c?r1=1.429&r2=1.430)
pgsql/src/backend/catalog:
aclchk.c (r1.167 -> r1.168)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/catalog/aclchk.c?r1=1.167&r2=1.168)
pg_proc.c (r1.175 -> r1.176)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/catalog/pg_proc.c?r1=1.175&r2=1.176)
pg_shdepend.c (r1.42 -> r1.43)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/catalog/pg_shdepend.c?r1=1.42&r2=1.43)
pgsql/src/backend/commands:
indexcmds.c (r1.197 -> r1.198)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/indexcmds.c?r1=1.197&r2=1.198)
opclasscmds.c (r1.67 -> r1.68)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/opclasscmds.c?r1=1.67&r2=1.68)
operatorcmds.c (r1.46 -> r1.47)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/operatorcmds.c?r1=1.46&r2=1.47)
tablecmds.c (r1.331 -> r1.332)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/tablecmds.c?r1=1.331&r2=1.332)
tablespace.c (r1.75 -> r1.76)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/tablespace.c?r1=1.75&r2=1.76)
vacuumlazy.c (r1.135 -> r1.136)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/vacuumlazy.c?r1=1.135&r2=1.136)
pgsql/src/backend/executor:
execUtils.c (r1.172 -> r1.173)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/execUtils.c?r1=1.172&r2=1.173)
functions.c (r1.143 -> r1.144)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/functions.c?r1=1.143&r2=1.144)
nodeMergejoin.c (r1.102 -> r1.103)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/nodeMergejoin.c?r1=1.102&r2=1.103)
pgsql/src/backend/lib:
stringinfo.c (r1.53 -> r1.54)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/lib/stringinfo.c?r1=1.53&r2=1.54)
pgsql/src/backend/libpq:
auth.c (r1.202 -> r1.203)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/libpq/auth.c?r1=1.202&r2=1.203)
be-secure.c (r1.101 -> r1.102)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/libpq/be-secure.c?r1=1.101&r2=1.102)
hba.c (r1.208 -> r1.209)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/libpq/hba.c?r1=1.208&r2=1.209)
pgsql/src/backend/optimizer/path:
costsize.c (r1.217 -> r1.218)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/path/costsize.c?r1=1.217&r2=1.218)
pgsql/src/backend/optimizer/plan:
analyzejoins.c (r1.2 -> r1.3)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/plan/analyzejoins.c?r1=1.2&r2=1.3)
planagg.c (r1.52 -> r1.53)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/plan/planagg.c?r1=1.52&r2=1.53)
planmain.c (r1.118 -> r1.119)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/plan/planmain.c?r1=1.118&r2=1.119)
pgsql/src/backend/optimizer/prep:
prepjointree.c (r1.72 -> r1.73)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/prep/prepjointree.c?r1=1.72&r2=1.73)
prepunion.c (r1.182 -> r1.183)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/prep/prepunion.c?r1=1.182&r2=1.183)
pgsql/src/backend/optimizer/util:
placeholder.c (r1.7 -> r1.8)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/util/placeholder.c?r1=1.7&r2=1.8)
pgsql/src/backend/parser:
parse_expr.c (r1.255 -> r1.256)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/parser/parse_expr.c?r1=1.255&r2=1.256)
scansup.c (r1.41 -> r1.42)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/parser/scansup.c?r1=1.41&r2=1.42)
pgsql/src/backend/port:
sysv_shmem.c (r1.56 -> r1.57)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/port/sysv_shmem.c?r1=1.56&r2=1.57)
pgsql/src/backend/port/win32:
socket.c (r1.26 -> r1.27)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/port/win32/socket.c?r1=1.26&r2=1.27)
timer.c (r1.18 -> r1.19)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/port/win32/timer.c?r1=1.18&r2=1.19)
pgsql/src/backend/postmaster:
pgstat.c (r1.203 -> r1.204)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/postmaster/pgstat.c?r1=1.203&r2=1.204)
postmaster.c (r1.613 -> r1.614)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/postmaster/postmaster.c?r1=1.613&r2=1.614)
syslogger.c (r1.57 -> r1.58)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/postmaster/syslogger.c?r1=1.57&r2=1.58)
pgsql/src/backend/replication:
walreceiver.c (r1.15 -> r1.16)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/replication/walreceiver.c?r1=1.15&r2=1.16)
walreceiverfuncs.c (r1.6 -> r1.7)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/replication/walreceiverfuncs.c?r1=1.6&r2=1.7)
walsender.c (r1.27 -> r1.28)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/replication/walsender.c?r1=1.27&r2=1.28)
pgsql/src/backend/replication/libpqwalreceiver:
libpqwalreceiver.c (r1.11 -> r1.12)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/replication/libpqwalreceiver/libpqwalreceiver.c?r1=1.11&r2=1.12)
pgsql/src/backend/storage/file:
copydir.c (r1.1 -> r1.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/file/copydir.c?r1=1.1&r2=1.2)
pgsql/src/backend/storage/ipc:
ipc.c (r1.107 -> r1.108)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/ipc/ipc.c?r1=1.107&r2=1.108)
procarray.c (r1.71 -> r1.72)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/ipc/procarray.c?r1=1.71&r2=1.72)
shmem.c (r1.104 -> r1.105)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/ipc/shmem.c?r1=1.104&r2=1.105)
standby.c (r1.26 -> r1.27)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/ipc/standby.c?r1=1.26&r2=1.27)
pgsql/src/backend/storage/lmgr:
proc.c (r1.220 -> r1.221)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/lmgr/proc.c?r1=1.220&r2=1.221)
pgsql/src/backend/tcop:
fastpath.c (r1.104 -> r1.105)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/tcop/fastpath.c?r1=1.104&r2=1.105)
postgres.c (r1.594 -> r1.595)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/tcop/postgres.c?r1=1.594&r2=1.595)
pgsql/src/backend/tsearch:
ts_typanalyze.c (r1.9 -> r1.10)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/tsearch/ts_typanalyze.c?r1=1.9&r2=1.10)
pgsql/src/backend/utils/adt:
formatting.c (r1.170 -> r1.171)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/formatting.c?r1=1.170&r2=1.171)
like_match.c (r1.29 -> r1.30)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/like_match.c?r1=1.29&r2=1.30)
oid.c (r1.77 -> r1.78)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/oid.c?r1=1.77&r2=1.78)
pg_locale.c (r1.56 -> r1.57)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/pg_locale.c?r1=1.56&r2=1.57)
xml.c (r1.97 -> r1.98)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/xml.c?r1=1.97&r2=1.98)
pgsql/src/backend/utils/cache:
catcache.c (r1.152 -> r1.153)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/cache/catcache.c?r1=1.152&r2=1.153)
relcache.c (r1.310 -> r1.311)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/cache/relcache.c?r1=1.310&r2=1.311)
pgsql/src/backend/utils/init:
postinit.c (r1.212 -> r1.213)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/init/postinit.c?r1=1.212&r2=1.213)
pgsql/src/backend/utils/mb:
mbutils.c (r1.95 -> r1.96)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/mb/mbutils.c?r1=1.95&r2=1.96)
pgsql/src/backend/utils/misc:
guc.c (r1.559 -> r1.560)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/guc.c?r1=1.559&r2=1.560)
ps_status.c (r1.41 -> r1.42)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/ps_status.c?r1=1.41&r2=1.42)
pgsql/src/backend/utils/mmgr:
portalmem.c (r1.119 -> r1.120)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/mmgr/portalmem.c?r1=1.119&r2=1.120)
pgsql/src/bin/pg_dump:
pg_backup_archiver.c (r1.186 -> r1.187)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_dump/pg_backup_archiver.c?r1=1.186&r2=1.187)
pg_backup_custom.c (r1.46 -> r1.47)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_dump/pg_backup_custom.c?r1=1.46&r2=1.47)
pg_dump.c (r1.580 -> r1.581)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_dump/pg_dump.c?r1=1.580&r2=1.581)
pgsql/src/bin/psql:
command.c (r1.220 -> r1.221)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/command.c?r1=1.220&r2=1.221)
common.c (r1.145 -> r1.146)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/common.c?r1=1.145&r2=1.146)
describe.c (r1.241 -> r1.242)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/describe.c?r1=1.241&r2=1.242)
print.c (r1.127 -> r1.128)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/print.c?r1=1.127&r2=1.128)
print.h (r1.45 -> r1.46)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/print.h?r1=1.45&r2=1.46)
tab-complete.c (r1.199 -> r1.200)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/tab-complete.c?r1=1.199&r2=1.200)
pgsql/src/include/access:
nbtree.h (r1.134 -> r1.135)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/access/nbtree.h?r1=1.134&r2=1.135)
pgsql/src/include/nodes:
relation.h (r1.186 -> r1.187)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/nodes/relation.h?r1=1.186&r2=1.187)
pgsql/src/include/port:
win32.h (r1.95 -> r1.96)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/port/win32.h?r1=1.95&r2=1.96)
pgsql/src/include/replication:
walprotocol.h (r1.1 -> r1.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/replication/walprotocol.h?r1=1.1&r2=1.2)
walreceiver.h (r1.10 -> r1.11)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/replication/walreceiver.h?r1=1.10&r2=1.11)
pgsql/src/include/storage:
pmsignal.h (r1.31 -> r1.32)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/storage/pmsignal.h?r1=1.31&r2=1.32)
proc.h (r1.122 -> r1.123)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/storage/proc.h?r1=1.122&r2=1.123)
procarray.h (r1.32 -> r1.33)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/storage/procarray.h?r1=1.32&r2=1.33)
pgsql/src/include/utils:
builtins.h (r1.349 -> r1.350)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/utils/builtins.h?r1=1.349&r2=1.350)
pgsql/src/interfaces/ecpg/ecpglib:
connect.c (r1.55 -> r1.56)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/ecpglib/connect.c?r1=1.55&r2=1.56)
error.c (r1.26 -> r1.27)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/ecpglib/error.c?r1=1.26&r2=1.27)
execute.c (r1.97 -> r1.98)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/ecpglib/execute.c?r1=1.97&r2=1.98)
misc.c (r1.58 -> r1.59)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/ecpglib/misc.c?r1=1.58&r2=1.59)
pgsql/src/interfaces/ecpg/preproc:
ecpg.c (r1.115 -> r1.116)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/preproc/ecpg.c?r1=1.115&r2=1.116)
type.c (r1.92 -> r1.93)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/preproc/type.c?r1=1.92&r2=1.93)
pgsql/src/interfaces/ecpg/test/expected:
preproc-outofscope.c (r1.3 -> r1.4)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/preproc-outofscope.c?r1=1.3&r2=1.4)
preproc-strings.c (r1.4 -> r1.5)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/preproc-strings.c?r1=1.4&r2=1.5)
pgsql/src/interfaces/ecpg/test/preproc:
strings.h (r1.1 -> r1.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/preproc/strings.h?r1=1.1&r2=1.2)
struct.h (r1.3 -> r1.4)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/preproc/struct.h?r1=1.3&r2=1.4)
pgsql/src/interfaces/libpq:
fe-connect.c (r1.394 -> r1.395)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/fe-connect.c?r1=1.394&r2=1.395)
fe-misc.c (r1.143 -> r1.144)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/fe-misc.c?r1=1.143&r2=1.144)
fe-secure.c (r1.134 -> r1.135)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/fe-secure.c?r1=1.134&r2=1.135)
libpq-int.h (r1.151 -> r1.152)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/libpq-int.h?r1=1.151&r2=1.152)
pgsql/src/pl/plperl:
plperl.c (r1.178 -> r1.179)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/pl/plperl/plperl.c?r1=1.178&r2=1.179)
pgsql/src/pl/plpgsql/src:
pl_exec.c (r1.260 -> r1.261)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/pl/plpgsql/src/pl_exec.c?r1=1.260&r2=1.261)
pgsql/src/pl/plpython:
plpython.c (r1.145 -> r1.146)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/pl/plpython/plpython.c?r1=1.145&r2=1.146)
pgsql/src/pl/tcl:
pltcl.c (r1.133 -> r1.134)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/pl/tcl/pltcl.c?r1=1.133&r2=1.134)
pgsql/src/port:
crypt.c (r1.16 -> r1.17)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/port/crypt.c?r1=1.16&r2=1.17)
dirmod.c (r1.62 -> r1.63)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/port/dirmod.c?r1=1.62&r2=1.63)
pipe.c (r1.16 -> r1.17)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/port/pipe.c?r1=1.16&r2=1.17)
snprintf.c (r1.35 -> r1.36)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/port/snprintf.c?r1=1.35&r2=1.36)
pgsql/src/test/examples:
testlibpq2.c (r1.16 -> r1.17)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/examples/testlibpq2.c?r1=1.16&r2=1.17)
pgsql/src/timezone:
pgtz.c (r1.73 -> r1.74)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/timezone/pgtz.c?r1=1.73&r2=1.74)
pgsql/src/tools/fsync:
test_fsync.c (r1.29 -> r1.30)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/tools/fsync/test_fsync.c?r1=1.29&r2=1.30)

On Tue, Jul 6, 2010 at 3:19 PM, Bruce Momjian <momjian(at)postgresql(dot)org> wrote:
> Log Message:
> -----------
> pgindent run for 9.0, second run

It appears that the <expletive> git mirror has deduced the wrong
contents for this commit. Apparently as a result, when I build from
git master, the dblink regression tests fail.

Can someone please fix this?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

Robert Haas wrote:
> On Tue, Jul 6, 2010 at 3:19 PM, Bruce Momjian <momjian(at)postgresql(dot)org> wrote:
>
>> Log Message:
>> -----------
>> pgindent run for 9.0, second run
>>
>
> It appears that the <expletive> git mirror has deduced the wrong
> contents for this commit. Apparently as a result, when I build from
> git master, the dblink regression tests fail.
>
> Can someone please fix this?
>
>

I despaired of this repo being anything like reliable months ago. AFAIK
it is using a known to be broken version of fromcvs.

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:

> I despaired of this repo being anything like reliable months ago.
> AFAIK it is using a known to be broken version of fromcvs.

Could we have it pull (using git) from the repo you have working
correctly? (Or would that be too Rube Goldbergesque?)

-Kevin

On Tue, Jul 20, 2010 at 12:01 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
>> I despaired of this repo being anything like reliable months ago.
>> AFAIK it is using a known to be broken version of fromcvs.
>
> Could we have it pull (using git) from the repo you have working
> correctly?  (Or would that be too Rube Goldbergesque?)

It would result in a massive merge commit and the duplication of the
entire history. The correct solution is probably to (a) install
Andrew's fixed version of the import tool on the server and (b) rewind
the history on the server so it reimports all the subsequent commits.
Sometimes doing only (b) is sufficient to correct the problem, since
the tool seems rather sensitive to ephemeral states of the
respository.

Unfortunately, (a) has not happened. Magnus seems to feel that Andrew
has not provided sufficient details about which version he should be
running and whether it will likely break anything, and I gather that
Andrew feels otherwise. Figuring out who is right and who is wrong
and what to do about it is above my pay grade, but it would be really
nice if someone could get this straightened out.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

On Tue, Jul 20, 2010 at 18:13, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Jul 20, 2010 at 12:01 PM, Kevin Grittner
> <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>> Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>>
>>> I despaired of this repo being anything like reliable months ago.
>>> AFAIK it is using a known to be broken version of fromcvs.
>>
>> Could we have it pull (using git) from the repo you have working
>> correctly?  (Or would that be too Rube Goldbergesque?)
>
> It would result in a massive merge commit and the duplication of the
> entire history.  The correct solution is probably to (a) install
> Andrew's fixed version of the import tool on the server and (b) rewind
> the history on the server so it reimports all the subsequent commits.
> Sometimes doing only (b) is sufficient to correct the problem, since
> the tool seems rather sensitive to ephemeral states of the
> respository.
>
> Unfortunately, (a) has not happened.  Magnus seems to feel that Andrew
> has not provided sufficient details about which version he should be
> running and whether it will likely break anything, and I gather that
> Andrew feels otherwise.  Figuring out who is right and who is wrong
> and what to do about it is above my pay grade, but it would be really
> nice if someone could get this straightened out.

Meh, who cares who's right or wrong :-)

My main point is I am unsure if this may have any adverse effects, and
I haven't had the time to investigate if it doesor not. Previously
we've just applied a manual correction patch to bring the branch tip
up to the correct state, which is supposedly good enough for the users
of the git server. In which case, someone just needs to proide said
patch :-)

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Kevin Grittner wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
>
>> I despaired of this repo being anything like reliable months ago.
>> AFAIK it is using a known to be broken version of fromcvs.
>>
>
> Could we have it pull (using git) from the repo you have working
> correctly? (Or would that be too Rube Goldbergesque?)
>
>
>

The trouble is that they don't have a common git commit history. I
suspect we'll just totally mangle the repo if we try that. But anyone
can experiment if they want to. My repo is available on
<git://github.com/oicu/pg-cvs-mirror.git> or
<http://github.com/oicu/pg-cvs-mirror.git> Or people can just use that
repo. I have four buildfarm members running off it daily, and I run a
daily health check on it against CVS. I can undertake to maintain it
until at least the middle of August (after which I'll be travelling for
a few weeks).

cheers

andrew

Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> It would result in a massive merge commit and the duplication of
> the entire history.

Ah, well, if the two repositories don't share the same IDs, it a
clear no-go. Now that I think about it, it would be a bit much to
expect those to match on independent conversions from CVS.

How is this going to play out when we do the "official" conversion
to git? Will those of us on repositories based off of
git.postgresql.org be faced with similar issues, or are we using the
repo there as the base for the conversion?

-Kevin

On Tue, Jul 20, 2010 at 18:32, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
>> It would result in a massive merge commit and the duplication of
>> the entire history.
>
> Ah, well, if the two repositories don't share the same IDs, it a
> clear no-go.  Now that I think about it, it would be a bit much to
> expect those to match on independent conversions from CVS.
>
> How is this going to play out when we do the "official" conversion
> to git?  Will those of us on repositories based off of
> git.postgresql.org be faced with similar issues, or are we using the
> repo there as the base for the conversion?

No, it will be a completely new repository. Those with the old one
will need to extract a patch from that and then apply it to the new
one.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Magnus Hagander wrote:
> On Tue, Jul 20, 2010 at 18:13, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
>> On Tue, Jul 20, 2010 at 12:01 PM, Kevin Grittner
>> <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>>
>>> Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>>>
>>>
>>>> I despaired of this repo being anything like reliable months ago.
>>>> AFAIK it is using a known to be broken version of fromcvs.
>>>>
>>> Could we have it pull (using git) from the repo you have working
>>> correctly? (Or would that be too Rube Goldbergesque?)
>>>
>> It would result in a massive merge commit and the duplication of the
>> entire history. The correct solution is probably to (a) install
>> Andrew's fixed version of the import tool on the server and (b) rewind
>> the history on the server so it reimports all the subsequent commits.
>> Sometimes doing only (b) is sufficient to correct the problem, since
>> the tool seems rather sensitive to ephemeral states of the
>> respository.
>>
>> Unfortunately, (a) has not happened. Magnus seems to feel that Andrew
>> has not provided sufficient details about which version he should be
>> running and whether it will likely break anything, and I gather that
>> Andrew feels otherwise. Figuring out who is right and who is wrong
>> and what to do about it is above my pay grade, but it would be really
>> nice if someone could get this straightened out.
>>
>
> Meh, who cares who's right or wrong :-)
>
> My main point is I am unsure if this may have any adverse effects, and
> I haven't had the time to investigate if it doesor not. Previously
> we've just applied a manual correction patch to bring the branch tip
> up to the correct state, which is supposedly good enough for the users
> of the git server. In which case, someone just needs to proide said
> patch :-)
>
>

Given that the repo's remaining lifetime is measured in weeks, that
seems reasonable.

cheers

andrew