> On 21 Mar 2024, at 18:54, Peter Geoghegan wrote:
> Do the posting lists that are corrupt
> (reported on elsewhere) also have duplicate TIDs?
I do not have access now, but AFAIR yes.
Thanks for pointers!
BTW there were also some errors in logs like
ERROR: index "tablename" contains
On Thu, 21 Mar 2024 at 07:17, Andrey M. Borodin wrote:
>
> > On 29 Jun 2022, at 17:43, Robins Tharakan wrote:
>
> Sorry to bump ancient thread, I have some observations that might or might
> not be relevant.
> Recently we noticed a corruption on one of clusters. The corruption at hand
> is not
On Thu, Mar 21, 2024 at 2:16 AM Andrey M. Borodin wrote:
> Most of these messages look similar, except last one: “cross page item order
> invariant violated for index”. Indeed, index scans were hanging in a cycle.
> I could not locate problem in WAL yet, because a lot of other stuff is going
>
> On 29 Jun 2022, at 17:43, Robins Tharakan wrote:
Sorry to bump ancient thread, I have some observations that might or might not
be relevant.
Recently we noticed a corruption on one of clusters. The corruption at hand is
not in system catalog, but in user indexes.
The cluster was
> Justin Pryzby writes:
> > I have nothing new to add, but wanted to point out this is still an issue.
> > This is on the v13 Opened Items list - for lack of anywhere else to put
> > them, I
> > also added two other, unresolved issues.
Two minor things to add:
1. This issue is still
Justin Pryzby writes:
> I have nothing new to add, but wanted to point out this is still an issue.
> This is on the v13 Opened Items list - for lack of anywhere else to put them,
> I
> also added two other, unresolved issues.
It's probably time to make a v14 open items page, and move anything
I have nothing new to add, but wanted to point out this is still an issue.
This is on the v13 Opened Items list - for lack of anywhere else to put them, I
also added two other, unresolved issues.
https://wiki.postgresql.org/index.php?title=PostgreSQL_13_Open_Items=revision=35624=35352
On Tue,
Peter Geoghegan writes:
> On Tue, Aug 4, 2020 at 1:31 PM Tom Lane wrote:
>> while the INSERT_IN_PROGRESS case has none. Simple symmetry
>> would suggest that the INSERT_IN_PROGRESS case should be
>>
>> if (checking_uniqueness ||
>> HeapTupleIsHeapOnly(heapTuple))
>> //
On Tue, Aug 4, 2020 at 1:31 PM Tom Lane wrote:
> The core of the issue seems to be that in the presence of concurrent
> updates, we might not have a stable opinion of which entry of the HOT
> chain is live, leading to trying to index multiple ones of them (using
> the same root TID), which leads
Peter Geoghegan writes:
> Any further thoughts on this, Tom?
Sorry for slow response ... my ISP had an equipment failure that took
out my email service for most of a day.
> This is clearly a live bug that we should fix before too long. I could
> write the patch myself, but I would like to get
On Tue, Jul 28, 2020 at 3:09 PM Peter Geoghegan wrote:
> Perhaps 2011's commit 520bcd9c9bb missed similar
> HEAPTUPLE_INSERT_IN_PROGRESS issues that manifest themselves within
> Justin's test case now?
Any further thoughts on this, Tom?
This is clearly a live bug that we should fix before too
On Tue, Jul 28, 2020 at 2:46 PM Peter Geoghegan wrote:
> The fact remains that this function (originally known as
> IndexBuildHeapScan(), now heapam_index_build_range_scan()) did not
> care about whether or not the index is unique for about 3 years
> (excluding the tupleIsAlive stuff, which was
On Tue, Jul 28, 2020 at 1:26 PM Peter Geoghegan wrote:
> On Tue, Jul 28, 2020 at 1:04 PM Tom Lane wrote:
> > No, I don't think so. It was designed for the case of unique key X
> > being inserted immediately after a deletion of the same key. The
> > deleted tuple is presumably not yet
On Tue, Jul 28, 2020 at 1:04 PM Tom Lane wrote:
> No, I don't think so. It was designed for the case of unique key X
> being inserted immediately after a deletion of the same key. The
> deleted tuple is presumably not yet vacuumed-away, so the new tuple
> should have a different TID. In no
Peter Geoghegan writes:
> I also find it suspicious that I can no longer produce the assertion
> failure once I force all non-unique system catalog indexes (such as
> Justin's repro index, pg_class_tblspc_relfilenode_index) to go through
> the HEAPTUPLE_INSERT_IN_PROGRESS +
>
On Tue, Jul 28, 2020 at 12:00 PM Peter Geoghegan wrote:
> I still don't know what's going on here, but I find it suspicious that
> some relevant tuples go through the HEAPTUPLE_INSERT_IN_PROGRESS +
> !TransactionIdIsCurrentTransactionId() path of
> heapam_index_build_range_scan(). After all, if
On Tue, Jul 28, 2020 at 10:37 AM Peter Geoghegan wrote:
> It's starting to look more like that. I can reproduce the bug by
> running the REINDEX in a tight loop while "make installcheck" runs. It
> looks as if the two tuples passed to comparetup_index_btree() are
> separate tuples that each point
On Tue, Jul 28, 2020 at 10:06 AM Peter Geoghegan wrote:
> I wrote the assertion that fails here with the bug that I fixed in
> commit 4974d7f87e62a58e80c6524e49677cb25cc10e12 in mind specifically.
> That was a bug that involved a scan that returned duplicate tuples due
> to a problem in
On Tue, Jul 28, 2020 at 8:47 AM Peter Geoghegan wrote:
> This is very likely to be related to incremental sort because it's a
> use-after-free issue, which is the kind of thing that could only
> really happen inside tuplesort.c. This is clear because some of the
> variables have the tell-tale
On Tue, Jul 28, 2020 at 8:40 AM James Coleman wrote:
> Is that assumption largely based on the incremental sort patch
> refactoring tuplesort.c a bit? I haven't looked at it much at all, but
> I'm wondering if the issue could also be related to the btree
> duplicates changes in 13 given that
On Tue, Jul 28, 2020 at 11:40:14AM -0400, James Coleman wrote:
> > This appears to be an issue with d2d8a229b (Incremental Sort), so I will add
> > at: https://wiki.postgresql.org/wiki/PostgreSQL_13_Open_Items
>
> Is that assumption largely based on the incremental sort patch
> refactoring
On Tue, Jul 28, 2020 at 11:10 AM Justin Pryzby wrote:
>
> An internal server aborted last night while running a maintenance script. I
> reproduced this easily running the crashing command in a loop, and verified
> this is a live issue on REL_13_STABLE (dc6f2fb43).
> REINDEX INDEX
An internal server aborted last night while running a maintenance script. I
reproduced this easily running the crashing command in a loop, and verified
this is a live issue on REL_13_STABLE (dc6f2fb43).
REINDEX INDEX pg_class_tblspc_relfilenode_index
It looks like this crashed once before, and I
23 matches
Mail list logo
