On Wed, Sep 14, 2011 at 03:56:27AM +0200, Craig Ringer wrote:
>
> You can't change the encoding of a database in-place.
Thanks Craig and all the other that responded.
Enjoy your day.
Regards
Johann
--
Johann SpiesTelefoon: 021-808 4699
Databestuurder / Data manag
Hi All
I was trying to load shapfiles into the postgre9, then I used this command:
C:\Program Files\PostgreSQL\9.0>shp2pgsql -s 2400 -c -W LATIN1
C:/Projects/Mandana/OBO/WSPBakgrund_shp/Primärkartan.shp | psql -U postgres OBO
Then I had a UTF encoding problem. (invalid byte sequence fo
On 09/13/2011 08:47 PM, Johann Spies wrote:
Thanks Giulio and Gabriele,
as Giulio pointed out, it seems like the destination database is in
LATIN1 encoding, rather than UTF8. Could you please confirm this?
That was the case. I deleted one of the databases and recreated it with
as a UTF
On 09/14/2011 03:38 AM, MirrorX wrote:
hello to all,
i have tried pg_upgrade to upgrade from 8.4 to 9.0. the operation was
completed succesfully. i only have one question:
i did the procedure twice. once without the 'link (-k) option' and one with
it. obviously the attempt with the link option
Steve Crawford writes:
> waiting for server to start../usr/pgsql-9.1/bin/pg_ctl: symbol
> lookup error: /usr/pgsql-9.1/bin/pg_ctl: undefined symbol: PQping
> There were problems executing "/usr/pgsql-9.1/bin/pg_ctl" -w -l
> "upgrade.log" -D "/var/lib/pgsql/9.1/data" -o "-p 5432 -b" start >>
I am encountering multiple issues in my attempt to upgrade from
PostgreSQL 9.0.4 to 9.1.0 on CentOS 5.6 i386.
The latest working version is 9.0.4 installed from the
http://yum.pgrpms.org/ site. After installing the 9.1 repo RPM and
installing 9.1 via yum I set up a script to do pg_upgrade with
=?ISO-8859-1?Q?Gunthard_St=FCbs?= writes:
>> What kernel and glibc versions are you running, exactly?
> Linux version 2.4.21-266-default
> GNU C Library stable release version 2.3.2 (20030827)
Yeah, we've seen this before. What it boils down to is that kernels
prior to 2.6.x don't have posix_fa
On Tue, 2011-09-13 at 14:47 +0200, Johann Spies wrote:
> Thanks Giulio and Gabriele,
>
> > as Giulio pointed out, it seems like the destination database is in
> > LATIN1 encoding, rather than UTF8. Could you please confirm this?
>
> That was the case. I deleted one of the databases and rec
=?ISO-8859-1?Q?Gunthard_St=FCbs?= writes:
> the correct backtrace looks like this:
> #3 0x082676a1 in pg_flush_data (fd=9, offset=0, amount=57344) at fd.c:335
> #4 0x0826ab02 in copy_file (fromfile=0xbfffeb90 "base/1/12051",
> tofile=0xbfffe790 "base/12277/12051")
> at copydir.c:205
> #5
hello to all,
i have tried pg_upgrade to upgrade from 8.4 to 9.0. the operation was
completed succesfully. i only have one question:
i did the procedure twice. once without the 'link (-k) option' and one with
it. obviously the attempt with the link option was much faster. but, what
does link mean
sorry, I first used for gdb the pg path Tom wrote and not my own one...
the correct backtrace looks like this:
#3 0x082676a1 in pg_flush_data (fd=9, offset=0, amount=57344) at fd.c:335
#4 0x0826ab02 in copy_file (fromfile=0xbfffeb90 "base/1/12051",
tofile=0xbfffe790 "base/12277/12051")
a
Tom,
thanks for your quick response.
as mentioned the linux is rather old (~ 7 years) and i know that some
software is not up to date. (but the admin has no time to update the entire
system)
i don't know what you mean with compiler options. if i enter gcc -v it lists:
Reading specs from /usr/
=?ISO-8859-1?Q?Gunthard_St=FCbs?= writes:
> I installed v9.1 on linux (older suse distr.) from source code using
> configure --without-readline (in case that it is important).
> performing initdb --locale=de_DE.UTF-8 -D /usr/local/pgsql/data/ everything
> run fine until:
> vacuuming database te
Hi all,
I am new to pg linux administration and this list.
I installed v9.1 on linux (older suse distr.) from source code using
configure --without-readline (in case that it is important).
performing initdb --locale=de_DE.UTF-8 -D /usr/local/pgsql/data/ everything
run fine until:
vacuuming
Thanks Giulio and Gabriele,
> as Giulio pointed out, it seems like the destination database is in
> LATIN1 encoding, rather than UTF8. Could you please confirm this?
That was the case. I deleted one of the databases and recreated it with
as a UTF-8 encoded database and the import went well
Hi Johann,
as Giulio pointed out, it seems like the destination database is in
LATIN1 encoding, rather than UTF8. Could you please confirm this?
By reading the little information we have, it seems like you have an
export in UTF8 and you are trying to load it into a LATIN1 database. If
hi,
the character that is giving you troubles is "orizontal ellipsis", this
character does not exists in latin1 encoding, only in utf8, so database you
dumped was utf8 encoded.
i think the fastest way you have to solve the problem is: change the encoding
of the target database you are trying
Good day,
I have installed postgresql 9.0 on my Debian and thought that restoring
the database would be as simple as psql -f .
However: I get several errors like this:
psql:pgdump.txt.1:4453471: ERROR: character 0xe280a6 of encoding "UTF8"
has no equivalent in "LATIN1"
I have changed the clien
On Mon, 2011-09-12 at 13:42 -0500, Peter Koczan wrote:
> Is there any way to set an access log for a specific table?
>
> What I'd like to do is have a record of all access for one table. It
> would be nice to do this by raising a notice and having it show up in
> syslog. I could use triggers, but
19 matches
Mail list logo
