From: | Markus Schiltknecht <markus(at)bluegap(dot)ch> |
---|---|
To: | org(at)kewlstuff(dot)co(dot)za |
Cc: | Tino Wildenhain <tino(at)wildenhain(dot)de>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: STOP all user access except for admin for a few minutes? |
Date: | 2007-01-24 17:10:19 |
Message-ID: | 45B792FB.8050304@bluegap.ch |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Hi,
org(at)kewlstuff(dot)co(dot)za wrote:
> Ha ha... thx Tino
> Yes, I think this is way to go, strange how my mind climbs the wrong
> tree sometimes :)
> I actually need to aquire a transaction across several dB's, check if
> the conditions are right, and then modify some tables, write and remove
> some triggers.
> Transactions in postgres are 2 sophisticated, I dont think they will
> hold the locks at the level I need them.
You want to read about explicit locking:
http://www.postgresql.org/docs/8.2/static/explicit-locking.html
> But I was thinking (climbing out of the wrong tree;)... I can just
> aquire exclusive locks on the tables, and hey presto, users are on hold
> while the software checks the dB's.
I'm sure, that's possible. However, I remember you were talking about
replication, thus I have to add a warning: please keep in mind that this
does not scale. You're most probably better using two phase commit,
aren't you?
Regards
Markus
From | Date | Subject | |
---|---|---|---|
Next Message | brian | 2007-01-24 17:27:04 | Re: missing cache data for cache id 27 |
Previous Message | Richard Huxton | 2007-01-24 17:07:38 | Re: missing cache data for cache id 27 |
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2007-01-24 17:27:43 | Recursive Queries |
Previous Message | Luis D. García | 2007-01-24 16:56:14 | Access last inserted tuple info... |