Re: PITR Dead horse?

Totally agree. Robustness and rock-solidness are the only
things missing for PostgreSQL to become the killer of certain
commercial enterprise databases out there. And the only thing
that is missing in this respect is PITR. PITR should be there
INGRES had it in '84 and some people as why PostgreSQL does
not have it.

I am well versed in the internals of "PITR" features of a certain
leading enterprise-class database out there. And would like to
contribute (write code) to this effort as much as I can.

Best regards,
Nicolai Tufar

> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org [mailto:pgsql-hackers-
> owner(at)postgresql(dot)org] On Behalf Of Simon Riggs
> Sent: Thursday, February 05, 2004 1:33 AM
> To: 'Tom Lane'; 'Marc G. Fournier'
> Cc: 'Tatsuo Ishii'; snaga(at)snaga(dot)org; austin(at)coremetrics(dot)com; pgsql-
> hackers(at)postgresql(dot)org
> Subject: Re: [HACKERS] 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
>
>
> ---------------------------(end of
broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if
your
> joining column's datatypes do not match