From: | "David Wilson" <david(dot)t(dot)wilson(at)gmail(dot)com> |
---|---|
To: | "Joris Dobbelsteen" <joris(at)familiedobbelsteen(dot)nl> |
Cc: | "Vance Maverick" <vmaverick(at)pgp(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: table as log (multiple writers and readers) |
Date: | 2008-04-22 00:05:50 |
Message-ID: | e7f9235d0804211705j626af5eco35ce861c8cba5d6@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, Apr 21, 2008 at 7:55 PM, Joris Dobbelsteen
<joris(at)familiedobbelsteen(dot)nl> wrote:
>
> If you want to clean up the the staging table I have some concerns about
> the advisory lock. I think you mean exclusive table lock.
Either works, really. An advisory lock is really just a lock over
which you have control of the meaning, as long as you're using it in
the appropriate places. Also, an advisory lock on just the processes
doing staging-to-log moves would allow writes into the staging table
to continue concurrently with the staging-to-log transaction (whereas
an exclusive lock would unnecessarily prevent them).
Also, while Vance appears to have chosen to have a dedicated
staging-to-log process, even that isn't necessary- each reader can
simply do the lock/clear staging/unlock before any attempt to read-
unless you're polling that log table at truly crazy rates, the
overhead should be negligible and will ensure that the staging table
is simply cleared out "whenever necessary" while removing the
complexity of a separate process.
--
- David T. Wilson
david(dot)t(dot)wilson(at)gmail(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Christophe | 2008-04-22 02:44:48 | Schema migration tools? |
Previous Message | Joris Dobbelsteen | 2008-04-21 23:55:36 | Re: table as log (multiple writers and readers) |