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
*
On 21/06/2024 02:12, Tom Lane wrote:
Heikki Linnakangas writes:
In commit af0e7deb4a, I removed the call to RelationCloseSmgr() from
RelationCacheInvalidate(). I thought it was no longer needed, because we
no longer free the underlying SmgrRelation.
However, it meant that if the relfilenode
Heikki Linnakangas writes:
> In commit af0e7deb4a, I removed the call to RelationCloseSmgr() from
> RelationCacheInvalidate(). I thought it was no longer needed, because we
> no longer free the underlying SmgrRelation.
> However, it meant that if the relfilenode of the relation was changed,
>
On 19/06/2024 23:00, Alexander Lakhin wrote:
Please look at a new anomaly, that I've discovered in master.
...
triggers a segfault:
2024-06-19 19:22:49.009 UTC [1607210:6] LOG: server process (PID 1607671) was
terminated by signal 11: Segmentation fault
...
server.log might also contain:
20
On Wed, Jun 19, 2024 at 11:00:00PM +0300, Alexander Lakhin wrote:
> Starting from af0e7deb4, the following script:
> [...]
> triggers a segfault:
> 2024-06-19 19:22:49.009 UTC [1607210:6] LOG: server process (PID
> 1607671) was terminated by signal 11: Segmentation fault
Open item added for this
Hello Heikki,
11.03.2024 10:09, Heikki Linnakangas wrote:
On 10/03/2024 22:59, Thomas Munro wrote:
On Mon, Mar 11, 2024 at 9:30 AM Heikki Linnakangas wrote:
Barring objections, I'll commit the attached.
+1
Pushed, thanks!
Please look at a new anomaly, that I've discovered in master.
St
On 10/03/2024 22:59, Thomas Munro wrote:
On Mon, Mar 11, 2024 at 9:30 AM Heikki Linnakangas wrote:
Barring objections, I'll commit the attached.
+1
Pushed, thanks!
I guess the comment for smgrreleaseall() could also be updated. It
mentions only PROCSIGNAL_BARRIER_SMGRRELEASE, but I think
On Mon, Mar 11, 2024 at 9:59 AM Thomas Munro wrote:
> On Mon, Mar 11, 2024 at 9:30 AM Heikki Linnakangas wrote:
> > Hmm, I'm not sure if we need even smgrreleaseall() here anymore. It's
> > not required for correctness AFAICS. We don't do it in single-rel
> > invalidation in RelationCacheInvalida
On Mon, Mar 11, 2024 at 9:30 AM Heikki Linnakangas wrote:
> Barring objections, I'll commit the attached.
+1
I guess the comment for smgrreleaseall() could also be updated. It
mentions only PROCSIGNAL_BARRIER_SMGRRELEASE, but I think sinval
overflow (InvalidateSystemCaches()) should also be men
On 10/03/2024 11:20, Heikki Linnakangas wrote:
On 10/03/2024 08:23, Thomas Munro wrote:
On Sun, Mar 10, 2024 at 6:48 PM Thomas Munro wrote:
I won't be surprised if the answer is: if you're holding a reference,
you have to get a pin (referring to bulk_write.c).
Ahhh, on second thoughts, I tak
Thanks for diagnosing this!
On 10/03/2024 08:23, Thomas Munro wrote:
On Sun, Mar 10, 2024 at 6:48 PM Thomas Munro wrote:
I won't be surprised if the answer is: if you're holding a reference,
you have to get a pin (referring to bulk_write.c).
Ahhh, on second thoughts, I take that back, I thin
On Sun, Mar 10, 2024 at 6:48 PM Thomas Munro wrote:
> I won't be surprised if the answer is: if you're holding a reference,
> you have to get a pin (referring to bulk_write.c).
Ahhh, on second thoughts, I take that back, I think the original
theory still actually works just fine. It's just that
On Sun, Mar 10, 2024 at 5:02 PM Thomas Munro wrote:
> Thanks, reproduced here (painfully slowly). Looking...
I changed that ERROR to a PANIC and now I can see that
_bt_metaversion() is failing to read a meta page (block 0), and the
file is indeed of size 0 in my filesystem. Which is not cool, f
On Sat, Mar 9, 2024 at 9:48 AM Tomas Vondra
wrote:
> I spent a bit of time investigating this today, but haven't made much
> progress due to (a) my unfamiliarity with the smgr code in general and
> the patch in particular, and (b) CLOBBER_CACHE_ALWAYS making it quite
> time consuming to iterate an
On 3/8/24 21:29, Thomas Munro wrote:
> On Sat, Mar 9, 2024 at 2:36 AM Tomas Vondra
> wrote:
>> On 3/8/24 13:21, Tomas Vondra wrote:
>>> My guess would be 8af25652489, as it's the only storage-related commit.
>>>
>>> I'm currently running tests to verify this.
>>>
>>
>> Yup, the breakage starts
On Sat, Mar 9, 2024 at 2:36 AM Tomas Vondra
wrote:
> On 3/8/24 13:21, Tomas Vondra wrote:
> > My guess would be 8af25652489, as it's the only storage-related commit.
> >
> > I'm currently running tests to verify this.
> >
>
> Yup, the breakage starts with this commit. I haven't looked into the
> r
Le vendredi 8 mars 2024, 14:36:48 CET Tomas Vondra a écrit :
> > My guess would be 8af25652489, as it's the only storage-related commit.
> >
> > I'm currently running tests to verify this.
>
> Yup, the breakage starts with this commit. I haven't looked into the
> root cause, or whether the commit
On 3/8/24 13:21, Tomas Vondra wrote:
> On 3/8/24 09:33, Thomas Munro wrote:
>> Happened again. I see this is OpenSUSE. Does that mean the file
>> system is Btrfs?
>
>
> It is, but I don't think that matters - I've been able to reproduce this
> locally on my laptop using ext4 filesystem. I'd
On 3/8/24 09:33, Thomas Munro wrote:
> Happened again. I see this is OpenSUSE. Does that mean the file
> system is Btrfs?
It is, but I don't think that matters - I've been able to reproduce this
locally on my laptop using ext4 filesystem. I'd bet the important piece
here is -DCLOBBER_CACHE_ALWA
Happened again. I see this is OpenSUSE. Does that mean the file
system is Btrfs?
On 3/4/24 14:16, Ronan Dunklau wrote:
> Le samedi 2 mars 2024, 23:29:52 CET Tomas Vondra a écrit :
>> These are "my" animals (running at a local university). There's a couple
>> interesting details:
>
> Hi Tomas,
> do you still have the failing cluster data ?
>
> Noah pointed me to this threa
Le samedi 2 mars 2024, 23:29:52 CET Tomas Vondra a écrit :
> These are "my" animals (running at a local university). There's a couple
> interesting details:
Hi Tomas,
do you still have the failing cluster data ?
Noah pointed me to this thread, and it looks a bit similar to the FSM
corruption is
These are "my" animals (running at a local university). There's a couple
interesting details:
1) the animals run on the same machine (one with gcc, one with clang)
2) I did upgrade the OS and restarted the machine on 2024/02/26, i.e.
right before the failures started
These might be just coincide
These two animals seem to have got mixed up about about the size of
this relation in the same place:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=avocet&dt=2024-02-28%2017%3A34%3A30
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=trilobite&dt=2024-03-01%2006%3A47%3A53
+++
/hom
24 matches
Mail list logo
