Subject: 8.2.4 patches?

From: Ray Stell <[email-masked]>
Date: Tue, 10 Jul 2007 16:32:32 -0400

Are there critical security or performance patches that should be 
applied to 824 and how could I have determined this without this post?

Thanks.

---

From: Richard Broersma Jr <[email-masked]>
Date: Tue, 10 Jul 2007 13:43:31 -0700 (PDT)

> applied to 824 and how could I have determined this without this post?

My understanding is that a security patch to Version 8.2.4 would be version 8.2.5, and so on.

notice the following links comment:
http://www.postgresql.org/support/versioning

Regards,
Richard Broersma Jr.

---

From: Alvaro Herrera <[email-masked]>
Date: Tue, 10 Jul 2007 17:00:10 -0400

> applied to 824 and how could I have determined this without this post?

The changelog after 8.2.4 is below.  I don't think there's a way to get
this easily, short of having a copy of the CVS repository.

2007-07-09 12:13  tgl

	* src/: backend/utils/adt/numeric.c (1.96.2.2),
	  test/regress/expected/aggregates.out (1.15.2.1):

Fix stddev_pop(numeric) and var_pop(numeric), which were incorrectly producing
the same outputs as stddev_samp() and var_samp() respectively.

2007-07-08 21:32  joe

	* contrib/dblink/: dblink.c (1.60.2.1), dblink.sql.in (1.11.2.1),
	  doc/connection (1.4.2.1):

Restrict non-superusers to password authenticated connections
to prevent possible escalation of privilege. Provide new SECURITY
DEFINER functions with old behavior, but initially REVOKE ALL
from public for these functions. Per list discussion and design
proposed by Tom Lane.

2007-07-08 18:23  tgl

	* src/: backend/postmaster/pgstat.c (1.140.2.5),
	  backend/storage/smgr/smgr.c (1.101.2.1), include/pgstat.h
	  (1.50.2.1):

Remove the pgstat_drop_relation() call from smgr_internal_unlink(), because
we don't know at that point which relation OID to tell pgstat to forget.
The code was passing the relfilenode, which is incorrect, and could possibly
cause some other relation's stats to be zeroed out.  While we could try to
clean this up, it seems much simpler and more reliable to let the next
invocation of pgstat_vacuum_tabstat() fix things; which indeed is how it
worked before I introduced the buggy code into 8.1.3 and later :-(.
Problem noticed by Itagaki Takahiro, fix is per subsequent discussion.

2007-07-02 17:58  mha

	* src/bin/pg_ctl/pg_ctl.c (1.74.2.1):

- Fix the -w (wait) option to work in Windows service mode, per bug #3382.
- Prevent the -w option being passed to the postmaster.
- Read the postmaster options file when starting as a Windows service.

Dave Page

2007-07-02 16:11  tgl

	* src/: backend/port/sysv_shmem.c (1.47.2.1), include/port/linux.h
	  (1.42.2.1):

Fix failure to restart Postgres when Linux kernel returns EIDRM for shmctl().

This is a Linux kernel bug that apparently exists in every extant kernel
version: sometimes shmctl() will fail with EIDRM when EINVAL is correct.
We were assuming that EIDRM indicates a possible conflict with pre-existing
backends, and refusing to start the postmaster when this happens.  Fortunately,
there does not seem to be any case where Linux can legitimately return EIDRM
(it doesn't track shmem segments in a way that would allow that), so we can
get away with just assuming that EIDRM means EINVAL on this platform.

Per reports from Michael Fuhr and Jon Lapham --- it's a bit surprising
we have not seen more reports, actually.

2007-07-01 13:45  tgl

	* src/backend/commands/trigger.c (1.210.2.2):

Avoid memory leakage when a series of subtransactions invoke AFTER triggers
that are fired at end-of-statement (as is the normal case for foreign keys,
for example).  In this situation the per-subxact deferred trigger context
is always empty when subtransaction exit is reached; so we could free it,
but were not doing so, leading to an intratransaction leak of 8K or more
per subtransaction.  Per off-list example from Viatcheslav Kalinin
subsequent to bug #3418 (his original bug report omitted a foreign key
constraint needed to cause this leak).

Back-patch to 8.2; prior versions were not using per-subxact contexts
for deferred triggers, so did not have this leak.

2007-06-29 12:18  tgl

	* configure (1.523.2.7), configure.in (1.490.2.7):

Fix computation of PG_VERSION_NUM by configure: remove unnecessary and
unportable backslashes in awk script (per Patrick Welche), and add
brackets to prevent autoconf from mangling sed's regexp (the sed call
here never did what was expected).

