| From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
|---|---|
| To: | Neil Conway <neilc(at)samurai(dot)com> |
| Cc: | Jan Wieck <JanWieck(at)Yahoo(dot)com>, shridhar_daithankar(at)persistent(dot)co(dot)in, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Big 7.4 items |
| Date: | 2002-12-14 00:48:09 |
| Message-ID: | 200212140048.gBE0m9s02402@candle.pha.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Neil Conway wrote:
> On Fri, 2002-12-13 at 13:36, Jan Wieck wrote:
> > But you cannot use the result of such a SELECT to update anything. So
> > you can only phase out complete read only transaction to the slaves.
> > Requires support from the application since the load balancing system
> > cannot know automatically what will be a read only transaction and what
> > not.
>
> Interesting -- SQL contains the concept of "read only" and "read write"
> transactions (the default is RW). If we implemented that (which
> shouldn't be too difficult[1]), it might make differentiating between
> classes of transactions a little easier. Client applications would still
> need to be modified, but not nearly as much.
>
> Does this sound like it's worth doing?
>
> [1] -- AFAICS, the only tricky implementation detail is deciding exactly
> which database operations are "writes". Does nextval() count, for
> example?
You can't migrate a session between nodes, so the entire _session_ has
to be read-only.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2002-12-14 00:50:25 | Re: [GENERAL] PostgreSQL Global Development Group Announces |
| Previous Message | Iavor Raytchev | 2002-12-14 00:44:57 | Re: [GENERAL] PostgreSQL Global Development Group Announces |