| From: | Will Mortensen <will(at)extrahop(dot)com> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Cc: | alvherre(at)alvh(dot)no-ip(dot)org, Yvonne Chen <yvonne(at)extrahop(dot)com> |
| Subject: | README.tuplock and SHARE lock |
| Date: | 2024-11-19 06:45:12 |
| Message-ID: | CAMpnoC6yEQ=c0Rdq-J7uRedrP7Zo9UMp6VZyP23QMT68n06cvA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
README.tuplock says:
> There is one exception
> here: since infomask space is limited, we do not provide a separate bit
> for SELECT FOR SHARE, so we have to use the extended info in a MultiXact in
> that case. (The other cases, SELECT FOR UPDATE and SELECT FOR KEY SHARE, are
> presumably more commonly used due to being the standards-mandated locking
> mechanism, or heavily used by the RI code, so we want to provide fast paths
> for those.)
But looking at the explanations of the infomask bits further down (as
updated in commit cdbdc4382743fcfabb3437ea7c4d103adaa01324), as well
as the actual code for locking a not-yet-locked tuple in
compute_new_xmax_infomask(), this doesn't seem to be true. Was this an
oversight?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bertrand Drouvot | 2024-11-19 06:52:40 | Re: fix deprecation mention for age() and mxid_age() |
| Previous Message | jian he | 2024-11-19 06:16:52 | Re: Emitting JSON to file using COPY TO |