thomas wrote:
The following bug has been logged online:
Bug reference: 4281
Logged by: thomas
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.3
Operating system: Windows 2003
Description:some types of errors do not log statements
Details:
this isn't reall
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 &
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 versio
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 ba
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
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 er
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] that
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
willi
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 page
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
Windows-and-U
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
http://www.postgresql.org/docs/8.3/static/textsearch-i
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
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
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:
I'l
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 pgsq
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
-
> 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: Sid
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 M
upgrade to 8.2.0
that problem was fixed there (had it myself as well)
- thomas
- Original Message -
From: "Terry Askew" <[EMAIL PROTECTED]>
To:
Sent: Thursday, December 21, 2006 6:13 PM
Subject: [BUGS] BUG #2853: Internal error XXOO Hangs while attempting to
clear table after several
>> 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 subqu
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 . in that case, p
> 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
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 i
... 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 a
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
20
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 relat
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
Here'
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. bu
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 lo
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: d
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
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 eve
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 affect
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, and
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
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. b
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 ...
this was merely 60min ago, and it hasn't yet finished...
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
nice
ult
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 PRO
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
"imad" <[EMAIL PROTECTED]>
To: "Magnus Hagander" <[EMAIL PROTECTED]>
Cc: "Thomas H." <[EMAIL PROTECTED]>; ; "Tom Lane"
<[EMAIL PROTECTED]>
Sent: Sunday, November 12, 2006 5:20 PM
Subject: Re: [BUGS] 8.2beta1 (w32): server process crash (
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 sys
"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:
magnus, has this fix made it into the 8.2b3 codebase? at least it fixed 1 of
my 3 problems ;-)
regards,
thomas
- Original Message -
From: "Magnus Hagander" <[EMAIL PROTECTED]>
To: "Thomas H." <[EMAIL PROTECTED]>
Sent: Monday, October 30, 2006 1:21
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 if
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 proces
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, wh
uot;Magnus Hagander" <[EMAIL PROTECTED]>
To: "Tom Lane" <[EMAIL PROTECTED]>
Cc: "Peter Brant" <[EMAIL PROTECTED]>; "Thomas H."
<[EMAIL PROTECTED]>; ; "Bruce Momjian"
<[EMAIL PROTECTED]>
Sent: Sunday, October 29, 2006 6:10
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 eac
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 havin
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 fu
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:
Sent: Tuesd
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
h
as the subject says - the upgrade.bat in the b2
release thats currently being mirrored points to the installation files
of 8.1 instead of the 8.2 ones.
best regards,
thomas
SQL-8.2\data\pg_xlog\0001000400DB 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:
Sent: Tuesday, October 24, 2006 3:15 PM
Subject: Re: [BUGS] c
"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 "
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
outpu
"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 writ
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" o
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 expect
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.200
ners and the such)
running - 8.1 on the same box (even on same partition) run fine.
regarnds,
- thomas
- Original Message -
From: "Thomas H." <[EMAIL PROTECTED]>
To: "Tom Lane" <[EMAIL PROTECTED]>
Cc:
Sent: Monday, October 23, 2006 11:52
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:
Sent: Monday, October 23, 2006 4:07 AM
Subject: Re: [BUGS] BUG #2712: could not
denied
2006-10-23 03:23:14 LOCATION: smgrsync, smgr.c:888
- thomas
- Original Message -
From: "Thomas H" <[EMAIL PROTECTED]>
To:
Sent: Monday, October 23, 2006 1:28 AM
Subject: [BUGS] BUG #2712: could not fsync segment: Permission denied
The following bug has be
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&#x
67 matches
Mail list logo
