Re: preserving forensic information when we freeze - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: preserving forensic information when we freeze
Date
Msg-id 20130529155502.GB15045@eldon.alvh.no-ip.org
Whole thread Raw
In response to Re: preserving forensic information when we freeze  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas escribió:
> On Tue, May 28, 2013 at 10:08 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> > On 2013-05-28 21:26:49 -0400, Robert Haas wrote:

> >> > I am all for adding a comment why this is safe though. We thought about
> >> > it for some while before we were convinced...
> >>
> >> I'm fine with that, but the logic is present in multiple places, and I
> >> did not want to comment them all identically.  If there's a central
> >> place in which a comment would be appropriate, let's add it there; or
> >> IOW, what do you suggest in detail?
> >
> > That's a good point. Generally lots of this is underdocumented/commented
> > and can only learned by spending a year or so in the postgres code. I'd
> > say rename README.HOT to README and add a section there and reference it
> > from those two places? It already has a mostly general explanation of
> > concurrent index builds. Don't have a better idea.
> 
> Anyone else have a suggestion?

I support the idea of using README files.  I don't have an opinion on
whether it's best to have a single file for everything (i.e. rename
README.HOT and add to it) or just explain this in README.freeze or
something like that.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: fallocate / posix_fallocate for new WAL file creation (etc...)
Next
From: Cédric Villemain
Date:
Subject: Re: PostgreSQL 9.3 beta breaks some extensions "make install"