Re: PITR Dead horse?

>Tom Lane wrote
> "Marc G. Fournier" <scrappy(at)postgresql(dot)org> writes:
> > Is this something large enough, like the win32 stuff, that having a
side
> > list for discussions is worth setting up?
>
> In terms of the amount of code to be written, I expect it's larger
than
> the win32 porting effort. And it should be mostly pretty separate
from
> hacking the core backend, since most of what remains to do is writing
> external management utilities (I think).

Yes it is! I'd like to start the discussion about PITR and try to go
through some functional requirements and how those might be implemented.
The Win32 port has a self-evident set of functional requirements; I'm
not sure that the PITR stuff is as clear - so I couldn't pass any
judgement at all (even if I did know the code well enough) on how big a
coding task that is, but I can see that the analysis and discussion is
large indeed.

> I've been dissatisfied with having the separate pgsql-hackers-win32
> list; I feel it just fragments the discussion, and people tend to end
up
> crossposting to -hackers anyway. But a separate list for PITR work
> might be a good idea despite that experience, since it seems like it'd
> be a more separable project.

I'd vote for a new list dedicated to discussing "Robustness" issues,
such as PITR and the fsync/sync issues. IMHO, PostgreSQL has the
Functionality and Performance, it just needs some rock-solid analysis of
where-things-can-go-wrong with it, so that the business data centre
people will be able to use it with absolute confidence...even if the
answer is "we've got every base covered". For me, the issues about
robustness are as much to do with risk reduction and confidence building
as they are about specific features in that area. [Wow, I expect some
flames on those comments!]

The list probably would remain clearly differentiated, in the same way
[Performance] covers lots of areas not discussed in [Hackers].

Not hung up on the name either, just something that indicates
breadth-of-scope, e.g. Availability or Data Protection or Resilience
etc..; maybe the Advocates would like to name it? It might even be a
press-release: "PostgreSQL community focuses new efforts towards
Robustness features for its next major release".

Best Regards, Simon Riggs