Re: Restoring a pg_dump fails with
От | Tom Lane |
---|---|
Тема | Re: Restoring a pg_dump fails with |
Дата | |
Msg-id | 14603.988639166@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Restoring a pg_dump fails with (Reiner Dassing <dassing@wettzell.ifag.de>) |
Список | pgsql-admin |
Reiner Dassing <dassing@wettzell.ifag.de> writes: >> Perhaps there is some configuration or platform issue here? What were >> your configure options? > The options were as follows: > ./configure --with-pgport=5432 \ > --with-x \ > --with-perl \ > --with-python \ > --with-tcl \ > --enable-odbc \ > --enable-syslog \ > --with-CC=cc --without-CXX \ > --prefix=/Postgres/pgsql \ > --with-tclconfig=/usr/local/lib \ > --with-include=/usr/local/include Drat. I was thinking maybe you were using multibyte --- there's some extra string-slinging for multibyte conversion that might have been a good place to look for a memory leak. But there's nothing above that looks significantly different from my setup. Again, can anyone else reproduce a memory leak during COPY IN? > There is the table pga_layout. > What happens if this table is missing, empty or the contents is not > correct in respect to COPY ...? Nothing. The backend does not know or care anything about pgaccess' tables... regards, tom lane
В списке pgsql-admin по дате отправления: