On Thu, Feb 9, 2023 at 3:55 PM Paul McGarry wrote:
> Will the amcheck reliably identify all issues that may arise from a collation
> change?
Theoretically it might not. In practice I'd be very surprised if it
ever failed to detect such an inconsistency. If you want to be extra
careful, and can a
Hi Peter,
Thanks for your input, I'm feeling more comfortable that I correctly
understand the problem now and it's "just" a collation related issue.
> I recommend running amcheck on all indexes, or at least all
> possibly-affected text indexes.
>
>
Will the amcheck reliably identify all issues t
r you've seen
("ERROR: posting list tuple with 2 items cannot be split at offset
17") comes from the initial 13.4 hardening, since I'd expect the
additional 13.5 hardening to catch the same issue sooner, with a
different error message (something like "table tid from new ind
On 2/8/23 23:53, Paul McGarry wrote:
I have three databases, two of databases where I am experiencing the
issue below.
The first database was created from a dump in Feb 2022 (a few weeks
after the time period for which I seem to have problematic indexes, maybe).
The second database was then cl
0:05.780573+00' AND description IS NOT NULL);
ERROR: posting list tuple with 2 items cannot be split at offset 17
A select on the same data works fine, so presumably a problem updating the
index, not accessing it or the corresponding table):
db=> select count(*) from widget w
