| |||||||||||||
PostgreSQL 9.0 arrives with many new featuresPostgreSQL 9.0 arrives with many new featuresPosted Sep 21, 2010 19:54 UTC (Tue) by ScOut3R (guest, #69996)In reply to: PostgreSQL 9.0 arrives with many new features by flewellyn Parent article: PostgreSQL 9.0 arrives with many new features
Yes, replication looks promising. Is there any documentation how it handles stuff under the hood? My biggest concern is how it handles stored procedures.
(Log in to post comments)
PostgreSQL 9.0 arrives with many new features Posted Sep 21, 2010 20:04 UTC (Tue) by andresfreund (subscriber, #69562) [Link]
Its binary log shipping - its shipping the write ahead log (which is also used for crash-safety) to the standby which does a "nearly normal" recovery.
The only difference is that it allows you to connect to it after it reaches a stable point.
So, the usage of stored procedures shouldn't matter...
PostgreSQL 9.0 arrives with many new features Posted Sep 21, 2010 20:23 UTC (Tue) by ScOut3R (guest, #69996) [Link]
Thank You for the clarification!
PostgreSQL 9.0 arrives with many new features Posted Sep 22, 2010 11:59 UTC (Wed) by smurf (subscriber, #17840) [Link]
> So, the usage of stored procedures shouldn't matter...
..., except that said stored procedure affects something outside of PostgreSQL. I might actually want that to happen on the backup server too.
PostgreSQL 9.0 arrives with many new features Posted Sep 22, 2010 17:28 UTC (Wed) by captrb (subscriber, #2291) [Link]
That seems like a fragile way to do things. Rather than have stored procedures cause side effects outside the database, what if you published events to a listen/notify queue, then have external processes reading the queues and cause the external state change. Have multiple queues for multiple recipients. The master and backup server would read the events from the currently-active database, failing over like the rest of your applications.
Slave servers vs. Stored Procedures Posted Sep 22, 2010 18:55 UTC (Wed) by smurf (subscriber, #17840) [Link]
The operative word here is "queue". If I want to keep the database and the external world in sync, I can't queue my changes.
Of course, it's a trade-off, and has its own pitfalls (what if the stored procedure works on the master but fails on the slave?). But so has every other solution.
PostgreSQL 9.0 arrives with many new features Posted Oct 3, 2010 22:50 UTC (Sun) by Wol (guest, #4433) [Link]
If you're worried about that, shouldn't you be using transactions as well as stored procedures?
And in the databases I use, using a stored procedure like that would cause the application to fail - "side effects are not permitted in a transaction!".
Cheers,
|
|||||||||||||