The following bug has been logged online:
Bug reference: 6086
Logged by: Dennis
Email address: dennis.noord...@helsinki.fi
PostgreSQL version: 9.0.4
Operating system: FreeBSD 8.2 (64 bit)
Description:Segmentation fault
Details:
For some reason a 9.0.4 server which
Thank you for responding.
Shortly after writing the email, I realized what I had done.
I did not use the wildcard*, but rather specified each column with its name.
However, the tables which were being moved contained foreign keys relating
to one another. Therefore the primary key had to be
Jon Nelson jnelson+pg...@jamponi.net writes:
With 8.4.7, I ran into an issue trying to explain a VIEW query.
After much effort, I distilled the query down and was able to
replicate the issue with a test script, included below.
FWIW, I can't reproduce such a failure with current 8.4 branch (nor
Alvaro Herrera alvhe...@commandprompt.com writes:
Hmm, so what's happening here, I think, is that the value is getting
assigned to the record variable without detoasting. I guess we should
detoast the value prior to assigning it, but it seems to me that that
would have a large performance
Chris Bandy bandy.ch...@gmail.com writes:
While using the information_schema to examine my tables, I found that
columns.column_default does not consistently represent the DEFAULT
constraint/definition of a column.
I would expect a column without a DEFAULT definition to return a null value,
The following bug has been logged online:
Bug reference: 6088
Logged by: Maksym Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 8.4.7
Operating system: Freebsd
Description:copy to stdout cannot be stopped with kill(pid) or
pg_terminate_backend
Details:
Maksym Boguk maxim.bo...@gmail.com writes:
But I found I can not stop
COPY bill.changes (id, cdate, mdate, status, table_name, pk_id, old_row,
new_row) TO stdout;
with pg_terminate_backend(procpid) or kill (procpid).
Works for me ...
regards, tom lane
--
Sent via
