[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
[BUGS] BUG #5351: compiling with --disable-shared is broken (patch included)
The following bug has been logged online: Bug reference: 5351 Logged by: Jonas Lund Email address: whizz...@gmail.com PostgreSQL version: 8.4.2 (+others) Operating system: FreeBSD (generic problem) Description:compiling with --disable-shared is broken (patch included) Details: I'm compiling with "--disable-shared" on 8.4.2 (worked with 8.3.1) and it fails with: gmake[3]: *** No rule to make target `libpq.so.5', needed by `all-shared-lib'. When examining Makefile.shlib i noticed that an ifeq clause had been narrowed down in the file between 8.3.1 and 8.4.2 and now missed a bunch of "secondary clauses" declaring the "shlib" variable and thus activating the: all-shared-lib: $(shlib) makefile rule EVEN IF --disable-shared is enabled and thus not making the libfile. This following patch disables those clauses: -- --- Makefile.shlib.orig 2010-02-28 23:15:15.877364960 +0100 +++ Makefile.shlib 2010-02-28 23:08:28.631839830 +0100 @@ -120,6 +120,8 @@ override CPPFLAGS += -DSO_MAJOR_VERSION=$(SO_MAJOR_VERSION) endif +ifeq ($(enable_shared), yes) + ifeq ($(PORTNAME), aix) ifdef SO_MAJOR_VERSION shlib = lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION) @@ -332,6 +334,8 @@ endif +endif + ## ## BUILD -- 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 #5351: compiling with --disable-shared is broken (patch included)
> Hmm ... out of curiosity, what exactly is your motivation for doing > that? The reason we don't test this anymore is that so much of > Postgres' functionality is bound up in loadable modules that a build > without them seems of little use. It wouldn't even come close to > passing the regression tests, for example. Personally i got sick of having software break after having dependant libs changing their ABI's. (Say when having to upgrade some lib that is used by an service facing outwards also being used by some internal software). When i googled for the problem i also noticed that someone building iPhone software had the same problem as me. Apple doesn't allow dynamic libraries, and if you're developing anything seriously you also need to make a "fat" binary with arm code for the iPhone and x86 for the simulator. (I've worked with some iPhone software recently so it struck me eventhough i'd personally prolly go with sqlite for that) What kind of functionality is tied to shared libs ? If building without shared libs isn't supported anymore then i think you should disable it altogether in the configure script instead of letting it be broken. Having options that breaks the build isn't making anyone happy. > The reason I'm being picky about this is that the change in > Makefile.shlib was intentional, and I'm afraid that your change > would break other stuff that works now. Yes, it's a big possibility that it breaks something since it's a big block of things for a bunch of platforms and i was hesitant of submitting the patch initially for that reason. Then again.. 2 good reasons why it should go in or the entire thing should be changed back to as it was before (or have something better done by someone who knows the makefiles better than me). 1: This clause is only enabled with --disable-shared being specified and as far as i could spot and go through other makefiles i couldn't notice any of the rules being used outside unless shared libraries are used. 2: Shouldn't things mostly not having to do with non-shared libs go somewhere else than Makefile.shlib ? :) > I'm not even convinced > that it's a good way of solving your problem --- shouldn't the > all-shared-lib target not get built, if you've disabled shlib > building? That's the point of the patch however, the "all-shared-lib" rule is defined in this file as: all-shared-lib: $(shlib) and because you have a bunch of platform specific rules setting the shlib variable even if disable-shared is specified (and thus triggering the rule without building the lib) it cannot be set if this rule isn't to be activated. I'm not 100% familiar with how gmake works but i guess there would be 3 other ways to solve the issue with the last one probably being the most clean variant. 1: have an "ifeq ($(enable_shared), yes)" declaration around every definition of "shlib" in the platform specifics, this is bound to be broken over and over but for separate platforms. 2: "undefine" shlib after the platform specific section (does this work with gmake?) 3: make the all-shared-lib rule fully conditional or have an conditional variant without any dependancy (does this work with gmake?) regards, Jonas Lund -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Re: low performance
Do you have any index on the tables ? Any triggers ?
If you want to insert 1 million rows you should drop the index, insert the data and
then recreate the index.
You should also try the COPY command to insert the data.
You should also avoid having anyone to connect to the database when you insert a lot
of rows, and 1 million rows are a lot of rows for any database.
I've been able to insert, in one table, 17 million record in ~3 hours on a Compaq SMP
750 Mhz with 512MB
by dropping the index, using several COPY commands at the same time loading different
parts of the data and then creating the index again.
At the time of the inserts no other processes than the COPY's was connected to the
database.
/Jonas Lindholm
Andreas Wernitznig wrote:
> I am running the precomplied binary of Postgreql 7.1.2 on a Redhat 7.1 (on a Dual
>Celeron System with 256MB, kernel 2.4.4 and 2.4.5) System.
> (The installation of the new 7.1.3 doesn't seem to solve the problem)
>
> I am connecting to the DB with a Perl Program (using Perl 5.6.0 with DBD-Pg-1.01 and
>DBI-1.19).
> The program inserts some million rows into a db with about 30 tables. The processing
>takes (if everyting works fine) about 10 hours to complete. Usually the my
>Perl-Script and the database share the available CPU time 50:50.
> But sometimes the database is very slow eating up most (>98%) of the available CPU
>time.
> (Of cause I know VACUUM and VACUUM ANALYZE, this is not the problem).
>
> The only thing that seems to help then, is killing the perl script, stopping
>postgresql, running "ipcclean", and start again from the beginning. If it works from
>the beginning, the database is ususally very fast until all data are processed.
>
> But if someone else connects (using psql), sometimes the database gets very slow
>until it is using all the CPU time.
>
> There are no error messages at postgres-startup.
> I already increased the number of buffers to 2048 (doesn't help)
>
> I cannot reproduce these problems, sometimes the db is fast, sometimes very slow.
>The perl script doesn't seem to be the problem, because I wrote all SQL Commands to a
>file and processed them later ("psql dbname postgres < SQL-File").
> Same thing: sometimes slow sometimes fast.
>
> Andreas
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] BUG #2555: runtime error 80040e21
The following bug has been logged online:
Bug reference: 2555
Logged by: Jonas Bruhn
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.4
Operating system: Windows 2000 Pro
Description:runtime error 80040e21
Details:
I'm using VB6, and trying to update a table. It is all happening on my home
pc with IIS running too. I can download the table to a datagrid, bit I can't
type any text i a textbox and update it whith out the error occuring. Here
is the code and some remarks afterwards:
Private Sub command2_click()
Dim cn As ADODB.Connection
Dim rs As ADODB.Recordset
Set cn = New ADODB.Connection
cn.Open "Provider=PostgreSQL.1;Password=***;User ID=postgres;Data
Source=localhost;Location=***" ';Extended Properties="""
Set rs = New ADODB.Recordset
rs.CursorLocation = adUseClient
rs.Open "select tilbudspris, materialer from efterkalk", cn,
adOpenKeyset, adLockOptimistic
rs.AddNew
debug here --- rs("tilbudspris").Value = Text1.Text
rs("materialer").Value = Text2.Text
rs.Update
Set rs.ActiveConnection = Nothing
Set rs = Nothing
cn.Close
Set cn = Nothing
End Sub
Remarks:
The columns in the table is set to text.
I've tried to write rs!tilbudspris and rs!materialer.
I've tried to trim(text1.text)
I've tried adopenstatic
I've tried rs.movefirst
I can't recognise where the problem should be, if it isn't a bug.
Best regards
Jonas Bruhn
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
[BUGS] BUG #3737: lower/upper fails to match extended chars in LATIN1
The following bug has been logged online: Bug reference: 3737 Logged by: Jonas Forsman Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.10 Operating system: Ubuntu 6.06 LTS Description:lower/upper fails to match extended chars in LATIN1 Details: Try: select * from table where lower(address) like '%Ã¥%' This select fails to find addresses including capital à and similars in LATIN1 (like à , Ã, Ã). The same bug is valid for upper. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #3737: lower/upper fails to match extended chars in LATIN1
From my point of view (administrators view, not developers) it is such a drawback in postgres implementation that it seriously challenges the position as a competitor to the big dragons. (IF they suffer from the same missing feature) Recreating indicies is maybe not great but can be done quit easily compared to reinitializing a db or recoding an entire database. Sometimes a bit of a solution is all what it is needed. Would it be possible to change the locale on the fly and only recreate indicies afterwards? / Jonas ps. I'd love to send you a patch, but there is no way it would be a good thing time/performance wise for me doing this. I am trying to be a great ambassador though, spreading the words everywhere. ds. Heikki Linnakangas skrev: (please keep the list cc'd) Jonas Forsman wrote: if I cannot change charset within a postgres installation and then benefit from all the features in postgres isn't that to be seen as a bug or at least it should be a workaround easier than dumping everything which I think is a too large risk to take if not really neccessary. Well, it's not a bug in the sense that it's documented and working as designed. But I agree that it sucks. Unfortunately changing the locale on-the-fly isn't as easy as it might sound. The locale affects the sort-ordering, for example, which means that you'd have to at least recreate all indexes with text data in them anyway. Changing the character encoding would be even worse. You'd have to re-encode all data, which means rewriting all data in the database. The best solution would be to support per-database and even per-table and per-column locales and character encodings, so that you could do the conversions piece by piece. Patches are welcome :-). -- ---- Jonas Forsman VD, Axier Technologies AB Malmgatan 2 SE-703 54 Örebro, SWEDEN Tel.: +46 (0)19 12 00 90 Mobile: +46 (0)73 506 33 00 [EMAIL PROTECTED] This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] Daylight saving bug in PostgreSQL 7.2.1 ?
Hi!
I believe I've found a bug with daylight saving time.
The example below shows that after inserting a row with a date and time
when daylight saving is changing (6 April 2003 02:00:00) any selects
using the same time and date are only returning correct result first
time. If the select is done again the row is not found.
CREATE SEQUENCE timespan_idx_seq INCREMENT 1 MINVALUE 1 MAXVALUE 9223372036854775807 CACHE 1;
CREATE TABLE timespan (
host text NOT NULL,
starttime timestamptz NOT NULL,
endtime timestamptz NOT NULL,
idx int8 DEFAULT nextval('"timespan_idx_seq"'::text) NOT NULL,
CONSTRAINT timespan_pkey PRIMARY KEY (host, starttime, endtime)
) WITH OIDS;
-- Index: timespan_i1
CREATE INDEX timespan_i1 ON timespan USING btree (host);
-- Index: timespan_i2
CREATE INDEX timespan_i2 ON timespan USING btree (starttime);
-- Index: timespan_i3
CREATE INDEX timespan_i3 ON timespan USING btree (endtime);
-- Index: timespan_i4
CREATE UNIQUE INDEX timespan_i4 ON timespan USING btree (idx);
-- Index: timespan_i5
CREATE INDEX timespan_i5 ON timespan USING btree (host, starttime);
-- Index: timespan_i6
CREATE INDEX timespan_i6 ON timespan USING btree (host, endtime);
INSERT INTO timespan VALUES('XX', ' 6-APR-2003 02:00:00', ' 6-APR-2003 03:00:00');
test=# SELECT idx FROM timespan WHERE host='XX' AND starttime=' 6-APR-2003
02:00:00' AND endtime=' 6-APR-2003 03:00:00';
idx
-
1 <= correct
(1 row)
test=# SELECT idx FROM timespan WHERE host='XX' AND starttime=' 6-APR-2003
02:00:00' AND endtime=' 6-APR-2003 03:00:00';
idx
-
(0 rows) <=== not correct
test=# SELECT idx FROM timespan WHERE host='XX' AND starttime=' 6-APR-2003 02:00:00' AND endtime=' 6-APR-2003 03:00:00';
idx
-
(0 rows) <=== not correct
test=# \q
[EMAIL PROTECTED] scripts]# /usr/local/pgsql/bin/psql test
Welcome to psql, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit
test=# SELECT idx FROM timespan WHERE host='XX' AND starttime=' 6-APR-2003
02:00:00' AND endtime=' 6-APR-2003 03:00:00';
idx
-
1 <= correct
(1 row)
test=# SELECT idx FROM timespan WHERE host='XX' AND starttime=' 6-APR-2003
02:00:00' AND endtime=' 6-APR-2003 03:00:00';
idx
-
(0 rows) <=== not correct
/Jonas Lindholm
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] BUG #6295: Update fails on empty concatenated strings
The following bug has been logged online: Bug reference: 6295 Logged by: Jonas Forsman Email address: jfo...@hotmail.com PostgreSQL version: 8.4.9 Operating system: Ubuntu 10.04 LTS Description:Update fails on empty concatenated strings Details: Field description (note the field name is "comment") : comment character varying(2048) sql: UPDATE user SET comment= E'[2011-11-16] Note to myself no: 171\\n' || comment WHERE userid=1 This query fails if comment is an empty string or null. This works: UPDATE user SET comment= E'[2011-11-16] Note to myself no: 171\\n' || comment || '' WHERE userid=1 -- 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 #4686: There is not enough memory to complete this operation
The following bug has been logged online: Bug reference: 4686 Logged by: Jonas R. Pacheco Email address: supo...@migrate.com.br PostgreSQL version: 8.3.5 Operating system: Windows Server 2003 Description:There is not enough memory to complete this operation Details: During use of the application, which connects to the database via ODBC, from time to time, appears the following message: There is not enough memory to complete this operation. Change some parameter in postgresql.conf, particularly the shared buffers, however, this only decreased the frequency at which the error occurs. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
