Re: SELECT INTO TABLE busted?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: SELECT INTO TABLE busted?
Дата
Msg-id 17315.918195190@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: SELECT INTO TABLE busted?  (Bruce Momjian <maillist@candle.pha.pa.us>)
Ответы Re: SELECT INTO TABLE busted?  (Bruce Momjian <maillist@candle.pha.pa.us>)
Re: [HACKERS] Re: SELECT INTO TABLE busted?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> I am passing the create_view regression test here.

I was afraid you would say that.  I'll start digging.

> Have you done a fresh initdb recently?    

Yup, this is starting from "distclean" sources and an empty
install directory.

I'm seeing several other regress failures that seem to be caused by
the same SELECT INTO problem.  Most are the same "no such table"
failure in a later test session, but the "transactions" test
actually coredumps:

QUERY: BEGIN;
QUERY: SELECT * INTO TABLE xacttest FROM aggtest;
QUERY: INSERT INTO xacttest (a, b) VALUES (777, 777.777);
QUERY: END;
QUERY: SELECT a FROM xacttest WHERE a > 100;
pqReadData() -- backend closed the channel unexpectedly.

I did a little bit of corefile-entrails-examining and found
that heapgettuple was hitting a bad pointer, but ran out of
energy before getting further than that.  If that rings any
bells please let me know.  I won't have time to look at this
more until Saturday.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: SELECT INTO TABLE busted?
Следующее
От: Michael Meskes
Дата:
Сообщение: Re: [HACKERS] preprocessor question: prepare statement