Re: [BUGS] BUG #5007: could not reattach to shared memory
Magnus and Craig, Thanks for the help. We upgraded and also put in the patch and things have been running for about a week now with all that in place. The reattach memory problem seems to have been cured by the patch. Unfortunately the System.OutOfMemory from .NET and the LOG: could not receive data from client: Unknown winsock error 10061 in postgresql logs still persist. I suspect the log error is just because the .NET app dies and abruptly disconnects its connection to PostgreSQL when it runs out of memory. I think I have ruled out PostgreSQL as the culprit here since I was able to successfully run the same query and dump out to shape with pgsql2shp command line. Looking at the .NET code, I think its just because they are trying to load the large query data into a DataSet object before dumping to shape file so can't really blame npgsql for that either. I think they'll just have to switch to use a Datareader instead or do a Process call to call pgsql2shp. Thanks, Regina -Original Message- From: Magnus Hagander [mailto:mag...@hagander.net] Sent: Tuesday, August 25, 2009 2:18 AM To: Craig Ringer Cc: Regina; pgsql-bugs@postgresql.org Subject: Re: [BUGS] BUG #5007: could not reattach to shared memory On Tuesday, August 25, 2009, Craig Ringer wrote: > On Tue, 2009-08-25 at 05:44 +, Regina wrote: >> The following bug has been logged online: >> >> Bug reference: 5007 >> Logged by: Regina >> Email address: �...@pcorp.us >> PostgreSQL version: 8.3.6 >> Operating system: Windows 2008 Server Standard >> Description: could not reattach to shared memory >> Details: >> >> One of our clients is getting the following error in their PostgreSQL >> 8.3.6 logs in their http://ASP.NET application. This only happens if >> their application runs a long query (which they dump out to disk and >> disk size (ESRI >> shapefiles) is generally above 70 mb or more) when this fails. >> >> The error is below: >> FATAL: could not reattach to shared memory (key=232, addr=01DF): >> 487 %t WARNING: worker took too long to start; cancelled > > Search the -general mailing list archives for "reattach to shared > memory". The issue has been around for a while but until recently > nobody could reproduce it well enough to isolate it and test possible fixed. > You'll see some recent discussion and a proposed patch. > > Try upgrading to the latest version in the 8.3 series. If you still > see the problem please follow up here, or try the patch for the issuye > proposed on the pgsql-general list. The probable fix is not in a released version - it will be in the next one. Please try to upgrade to the latest and then replace postgres.exe with the one from http://blog.hagander.net ad let us know if it works in your situation. > >> In these cases their .NET app returns this error Exception of type >> 'System.OutOfMemoryException' was thrown > > That's probably a bug in their application caused by failure to > properly handle a connection problem. Yes, or possibly npgsql having the bug, though I haven't heard of it there. The stacktrace should probably tell you where - if not, a memory dump with the debugger. /Magnus -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5010: perl iconv function returns ? character
Cluster is created with cs_CZ.UTF-8 collation.
List of databases
Name| Owner | Encoding | Collation |Ctype|
Access privileges
---+--+--+-+-+---
postgres | postgres | UTF8 | cs_CZ.UTF-8 | cs_CZ.UTF-8 |
template0 | postgres | UTF8 | cs_CZ.UTF-8 | cs_CZ.UTF-8 | =c/postgres
:
postgres=CTc/postgres
template1 | postgres | UTF8 | cs_CZ.UTF-8 | cs_CZ.UTF-8 | =c/postgres
:
postgres=CTc/postgres
(3 rows)
2009/9/6 Tom Lane :
> Robert Haas writes:
>> On Tue, Aug 25, 2009 at 8:15 AM, Lampa wrote:
>>> function my_ascii2 is defined:
>>> CREATE FUNCTION my_ascii2(text) RETURNS text AS $$ use strict; use
>>> Text::Iconv; my $conv = Text::Iconv->new("UTF8", "ASCII//TRANSLIT"); return
>>> $conv->convert($_[0]); $$ LANGUAGE plperlu;
>>>
>>> 8.3.x version works perfectly, 8.4.0 problem
>
>> I can't reproduce this on 8.4.0 or CVS HEAD. I think that whatever
>> problem you have here is not a PostgreSQL bug.
>
> I suspect that function will only work as desired in a database with
> UTF8 server_encoding. Maybe the problem is the 8.4 database is set up
> with some other encoding?
>
> regards, tom lane
>
--
Lampa
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] 8.4 dropped Russian server translations
Hello all, is there any reason why 8.4 dropped src/backend/po/ru.po? It was still present in 8.3, and still works. It might perhaps not be entirely up to date, but 90% coverage is certainly better than 0? Or were there any other problems with it? Thanks in advance, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: [BUGS] 8.4 dropped Russian server translations
Martin Pitt writes: > is there any reason why 8.4 dropped src/backend/po/ru.po? The translation team instituted a policy that translations must be at least X% complete to be included. If you have users complaining that their favorite language was dropped, please suggest that the translation team could use some help. > 90% coverage is certainly better than 0? According to http://babel.postgresql.org/ it's more like 38%. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] 8.4 dropped Russian server translations
Tom Lane [2009-09-06 10:24 -0400]: > According to > http://babel.postgresql.org/ > it's more like 38%. Ah, thanks for the link! Makes sense then. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5034: plperlu problem with gethostbyname
On Sep 5, 2009, at 6:52 PM, Tom Lane wrote:
Robert Haas writes:
On Thu, Sep 3, 2009 at 5:21 PM, Diego de Lima> wrote:
Using Fedora 10 default rpm packages, all updated last month via
yum.
I can't reproduce this on a clean build of 8.3.7 or on a clean build
of CVS HEAD, both against perl 5.10.0, so I don't think this is a
PostgreSQL bug. I'm guessing you have a bug in your code someplace.
Here's the test case I used.
create or replace function test() returns varchar as $$use
Data::Dumper; Dumper(gethostbyname("www.google.com"));$$ language
plperlu;
select test();
Don't have Fedora 10 installed anymore, but the F-11 packages should
be equivalent, and on F-11 I get this:
test
-
$VAR1 = 'www.l.google.com';
$VAR2 = 'www.google.com';
$VAR3 = 2;
$VAR4 = 4;
$VAR5 = 'J}';
$VAR6 = 'J}c';
$VAR7 = 'J}g';
$VAR8 = 'J}h';
$VAR9 = 'J}i';
$VAR10 = 'J}j';
(1 row)
I don't know enough about either gethostbyname or Data::Dumper
to figure out if this is sane or not.
I think so. It's certainly an array rather than just the scalar 1, as
the OP alleged we were producing.
...Robert
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5010: perl iconv function returns ? character
Robert Haas writes:
> On Tue, Aug 25, 2009 at 8:15 AM, Lampa wrote:
>> function my_ascii2 is defined:
>> CREATE FUNCTION my_ascii2(text) RETURNS text AS $$ use strict; use
>> Text::Iconv; my $conv = Text::Iconv->new("UTF8", "ASCII//TRANSLIT"); return
>> $conv->convert($_[0]); $$ LANGUAGE plperlu;
>>
>> 8.3.x version works perfectly, 8.4.0 problem
> I can't reproduce this on 8.4.0 or CVS HEAD. I think that whatever
> problem you have here is not a PostgreSQL bug.
Hmm ... I can reproduce the problem on Fedora 11. Given a UTF8-encoded
database (I don't think locale matters), 8.3.7 works as described, but
8.3.8 fails as described, as do 8.4.1 and HEAD. Given that the only
difference in plperl.c between 8.3.7 and 8.3.8 is the addition of the
PERL_SYS_INIT3 call, I have to suppose that that's screwing up
Text::Iconv somehow.
I'd bet a small amount of money that this is somehow related to the
UTF8-specific code in plperl_safe_init(), which always struck me
as unexplained hocus-pocus. Since the test function is plperlu,
plperl_safe_init() obviously can't be directly to blame; but I'm
thinking that what it's really doing is papering over some missed
initialization issue that affects plperlu functions too.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5010: perl iconv function returns ? character
On Sun, 2009-09-06 at 12:52 -0400, Tom Lane wrote: > I would have said that the RPMs are > not built in any way significantly different from a straight > configure-and-build-from-source, but it appears that something in > the RPM build options makes this work. Investigating ... Could it be because of perl-Text-Iconv package? -- Devrim GÜNDÜZ, RHCE Command Prompt - http://www.CommandPrompt.com devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org signature.asc Description: This is a digitally signed message part
Re: [BUGS] BUG #5010: perl iconv function returns ? character
I wrote: > Hmm ... I can reproduce the problem on Fedora 11. Given a UTF8-encoded > database (I don't think locale matters), 8.3.7 works as described, but > 8.3.8 fails as described, as do 8.4.1 and HEAD. Given that the only > difference in plperl.c between 8.3.7 and 8.3.8 is the addition of the > PERL_SYS_INIT3 call, I have to suppose that that's screwing up > Text::Iconv somehow. Huh ... belay that. Diking out the PERL_SYS_INIT3 call doesn't make the problem go away. What I was actually comparing was the current Fedora 11 8.3.7 RPMs with 8.3.8 built from source. I would have said that the RPMs are not built in any way significantly different from a straight configure-and-build-from-source, but it appears that something in the RPM build options makes this work. Investigating ... (Whether this has anything to do with the OP's problem on Debian remains to be determined, but it's definitely busted on Fedora.) regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5010: perl iconv function returns ? character
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= writes: > On Sun, 2009-09-06 at 12:52 -0400, Tom Lane wrote: >> I would have said that the RPMs are >> not built in any way significantly different from a straight >> configure-and-build-from-source, but it appears that something in >> the RPM build options makes this work. Investigating ... > Could it be because of perl-Text-Iconv package? Well, you have to install that before you can test the problem at all, but the working and non-working cases are using the same Text::IConv code. I think I just figured it out though. I had dismissed locale as not being the critical difference, but that was foolish (and I paid for it with an hour of wasted effort). My RPM installation is working because it defaults to en_US locale, and my source installation is not working because it uses C locale. If I switch to either en_US or cz_CZ locale then Text::IConv gives the expected result. I now believe that the OP's actual problem is related to this: http://archives.postgresql.org/pgsql-committers/2009-07/msg00098.php He's probably ending up in C locale internally. If so it'll be fixed in 8.4.1. The only observation not accounted for is Robert's statement that he couldn't reproduce it in 8.4.0 --- but I think the behavior with the bug is dependent on the postmaster's starting environment, so it would be easy to fail to duplicate someone else's result. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5040: Latest version of PostgreSQL's JDBC driver is not available in Maven's central repository
The following bug has been logged online: Bug reference: 5040 Logged by: Clemens Fuchslocher Email address: fuchsloc...@users.sourceforge.net PostgreSQL version: 8.4 Operating system: Debian GNU/Linux 5.0 Description:Latest version of PostgreSQL's JDBC driver is not available in Maven's central repository Details: The latest version of PostgreSQL's JDBC driver is not available in Maven's central repository: http://repo1.maven.org/maven2/postgresql/postgresql/ http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&&query=Postgr eSQL&summary=true&description=true&body=true&pid=10367 Guide to uploading artifacts to the Central Repository http://maven.apache.org/guides/mini/guide-central-repository-upload.html -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5041: Changing data_directory problem
The following bug has been logged online: Bug reference: 5041 Logged by: Jonas Email address: jonasdono...@hotmail.com PostgreSQL version: 8.4 Operating system: Ubuntu 9.10 Description:Changing data_directory problem Details: After changing data_directory - in the same way as I did for postgres 8.3 - postgres 8.4 gives me: r...@ip-10-224-94-129:/mnt/postgresql/8.4/main# sudo /etc/init.d/postgresql-8.4 start * Starting PostgreSQL 8.4 database server Error: could not exec /usr/lib/postgresql/8.4/bin/pg_ctl /usr/lib/postgresql/8.4/bin/pg_ctl start -D /mnt/postgresql/8.4 /main -l /var/log/postgresql/postgresql-8.4-main.log -s -o -c config_file="/etc/postgresql/8.4/main/postgresql.conf" : -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5040: Latest version of PostgreSQL's JDBC driver is not available in Maven's central repository
Clemens Fuchslocher wrote: The following bug has been logged online: Bug reference: 5040 Logged by: Clemens Fuchslocher Email address: fuchsloc...@users.sourceforge.net PostgreSQL version: 8.4 Operating system: Debian GNU/Linux 5.0 Description:Latest version of PostgreSQL's JDBC driver is not available in Maven's central repository Details: The latest version of PostgreSQL's JDBC driver is not available in Maven's central repository: http://repo1.maven.org/maven2/postgresql/postgresql/ http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&&query=Postgr eSQL&summary=true&description=true&body=true&pid=10367 Guide to uploading artifacts to the Central Repository http://maven.apache.org/guides/mini/guide-central-repository-upload.html Not sure what you want us to do here? even if a knew what maven or an "artifact" I would be stillf confused as to what you consider a bug here. The official website for the JDBC driver is http://jdbc.postgresql.org/ with downloads at http://jdbc.postgresql.org/download.html. Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5040: Latest version of PostgreSQL's JDBC driver is not available in Maven's central repository
On Sun, 2009-09-06 at 14:40 +, Clemens Fuchslocher wrote: > > The latest version of PostgreSQL's JDBC driver is not available in > Maven's > central repository: > > http://repo1.maven.org/maven2/postgresql/postgresql/ Why don't you file a bug report against them? -- Devrim GÜNDÜZ, RHCE Command Prompt - http://www.CommandPrompt.com devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org signature.asc Description: This is a digitally signed message part
[BUGS] BUG #5042: Update numeric within a rule
The following bug has been logged online: Bug reference: 5042 Logged by: Ilian Georgiev Email address: georgiev.il...@gmail.com PostgreSQL version: 8.1.10 Operating system: Windows XP Description:Update numeric within a rule Details: Hello I have a sutuation where I can do update on numeric column with a signle update but when this update statement is in a rule it doesn't wotk properly. Look : I have a table with videos : CREATE TABLE video ( video_sid SERIAL PRIMARY KEY, category_sid int NOT NULL REFERENCES category ON UPDATE RESTRICT ON DELETE RESTRICT, url varchar(32) NOT NULL, user_sid int NOT NULL REFERENCES "user" ON UPDATE RESTRICT ON DELETE RESTRICT, image_sid int REFERENCES image, creation_datetime timestamp NOT NULL DEFAULT NOW(), view_count int NOT NULL DEFAULT 0, comment_count int NOT NULL DEFAULT 0, rating numeric(4,2) NOT NULL DEFAULT 0, rating_percent int NOT NULL DEFAULT 0, votes int NOT NULL DEFAULT 0, is_published boolean NOT NULL DEFAULT false, title varchar(128) NOT NULL, description text ); GRANT INSERT, UPDATE, SELECT ON video TO web; GRANT SELECT, UPDATE ON video_video_sid_seq TO web; COMMENT ON TABLE video IS 'Holds video desctiptions'; CREATE OR REPLACE FUNCTION update_rating_percent() RETURNS "trigger" AS $BODY$ BEGIN IF (NEW.rating!=0) THEN NEW.rating_percent := ((NEW.rating / 5 ) * 100)::int; END IF; RETURN NEW; END; $BODY$ LANGUAGE 'plpgsql' VOLATILE; GRANT EXECUTE ON FUNCTION update_rating_percent() TO web; CREATE TRIGGER update_rating_percent_trg BEFORE UPDATE ON video FOR EACH ROW EXECUTE PROCEDURE update_rating_percent(); and table with votes : CREATE TABLE video_vote ( video_sid int NOT NULL REFERENCES video ON UPDATE CASCADE ON DELETE CASCADE, ip_address inet NOT NULL, rate int NOT NULL CHECK (rate > 0 AND rate < 6), creation_datetime timestamp NOT NULL DEFAULT NOW() ); GRANT INSERT, UPDATE, DELETE, SELECT ON video_vote TO web; COMMENT ON TABLE video_vote IS 'Votes of every user by IP address'; CREATE UNIQUE INDEX video_vote_ukey ON video_vote (video_sid, ip_address); with a rule connected to the video table : CREATE OR REPLACE RULE video_vote_insert_rule AS ON INSERT TO video_vote DO ALSO UPDATE video SET votes = votes + 1, rating = (( SELECT SUM(rate)::numeric FROM video_vote WHERE video_sid = NEW.video_sid ) / (votes + 1) )::numeric WHERE video_sid = NEW.video_sid; now when I do simple update on video it gets the right value for scale.But when I do insert on video_vote and this do update on video table I got .00 for scale. I even changed my rule to : CREATE OR REPLACE RULE video_vote_insert_rule AS ON INSERT TO video_vote DO ALSO UPDATE video SET rating = 2.95 WHERE video_sid = NEW.video_sid; The result in rating column was 2.00 . When I do : update video set rating = 2.95 where video_sid = 1; Then the result is expected = 2.95 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5041: Changing data_directory problem
Jonas [2009-09-06 17:29 +]: > After changing data_directory - in the same way as I did for postgres 8.3 - The official way is to move the directory and set "data_directory" in postgresql.conf. (Or create a new cluster with the -d/--datadir option). Is that what you did? Please give us the output of "pg_lsclusters". Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5041: Changing data_directory problem
On Sunday 06 September 2009 19:29:54 Jonas wrote: > The following bug has been logged online: > > Bug reference: 5041 > Logged by: Jonas > Email address: jonasdono...@hotmail.com > PostgreSQL version: 8.4 > Operating system: Ubuntu 9.10 > Description:Changing data_directory problem > Details: > > After changing data_directory - in the same way as I did for postgres 8.3 - > postgres 8.4 gives me: How did you do it in 8.3? Andres -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
