Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Well, if a transaction modifies a table in some way, even without
> > changing the data, should generate an unfreeze event, because it will
> > need to lock the table; for example AlterTable locks the affected
> > relation with Access
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Well, if a transaction modifies a table in some way, even without
> changing the data, should generate an unfreeze event, because it will
> need to lock the table; for example AlterTable locks the affected
> relation with AccessExclusiveLock. It's impor
Tom Lane wrote:
> I wrote:
> > Well, that needs rethinking. The unfreeze has to be a non-transactional
> > update (if our transaction rolls back, the unfreeze still has to
> > "stick", because we may have put dead tuples into the rel).
>
> Actually, this seems even messier than I thought. Consid
I wrote:
> Well, that needs rethinking. The unfreeze has to be a non-transactional
> update (if our transaction rolls back, the unfreeze still has to
> "stick", because we may have put dead tuples into the rel).
Actually, this seems even messier than I thought. Consider a
transaction that does s
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Where did all these CommandCounterIncrement calls come from?
> I added them in heap_unfreeze precisely because I want the relation to
> be frozen exactly once, and this doesn't seem to happen if I don't CCI
> there -- I was seeing mul
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > CREATE TABLE foo (a int);
>
> > for some unknown reason, an inval message involving relation foo seems
> > to be emitted.
>
> > heap_unfreeze(pg_class)
> > CommandCounterIncrement()
> > heap_unfreeze(pg_attribute)
> > CommandCou
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> CREATE TABLE foo (a int);
> for some unknown reason, an inval message involving relation foo seems
> to be emitted.
> heap_unfreeze(pg_class)
> CommandCounterIncrement()
> heap_unfreeze(pg_attribute)
> CommandCounterIncrement()
> ... insert the pg_
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> (Now, if you're combining this with the very grotty relpages/reltuples
>> update code, then I'm all for making that xlog properly --- we've gotten
>> away without it so far but it really should xlog the change.)
> I hadn't done that,
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> We should reorganize things so this is done once at the outer level.
>> It'd require some change of the ambuild() API, but considering we're
>> hacking several other aspects of the AM API in this development cycle,
>> that doesn't both
Tom Lane wrote:
> BTW, one thing I was looking at last week was whether we couldn't
> refactor the relpages/reltuples updates to be done in a cleaner place.
> Right now UpdateStats is called (for indexes) directly from the index
> AM, which sucks from a modularity point of view, and what's worse i
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> (Now, if you're combining this with the very grotty relpages/reltuples
>> update code, then I'm all for making that xlog properly --- we've gotten
>> away without it so far but it really should xlog the change.)
> I hadn't done that,
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Ah, there's another reason, and it's that I'm rewriting the tuple in
> > place, not calling heap_update.
>
> Is that really a good idea, as compared to using heap_update?
Not sure -- we would leave dead tuples after the VACUUM is fi
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Ah, there's another reason, and it's that I'm rewriting the tuple in
> place, not calling heap_update.
Is that really a good idea, as compared to using heap_update?
(Now, if you're combining this with the very grotty relpages/reltuples
update code, the
Tom Lane wrote:
> But why do you need your own xlogging at all? Shouldn't these actions
> be perfectly ordinary updates of the relevant catalog tuples?
The XLog entry can be smaller, AFAICT (we need to store the whole new
tuple in a heap_update, right?). If that's not a worthy goal I'll
gladly
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I'm not too sure about the XLOG routines -- I don't understand very well
> the business about attaching the changes to a buffer; I thought at first
> that since all the changes go to a tuple, they all belong to the buffer,
> so I assigned a single XLogRe
15 matches
Mail list logo