2007-06-28 21:51  tgl

	* src/backend/utils/adt/formatting.c (1.116.2.3):

Fix a passel of ancient bugs in to_char(), including two distinct buffer
overruns (neither of which seem likely to be exploitable as security holes,
fortunately, since the provoker can't control the data written).  One of
these is due to choosing to stomp on the output of a called function, which
is bad news in any case; make it treat the called functions' results as
read-only.  Avoid some unnecessary palloc/pfree traffic too; it's not
really helpful to free small temporary objects, and again this is presuming
more than it ought to about the nature of the results of called functions.
Per report from Patrick Welche and additional code-reading by Imad.

2007-06-28 13:49  tgl

	* src/pl/plperl/plperl.c (1.123.2.1):

Fix incorrect tests for undef Perl values in some places in plperl.c.
The correct test for defined-ness is SvOK(sv), not anything involving
SvTYPE.  Per bug #3415 from Matt Taylor.
Back-patch as far as 8.0; no apparent problem in 7.x.

2007-06-21 23:19  neilc

	* src/bin/psql/common.c (1.130.2.2):

In psql, when running a SELECT query using a cursor, flush the query
output after each FETCH. This ensures that incremental results are
available to clients that are executing long-running SELECT queries
via the FETCH_COUNT feature.

2007-06-20 14:21  tgl

	* src/backend/parser/analyze.c (1.353.2.1):

transformColumnDefinition failed to complain about
	create table foo (bar int default null default 3);
due to not thinking about the special-case handling of DEFAULT NULL.
Problem noticed while investigating bug #3396.

2007-06-20 14:15  tgl

	* src/backend/commands/typecmds.c (1.97.2.2):

CREATE DOMAIN ... DEFAULT NULL failed because gram.y special-cases DEFAULT
NULL and DefineDomain didn't.  Bug goes all the way back to original coding
of domains.  Per bug #3396 from Sergey Burladyan.

2007-06-14 09:53  alvherre

	* src/backend/commands/vacuum.c (1.342.2.3):

Avoid having autovacuum run multiple ANALYZE commands in a single transaction,
to prevent possible deadlock problems.  Per request from Tom Lane.

2007-06-13 21:48  adunstan

	* src/: backend/postmaster/syslogger.c (1.29.2.1),
	  backend/utils/error/elog.c (1.178.2.2),
	  include/postmaster/syslogger.h (1.7.2.1):

Implement a chunking protocol for writes to the syslogger pipe, with messages
reassembled in the syslogger before writing to the log file. This prevents
partial messages from being written, which mucks up log rotation, and
messages from different backends being interleaved, which causes garbled
logs. Backport as far as 8.0, where the syslogger was introduced.

Tom Lane and Andrew Dunstan

2007-06-12 11:58  tgl

	* src/: backend/utils/adt/datetime.c (1.174.2.2),
	  test/regress/expected/timestamptz.out (1.21.2.2),
	  test/regress/sql/timestamptz.sql (1.10.2.1):

Fix DecodeDateTime to allow timezone to appear before year.  This had
historically worked in some but not all cases, but as of 8.2 it failed for all
timezone formats.  Fix, and add regression test cases to catch future
regressions in this area.  Per gripe from Adam Witney.

2007-06-09 11:52  tgl

	* src/backend/utils/adt/numeric.c (1.96.2.1):

Allow numeric_fac() to be interrupted, since it can take quite a while for
large inputs.  Also cause it to error out immediately if the result will
overflow, instead of grinding through a lot of calculation first.
Per gripe from Jim Nasby.

2007-06-07 15:07  alvherre

	* src/backend/postmaster/pgstat.c (1.140.2.4):

Avoid losing track of data for shared tables in pgstats.  Report by Michael
Fuhr, patch from Tom Lane after a messier suggestion by me.

2007-06-07 10:49  tgl

	* doc/src/sgml/array.sgml (1.52.2.5):

Fix array_dims() example to be consistent with the data previously shown.
Christian Rossow

2007-06-05 08:47  teodor

	* src/backend/access/gin/: ginbtree.c (1.6.2.1), gininsert.c
	  (1.5.2.1), ginvacuum.c (1.9.2.2):

Move call of MarkBufferDirty() before XLogInsert() as required.
Many thanks to Heikki Linnakangas <[email-masked]> for his
sharp eyes.

2007-06-04 11:56  teodor

	* src/backend/access/gin/: gindatapage.c (1.5.2.1), ginentrypage.c
	  (1.5.2.1), ginget.c (1.4.2.1), ginvacuum.c (1.9.2.1), ginxlog.c
	  (1.5.2.1):

Fix bundle bugs of GIN:
- Fix possible deadlock between UPDATE and VACUUM queries. Bug never was
  observed in 8.2, but it still exist there. HEAD is more sensitive to
  bug after recent "ring" of buffer improvements.
- Fix WAL creation: if parent page is stored as is after split then
  incomplete split isn't removed during replay. This happens rather rare, only
  on large tables with a lot of updates/inserts.
- Fix WAL replay: there was wrong test of XLR_BKP_BLOCK_* for left
  page after deletion of page. That causes wrong rightlink field: it pointed
  to deleted page.
- add checking of match of clearing incomplete split
- cleanup incomplete split list after proceeding

All of this chages doesn't change on-disk storage, so backpatch...
But second point may be an issue for replaying logs from previous version.

2007-06-04 09:39  mha

	* src/backend/port/win32/socket.c (1.14.2.3):

On win32, retry reading when WSARecv returns WSAEWOULDBLOCK. There seem
to be cases when at least Windows 2000 can do this even though select
just indicated that the socket is readable.

Per report and analysis from Cyril VELTER.

2007-06-04 07:59  mha

	* src/backend/libpq/pqcomm.c (1.188.2.1):

On win32, don't use SO_REUSEADDR for TCP sockets.

Per failure on buildfarm member baiji and subsequent discussion.

2007-06-02 12:41  tgl

	* src/backend/utils/adt/date.c (1.125.2.1):

Fix erroneous error reporting for overlength input in text_date(),
text_time(), and text_timetz().  7.4-vintage bug found by Greg Stark.

2007-06-02 11:15  neilc

	* doc/src/sgml/plpgsql.sgml (1.101.2.2):

Remove incorrect semicolon in example. This was previously fixed in
HEAD only -- backporting to 8.2. Per report from Frank van Vugt.

2007-06-01 19:43  tgl

	* src/backend/storage/file/buffile.c (1.24.2.1):

Fix aboriginal bug in BufFileDumpBuffer that would cause it to write the
wrong data when dumping a bufferload that crosses a component-file boundary.
This probably has not been seen in the wild because (a) component files are
normally 1GB apiece and (b) non-block-aligned buffer usage is relatively
rare.  But it's fairly easy to reproduce a problem if one reduces RELSEG_SIZE
in a test build.  Kudos to Kurt Harriman for spotting the bug.

2007-06-01 11:58  tgl

	* src/: backend/access/hash/hashfunc.c (1.48.2.1),
	  backend/executor/nodeHash.c (1.107.2.1), include/access/hash.h
	  (1.73.2.2):

Fix performance problems in multi-batch hash joins by ensuring that we select
a well-randomized batch number even when given a poorly-randomized hash value.
This is a bit inefficient but seems the only practical solution given the
constraint that we can't change the hash functions in released branches.
Per report from Joseph Shraibman.

Applied to 8.1 and 8.2 only --- HEAD is getting a cleaner fix, and 8.0 and
before use different coding that seems less vulnerable.

2007-05-30 17:01  tgl

	* src/backend/access/transam/xact.c (1.229.2.2):

Fix overly-strict sanity check in BeginInternalSubTransaction that made it
fail when used in a deferred trigger.  Bug goes back to 8.0; no doubt the
reason it hadn't been noticed is that we've been discouraging use of
user-defined constraint triggers.  Per report from Frank van Vugt.

2007-05-29 00:58  neilc

	* doc/src/sgml/datatype.sgml (1.181.2.3),
	  src/backend/utils/adt/datetime.c (1.174.2.1),
	  src/include/utils/datetime.h (1.62.2.1),
	  src/test/regress/expected/interval.out (1.18.2.1),
	  src/test/regress/sql/interval.sql (1.11.2.1):

Fix a bug in input processing for the "interval" type. Previously,
"microsecond" and "millisecond" units were not considered valid input
by themselves, which caused inputs like "1 millisecond" to be rejected
erroneously.

Update the docs, add regression tests, and backport to 8.2 and 8.1

2007-05-22 19:23  tgl

	* src/: backend/nodes/copyfuncs.c (1.353.2.1),
	  backend/nodes/equalfuncs.c (1.287.2.1), backend/nodes/outfuncs.c
	  (1.285.2.2), backend/optimizer/plan/initsplan.c (1.123.2.5),
	  include/nodes/relation.h (1.128.2.3),
	  test/regress/expected/join.out (1.28.2.2),
	  test/regress/expected/join_1.out (1.10.2.2),
	  test/regress/sql/join.sql (1.19.2.2):

Repair planner bug introduced in 8.2 by ability to rearrange outer joins:
in cases where a sub-SELECT inserts a WHERE clause between two outer joins,
that clause may prevent us from re-ordering the two outer joins.  The code
was considering only the joins' own ON-conditions in determining reordering
safety, which is not good enough.  Add a "delay_upper_joins" flag to
OuterJoinInfo to flag that we have detected such a clause and higher-level
outer joins shouldn't be permitted to commute with this one.  (This might
seem overly coarse, but given the current rules for OJ reordering, it's
sufficient AFAICT.)

