[PATCH] Attempt to clarify example of serialization anomaly

Started by Will Mortensenover 3 years ago3 messagesdocs
Beta feature

Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.

appliessuccessCI history

You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:

docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t77348
psql -h localhost -U postgres

Built from patchset v2 (message #2), September 20, 2026 at 05:17 AM.

Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:

git clone --branch t77348_2 https://github.com/hackorum-dev/postgres.git

In a checkout you already have, add the fork once:

git remote add hackorum https://github.com/hackorum-dev/postgres.git

then, for this patchset and every later one:

git fetch hackorum t77348_2 && git checkout t77348_2

Patchset v2 (message #2) is on t77348_2

Jump to latest
#1Will Mortensen
will@extrahop.com

(sorry to the CCs for sending this twice)

This example has been pointed out as confusing in multiple places, e.g.:

* https://postgrespro.com/list/thread-id/1845118
* https://dba.stackexchange.com/a/43951
* https://stackoverflow.com/a/50733640 ("this paragraph is dark")

As mentioned in those links, it seems to attempt to summarize the
wiki's example at https://wiki.postgresql.org/wiki/SSI#Deposit_Report
. I'm not sure if/how to link to the wiki from the docs, so here is my
humble attempt to summarize it concisely and (hopefully) clearly.

Alternatively, this example could be removed in favor of a reference
to the Serializable section and its example.

Attachments:

0004-doc-clarify-example-of-serialization-anomaly.patch.txttext/plain; charset=US-ASCII; name=0004-doc-clarify-example-of-serialization-anomaly.patch.txtDownload+23-11
#2Will Mortensen
will@extrahop.com
In reply to: Will Mortensen (#1)
Re: [PATCH] Attempt to clarify example of serialization anomaly

Rebased on master and updated the wording in several places. All
feedback is appreciated. :-)

I now see how to link to the wiki from the docs. I guess I numbered
the transactions differently than the wiki's version though; I can
rework it to more closely match the wiki if linking seems
desirable.

Thanks Bruce for applying my more trivial patches. :-)

Attachments:

t77348_2
0001-doc-clarify-example-of-serialization-anomaly.patchapplication/x-patch; name=0001-doc-clarify-example-of-serialization-anomaly.patchDownload+24-11
#3Laurenz Albe
laurenz.albe@cybertec.at
In reply to: Will Mortensen (#2)
Re: [PATCH] Attempt to clarify example of serialization anomaly

On Tue, 2023-06-20 at 20:01 -0700, Will Mortensen wrote:

Rebased on master and updated the wording in several places. All
feedback is appreciated. :-)

I now see how to link to the wiki from the docs. I guess I numbered
the transactions differently than the wiki's version though; I can
rework it to more closely match the wiki if linking seems
desirable.

I agree that the current wording in the documentation is too terse,
so your patch is an improvement.

There is still the potential for confusion. Perhaps an example with
explicit SQL statements (as in the other sections) might be even better.

Perhaps something simple like

If two concurrent sessions run:

BEGIN ISOLATION LEVEL REPEATABLE READ;
SELECT count(*) FROM tab WHERE name = 'alice';
/* if the result is <> 0, rollback */
INSERT INTO table (name) VALUES ('alice');
COMMIT;

you could end up with two rows with the same name, which could not
happen in a serial execution of the transactions.

Yours,
Laurenz Albe