Heikki Linnakangas writes:
> I was finally able to reproduce this, by running the failing pg_regress
> tests concurrently with repeated "vacuum full pg_database" calls. It's
> curious that 'prion' failed on the first run after the commit, I was not
> able to reproduce it by just running the unm
On 31/10/2024 12:06, Heikki Linnakangas wrote:
On 31/10/2024 10:14, Heikki Linnakangas wrote:
Committed with those fixes, thanks for the review!
There is a failure in the buildfarm animal 'prion', which builds with
-DRELCACHE_FORCE_RELEASE -DCATCACHE_FORCE_RELEASE options. I'll look
into tha
On 31/10/2024 10:14, Heikki Linnakangas wrote:
Committed with those fixes, thanks for the review!
There is a failure in the buildfarm animal 'prion', which builds with
-DRELCACHE_FORCE_RELEASE -DCATCACHE_FORCE_RELEASE options. I'll look
into that later today. (I did test with -DRELCACHE_FORCE
On 23/09/2024 04:39, jian he wrote:
static void
RelationClearRelation(Relation relation)
{
Assert(RelationHasReferenceCountZero(relation));
Assert(!relation->rd_isnailed);
/*
* Relations created in the same transaction must never be removed, see
* RelationFlushRelation
On Wed, Jun 5, 2024 at 9:56 PM Heikki Linnakangas wrote:
>
> ## Patch 3: Split RelationClearRelation into three different functions
>
> RelationClearRelation() is complicated. Depending on the 'rebuild'
> argument and the circumstances, like if it's called in a transaction and
> whether the relati
While looking at the recent bug report from Alexander Lakhin [1], I got
annoyed by the relcache code, and RelationClearRelation in particular. I
propose to refactor it for clarity.
[1]
https://www.postgresql.org/message-id/e56be7d9-14b1-664d-0bfc-00ce9772721c%40gmail.com
## Patch 1
This is
