Re: Simple Atomic Relationship Insert
От | Robert DiFalco |
---|---|
Тема | Re: Simple Atomic Relationship Insert |
Дата | |
Msg-id | CAAXGW-wK9+5edzggoBfAvmTvcgV2Q-nuNCff1GihP8aKD-Y+HQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Simple Atomic Relationship Insert (Brian Dunavant <brian@omniti.com>) |
Ответы |
Re: Simple Atomic Relationship Insert
|
Список | pgsql-general |
Good points. I guess my feeling is that if there can be a race condition on INSERT then the CTE version is not truly atomic, hence the LOOP.
On Tue, Jan 13, 2015 at 3:11 PM, Brian Dunavant <brian@omniti.com> wrote:
A very good point, but it does not apply as here (and in my article)
we are not using updates, only insert and select.
On Tue, Jan 13, 2015 at 6:03 PM, Thomas Kellerer <spam_eater@gmx.net> wrote:
> Brian Dunavant wrote on 13.01.2015 22:33:
>>
>> What issue are you having? I'd imagine you have a race condition on
>> the insert into hometowns, but you'd have that same race condition in
>> your app code using a more traditional 3 query version as well.
>>
>> I often use CTEs like this to make things atomic. It allows me to
>> remove transactional code out of the app and also to increase
>> performance by reducing the back-and-forth to the db.
>> http://omniti.com/seeds/writable-ctes-improve-performance
>>
>
> Craig Ringer explained some of the pitfalls of this approach here:
>
> http://dba.stackexchange.com/questions/78510/why-is-cte-open-to-lost-updates
>
> which is a follow up question based on this:
> http://stackoverflow.com/a/8702291/330315
>
> Thomas
>
>
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
В списке pgsql-general по дате отправления: