From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Siddharth Jain <siddhsql(at)gmail(dot)com> |
Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Question regarding how databases support atomicity |
Date: | 2024-05-07 17:04:44 |
Message-ID: | 4133571.1715101484@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Siddharth Jain <siddhsql(at)gmail(dot)com> writes:
> Thanks All for the kind responses. I understand how MVCC takes care of
> atomicity for updates to rows. I was developing a project where lets say
> data for each table is stored in its own folder together with metadata (we
> are not talking postgres now). So if I have two tables A and B I have a
> folder structure like:
> A
> \_ metadata.json
> B
> \_ metadata.json
> Now if I want to rename a table, I need to move the folder and also update
> metadata accordingly. These are two separate operations but need to be done
> atomically - all or none. in this case it is possible that we succeed in
> renaming the folder but fail to update metadata for whatever reason. then
> if we try to undo the folder rename we get another failure for whatever
> reason. how to deal with such scenarios? are there no such scenarios in
> postgres?
There aren't, because we don't assume that we can apply filesystem
metadata changes like that. That's why our on-disk files are not
named after their tables ;-) --- that way they never need renaming.
https://www.postgresql.org/docs/current/storage-file-layout.html
There may be filesystems out there that would give you guarantees in
this area, but it'd require non-POSIX and hence non-portable system
calls.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2024-05-07 17:15:23 | Re: Question regarding how databases support atomicity |
Previous Message | Tom Lane | 2024-05-07 16:57:33 | Re: Forcing INTERVAL days display, even if the interval is less than one day |