Thank you very much for Peter Geoghegan's help. The issue has been resolved for
some time now. It was indeed caused by corrupted index data, which resulted
from collation differences between the hosts before and after the migration.
Although the collation names were consistent, the differing gli
mid);
// Here, will low and mid ever be unequal? If low is returned in such
cases, would it result in an error? maybe we fix it like this ?
//low = mid;
// break;
}
}
return low;
}
At 2024-11-27 18:53:20, "yuansong" wrote:
we find c
Geoghegan" wrote:
>On Sun, Dec 1, 2024 at 8:11 AM yuansong wrote:
>> the _bt_binsrch_insert function always returns low, but during the post list
>> search, are there cases where low and mid are unequal?
>>
>> If so, this could potentially cause an offset in the subse
. However, the loop doesn't terminate
and continues, causing the value of low to become 4. This is where I applied my
fix based on master.
I aslo don't know how to fix the bug and commit it to the community master.
At 2024-12-01 21:33:28, "Peter Geoghegan" wrote:
>On S
1 23:58:03, "Peter Geoghegan" wrote:
>On Thu, Nov 21, 2024 at 10:03 AM yuansong wrote:
>> Should nhtids be less than or equal to IndexTupleSize(oposting)?
>> Why is nhtids larger than IndexTupleSize(oposting) ? I think there should
>> be an error in the master host
My database version is Postgresql 13.2 , backup server core when redo a
btree_xlog_insert that type is XLOG_BTREE_INSERT_POST
#0 0x2aab66695d86inmemmove ssse3 krom /lib64/libc.so.6
#1
0x004f5574in_bt_swap_posting(newitem=0x125d998,oposting=0x2aabcd55dcc8ostingoff=13)
at nbt
thanks，After reconsideration, I realized that what I really want is for other
connections to remain unaffected when a process crashes. This is something that
a connection pool cannot solve.
At 2023-11-14 09:41:03, "Thomas wen" wrote:
Hi yuansong
there is connnection
nyone have any insights? Please help me. Thank you.
At 2023-11-13 13:53:29, "Laurenz Albe" wrote:
>On Sun, 2023-11-12 at 21:55 -0500, Tom Lane wrote:
>> yuansong writes:
>> > In PostgreSQL, when a backend process crashes, it can cause other backend
>>
In PostgreSQL, when a backend process crashes, it can cause other backend
processes to also require a restart, primarily to ensure data consistency. I
understand that the correct approach is to analyze and identify the cause of
the crash and resolve it. However, it is also important to be able t
