| From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
|---|---|
| To: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: Failures in constraints regression test, "read only 0 of 8192 bytes" |
| Date: | 2024-06-21 14:14:32 |
| Message-ID: | 46f9dda0-be36-4115-aa54-2da2c4b20232@iki.fi |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 21/06/2024 02:25, Heikki Linnakangas wrote:
> Hmm, looking closer, I think this might be a more appropriate place for
> the RelationCloseSmgr() call:
>
>> /*
>> * If it's a mapped relation, immediately update its rd_locator in
>> * case its relfilenumber changed. We must do this during phase 1
>> * in case the relation is consulted during rebuild of other
>> * relcache entries in phase 2. It's safe since consulting the
>> * map doesn't involve any access to relcache entries.
>> */
>> if (RelationIsMapped(relation))
>> RelationInitPhysicalAddr(relation);
>
> That's where we change the relfilenumber, before the
> RelationClearRelation() call.
Pushed a fix that way.
--
Heikki Linnakangas
Neon (https://neon.tech)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jelte Fennema-Nio | 2024-06-21 14:36:13 | cfbot update: Using GitHub for patch review |
| Previous Message | Amit Langote | 2024-06-21 13:48:04 | Re: pgsql: Add more SQL/JSON constructor functions |