The following bug has been logged online:
Bug reference: 2724
Logged by: Alexey Zayats
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.5
Operating system: SuSE 10.0 Linux 2.6.13 x86-64
Description:Could not check connection status with "ssl=on"
Details:
I'm
It might be interesting to think about not requiring the ControlFileLock
to be held while making new WAL segments. I think the only reason it
does that is to ensure that link/rename failure can be treated as a hard
error (because no one could have beat us to the filename), but we're
already havin
"Alexey Zayats" <[EMAIL PROTECTED]> writes:
> I've got next backtrace from core file:
> --
> Program received signal SIGPIPE, Broken pipe.
> [Switching to Thread 46912549615488 (LWP 28743)]
> 0x2d07ae32 in __write_nocancel () from /lib64/tls/libpthread.so.0
> (gdb) b
You can insert invalid UTF8 bytes sequences into a TEXT type on an 8.1
installation by doing something like:
INSERT INTO foo(t) VALUES('\xFF');
Then, you can do a:
COPY foo TO '/some/file';
but if you try to do a:
COPY foo FROM '/some/file';
That will fail because /some/file contains invalid
On Fri, 2006-10-27 at 14:42 -0700, Jeff Davis wrote:
> It seems to be essentially a data corruption issue if applications
> insert binary data in text fields using escape sequences. Shouldn't
> PostgreSQL reject an invalid UTF8 sequence in any text type?
>
Another note: PostgreSQL rejects invalid
FYI, prior to 8.2, there is another source of bad UTF8 byte sequences:
when using tsearch2 on utf8 content in <8.2, tsearch2 was generating bad
utf8 sequences. as tsearch2 does lowercase each char in the text its
indexing, it did also do so with multibyte-characters... unfortunately
taking eac
