| From: | PetSerAl <petseral(at)gmail(dot)com> |
|---|---|
| To: | pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Synchronous commit after asynchronous commit |
| Date: | 2024-12-26 17:40:44 |
| Message-ID: | CAKygsHRz=pu35g0rGW8xPorho=1x+BKFd3_HegDerzgi2UYabw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
--setup
create table a(i int);
create table b(i int);
insert into a values (1);
insert into b values (1);
-- case 1
set synchronous_commit = off;
begin read write;
update a set i = i + 1;
commit;
set synchronous_commit = on;
begin read write;
update b set i = i + 1;
commit;
-- case 2
set synchronous_commit = off;
begin read write;
update a set i = i + 1;
commit;
set synchronous_commit = on;
begin read only;
select i from a;
commit;
-- case 3
set synchronous_commit = off;
begin read write;
update a set i = i + 1;
commit;
set synchronous_commit = on;
begin read only;
select i from b;
commit;
-- case 4
set synchronous_commit = off;
begin read write;
update a set i = i + 1;
commit;
set synchronous_commit = on;
begin read only;
commit;
As I understand documentation, case 1 is clear: following synchronous
commit of read write transaction force previous asynchronous commits
to be flushed with it. But what about case 2 (read changes from
asynchronous commit), case 3 (read unrelated data) and case 4 (empty
commit)? Would synchronous commit of read only transaction force
previous asynchronous commits to be flushed to disk?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeremy Schneider | 2024-12-26 20:21:08 | Re: Disabling vacuum truncate for autovacuum |
| Previous Message | Slava Shpitalny | 2024-12-26 11:48:59 | Re: could not open file "base/XX/XX": Interrupted system call |