Re: Tuple concurrency issue in large objects

Поиск
Список
Период
Сортировка
От Justin
Тема Re: Tuple concurrency issue in large objects
Дата
Msg-id CALL-XePGYWna1N871GVrnd7+abFKDmOxEN3Pi6Aw_=xPAz=1DA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Tuple concurrency issue in large objects  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Tuple concurrency issue in large objects  (Shalini <shalini@saralweb.com>)
Список pgsql-general
I agree  completely, 

I do not think Postgresql is a good fit for Shalini based on the conversation so far

tracking Concurrency is going to be a killer...  But i see the temptation to use a DB for this as the updates are ACID less likely to corrupted data for X reason 

On Wed, Dec 18, 2019 at 12:12 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Justin <zzzzz.graf@gmail.com> writes:
> I now see what is causing this specific issue...
> The update and row versions is happening on 2kb chunk at a time,  That's
> going to make tracking what other clients are doing a difficult task.

Yeah, it's somewhat unfortunate that the chunkiness of the underlying
data storage becomes visible to clients if they try to do concurrent
updates of the same large object.  Ideally you'd only get a concurrency
failure if you tried to overwrite the same byte(s) that somebody else
did, but as it stands, modifying nearby bytes might be enough --- or
not, if there's a chunk boundary between.

On the whole, though, it's not clear to me why concurrent updates of
sections of large objects is a good application design.  You probably
ought to rethink how you're storing your data.

                        regards, tom lane

В списке pgsql-general по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Tuple concurrency issue in large objects
Следующее
От: Steven Lembark
Дата:
Сообщение: Re: How to prevent POSTGRES killing linux system from accepting toomuch inserts?