Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
PostgreSQL 9.0 arrives with many new features
Posted Sep 21, 2010 20:04 UTC (Tue) by andresfreund (subscriber, #69562)
So, the usage of stored procedures shouldn't matter...
Posted Sep 21, 2010 20:23 UTC (Tue) by ScOut3R (guest, #69996)
Posted Sep 22, 2010 11:59 UTC (Wed) by smurf (subscriber, #17840)
..., except that said stored procedure affects something outside of PostgreSQL. I might actually want that to happen on the backup server too.
Posted Sep 22, 2010 17:28 UTC (Wed) by captrb (subscriber, #2291)
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)
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.
Posted Oct 3, 2010 22:50 UTC (Sun) by Wol (guest, #4433)
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!".
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds