Re: [RFC] Should smgrtruncate() avoid sending sinval message for temp relations - Mailing list pgsql-hackers

From MauMau
Subject Re: [RFC] Should smgrtruncate() avoid sending sinval message for temp relations
Date
Msg-id 4985ECDB74BE44588CF9BDFBFD2696DE@maumau
Whole thread Raw
In response to Re: [RFC] Should smgrtruncate() avoid sending sinval message for temp relations  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [RFC] Should smgrtruncate() avoid sending sinval message for temp relations
List pgsql-hackers
From: "Tom Lane" <tgl@sss.pgh.pa.us>
> This seems like a pretty unsafe suggestion, because the smgr level doesn't
> know or care whether relations are temp; files are files.  In any case it
> would only paper over one specific instance of whatever problem you're
> worried about, because sinval messages definitely do need to be sent in
> general.

I'm sorry I don't show the exact problem yet.  Apart from that, I understood 
that you insist it's not appropriate for smgr to be aware of whether the 
file is a temporary relation, in terms of module layering.  However, it 
doesn't seem so in the current implementation.  md.c, which is a layer under 
or part of smgr, uses SmgrIsTemp().  In addition, as the name suggests, 
SmgrIsTemp() is a function of smgr, which is defined in smgr.h.  So, it's 
not inappropriate for smgr to use it.

What I wanted to ask is whether and why sinval messages are really necessary 
for session-private objects like temp relations.  I thought shared inval is, 
as the name indicates, for objects "shared" among sessions.  If so, sinval 
for session-private objects doesn't seem to match the concept.

Regards
MauMau




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Doing better at HINTing an appropriate column within errorMissingColumn()
Next
From: Fabien COELHO
Date:
Subject: Re: gaussian distribution pgbench -- splits v4