|
Home > Archive > Slony1 PostgreSQL Replication > August 2005 > tweaking denyAccess()
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
tweaking denyAccess()
|
|
| George McQuade 2005-08-26, 8:24 pm |
| Hello List,
We are happily replicating branches (providers) 1,2,3 and 4 into
corporate server (subscriber) 999 using separate schemas s1,s2,s3 and
s4. Everything works great.
All users using server 999 know all data is for read-only purposes, and
they certainly appreciate slony's denyAccess() reminder message any time
someone attempts to write to one of the replicas.
The question is, is it feasible to tweak denyAccess() to redirect the
write request back to the provider for inclusion in the db?
I know this can be done at the application level, but denyAccess() seems
to be one place where this can happen without modifying the app.
Users realize the write will not be as fast as if it was done on a local
server and they also know it may fail if the link happens to be down,
but they still benefit from the convenience of it all being transparent.
Any input is welcome.
george
| |
| Darcy Buskermolen 2005-08-26, 8:24 pm |
| On Friday 26 August 2005 13:43, George McQuade wrote:
> Hello List,
>
> We are happily replicating branches (providers) 1,2,3 and 4 into
> corporate server (subscriber) 999 using separate schemas s1,s2,s3 and
> s4. Everything works great.
>
> All users using server 999 know all data is for read-only purposes, and
> they certainly appreciate slony's denyAccess() reminder message any time
> someone attempts to write to one of the replicas.
>
> The question is, is it feasible to tweak denyAccess() to redirect the
> write request back to the provider for inclusion in the db?
>
> I know this can be done at the application level, but denyAccess() seems
> to be one place where this can happen without modifying the app.
>
> Users realize the write will not be as fast as if it was done on a local
> server and they also know it may fail if the link happens to be down,
> but they still benefit from the convenience of it all being transparent.
>
> Any input is welcome.
I can't make a good argument for doing so, I would see this as a way to
provide the user with a very false sence of database level multimaster
replication, which Slony-I is well stated not.
>
> george
>
> ____________________
____________________
_______
> Slony1-general mailing list
> Slony1-general- AuKwsB3Fm+ugFIWk8tvy
RWD2FQJk+8+b@public.gmane.org
> http://gborg.postgresql.org/mailman.../slony1-general
--
Darcy Buskermolen
Wavefire Technologies Corp.
http://www.wavefire.com
ph: 250.717.0200
fx: 250.763.1759
|
|
|
|
|