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 h
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 transfe
Jon Nelson 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 any
other). It's poss
Alvaro Herrera 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 penalty for other cases in
"Chris Bandy" 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,
> while a colu
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" 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 pgsql-bugs mailin
