From: Dave Page [EMAIL PROTECTED]
On Thu, May 29, 2008 at 2:05 AM, Thomas H. [EMAIL PROTECTED] wrote:
From: Thomas H. [EMAIL PROTECTED]
i've just verified that the 8.3.1 msi version provided on postgres.org also
does NOT contain the locale folder files. should i report this as a
separate bug
From: Tom Lane [EMAIL PROTECTED]
Thomas H. [EMAIL PROTECTED] writes:
nevertheless the problem/bug exists: changing LC_MESSAGES has no effect
on the windows boxes, while it works on the non-win32 systems. all i
really would like is to get english system messages back on our
non-english win32
From: Thomas H. [EMAIL PROTECTED]
what i noticed: if i delete the folder share/locale/de/ the system
messages are back to english - but that can't be THE solution, can it? :)
well, it actually was the solution, at least to the weird part of the
problem:
there are two versions of win32
From: Tom Lane [EMAIL PROTECTED]
the patch discussed here [1] that supposedly made the win32 msvc builds use
lc_locale properly has flaws.
I think a large part of the confusion that's been evidenced in this
thread is because you are submitting a bug report about a patch that is
not in fact in
Euler Taveira de Oliveira wrote:
please observe the (previously already submitted) test queries. i've
removed the date/time testqueries to no further distract from the
problem. the bogus query select x; always results in a german error
messages no matter what LC_MESSAGES is set:
OK, that's
euler taveira de olivieira wrote:
the patch discussed here [1] that supposedly made the win32 msvc
builds use
lc_locale properly has flaws.
I think you misunderstood the feature [1] added recently. This new
actually no. the problem is as i intended to point out with the system
generated
The following bug has been logged online:
Bug reference: 4186
Logged by: Thomas H
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.1
Operating system: Windows 2003
Description:set lc_messages does not work
Details:
the patch discussed here [1
Tom Lane wrote:
Thomas H. [EMAIL PROTECTED] writes:
Tom Lane wrote:
Can any Windows hackers check into whether the WIN32 coding in
wchar2char() and char2wchar() in ts_locale.c is sane?
has anyone had the chance to look into that problem? i'd be more than
willing to help testing an updated
tom lane wrote:
Can any Windows hackers check into whether the WIN32 coding in
wchar2char() and char2wchar() in ts_locale.c is sane?
has anyone had the chance to look into that problem? i'd be more than
willing to help testing an updated build if needed.
After re-reading Microsoft's man
Tom Lane wrote:
Operating system: Windows 2003
CREATE INDEX posts_fts_idx ON forum.posts USING gin(to_tsvector('english',
p_msg_clean));
ERROR: translation from wchar_t to server encoding failed: No error
Hmm. That error message is close to some code that is specific to the
the reported problem below can be reproduced by using this simple query
straight from the documentation:
SELECT to_tsvector('a fat cat sat on a mat and ate a fat rat');
-- postgres.exe dies instantly, with the logs being the same as in the
bugreport.
interestingly using ::tsvector (which
the reported problem below can be reproduced by using this simple query
straight from the documentation:
SELECT to_tsvector('a fat cat sat on a mat and ate a fat rat');
Works for me:
u=# set default_text_search_config = 'pg_catalog.german';
SET
u=# SELECT to_tsvector('a fat cat sat on a mat
there are more problems with tsvectors. this also fails:
SELECT ' just a test: 123 '::tsvector;
ERROR: syntax error in tsvector: just a test: 123
That's not a bug; your input isn't valid tsvector syntax.
ok. after re-reading page
hi there
i'm not sure it its really a bug - the manual specifies that COPY ...
BINARY between different PGSQL versions might be problematic.
nevertheless: i've imported several tables from 8.2.5 to 8.3b2 without
any problems, until one table produced an error on a timestamp field:
from
tom lane wrote:
i'm not sure it its really a bug - the manual specifies that COPY ...
BINARY between different PGSQL versions might be problematic.
nevertheless: i've imported several tables from 8.2.5 to 8.3b2 without
any problems, until one table produced an error on a timestamp field:
Bug reference: 3715
PostgreSQL version: 8.3b2
Operating system: Windows 2003
Description:StackBuilder failing
some additional info to the just submitted bugreport:
- pgAdminIII fails as well
- postgres service starts fine
- eventlog shows missing dependencies:
Source:
Already fixed - theres an updated build at
http://developer.pgadmin.org/~dpage/postgresql-8.3-beta2-2.zip
Thanks for the report though.
thanks, works fine now. maybe worth a short note in the download
directory, so that others won't report the same thing?
- thomas
hi kenneth
these special characters work fine here:
select lower('ÆØÅ'), upper('æøå'), lower('Æble, tørret'), upper('Æble,
tørret');
result: æøå ÆØÅ æble, tørretÆBLE, TØRRET
as pavel hinted, you probably aren't using the proper locale settings
cheers,
thomas
Original
upgrade to 8.2.0
that problem was fixed there (had it myself as well)
- thomas
- Original Message -
From: Terry Askew [EMAIL PROTECTED]
To: pgsql-bugs@postgresql.org
Sent: Thursday, December 21, 2006 6:13 PM
Subject: [BUGS] BUG #2853: Internal error XXOO Hangs while attempting to
Is it a bug? If no, maybe to produce warning in such cases?
oups. just thumbled over this as well when i forgot a FROM in a WHERE ... IN
() and damaged quite some data. the bad query went like this:
SELECT * FROM movies.names WHERE mov_id IN (SELECT DISTINCT mov_id WHERE
mov_name like
oups. just thumbled over this as well when i forgot a FROM in a WHERE ...
IN
() and damaged quite some data. the bad query went like this:
SELECT * FROM movies.names WHERE mov_id IN (SELECT DISTINCT mov_id WHERE
mov_name like '%, %' LIMIT 2)
the subselect is missing a FROM table. in that
SELECT * FROM movies.names WHERE mov_id IN (SELECT DISTINCT mov_id
WHERE
mov_name like '%, %' LIMIT 2)
IF the subquery would only have returned 2 ids, then there would be at
most
like +/-10 records affected. each mov_id can hold one or more (usuals up
to
5) names. but here, the subquery
Here's a few seconds of the log output (this has been going on for 10
mins as of this e-mail being sent):
2006-11-28 16:16:10 LOG: could not fsync segment 0 of relation
1663/16404/30267: Permission denied
2006-11-28 16:16:10 ERROR: storage sync failed on magnetic disk:
Permission denied
in 8.2.0 the error messages changed a bit:
2006-12-05 03:47:12 [736] LOG: could not fsync segment 0 of relation
1663/16692/2361629: Permission denied
2006-12-05 03:47:12 [736] ERROR: storage sync failed on magnetic disk:
Permission denied
2006-12-05 03:47:13 [736] ERROR: could not open
2006-12-05 03:47:12 [736] LOG: could not fsync segment 0 of relation
1663/16692/2361629: Permission denied
2006-12-05 03:47:12 [736] ERROR: storage sync failed on magnetic disk:
Permission denied
2006-12-05 03:47:13 [736] ERROR: could not open relation
1663/16692/2361629: Permission denied
... in addition to the above messages, the log is now also
flooded by:
2006-12-05 04:16:29 [5196] LOG: could not rename temporary statistics
file
global/pgstat.tmp to global/pgstat.stat: A blocking operation was
interrupted by a call to WSACancelBlockingCall.
Hm ... there simply isn't
So what's holding the file open now? It's evidently not the bgwriter.
one of the unnamed postgresql.exe processes from the connection pool:
postgres: db_outnow outnow 127.0.0.1(3384) idle
Hm. I would imagine that as soon as this process does something,
the messages stop? (It should close
2006-11-29 23:57:52 LOG: could not rename file
pg_xlog/00010019005E to
pg_xlog/00010019007F, continuing to try
i had this one as well. good news is: this bug is fixed in 8.2
- thomas
---(end of broadcast)---
TIP 5:
Did you run into problems where transactions would hang? If so, did
those disappear in 8.2?
well, i wasn't really able to exactly determine under what conditions that
xlog bug appeared in our case. tho it always was when lots of data is
imported at once within one transaction. under normal
We were also running it on Windows Server 2003. We ended up rolling
back service pack 1 and it seems to have taken care of the hanging
transactions and we haven't seen a semctl error in awhile.
interesting. we're using sp1 pgsql since day 1 and the problem only
started when testing 8.2b1.
regarding pg_dump: where there some changes from b3 to rc1 that would
explain the resulting rc1 pg_dump output (-c) being half as big as with
b3?
No...
regards, tom lane
well, it was 300mb before rc1, and now its only 188mb. inbetween i did a
vacuum full on one table. that shoulnd't
I forgot to mention - this problem is occurring on multiple Windows
machines. One of them is running Windows XP Professional. The other is
running Windows Server 2003. I have disabled indexing, virus scanning,
and all non-essential services on both of them. The problem continues
to show up
Perhaps this should be #ifdef WIN32, although there's probably no harm
in doing it on Unixen too. Can someone test this idea?
if magnus/dave could provide me a patched rc1 exe, i could run it in our
semi-productive environment for some tests.
- thomas
---(end of
well yes, as the system is live, users are browsing the website. but
all queries that try to access the table in question are stalled at the
moment. when querying server status i'm seeing lots of queries that are
waiting for access to the table.
would vacuum freeze be faster?
Vacuum freeze
We have never promised backward compatibility of pg_dump output to older
server versions.
regarding pg_dump: where there some changes from b3 to rc1 that would
explain the resulting rc1 pg_dump output (-c) being half as big as with b3?
i've rerun pg_dump several times with the same result,
this somehow sounds buggy:
there's this table forum.posts which had 224mb table size, 145mb toast table
size and 176mb indexes size (aproximately 60'000 rows). as i was doing some
updates of all the records, i've issued a VACUUM FULL tablename...
this was merely 60min ago, and it hasn't yet
this somehow sounds buggy:
vacuum full absolutely *will* bloat your index, if run on a
heavily-modified table. I do not think it will bloat pg_xlog by itself
however; are you sure you don't have some other open transactions?
well yes, as the system is live, users are browsing the website.
The following bug has been logged online:
Bug reference: 2780
Logged by: Thomas H.
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2rc1
Operating system: windows 2003 standard
Description:could not fsync segment 0
Details:
still seeing lots of these errors
me wrote:
i've loaded 1gb of data without any xlog-problems, whereas with the 8.2b2
executable it locked up after ~100mb. the xlog-files are cycling...
if i need to test for some specific behaviour let me know.
what's the status on this patch for inclusion in future 8.2 builds? would be
this bug (please see below) is unfortunately still present in beta3 (win32
build). test case still crashes the child process and lets postmaster kill
reload everything.
it is not GiST-related, i've just validated the same problem using GIN.
this breaks tsearch2 functionality on our win32
PROTECTED]
To: Magnus Hagander [EMAIL PROTECTED]
Cc: Thomas H. [EMAIL PROTECTED]; pgsql-bugs@postgresql.org; Tom Lane
[EMAIL PROTECTED]
Sent: Sunday, November 12, 2006 5:20 PM
Subject: Re: [BUGS] 8.2beta1 (w32): server process crash (tsvector)
yeah... i dont think it will be related to index anyway
Did you do anything to install tsearch2 into this fresh database beyond
\i tsearch2.sql?
no, i used the win32 setup and selected to install tsearch2 contrib
module... so i didn't even had to run \i tsearch2.sql. installation logs
are available if helpful.
should i try a manual install of
in my test case is unfortunately the same - crashing.
- thomas
- Original Message -
From: Tom Lane [EMAIL PROTECTED]
To: Thomas H. [EMAIL PROTECTED]
Cc: imad [EMAIL PROTECTED]; Magnus Hagander [EMAIL PROTECTED];
pgsql-bugs@postgresql.org
Sent: Sunday, November 12, 2006 6:56 PM
Magnus Hagander [EMAIL PROTECTED] writes:
It seems to me that it's not been included in b3. Tom?
I'm waiting for some report of whether it fixes the problems?
voilà:
Sent: Tuesday, October 31, 2006 7:23 AM
Subject: Re: [BUGS] xlog lockup patch (was: BUG #2712: could not fsync
segment:
Windows has another bug; they don't include a proper loopback function
with the standard distribution _and_ they have some asenine view that if
there's no physical network connection available, they tear down the
network stack! This means that anything that connects with TCP/IP can't
work, even
unfortunately, my problems with 8.2 on win32 become
more and more severe. when i wanted to test magnus compiled patch for the xlog
transaction rename lockup, i run into more problems (with the original beta2
files):
it seems that processes regurarly crash after a
number of transactions,
i've loaded 1gb of data without any xlog-problems, whereas with the 8.2b2
executable it locked up after ~100mb. the xlog-files are cycling...
if i need to test for some specific behaviour let me know.
maybe a similar patch could be found for the 2nd permission problem, where
the writer
Hagander [EMAIL PROTECTED]
To: Tom Lane [EMAIL PROTECTED]
Cc: Peter Brant [EMAIL PROTECTED]; Thomas H.
[EMAIL PROTECTED]; pgsql-bugs@postgresql.org; Bruce Momjian
[EMAIL PROTECTED]
Sent: Sunday, October 29, 2006 6:10 PM
Subject: RE: [BUGS] BUG #2712: could not fsync segment: Permission
I
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
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
as the subject says - the upgrade.bat in the b2
release thats currently being mirrored points to the installation files
of8.1 instead of the 8.2 ones.
best regards,
thomas
I'm not in a position to test this though. Magnus or Bruce?
I haven't reproduced this on my box. But if you can give me a patch to
try I can build binaries for Thomas to test, if he can do testing but
not building.
a binary would be marvelous. if too much hasle, i can setup a msvc++ 2005
just a small update: this problem is also present in beta 2.
not a big problem for the moment, as we currently have disabled fulltext
search capabilities on the website.
regards,
thomas
- Original Message -
From: [EMAIL PROTECTED]
To: Tom Lane [EMAIL PROTECTED]
Cc:
As for fixing the problem we do understand: ISTM it's just an
awful idea for pgrename and pgunlink to be willing to loop
forever. I think they should time out and report the failure
after some reasonable period (say between 10 sec and a minute).
is the main problem realy in the rename/delete
Peter Brant [EMAIL PROTECTED] writes:
The same problem exists in 8.1 too. See this thread
http://archives.postgresql.org/pgsql-bugs/2006-04/msg00177.php
Tom and Magnus tracked down a cause, but I don't think a fix was ever
implemented.
Thomas seems to have two different issues there: the
DELETE PEND
Options: Open Access: 00110080
sorry for flooding. just tell me if i shall rather stop.
- thomas
- Original Message -
From: Thomas H. [EMAIL PROTECTED]
To: pgsql-bugs@postgresql.org
Sent: Tuesday, October 24, 2006 3:15 PM
Subject: Re: [BUGS] could not rename xlog
unfortunately not.
and this is not happening with 8.1
regards,
thomas
- Original Message -
From: Tom Lane [EMAIL PROTECTED]
To: Thomas H [EMAIL PROTECTED]
Cc: pgsql-bugs@postgresql.org
Sent: Monday, October 23, 2006 4:07 AM
Subject: Re: [BUGS] BUG #2712: could not fsync segment
(even on same partition) run fine.
regarnds,
- thomas
- Original Message -
From: Thomas H. [EMAIL PROTECTED]
To: Tom Lane [EMAIL PROTECTED]
Cc: pgsql-bugs@postgresql.org
Sent: Monday, October 23, 2006 11:52 AM
Subject: Re: [BUGS] BUG #2712: could not fsync segment: Permission denied
The same problem exists in 8.1 too. See this thread
its only appearing in 8.2 here, i've just rechecked our logs...
is there any workaround? how did you get around that problem of having a
total lockdown?
thanks,
thomas
Thomas H. [EMAIL PROTECTED] 23.10.2006 18:21
there is defenitely
Actually, now that I look back in the archives, I think we had theorized
that the fsync errors come from attempting to fsync a file that's
already been deleted but some backend still has a reference to.
Apparently that leads to EACCES instead of ENOENT (which the code is
already prepared to
with process explorer i can actually check which postgres.exe instance
(in
all cases i've checked its just 1 instance, and always just 1 file) holds
the lock for the file in question.
So which one is it?
it's always one of the db-slaves and not logger process, stats
collector process or
Thomas H. [EMAIL PROTECTED] writes:
right now its PID 4844 (\BaseNamedObjects\pgident: postgres: db_outnow
outnow1 127.0.0.1(2122) idle) that tries to write
D:\DB\PostgreSQL-8.2\data\base\3964774\6422331
Do you actually mean it's trying to write that file? Or is it just
sitting there holding
The log messages you have don't make it clear which process is trying to
do the fsync, but I would expect it to be the bgwriter. (Possibly you
should modify log_line_prefix to include PID so we can tell a bit
better.)
you're right (as always :-)). its the writer process (pid 5196) that
The following bug has been logged online:
Bug reference: 2712
Logged by: Thomas H
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2b1
Operating system: windows 2003 standard
Description:could not fsync segment: Permission denied
Details:
sometimes we're
denied
2006-10-23 03:23:14 LOCATION: smgrsync, smgr.c:888
- thomas
- Original Message -
From: Thomas H [EMAIL PROTECTED]
To: pgsql-bugs@postgresql.org
Sent: Monday, October 23, 2006 1:28 AM
Subject: [BUGS] BUG #2712: could not fsync segment: Permission denied
The following bug has
65 matches
Mail list logo
