Vadim Mikheev <vadim@krs.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