Re: table as log (multiple writers and readers) - Mailing list pgsql-general

From David Wilson
Subject Re: table as log (multiple writers and readers)
Date
Msg-id e7f9235d0804221159w10b50de1y9b1d87181249c9aa@mail.gmail.com
Whole thread Raw
In response to Re: table as log (multiple writers and readers)  (Joris Dobbelsteen <joris@familiedobbelsteen.nl>)
Responses Re: table as log (multiple writers and readers)  ("Gurjeet Singh" <singh.gurjeet@gmail.com>)
List pgsql-general
On Tue, Apr 22, 2008 at 2:48 PM, Joris Dobbelsteen
<joris@familiedobbelsteen.nl> wrote:
>
>  Ah, yes, all visible rows...
>  My point is that, unless you use a transaction with serializable isolation,
> this all visible rows for the second statement might be different from those
> that you copied into the log table.
>
>  With the normal Read committed isolation level you suffer from a possible
> nonrepeatable read that might change tuple visibility between different
> statements.

That depends on implementation. A select into ... to do the initial
copy followed by a delete where... with the where clause referencing
the log table itself to ensure that we delete only things that now
exist in the log table, or a row by row  insert/delete pair. Either
would provide the appropriate level of protection from accidental
deletion of more things than you intended without harming concurrency.
The delete referencing the log table might require that the log table
be indexed for performance, but it's likely that such indexing would
be done anyway for general log use.
--
- David T. Wilson
david.t.wilson@gmail.com

pgsql-general by date:

Previous
From: Joris Dobbelsteen
Date:
Subject: Re: table as log (multiple writers and readers)
Next
From: Mary Ellen Fitzpatrick
Date:
Subject: Re: Can not restart postgres: Panic could not locate a valid checkpoint record