On 17/12/2024 23:28, Andres Freund wrote:
On 2024-12-17 19:57:13 +0200, Heikki Linnakangas wrote:
On 14/12/2024 01:44, Andres Freund wrote:
The zero_damaged_pages path in bufmgr.c makes sense to me, but this one seems
less sane to me. If you want to recover from a data corruption event and
can
On Tue, Dec 17, 2024 at 5:27 PM Andres Freund wrote:
> Bitmap heapscans go through a distinct path, so it'd be trivial to accept tids
> pointing into the void for bitmap scans but not index [only] scans.
I wasn't clear. Plain nbtree index scans can drop their leaf page
buffer pin, which makes the
Hi,
On 2024-12-17 17:07:34 -0500, Peter Geoghegan wrote:
> On Tue, Dec 17, 2024 at 4:46 PM Andres Freund wrote:
> > ISTM that we could do better with some fairly simple cooperation between
> > index
> > and table AM. It should be rather rare to look up a TID that was removed
> > between finding
On Tue, Dec 17, 2024 at 4:46 PM Andres Freund wrote:
> ISTM that we could do better with some fairly simple cooperation between index
> and table AM. It should be rather rare to look up a TID that was removed
> between finding the index entry and fetching the table entry, a small amount
> of extra
Hi,
On 2024-12-17 16:11:53 -0500, Peter Geoghegan wrote:
> On Tue, Dec 17, 2024 at 12:57 PM Heikki Linnakangas wrote:
> > Hmm, looking at index_fetch_heap(), I'm surprised it doesn't throw an
> > error or even a warning if the heap tuple isn't found. That would seem
> > like a useful sanity check
Hi,
On 2024-12-17 19:57:13 +0200, Heikki Linnakangas wrote:
> On 14/12/2024 01:44, Andres Freund wrote:
> > The zero_damaged_pages path in bufmgr.c makes sense to me, but this one
> > seems
> > less sane to me. If you want to recover from a data corruption event and
> > can't dump the data becau
On Tue, Dec 17, 2024 at 12:57 PM Heikki Linnakangas wrote:
> Hmm, looking at index_fetch_heap(), I'm surprised it doesn't throw an
> error or even a warning if the heap tuple isn't found. That would seem
> like a useful sanity check. An index tuple should never point to a
> non-existent heap TID I
On 14/12/2024 01:44, Andres Freund wrote:
The zero_damaged_pages path in bufmgr.c makes sense to me, but this one seems
less sane to me. If you want to recover from a data corruption event and
can't dump the data because a seqscan stumbles over an invalid page -
zero_damaged_pages makes sense.
Hi,
On 2024-12-13 19:06:16 -0500, Tom Lane wrote:
> Andres Freund writes:
> > We have a fair number of special paths in md.c that are specific to
> > recovery. E.g. in mdreadv() we do:
> > ...
> > As far as I can tell, nearly all - including the above - InRecovery paths in
> > md.c are basically
Andres Freund writes:
> We have a fair number of special paths in md.c that are specific to
> recovery. E.g. in mdreadv() we do:
> ...
> As far as I can tell, nearly all - including the above - InRecovery paths in
> md.c are basically unreachable. And have been for quite a while.
> XLogReadBuffer
Hi,
We have a fair number of special paths in md.c that are specific to
recovery. E.g. in mdreadv() we do:
v = _mdfd_getseg(reln, forknum, blocknum, false,
EXTENSION_FAIL |
EXTENSION_CREATE_RECOVERY);
and
11 matches
Mail list logo