The failure case is actually pretty narrow: it needs a WHERE clause within
the RHS of a left join that checks the RHS of a lower left join, but is not
strict for that RHS (else we'd have simplified the lower join to a plain
join).  Even then no failure will be manifest unless the planner chooses to
rearrange the join order.

Per bug report from Adam Terrey.

2007-05-21 21:40  tgl

	* src/: backend/nodes/outfuncs.c (1.285.2.1),
	  backend/optimizer/path/indxpath.c (1.212.2.2),
	  backend/optimizer/path/joinpath.c (1.107.2.1),
	  include/nodes/relation.h (1.128.2.2), include/optimizer/paths.h
	  (1.93.2.2):

Fix best_inner_indexscan to return both the cheapest-total-cost and
cheapest-startup-cost innerjoin indexscans, and make joinpath.c consider
both of these (when different) as the inside of a nestloop join.  The
original design was based on the assumption that indexscan paths always
have negligible startup cost, and so total cost is the only important
figure of merit; an assumption that's obviously broken by bitmap
indexscans.  This oversight could lead to choosing poor plans in cases
where fast-start behavior is more important than total cost, such as
LIMIT and IN queries.  8.1-vintage brain fade exposed by an example from
Chuck D.

2007-05-21 11:09  petere

	* doc/src/sgml/info.sgml (1.24.2.1):

