>> I'm using PG 8.2.3:
>
> You should update to 8.2.4, it includes a security fix and several bug
> fixes.
That was my next option. My last backup dump looks suspiciously small,
but the day before that looks about right.
> My first thought is bad memory. It's always good to rule that out sinc
Hello all,
I'm using PG 8.2.3:
PostgreSQL 8.2.3 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.3.6
I happened to notice this error in the log when my application was refused
a db connection (quite unexpectedly):
PANIC: corrupted item pointer: offset = 3308, size = 28
LOG: autovacuum proces
> - dblink would allow you to open another connection concurrently
This suggestion worked perfectly, thank you very much.
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail co
Hi there,
I'm using PG 8.2.3.
Is it possible to (somehow) commit a specific statement in a trigger
function if the function itself is rolled back because of an error (eg, for a
unique index error)?
For example:
create table tab1 (col1 int unique);
create table tab2 (col1 int);
CREATE OR REPLAC
> [EMAIL PROTECTED] writes:
>>> It should be in the dump file, almost the first line. Locale is of no
>>> interest to pg_dump, you'll have to decide how you want it.
>
>> Yes: UTF-8 and the other is LATIN1
>
> Note that this represents what the original server *thought* the
> encoding was. But
> On Fri, Aug 04, 2006 at 11:58:22AM +0200, [EMAIL PROTECTED] wrote:
>> > On Fri, Aug 04, 2006 at 10:48:17AM +0200, [EMAIL PROTECTED] wrote:
>> > Two big questions:
>> >
>> > 1. What encoding are the two database (\l will tell you)?
>> > 2. What encoding are the clients expecting?
>
>> I've even
> On Fri, Aug 04, 2006 at 10:48:17AM +0200, [EMAIL PROTECTED] wrote:
>> Hello all,
>>
>> I somehow managed to stuff up the encoding (or locale or something) in a
>> transfer of a database from one machine to another (also different linux
>> distribution).
>>
>> The problem is this: the origional
Hello all,
I somehow managed to stuff up the encoding (or locale or something) in a
transfer of a database from one machine to another (also different linux
distribution).
The problem is this: the origional database was created and populated
with data using whatever default locale/encoding was i
