I'm working on Tom's xlogdump tool to add some functionality.
IMHO some useful improvements would be and an idea of implementation:


- have an options to output only the transactions with their status and some
aggregate data (transaction size).

When the user pass a -t parameter, instead of printing echa record info the
program uses a linked list to acumulate the total length and status info
about each xid. The status begin with NOT COMMITED, it can change to
COMMITED or ABORTED. If the user pass all the files in the pg_xlog directory
as parameters he knows the current status of each transaction.

- Find loser transactions (not commited to the end of the log)

I though of doing this for the only transactions option (see above).

- Have a filter to get a specifid rmid

There's always grep, but for windows users it might be interesting to filter
records by rmid. There can be a flag like -r (from rmname), or -o
(operation) where the user can pass a parameter like: xact, heap, etc...
And then filter the output records.

- Option to translate OIDs to names given a database connection

I receive parameters to open a connection (the usual -h, -p and -U). In the
startup I try to open a connection. If the user passes the parameters of the
connection the application automaticaly enter in the translate oids mode.
Then each data returning function tries to get from the connected database
the objects name.

- Extract the exact SQL statement in cases of xlog generated by
insert/update/delete.

This is the one where I need help from you the most. I'm not certain of how
to implement. But as I can see, I'll need to get object's structure from the
system catalog to decode the statement. So this option will be available
only if you have a connection to the database. Is this right?

I'd like to have opinions on the subject. If somebody could give me some
advice on how to start the last feature (decode the statemets) I'd apreciate
very much.

--
Diogo Biazus - diogob@gmail.com
Móvel Consultoria
http://www.movelinfo.com.br
http://www.postgresql.org.br

On Fri, Jul 14, 2006 at 10:43:15AM -0300, Diogo Biazus wrote:
> I'm working on Tom's xlogdump tool to add some functionality.
> IMHO some useful improvements would be and an idea of implementation:

<snip>

Neato. Looks like good stuff there.
> - Extract the exact SQL statement in cases of xlog generated by
> insert/update/delete.
>
> This is the one where I need help from you the most. I'm not certain of how
> to implement. But as I can see, I'll need to get object's structure from the
> system catalog to decode the statement. So this option will be available
> only if you have a connection to the database. Is this right?

Well, obvously you can only create dummy statements that acheives the
same effect, you can't get exactly the statements executed. That's
still useful though.

Decoding tuples is tricky, if done externally. If you're inside the
backend you could use the functions there. What you need to do is build
a table of all the columns and their types. For each type you need to
get the info needed to decode it. Finally, you extract the data and
convert it to a readable form.

If you really want to tackle this the hard way, find some other program
that does it. Here one written in Perl that can decode most tuples, but
not all. It fails because it doesn't recognise all the types.

http://svana.org/kleptog/pgsql/pgfsck.html

Have a ncie day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEt6QMIB7bNG8LQkwRAmX/AJ9jBAyNr9dj4wfzCtgzlsqdP59ocACfZ77n
OfemHwlYVKk2cXzwgFsIxaM=
=N1RE
-----END PGP SIGNATURE-----

On 7/14/06, Martijn van Oosterhout <kleptog@svana.org> wrote:
> If you really want to tackle this the hard way, find some other program
> that does it. Here one written in Perl that can decode most tuples, but
> not all. It fails because it doesn't recognise all the types.

Yep Diogo, Martijn is correct. You have to reassemble the tuple and
then generate the appropriate SQL statement for it. For this, you'll
definitely need the catalog information to resolve relations, type
handling, etc.

--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation | fax: 732.331.1301
33 Wood Ave S, 2nd Floor | jharris@enterprisedb.com
Iselin, New Jersey 08830 | http://www.enterprisedb.com/

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

On 7/14/06, Jonah H. Harris <jonah.harris@gmail.com> wrote:
>
> On 7/14/06, Martijn van Oosterhout <kleptog@svana.org> wrote:
> > If you really want to tackle this the hard way, find some other program
> > that does it. Here one written in Perl that can decode most tuples, but
> > not all. It fails because it doesn't recognise all the types.
>
> Yep Diogo, Martijn is correct. You have to reassemble the tuple and
> then generate the appropriate SQL statement for it. For this, you'll
> definitely need the catalog information to resolve relations, type
> handling, etc.
>
> Thanks for the info, I'm taking a look in that program. Is good to have a
starting point :-)

--
Diogo Biazus - diogob@gmail.com
Móvel Consultoria
http://www.movelinfo.com.br
http://www.postgresql.org.br