Fix spurious German index entry

2007-05-21 10:57  meskes

	* src/interfaces/ecpg/pgtypeslib/dt_common.c (1.36.2.2):

Removed errant ISODOW

2007-05-21 03:10  meskes

	* src/interfaces/ecpg/pgtypeslib/dt_common.c (1.36.2.1):

Backported fix from HEAD that removes superfluous function Vista has a problem with

2007-05-18 05:43  petere

	* doc/src/sgml/Makefile (1.81.2.3):

Fix inappropriate comments

2007-05-17 21:20  tgl

	* src/backend/libpq/be-secure.c (1.74.2.2):

Remove redundant logging of send failures when SSL is in use.  While pqcomm.c
had been taught not to do that ages ago, the SSL code was helpfully bleating
anyway.  Resolves some recent reports such as bug #3266; however the
underlying cause of the related bug #2829 is still unclear.

2007-05-17 19:31  tgl

	* src/: backend/utils/adt/network.c (1.66.2.1),
	  backend/utils/adt/pgstatfuncs.c (1.34.2.1),
	  include/utils/builtins.h (1.282.2.2):

Temporary fix for the problem that pg_stat_activity, inet_client_addr(),
and inet_server_addr() fail if the client connected over a "scoped" IPv6
address.  In this case getnameinfo() will return a string ending with
a poorly-standardized "%something" zone specifier, which these functions
try to feed to network_in(), which won't take it.  So that we don't lose
functionality altogether, suppress the zone specifier before giving the
string to network_in().  Per report from Brian Hirt.

