public inbox for [email protected]
help / color / mirror / Atom feedRe: Question regarding how databases support atomicity
2+ messages / 2 participants
[nested] [flat]
* Re: Question regarding how databases support atomicity
@ 2024-05-04 03:02 Siddharth Jain <[email protected]>
2024-05-04 03:10 ` Re: Question regarding how databases support atomicity David G. Johnston <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Siddharth Jain @ 2024-05-04 03:02 UTC (permalink / raw)
To: [email protected]
On Fri, May 3, 2024 at 8:00 PM Siddharth Jain <[email protected]> wrote:
> I am trying to sharpen my understanding of databases. Let's say there is
> an operation foo as part of the public API that internally translates to
> more than 1 operation - I am sure there are examples like this in postgres.
> So to do foo we have to do following in order in all or none fashion:
>
> 1. Step 1
> 2. Step 2
> 3. Step 3
>
> The way I understand this is that if there is a failure in-between, we
> start undoing and reverting the previous operations one by one. But what if
> there is a failure and we are not able to revert an operation. How is that
> situation handled? e.g., something failed when we tried to do Step 3. now
> we revert Step 2 and succeed. but when we try to revert step 1 we fail.
> what happens now? To me, it seems its impossible to guarantee true
> atomicity in general.
>
> S.
>
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Question regarding how databases support atomicity
2024-05-04 03:02 Re: Question regarding how databases support atomicity Siddharth Jain <[email protected]>
@ 2024-05-04 03:10 ` David G. Johnston <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: David G. Johnston @ 2024-05-04 03:10 UTC (permalink / raw)
To: Siddharth Jain <[email protected]>; +Cc: [email protected] <[email protected]>
On Friday, May 3, 2024, Siddharth Jain <[email protected]> wrote:
>
>
> On Fri, May 3, 2024 at 8:00 PM Siddharth Jain <[email protected]> wrote:
>
>> I am trying to sharpen my understanding of databases. Let's say there is
>> an operation foo as part of the public API that internally translates to
>> more than 1 operation - I am sure there are examples like this in postgres.
>> So to do foo we have to do following in order in all or none fashion:
>>
>> 1. Step 1
>> 2. Step 2
>> 3. Step 3
>>
>> The way I understand this is that if there is a failure in-between, we
>> start undoing and reverting the previous operations one by one.
>>
>
Not in PostgreSQL. All work performed is considered provisional until a
commit succeeds. At which point all provisional work, which had been
tagged with the same transaction identifier, becomes reality to the rest of
the system, by virtue of marking the transaction live. If the commit never
happens, either because of error, rollback, or session end, the transaction
ends up being left unalive and eventually is cleaned up.
You need to ensure a “begin” happens before Step 1 and a “commit” after
Step 3.
David J.
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2024-05-04 03:10 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-05-04 03:02 Re: Question regarding how databases support atomicity Siddharth Jain <[email protected]>
2024-05-04 03:10 ` David G. Johnston <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox