On 7/7/06, Martijn van Oosterhout kleptog@svana.org wrote:
Something I've been thinking of while reading this thread. One bigdisadvantage of doing it in the backend is that your methods ofreturning data are limited. Your resultset can only return one type.
For example, if you start decoding all
Diogo Biazus [EMAIL PROTECTED] writes:
I exposed the idea of bringing the xlogdump functionality to a backend
module. The main drawback is the use case where the database is down. But
the access to a failed cluster isn't impossible, just a little bit more
dificult, requiring another cluster
On 07 Jul 2006 09:58:29 -0400, Greg Stark [EMAIL PROTECTED]
wrote:
Diogo Biazus [EMAIL PROTECTED] writes: I exposed the idea of bringing the xlogdump functionality to a backend
module. The main drawback is the use case where the database is down. But
the access to a failed cluster isn't
On Fri, Jul 07, 2006 at 11:59:41AM -0300, Diogo Biazus wrote:
On 07 Jul 2006 09:58:29 -0400, Greg Stark [EMAIL PROTECTED] wrote:
That's the main reason I think a stand-alone module makes more
sense. You can always take a stand-alone module and stick an
interface to it into the server. You
I've worked on a prototype (attached to this email) of the SRF function and I can query the xlog files for some useful info.I know that the error codes are still incorrect and the tests are missing, but this is only a proof of concept.
Examples of usage:Query for committed transactions on the xlog