TODO: probably someday the inet type should support scoped IPv6 addresses,
and then this patch should be reverted.

Backpatch to 8.2 ... is it worth going further?

2007-05-15 16:20  alvherre

	* src/bin/pg_dump/pg_dumpall.c (1.85.2.1):

Avoid emitting empty role names in the GRANTED BY clause of GRANT ROLE
when the grantor has been dropped.  This is a workaround for the fact
that we don't track the grantor as a shared dependency.

2007-05-15 15:43  neilc

	* doc/src/sgml/: ddl.sgml (1.69.2.2), ref/alter_role.sgml
	  (1.7.2.1), ref/alter_user.sgml (1.42.2.1), ref/begin.sgml
	  (1.34.2.1), ref/create_group.sgml (1.17.2.1),
	  ref/create_user.sgml (1.39.2.1), ref/createlang.sgml (1.38.2.3),
	  ref/drop_group.sgml (1.13.2.1), ref/drop_user.sgml (1.23.2.1):

Fix a bunch of bad grammar in the docs: "<link>, which see for more
information" is un-good English.

2007-05-15 11:35  neilc

	* doc/src/sgml/config.sgml (1.98.2.6):

Add a note to the documentation to clarify that even when
"autovacuum = off", the system may still periodically start autovacuum
processes to prevent XID wraparound. Patch from David Fetter, with
editorializing.

2007-05-13 12:04  mha

	* doc/src/sgml/ref/cluster.sgml (1.38.2.1):

Document that CLUSTER breaks MVCC visibility rules.
(Not needed in cvs head, because CLUSTER itself is fixed there)

Heikki Linnakangas

2007-05-12 15:22  tgl

	* src/backend/optimizer/util/predtest.c (1.10.2.1):

Improve predicate_refuted_by_simple_clause() to handle IS NULL and IS NOT NULL
more completely.  The motivation for having it understand IS NULL at all was
to allow use of "foo IS NULL" as one of the subsets of a partitioning on
"foo", but as reported by Aleksander Kmetec, it wasn't really getting the job
done.  Backpatch to 8.2 since this is arguably a performance bug.

2007-05-11 16:16  tgl

	* doc/src/sgml/ref/alter_domain.sgml (1.20.2.1),
	  src/backend/commands/tablecmds.c (1.206.2.3),
	  src/backend/commands/typecmds.c (1.97.2.1),
	  src/include/commands/tablecmds.h (1.31.2.1),
	  src/test/regress/expected/domain.out (1.38.2.3),
	  src/test/regress/sql/domain.sql (1.21.2.3):

Fix my oversight in enabling domains-of-domains: ALTER DOMAIN ADD CONSTRAINT
needs to check the new constraint against columns of derived domains too.

Also, make it error out if the domain to be modified is used within any
composite-type columns.  Eventually we should support that case, but it seems
a bit painful, and not suitable for a back-patch.  For the moment just let the
user know we can't do it.

