The following bug has been logged online:
Bug reference: 4678
Logged by: Harald Armin Massa
Email address: haraldarminma...@gmail.com
PostgreSQL version: 8.3.5 / 8.3.6
Operating system: XPSP2, 2003, XP SP3, W7 Beta
Description:codepage UTF8 crashes psql
Details:
(sa
On Mon, Feb 2, 2009 at 8:46 PM, Tom Lane wrote:
> "Robert Walker" writes:
>> I have a function that basically loops through a query and uses the results
>> from that query to do an individual insert into another table, and if there
>> is a unique violation, it simply raises a notice and continues
The following bug has been logged online:
Bug reference: 4679
Logged by: Bhajesh
Email address: bbhaj...@zeomega.com
PostgreSQL version: 8.1
Operating system: red hat linux 9
Description:invalid UTF-8 byte sequence detected near byte 0xa3 +
postgresql
Details:
Hi
Dave Page wrote:
On Mon, Feb 2, 2009 at 8:46 PM, Tom Lane wrote:
"Robert Walker" writes:
I have a function that basically loops through a query and uses the results
from that query to do an individual insert into another table, and if there
is a unique violation, it simply raises a notice and
The following bug has been logged online:
Bug reference: 4680
Logged by: Denis Afonin
Email address: v...@itkm.ru
PostgreSQL version: 8.3.6
Operating system: Linux Debian Lenny
Description:Server crashed if using wrong (mismatch) conversion
functions
Details:
I do:
On Fri, Feb 27, 2009 at 10:37 AM, Heikki Linnakangas
wrote:
> But I wonder, why does plpgsql debugger even try to display those variables
> after the exception block? I'm not familiar with the tool; I'm guessing that
> it just displays all variables, regardless of scope.
I believe so. I'm not th
On Thu, Feb 26, 2009 at 03:50:16PM -0500, Tom Lane wrote:
> "aiwaniuk" writes:
> > i postgres version 8.2, 8.3 and probobly 8.1 there is problem with running
> The reason there's an issue here is that you're invoking the same
> function f() both inside and outside the subtransactions caused by
> t
On Thu, Feb 26, 2009 at 03:50:16PM -0500, Tom Lane wrote:
> The reason there's an issue here is that you're invoking the same
i'v forgotten to mention that this behavior we saw when we
had migrated one database from version 8.0 to 8.3. further test showed, that
in v8.2 this problem is also seen. v
Denis Afonin wrote:
test=# CREATE DEFAULT CONVERSION test1 FOR 'LATIN1' TO 'KOI8' FROM
ascii_to_mic;
CREATE CONVERSION
test=# CREATE DEFAULT CONVERSION test2 FOR 'KOI8' TO 'LATIN1' FROM
mic_to_ascii;
CREATE CONVERSION
test=# set client_encoding to 'LATIN1';
server closed the connection unexpected
Bhajesh wrote:
My previous server database encoding was SQL_ASCII.i took the backup in
UTF8 encoding.when i was going to restore the backup in new server whose
encoding is UTF-8 it is throwing some error like "invalid UTF-8 byte
sequence detected near byte 0xa3".When i tried to restore same se
Heikki Linnakangas writes:
> I think we should instead try to break the PANIC cycle. If we exceed
> ERRORDATA_STACK_SIZE, and we're already PANICing, we should just die
> immediately instead of throwing another PANIC about exceeding the stack
> size. The attached patch does that.
I don't think
Tom Lane wrote:
Heikki Linnakangas writes:
I think we should instead try to break the PANIC cycle. If we exceed
ERRORDATA_STACK_SIZE, and we're already PANICing, we should just die
immediately instead of throwing another PANIC about exceeding the stack
size. The attached patch does that.
I
Heikki Linnakangas writes:
> When the conversion function doesn't work, any attempt to send any text
> to the client will fail.
Ah, now I remember: we arranged to short-circuit translation of the
error message when we were in this situation. But it will still get
passed through the encoding con
Tom Lane wrote:
Heikki Linnakangas writes:
When the conversion function doesn't work, any attempt to send any text
to the client will fail.
Ah, now I remember: we arranged to short-circuit translation of the
error message when we were in this situation. But it will still get
passed through t
mvazq...@mx1.ibm.com (Manuel G Vazquez B/Mexico/IBM) writes:
> I have a customer who bought an IBM
> Power Systems, running AIX 5.3 and wants to install the face="Arial">PostgresSQL
> 8.1.9. Can you pls tell me where I can Download this version for AIX? and
> if youa have some documentation or FAQ
Heikki Linnakangas writes:
> Tom Lane wrote:
>> I wonder how ugly it would be to try to suppress encoding
>> conversion as well?
> The error message might contain user data, which might contain non-ASCII
> characters. Or maybe not, but it seems like a shaky assumption to make.
The particular c
Tom Lane wrote:
Heikki Linnakangas writes:
Tom Lane wrote:
I wonder how ugly it would be to try to suppress encoding
conversion as well?
The error message might contain user data, which might contain non-ASCII
characters. Or maybe not, but it seems like a shaky assumption to make.
The pa
Tom Lane wrote:
Josh Berkus writes:
When doing pg_dump in text mode, complext types will be dumped like this:
CREATE TYPE complex_foo (
var INT,
gar TEXT,
natch public.foo_type
);
You didn't say which schema "complex_foo" is in?
Public.
--Josh
--
Sent
Jeff Davis wrote:
On Fri, 2009-02-27 at 01:24 -0500, Tom Lane wrote:
Are you entirely sure that they don't?
Oh, you're right, of course:
postgres=# create type public.mytype as (i int);
CREATE TYPE
postgres=# create type public.mytype2 as (j mytype);
CREATE TYPE
-- pg_dump output:
CREATE TYP
The following bug has been logged online:
Bug reference: 4682
Logged by: Adam Flott
Email address: a...@npjh.com
PostgreSQL version: 8.3.6
Operating system: Debian 5.0
Description:Control-\ segfaults psql
Details:
1. psql amarok
2. enter C-\
3. amarok=# zsh: quit
Josh Berkus writes:
> Ok, I'll have to work up a reproduceable case, because I'm definitely
> getting the "public" qualification in the create type.
Hmm, that shouldn't happen if the containing type is in "public",
so yeah, let's see the test case.
regards, tom lane
--
"Adam Flott" writes:
> 1. psql amarok
> 2. enter C-\
> 3. amarok=# zsh: quit (core dumped) psql amarok
This is not a bug, it's the intended result of typing control-\.
You've probably got "stty quit ^\" set in your profile.
regards, tom lane
--
Sent via pgsql-bugs mail
Heikki Linnakangas writes:
> I think it would be good to have a circuit-breaker to break the infinite
> recursion in case PANIC fails and recurses, for any reason.
Well, your proposed patch replaces core dump due to stack overflow with
core dump due to abort(), which is no improvement at all as
23 matches
Mail list logo
