From: | Hannu Krosing <hannu(at)skype(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Martijn van Oosterhout <kleptog(at)svana(dot)org>, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, Wes <wespvp(at)syntegra(dot)com>, Zeugswetter Andreas DCP SD <ZeugswetterA(at)spardat(dot)at>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Catalog Access (was: [GENERAL] Concurrency problem |
Date: | 2006-04-25 22:08:46 |
Message-ID: | 1146002926.3961.21.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Ühel kenal päeval, T, 2006-04-25 kell 13:58, kirjutas Tom Lane:
> Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> > I think the basic problem is that DDL can't really work within a
> > transaction. If I do an ALTER TABLE, some of these changes need to show
> > up to concurrent transactions (maybe creating a unique index?).
>
> The point is that DDL can't be MVCC. If for instance you add an index
> to a table, once you commit every other transaction must *immediately*
> start updating that index when they modify the table.
How is it done in a way that all other backends see it, but only after
commit ?
Is there some secret transaction isolation mode for DDL? Maybe something
that fits between "read uncommitted" and "read committed" ? Or is it
just that catalog access is always done in read-committed mode, even if
transaction is in "serializable" ?
Would this take effect even inside a single command ? in other words, if
it were possible that an index appeared in middle of a big update, would
the tuples updated after the index becomes visible be also added to the
index ?
The reason I ask, is that I'm still keen on implementin a CONCURRENT
INDEX command, and I want to get as much background info as possible
before diving in.
> They can't use
> the excuse of "not my problem because the catalog change postdates the
> snapshot I'm using". The drop-index case is even worse, since a
> transaction that believes the index is still present is likely to try
> to access/update a disk file that's not there anymore. Adding/dropping
> columns, constraints, triggers, etc all have hazards of the same ilk.
at what point will an add/drop column become visible for parallel
transactions ?
can trigger/constraint appear magically inside a transaction ? so if I
update 5 rows inside one serialisable trx, is it possible that a trigger
added to the table after 2nd update will fire for last 3 updates ?
btw, i don't think that a stored procedure (cached plans) will pick up
something like added/changed default even after commit in both
connections.
> > I think it's like Tom says in that email, it could be done, but the
> > cost/benefit ratio isn't very good...
>
> It's barely possible that we could make this happen, but it would be a
> huge amount of work, and probably a huge amount of instability for a
> very long time until we'd gotten all the corner cases sorted. I think
> there are much more productive uses for our development effort.
True.
-------------------
Hannu
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2006-04-25 22:28:14 | Re: Catalog Access (was: [GENERAL] Concurrency problem |
Previous Message | Jesper Pedersen | 2006-04-25 20:30:26 | Summer of Code idea |