Backpatch to 8.2, which is the only released version that allows nested
domains.  Possibly the other part should be back-patched further.

2007-05-05 13:05  mha

	* src/backend/utils/adt/selfuncs.c (1.214.2.5):

Check return code from strxfrm on Windows since it has a
non-standard way of indicating errors, so we don't try to
allocate INT_MAX bytes to store a result in.

2007-05-03 11:47  alvherre

	* doc/src/sgml/: external-projects.sgml (1.14.2.1), release.sgml
	  (1.488.2.11):

Fix a few more double words in docs.

2007-05-03 11:05  neilc

	* doc/src/sgml/: ddl.sgml (1.69.2.1), plperl.sgml (2.59.2.2),
	  spi.sgml (1.49.2.1):

Fix some typos in the documentation. Patch from Brian Gough. Backport
the relevant fixes to 8.2 as well.

2007-05-01 14:53  tgl

	* src/: backend/optimizer/util/clauses.c (1.223.2.3),
	  test/regress/expected/polymorphism.out (1.9.2.1),
	  test/regress/sql/polymorphism.sql (1.3.2.1):

Fix a thinko in my patch of a couple months ago for bug #3116: it did the
wrong thing when inlining polymorphic SQL functions, because it was using the
function's declared return type where it should have used the actual result
type of the current call.  In 8.1 and 8.2 this causes obvious failures even if
you don't have assertions turned on; in 8.0 and 7.4 it would only be a problem
if the inlined expression were used as an input to a function that did
run-time type determination on its inputs.  Add a regression test, since this
is evidently an under-tested area.

2007-04-27 03:55  meskes

	* src/interfaces/ecpg/ecpglib/extern.h (1.20.2.1):

Removed non-existant function from extern.h

2007-04-27 02:58  meskes

	* src/interfaces/ecpg/ecpglib/: descriptor.c (1.20.2.1), execute.c
	  (1.62.2.3):

Inlined two functions to get rid of va_list prolems on some archs.

2007-04-26 19:24  tgl

	* src/: backend/access/transam/xact.c (1.229.2.1),
	  backend/commands/prepare.c (1.66.2.1),
	  backend/executor/nodeSubplan.c (1.80.2.3),
	  backend/nodes/tidbitmap.c (1.10.2.1), backend/storage/smgr/md.c
	  (1.123.2.3), backend/utils/hash/dynahash.c (1.73.2.1),
	  backend/utils/mmgr/portalmem.c (1.97.2.1),
	  include/nodes/execnodes.h (1.161.2.2), include/utils/hsearch.h
	  (1.45.2.1):

Fix dynahash.c to suppress hash bucket splits while a hash_seq_search() scan
is in progress on the same hashtable.  This seems the least invasive way to
fix the recently-recognized problem that a split could cause the scan to
visit entries twice or (with much lower probability) miss them entirely.
The only field-reported problem caused by this is the "failed to re-find
shared lock object" PANIC in COMMIT PREPARED reported by Michel Dorochevsky,
which was caused by multiply visited entries.  However, it seems certain
that mdsync() is vulnerable to missing required fsync's due to missed
entries, and I am fearful that RelationCacheInitializePhase2() might be at
risk as well.  Because of that and the generalized hazard presented by this
bug, back-patch all the supported branches.

Along the way, fix pg_prepared_statement() and pg_cursor() to not assume
that the hashtables they are examining will stay static between calls.
This is risky regardless of the newly noted dynahash problem, because
hash_seq_search() has never promised to cope with deletion of table entries
other than the just-returned one.  There may be no bug here because the only
supported way to call these functions is via ExecMakeTableFunctionResult()
which will cycle them to completion before doing anything very interesting,
but it seems best to get rid of the assumption.  This affects 8.2 and HEAD
only, since those functions weren't there earlier.

2007-04-24 08:25  mha

	* src/backend/port/win32_sema.c (1.3.2.1):

Set maximum semaphore count to 32767 instead of 1. Fixes
errorcode 298 when unlocking a semaphore more than once.

