Re: COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Pavan Deolasee <pavan.deolasee@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Jeff Janes <jeff.janes@gmail.com>, Simon Riggs <simon@2ndquadrant.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>
Date: 2019-04-04T19:23:08Z
Lists: pgsql-hackers
Hi, On 2019-04-04 16:15:54 -0300, Alvaro Herrera wrote: > On 2019-Apr-04, Andres Freund wrote: > > > I'm totally not OK with this from a layering > > POV. CheckAndSetAllVisibleBulkInsertState is entirely heap specific > > (without being named such), whereas all the heap specific bits are > > getting moved below tableam. > > This is a fair complaint, but on the other hand the COPY changes for > table AM are still being developed, so there's no ground on which to > rebase this patch. Do you have a timeline on getting the COPY one > committed? ~2h. Just pondering the naming of some functions etc. Don't think there's a large interdependency though. But even if tableam weren't committed, I'd still argue that it's structurally done wrong in the patch right now. FWIW, I actually think this whole approach isn't quite right - this shouldn't be done as a secondary action after we'd already inserted, with a separate lock-unlock cycle etc. Also, how is this code even close to correct? CheckAndSetPageAllVisible() modifies the buffer in a crucial way, and there's no WAL logging? Without even a comment arguing why that's OK (I don't think it is)? Greetings, Andres Freund
Commits
-
Fix COPY FREEZE with CLOBBER_CACHE_ALWAYS
- 39b66a91bdeb 14.0 landed
-
Set PD_ALL_VISIBLE and visibility map bits in COPY FREEZE
- 7db0cd2145f2 14.0 landed
-
docs: client certificates are always sent to the server
- ff60394a8c9a 14.0 cited
-
Mark commit and abort WAL records with XLR_SPECIAL_REL_UPDATE.
- a28d731a1187 14.0 cited
-
docs: land height is "elevation", not "altitude"
- 92c12e46d5f1 13.0 cited
-
Improve the internal implementation of ereport().
- 17a28b03645e 13.0 cited