Re: [HACKERS] Re: Freezing docs for v6.5

Vadim Mikheev <vadim(at)krs(dot)ru> writes:
> Note this:
> vac=> begin;
> BEGIN
> vac=> create table bug1 (f1 int28);
> CREATE
> vac=> abort;
> ABORT
> vac=> create table bug1 (f1 int28);
> CREATE

That's not a very interesting case, because (AFAICS) there is nothing
that will cause the pg_class row for bug1 to get loaded into SysCache
during the transaction. So, no problem.

I tried the obvious extension:

play=> begin;
BEGIN
play=> create table bug1 (f1 int);
CREATE
play=> create index bug1i on bug1(f1);
CREATE
play=> abort;
ABORT
play=> create table bug1 (f1 int);
CREATE

Hmm ... that's interesting, why does that work? My guess is that the
CommandCounterIncrement() after the CREATE TABLE causes the SI code
to take responsibility for bug1's pg_class row even though it's not
truly committed. However,

play=> begin;
BEGIN
play=> create table bug1 (f1 int28);
CREATE
play=> create index bug1i on bug1(f1);
ERROR: Can't find a default operator class for type 22.
play=> abort;
ABORT
play=> create table bug1 (f1 int28);
ERROR: bug1 relation already exists

I really do not understand why this last fails when the prior
example works.

However, I've already committed a fix, and all of these
examples now work fine with 6.5 ;-). So I'm not inclined to
spend more time on the issue right now ... other bugs beckon.

regards, tom lane