Per report from Marcin Waldowski.

2007-04-23 12:52  neilc

	* doc/src/sgml/ref/create_function.sgml (1.70.2.2):

Fix newly-introduced documentation typo.

2007-04-23 11:13  neilc

	* src/backend/utils/misc/guc.c (1.360.2.1):

Fix LOCK_DEBUG compilation in the 8.2 branch; HEAD was fixed earlier.
Heikki Linnakangas.

-- 
Alvaro Herrera                         http://www.flickr.com/photos/alvherre/
"El Maquinismo fue proscrito so pena de cosquilleo hasta la muerte"
(Ijon Tichy en Viajes, Stanislaw Lem)

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 10 Jul 2007 17:05:47 -0400

> applied to 824 and how could I have determined this without this post?

If there were a real critical bug, there'd be a new release (which
would mean 8.2.5).  So the short answer is, "No."

But sometimes there are patches that are critical for you_ but not
_for everyone.  You can compare the difference
between the REL_[v_num]_STABLE and REL_[v_num]_[minor] of your
release to see if there's something.  You can do that by looking at
the CVS interface at
<http://developer.postgresql.org/cvsweb.cgi/pgsql/>, among other ways.

A
-- 
Andrew Sullivan  | [email-masked]
When my information changes, I alter my conclusions.  What do you do sir?
		--attr. John Maynard Keynes

---

From: Tom Lane <[email-masked]>
Date: Tue, 10 Jul 2007 19:39:47 -0400

> this easily, short of having a copy of the CVS repository.

The other way to check the change history is to troll the
pgsql-committers archives
http://archives.postgresql.org/pgsql-committers/
although certainly cvs2cl output is a lot easier to scan.

My $0.02: if you really want the latest and greatest, the nightly
snapshot tarball of the current stable branch would be the thing to
grab, rather than fooling with individual patches.

			regards, tom lane

---

From: Ray Stell <[email-masked]>
Date: Wed, 11 Jul 2007 08:14:13 -0400

On Tue, Jul 10, 2007 at 07:39:47PM -0400, Tom Lane wrote:
> snapshot tarball of the current stable branch 

sounds great, but I've no idea where to look for that. Thanks.

---

From: "Milen A. Radev" <[email-masked]>
Date: Wed, 11 Jul 2007 15:25:26 +0300

> sounds great, but I've no idea where to look for that. Thanks.

Probably here - http://www.postgresql.org/ftp/stable_snapshot/ .

-- 
Milen A. Radev

---

From: Alvaro Herrera <[email-masked]>
Date: Wed, 11 Jul 2007 08:49:37 -0400

> grab, rather than fooling with individual patches.

Hmm, do we include the cvs2cl-generated ChangeLog in the tarballs?

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 11 Jul 2007 09:06:09 -0400 (EDT)

> Hmm, do we include the cvs2cl-generated ChangeLog in the tarballs?

No, we don't.  We used to but the file got too large.  Perhaps we should
supply a URL that generates that information.

-- 
  Bruce Momjian  <[email-masked]>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---

From: Alvaro Herrera <[email-masked]>
Date: Wed, 11 Jul 2007 09:22:51 -0400

Bruce Momjian wrote:
> No, we don't.  We used to but the file got too large.

How about including the changelog until the branch point?

I remember there used to be ChangeLog files on CVS but that sounds a bit
redundant.  But I am thinking in generating them for the tarball only,
just like we provide the HTML docs or the bison output.

> Perhaps we should supply a URL that generates that information.

I think we should *also* do this.

FWIW I use

cvs2cl --revisions --no-indent --no-wrap --separate-header --follow $branch \
     --no-ancestors --accum

and it generates a 90k file when branch=REL8_2_STABLE (it only includes
the changes after REL8_2_STABLE was first tagged).

-- 
Alvaro Herrera                 http://www.amazon.com/gp/registry/CTMLCN8V17R4
Este mail se entrega garantizadamente 100% libre de sarcasmo.

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 11 Jul 2007 09:28:00 -0400 (EDT)

