Hello everyone.
Sorry,I'm not good at English.
But Postgres8.2(Win) installer error ocurred.
Installing, when creating initdb process says error as follows,
"WS2 32.dll can't find. Fatal error"
See Program Files/PostgreSQL/8.2/tmp
But,that file is empty.
Regards,
Thanks.
--
Toshihito Kodama
Timur Luchkin wrote:
> I have stored procedure in "plperlu" language. After the call to it Im
> getting "could not open relation ... No such file or directory" on any next
> operation in psql (the procedure itself works fine). If I'll close the
> console and reopen it again, then everything works f
The following bug has been logged online:
Bug reference: 3673
Logged by: Timur Luchkin
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: Fedora Core 5 / Red Hat Ent. Linux AS 3
Description:Untrusted perl language: ERROR: could not open relat
Tom Lane wrote:
> Martin Pitt <[EMAIL PROTECTED]> writes:
>> However, if I use 8.2 programs with the 8.3 library, things start to
>> become weird:
>
>> $ # kill postgres instance
>> $ rm -rf /tmp/x; LC_ALL=3Den_US.UTF-8 /usr/lib/postgresql/8.2/bin/initdb =
>> --encoding UTF8 -D /tmp/x
>
> Doe
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Perhaps we should leave a gap where JOHAB used to be and add it at the end.
> Otherwise we may have to do a soname exercise.
The question to me is whether the encoding numbers used by libpq
should be considered anything other than black-box numbers.
Martin Pitt <[EMAIL PROTECTED]> writes:
> Sounds convincing. The hard part is that this then also a bug in 8.2's
> initdb, which cannot be changed,
Why not? Also, is there really a bug in 8.2 or before? chklocale.c
is new in 8.3.
regards, tom lane
--
Hi,
Tom Lane [2007-10-12 13:23 -0400]:
> I'm becoming more and more convinced that this is initdb's bug not
> libpq's. The problem stems from initdb using libpq's functions and
> assuming that its numbers match up with pg_wchar.h. But note that
> pg_wchar.h is not exported by libpq.
Sounds conv
Heikki Linnakangas wrote:
> Note that we've also added PG_EUC_JIS_2004 and PG_SJIS (client-only) to
> the enumeration. That means that all the previous client-only encodings
> have been shifted by two.
On closer look, PG_SJIS is not new, PG_SHIFT_JIS-2004 is. But that was
added to the end, so the
Hi,
Tom Lane [2007-10-12 12:02 -0400]:
> Does anything other than initdb get weird?
It's hard to tell, my test suite concentrates on hammering initdbs
with various locales, encodings, getting a chain of 7.4->8.{0,1,2,3}
upgrades and testing the conversion of postgresql.conf arguments, etc.
I do n
Am Freitag, 12. Oktober 2007 schrieb Tom Lane:
> Sorry, you don't get to put JOHAB back into the portion of the list that
> is backend-legal encodings.
>
> It's a bit nasty that this enum is exposed as part of the ABI, but I'm
> afraid we may be stuck with that decision.
Perhaps we should leave a
Martin Pitt <[EMAIL PROTECTED]> writes:
> However, if I use 8.2 programs with the 8.3 library, things start to
> become weird:
> $ # kill postgres instance
> $ rm -rf /tmp/x; LC_ALL=3Den_US.UTF-8 /usr/lib/postgresql/8.2/bin/initdb =
> --encoding UTF8 -D /tmp/x
Does anything other than initdb
Martin Pitt <[EMAIL PROTECTED]> writes:
> Ah, got it. The ordering in pg_enc2name_tbl[] changed, which makes the
> indices jump around.
Sorry, you don't get to put JOHAB back into the portion of the list that
is backend-legal encodings.
It's a bit nasty that this enum is exposed as part of the AB
Hi,
Martin Pitt [2007-10-12 16:33 +0200]:
> I'm currently hunting down the last postgresql-common test case
> failure that I see with 8.3beta1. It seems the 8.3 version of libpq
> changes some internal encoding lists?
Ah, got it. The ordering in pg_enc2name_tbl[] changed, which makes the
indices
Hi PostgreSQL developers,
I'm currently hunting down the last postgresql-common test case
failure that I see with 8.3beta1. It seems the 8.3 version of libpq
changes some internal encoding lists?
If I use the 8.2 programs with the 8.2 library, all is well:
$ LC_ALL=en_US.UTF-8 /usr/lib/postgre
The following bug has been logged online:
Bug reference: 3672
Logged by: Marc Mamin
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: Linux
Description:ALTER TYPE change the underlying index
tablespace to default
Details:
steps to repeat:
On Fri, Oct 12, 2007 at 05:23:30PM +0900, KODAMA, Toshihito wrote:
> Hello everyone.
> Sorry,I'm not good at English.
>
> But Postgres8.2(Win) installer error ocurred.
>
> Installing, when creating initdb process says error as follows,
> "WS2 32.dll can't find. Fatal error"
>
> See Program Files
Hi,
Tom Lane [2007-10-12 11:50 -0400]:
> Martin Pitt <[EMAIL PROTECTED]> writes:
> > Ah, got it. The ordering in pg_enc2name_tbl[] changed, which makes the
> > indices jump around.
>
> Sorry, you don't get to put JOHAB back into the portion of the list that
> is backend-legal encodings.
Ah, the
Neil Conway <[EMAIL PROTECTED]> writes:
> I wouldn't call this behavior buggy, but I found it somewhat surprising.
> expression_tree_walker() assumes that the walker has already been
> invoked on the current node (the node that a given recursive call of
> expression_tree_walker() has been invoked o
The following bug has been logged online:
Bug reference: 3674
Logged by: ITAGAKI Takahiro
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3beta1
Operating system: independent
Description:Unnecessary checkpoints by WAL Writer
Details:
WAL Writer requests unnec
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> But OTOH, I feel we should just stop exporting them now; I don't think
> there's a legitimate use case for a client application to use them.
Actually, that doesn't seem workable as a solution to our immediate
problem: we surely can't remove export
"ITAGAKI Takahiro" <[EMAIL PROTECTED]> writes:
> WAL Writer requests unnecessary checkpoints with CHECKPOINT_CAUSE_XLOG.
> RedoRecPtr, declared in xlog.c, is initialized at StartupXLOG() but never
> updated in WAL Writer because it never calls XLogInsert(). It judges excess
> of segments wrongly.
OK, I spent some time analyzing this problem, and I think there's a
fairly simple way to avoid a libpq ABI break between 8.2 and 8.3.
Although we removed PG_JOHAB as a backend encoding, we added
PG_EUC_JIS_2004. Therefore, if we rearrange things to give
PG_EUC_JIS_2004 the old number of PG_JOHAB,
"Marc Mamin" <[EMAIL PROTECTED]> writes:
> Description:ALTER TYPE change the underlying index
> tablespace to default
Good catch, will fix.
regards, tom lane
---(end of broadcast)---
TIP 1: if posting/reading throug
23 matches
Mail list logo
