On Wed, Jul 23, 2014 at 12:17 PM, MauMau <maumau...@gmail.com> wrote:
> From: "Tom Lane" <t...@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.
I think the problem here is that it actually is possible for one
session to access the temporary objects of another session:
rhaas=# create temp table fructivore (a int);
CREATE TABLE
rhaas=# select 'fructivore'::regclass::oid;
oid
-------
24578
(1 row)
Switch windows:
rhaas=# select 24578::regclass;
regclass
----------------------
pg_temp_2.fructivore
(1 row)
rhaas=# alter table pg_temp_2.fructivore add column b int;
ALTER TABLE
Now, we could prohibit that specific thing. But at the very least, it
has to be possible for one session to drop another session's temporary
objects, because autovacuum does it eventually, and superusers will
want to do it sooner to shut autovacuum up. So it's hard to reason
about whether and to what extent it's safe to not send sinval messages
for temporary objects.
I think you might be approaching this problem from the wrong end,
though. The question in my mind is: why does the
StartTransactionCommand() / CommitTransactionCommand() pair in
ProcessCatchupEvent() end up writing a commit record? The obvious
possibility that occurs to me is that maybe rereading the invalidated
catalog entries causes a HOT prune, and maybe there ought to be some
way for a transaction that has only done HOT pruning to commit
asynchronously, just as we already do for transactions that only
modify temporary tables. Or, failing that, maybe there's a way to
suppress synchronous commit for this particular transaction.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