> just like we provide the HTML docs or the bison output.

Yes, they were just in the tarballs.

> the changes after REL8_2_STABLE was first tagged).

But then do we also supply the cvs2cl for a major release.  We certainly
could.

---

From: "Guillaume Lelarge" <[email-masked]>
Date: Wed, 11 Jul 2007 16:06:29 +0200 (CEST)

Bruce Momjian wrote:
>> [...]

That would be great. +5 :)

Regards.

-- 
Guillaume.

---

From: Tom Lane <[email-masked]>
Date: Wed, 11 Jul 2007 10:41:53 -0400

> supply a URL that generates that information.

There are a couple of different queries that people would be interested
in:

* the full cvs2cl log between any two release points;
* the cvs2cl log from latest release to branch tip.

I do not think it's appropriate to stick this into the tarballs, as
there's an awful lot of noise in the logs (eg, docs tweaks, reverted
patches, trivial code cleanups); our practice of generating a condensed
release-notes page is a large public service in my eyes.  But +1 to
providing a web page from which the detailed answers could be generated
easily.

BTW, cvs2cl (at least the version I use) works fine against a remote
repository, so it's not like Ray couldn't have gotten the answer for
himself.  But a web page would be more user-friendly.

			regards, tom lane

---

From: Alvaro Herrera <[email-masked]>
Date: Mon, 22 Dec 2008 09:28:11 -0300

Hi,

This was proposed over a year ago, here
http://archives.postgresql.org/message-id/25050.1184164913%40sss.pgh.pa.us

Any thoughts on how could we do it?  Maybe a hook on the anoncvs
auto-update thing, that regenerated a set of static files?

---

From: Magnus Hagander <[email-masked]>
Date: Mon, 22 Dec 2008 13:43:16 +0100

Seems doable, at least in theory :)

I've actually been toying with this a bit earlier, trying to get a
summary of the CVS log messages into a database. That could be used to
genereate pretty much anything. I ended up using the git repository
instead, because it was easier - but given that it appears to be fairly
fragile, I don't think that'd be a good idea in a case like this.

IIRC, cvs2cl can actually produce XML output, which we could "easily"
process and stick in a database, and then from there to the web. Adding
this intermediate step would allow us to produce the output in multiple
formats - for example, it wouldn't surprise me if people would
appreciate an RSS feed... (Again, I've used the git repo for this
myself, but that's proven to not be so good)

Not sure how to solve the second of Toms points there automatically
though - IIRC I hadn't solved the issue of getting the tags in there.

I think it's easier to just run it with a cronjob, rather than trying to
put more stuff into the commit hooks. We could still use it to trigger a
run if the runs appear to be too slow - but I don't think we need
anything like 5-minute granularity on the updates (which is the main
reason for that commit hook)

//Magnus

---

From: Magnus Hagander <[email-masked]>
Date: Mon, 22 Dec 2008 17:24:31 +0100

> Seems doable, at least in theory :)

I've cleaned up my script a bit and am running some further tests now.

>>> himself.  But a web page would be more user-friendly.

What version is this? Mine seems to need a local checkout to work at all...

//Magnus

---

From: Tom Lane <[email-masked]>
Date: Mon, 22 Dec 2008 11:56:45 -0500

> What version is this? Mine seems to need a local checkout to work at all...

Yeah, mine too, but you can certainly make a local checkout if you have
access to the remote repository.

One thing to watch out for is that (at least in the version I use) what
cvs2cl seems to care about is having a local directory structure that
matches the repository.  If you use the -P option to prune away local
subdirectories that no longer contain any live files, then cvs2cl won't
find log entries for the files that had been in that subdirectory.
Most of the time this isn't a huge problem, but if you want a complete
history then it's a good idea to make your checkout without -P.

			regards, tom lane

---

From: Magnus Hagander <[email-masked]>
Date: Tue, 23 Dec 2008 09:54:23 +0100

> access to the remote repository.

Ah, misunderstanding..

> history then it's a good idea to make your checkout without -P.

Good point, will be sure not to do that...

//Magnus