Re: serializable read only deferrable - Mailing list pgsql-hackers

From Florian Pflug
Subject Re: serializable read only deferrable
Date
Msg-id 94C154B6-0F9E-43B0-A245-1CFA8630064A@phlo.org
Whole thread Raw
In response to serializable read only deferrable  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: serializable read only deferrable  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers
On Dec5, 2010, at 16:11 , Kevin Grittner wrote:
> The simple way to implement SERIALIZABLE READ ONLY DEFERRABLE under
> SSI would be to have each non-read-only serializable transaction
> acquire a heavyweight lock which can coexist with other locks at the
> same level (SHARE looks good) on some common object and hold that for
> the duration of the transaction, while a SERIALIZABLE READ ONLY
> DEFERRABLE transaction would need to acquire a conflicting lock
> (EXCLUSIVE looks good) before it could acquire a snapshot, and
> release the lock immediately after acquiring the snapshot.

Hm, so once a SERIALIZABLE READ ONLY DEFERRABLE is waiting to acquire the lock, no other transaction would be allowed
tostart until the SERIALIZABLE READ ONLY DEFERRABLE transaction has been able to acquire its snapshot. For pg_dump's
purposesat least, that seems undesirable, since a single long-running transaction at the time you start pg_dump would
effectlyDoS your system until the long-running transaction finishes. 

The alternative seems to be to drop the guarantee that a SERIALIZABLE READ ONLY DEFERRABLE won't be starved forever by
astream of overlapping non-READ ONLY transactions. Then a flag in the proc array that marks non-READ ONLY transactions
shouldbe sufficient, plus a wait-and-retry loop to take snapshots for SERIALIZABLE READ ONLY DEFERRABLE transactions. 

best regards,
Florian Pflug



pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: pg_execute_from_file review
Next
From: marcin mank
Date:
Subject: Re: WIP patch for parallel pg_dump