Thread: Latest checkpoint's NextOID
Hello Admins,
i’m using 9.1 PostgreSQL and looking for a function to write WAL to table in order to save all the data into database and to make a recovery on the 2nd DB Server.
The idea is to help recovery on other server and get the same OID on the 2nd Server and that’s by using the Latest checkpoint's NextOID from the first Server.
Any help will be helpful
Regards
Muthana
Tel.: +49.40.42878.2338
E-Mail: m.al@tu-harburg.de
On 25 September 2014 11:12, AL-Temimi, Muthana <muthana.al-temimi@tu-harburg.hamburg.de> wrote: > i’m using 9.1 PostgreSQL and looking for a function to write WAL to table in > order to save all the data into database and to make a recovery on the 2nd > DB Server. > > > > The idea is to help recovery on other server and get the same OID on the 2nd > Server and that’s by using the Latest checkpoint's NextOID from the first > Server. A short explanation of what you're trying to do and what is wrong with existing replication techniques would be the place to start. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On 25 September 2014 11:12, AL-Temimi, Muthana <muthana.al-temimi@tu-harburg.hamburg.de> wrote: > i’m using 9.1 PostgreSQL and looking for a function to write WAL to table in > order to save all the data into database and to make a recovery on the 2nd > DB Server. > > > > The idea is to help recovery on other server and get the same OID on the 2nd > Server and that’s by using the Latest checkpoint's NextOID from the first > Server. Why not use WAL-shipping or streaming replication the normal way? You do realize that everything that goes into tables goes into the WAL, so you write WAL into a table, the table gets loggedto WAL, and then that WAL... That's just not going to work, unless you use an unlogged table, in which case you havea replication/recovery mechanism which is inherently unreliable, which is pretty worthless. So the whole idea seems tobe unrealistic. Now, if you want to log changes to tables into a table, that's doable via triggers, usually for audit purposes, but it canbe used to keep replicas in synch. It's just that it's hard to imagine what you'd do that Slony-I doesn't already do,assuming you even need its features as opposed to streaming replication. -- Scott Ribe scott_ribe@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice