SEO

Alvaro Herrera <alvherre@commandprompt.com> 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_attribute rows ...

Where did all these CommandCounterIncrement calls come from?
I don't think it's going to work if you are throwing in CCIs
at random places; this problem with the relcache will be the
least of your worries. Why do you think you need that anyway?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> 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_attribute rows ...
>
> Where did all these CommandCounterIncrement calls come from?
> I don't think it's going to work if you are throwing in CCIs
> at random places; this problem with the relcache will be the
> least of your worries. Why do you think you need that anyway?

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 multiple occurences of the NOTICE I put in
heap_unfreeze for the same relation for a single CREATE TABLE (multiple
unfreezes of pg_class and pg_attribute, for example).

Maybe the problem is elsewhere. I'll investigate more.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Alvaro Herrera <alvherre@commandprompt.com> 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 multiple occurences of the NOTICE I put in
> heap_unfreeze for the same relation for a single CREATE TABLE (multiple
> unfreezes of pg_class and pg_attribute, for example).

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). Therefore,
a CCI is neither necessary nor useful. I didn't look at your patch in
any detail ... didn't you modify it to use the non-transactional update
code I put in heapam.c recently?

It might be that we need to broadcast an sinval message for the tuple
when we update it this way ... although sinval believes updates are
transactional, so that's not going to work all that well. Maybe we have
to legislate that catcache/syscache entries shouldn't be trusted to have
up-to-date values of these fields.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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 something transactional to a table's schema,
thereby generating a new pg_class row (but not touching any data within
the table), and then alters the table contents, requiring an unfreeze.
An update to the apparently-current pg_class tuple is not good because
that tuple might be rolled back. An update to the last committed
version doesn't work either.

This seems real close to the recent discussions about how to put
sequence data into a single one-row-per-sequence system catalog,
specifically about how there were some parts of the sequence catalog
data that should be transactional and some that should not be.
I'm wondering if we need a second pg_class-derived catalog that carries
just the nontransactional columns.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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. Consider a
> transaction that does something transactional to a table's schema,
> thereby generating a new pg_class row (but not touching any data within
> the table), and then alters the table contents, requiring an unfreeze.
> An update to the apparently-current pg_class tuple is not good because
> that tuple might be rolled back. An update to the last committed
> version doesn't work either.

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 important for the
non-transactional change to the pg_class tuple be the very first in the
transaction, because otherwise the change could be lost; but other than
this, I don't think there's any problem.

Not that I had actually considered this problem, to be frank; but it
seems a nice side effect of how the unfreezing works.

> This seems real close to the recent discussions about how to put
> sequence data into a single one-row-per-sequence system catalog,
> specifically about how there were some parts of the sequence catalog
> data that should be transactional and some that should not be.
> I'm wondering if we need a second pg_class-derived catalog that carries
> just the nontransactional columns.

I hope we don't need to do this because ISTM it will be a very big change.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Alvaro Herrera <alvherre@commandprompt.com> 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 important for the
> non-transactional change to the pg_class tuple be the very first in the
> transaction, because otherwise the change could be lost; but other than
> this, I don't think there's any problem.

You can't guarantee that. Consider for instance manual updates to
pg_class:

BEGIN;
UPDATE pg_class SET reltriggers = 0 WHERE relname = ...
... alter table contents ...
COMMIT or ROLLBACK;

I believe there are actually patterns like this in some pg_dump output.
Will you hack every UPDATE operation to test whether it's changing
pg_class and if so force an "unfreeze" operation before changing any
row? No thanks :-(

>> I'm wondering if we need a second pg_class-derived catalog that carries
>> just the nontransactional columns.

> I hope we don't need to do this because ISTM it will be a very big change.

(Yawn...) We've made far bigger changes than that. The important
thing is to get it right.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> 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 important for the
> > non-transactional change to the pg_class tuple be the very first in the
> > transaction, because otherwise the change could be lost; but other than
> > this, I don't think there's any problem.
>
> You can't guarantee that. Consider for instance manual updates to
> pg_class:
>
> BEGIN;
> UPDATE pg_class SET reltriggers = 0 WHERE relname = ...
> ... alter table contents ...
> COMMIT or ROLLBACK;
>
> I believe there are actually patterns like this in some pg_dump output.
> Will you hack every UPDATE operation to test whether it's changing
> pg_class and if so force an "unfreeze" operation before changing any
> row? No thanks :-(

Oh, true, I hadn't thought of direct updates to pg_class.

> >> I'm wondering if we need a second pg_class-derived catalog that carries
> >> just the nontransactional columns.
>
> > I hope we don't need to do this because ISTM it will be a very big change.
>
> (Yawn...) We've made far bigger changes than that. The important
> thing is to get it right.

Yeah, I know -- I've been involved in some of them. I hereby volunteer
to do it for 8.2 because I'd really like to see this patch in.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings