Re: [BUGS] BUG #5741: syslog line length
Hi, On Sat, Aug 6, 2011 at 12:18 AM, Noah Misch wrote: > A PG_SYSLOG_LIMIT value that loses data to truncation on nearly every default > GNU/Linux installation makes for a poor default. On Sat, Aug 6, 2011 at 3:03 AM, Tom Lane wrote: > OK, applied to HEAD and 9.1. We hit this problem a few days ago on a server with RHEL 5 + PostgreSQL 8.4 + syslog. It made it quite difficult to work on the slow queries paralyzing the server as several of them had truncated lines in the middle of them. Any chance to have this fix backported to 8.4 and 9.0 as this is a regression introduced in 8.4? Thanks for your feedback. -- Guillaume -- 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 #6275: Horrible performance regression
On Mon, Oct 31, 2011 at 1:50 PM, Robert Haas wrote: > If you can't do that for some reason, there's always auto_explain, but > that has some overhead and is a bit more work to set up. If it's a massive load of data with a lot of queries, I think his best bet is to log the queries with log_min_duration_statement = (I'd try to start with 30ms) then analyze the log results with pgFouine or any other log analyzer for both versions. -- Guillaume -- 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 #6219: date_part() function producting incorrect year
On Wed, Sep 21, 2011 at 11:17 PM, Eric Vollnogel
wrote:
> The date_part('isoyear', some_column) function is not always returning the
> correct result. See below:
See http://www.postgresql.org/docs/8.4/static/functions-datetime.html :
"Each ISO year begins with the Monday of the week containing the 4th
of January, so in early January or late December the ISO year may be
different from the Gregorian year. See the week field for more
information."
So ISO year 2011 starts on Monday the 3rd of January.
If you want the Gregorian year, just user 'year' instead of 'isoyear'.
--
Guillaume
--
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 #6186: out of memory while analyze
Hi Lampa, On Thu, Sep 1, 2011 at 6:26 AM, Lampa wrote: > With default value 100 have bad perfomance :-( Don't set the default value higher: specify a higher value only where needed. See ALTER TABLE ALTER [ COLUMN ] column SET STATISTICS integer ( http://www.postgresql.org/docs/9.0/interactive/sql-altertable.html ). -- Guillaume -- 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 #6061: Progresql.exe memory usage using HOLD cursor.
Yann, 2011/6/16 Delorme, Yann : > Thanks > > Do you think that it will be fix in future release 9.1 ? Tom commited a fix in all the supported releases where the bug is present including 9.0: http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=669ac03af62328e4eb572dacb8ba319414ef1211 You can either build a specific 9.0 release with the patch or wait for the next 9.0.x maintenance release. Have a nice day. -- Guillaume -- 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 #5216: pgFouine 1.1 not working correctly, when LC_MESSAGES is "es_ES.UTF-8"
Henrik, On Fri, Nov 27, 2009 at 4:15 AM, Henrik Pestano wrote: > I have a problem with the parameter LC_MESSAGES, where its value is > es_ES.UTF-8 (Spanish), the pgFouine 1.1 not work correctly, because csvlog > generates a column "duración: 0138 ms sentencia: SELECT format_type (oid, > 54) as typname pg_type FROM WHERE oid = 1043" and pgFouine not understand > the words "duración" and "sentencia". This information can be in two > columns. Please note that pgsql-bugs mailing list is for PostgreSQL bugs only. pgFouine doesn't support lc_message other than english. It's usually considered a good practice to keep your logs in english as it's far easier to find useful information on the internet with a log message in english. I suppose you could use a sed line to translate your logs before analyzing them with pgFouine. -- Guillaume -- 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] psql: FATAL: the database system is in recovery mode
On Tue, Sep 1, 2009 at 8:47 AM, Bhushan Verma wrote: > But my fedora 9 machine have as follows postgres version. > rpm -qa|grep postgres > postgresql-server-8.3.1-1.fc9.i386 > postgresql-devel-8.3.1-1.fc9.i386 > postgresql-python-8.3.1-1.fc9.i386 > postgresql-8.3.1-1.fc9.i386 > postgresql-libs-8.3.1-1.fc9.i386 Same here, please upgrade to 8.3.7 and see if you can reproduce the problem. If so, please provide more information: a self contained test case would be nice if you can build one or a backtrace as Heikki suggested it. If you can't upgrade for a good reason, please provide the self contained test case so that we can check ourselves if it's still reproducible with 8.3.7. Thanks. -- Guillaume -- 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 #4794: server closed the connection unexpectedly
On Wed, May 6, 2009 at 11:05 AM, Markus Meyer wrote:
> If i make an
>
> SELECT xmlconcat(('' || NULL || '')::xml);
>
> follows
>
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
It's fixed in 8.3.7:
wombat=> SELECT xmlconcat(('' || NULL || '')::xml);
xmlconcat
---
(1 ligne)
(More exactly see the release nots of 8.3.6: "Fix crash of
xmlconcat(NULL) (Peter)")
Consider upgrading your installation to the latest minor release of
8.3. It's highly recommended.
--
Guillaume
--
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] data loss with pg_standby when doing a controlled failover
On Mon, Apr 6, 2009 at 1:37 PM, Andreas Pflug wrote: > IMHO this should be mentioned in the docs explicitly (I find it quite > surprising that data can be lost even if the system is shutdown > correctly), or better when shutting down the postmaster should spit all > log segments containing all changes when archiving is on so the warm > standby server can catch up. See also this thread which might be interesting for you: http://archives.postgresql.org/message-id/3f0b79eb0903242329j12865d55s348f5c873a956...@mail.gmail.com -- Guillaume -- 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 #4728: segfault with window function partition involving subquery
On Tue, Mar 24, 2009 at 10:11 PM, Tom Lane wrote: > Sigh ... I could've sworn I tested that code path, but evidently not, > 'cause it's broken as can be. If it's a code path not exercised by any regression test, is it worth it to add one or we don't have any chance to break this code again later? -- Guillaume -- 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 #4689: Expanding the length of a VARCHAR column should not induce a table rewrite
On Wed, Mar 4, 2009 at 11:50 AM, Peter Eisentraut wrote: > The question is how you want to implement this in a data type independent > fashion. You can't assume that increasing the typmod is a noop for all data > types. Sure. See my previous answer on -hackers (I don't think this discussion belong to -bugs) and especially the discussion in the archives about Jonas' patch. -- Guillaume -- 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 #4688: Bug in cache.
On Tue, Mar 3, 2009 at 4:37 PM, Tom Lane wrote: > Heikki Linnakangas writes: >> I believe the command has been like that for a long time, and this is >> the first time someone managed to shoot one's foot. > > True. Maybe it's not worth the trouble. IMHO, the consequences are far from being negligible and can put a cluster down for quite a long time if the database is large (considering the method suggested by Heikki to fix the problem). So if we can avoid this sort of problem in a few cases without too much work, it seems like something we should fix. -- Guillaume -- 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 #4631: Hibernate Restriction bigint~~bigint
On Tue, Jan 27, 2009 at 4:20 PM, Hauke Runge wrote: > this was working very well. Changing to postgreSql 8.3 we got the following > error: > ERROR: operator does not exist: bigint ~~ bigint > > we changed the jdbc driver to the latest jdbc3 driver - but the error was > the same. > > > I think, this could be a bug. You should use Restrictions.eq(). -- Guillaume -- 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] download PostgreSQL 8.0.2
On Tue, Dec 9, 2008 at 11:11 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > "Alexander Gallardo Torres" <[EMAIL PROTECTED]> writes: >> I need download PostgreSQL 8.0.2 but this link has problem. > > Surely you want something newer than that --- 8.0.2 was obsoleted over > three years ago. Try 8.0.15, which I believe is the last 8.0.x release > we made for Windows. > > (Actually, you should seriously consider upgrading to 8.2.x or 8.3.x; > we no longer support 8.0.x for Windows because it was too buggy.) +1. But if you're really into archeology, you can find all the old versions in the ftp archives: ftp://ftp-archives.postgresql.org/pub/binary/v8.0.2/win32/ Don't even try to use this version for a production database. -- Guillaume -- 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 #4428: renaming tables, columns and fk cheks problem
Hi Taras, On Sat, Sep 20, 2008 at 10:26 AM, Taras Kopets <[EMAIL PROTECTED]> wrote: > INSERT INTO fkb VALUES(6,4);-- stange error (see below) > -- ERROR: relation "public.fktest_a" does not exist > -- SQL state: 42P01 > -- Context: SQL statement "SELECT 1 FROM ONLY "public"."fktest_a" x WHERE > "a_id" OPERATOR(pg_catalog.=) $1 FOR SHARE OF x" This problem has already been reported a couple of days ago. See this thread for more information: http://archives.postgresql.org/pgsql-bugs/2008-09/msg00090.php . It has been fixed by Tom Lane and will be part of the 8.3.4 release which should be released in the next few days. Thanks for your very detailed report. -- Guillaume -- 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] error php - postgresql
On Fri, Apr 11, 2008 at 5:31 PM, jalvarez <[EMAIL PROTECTED]> wrote: > i have that error where execute page > > server closed the connection unexpectedly This probably means the server > terminated abnormally before or while processing the request postgres linux Please dig a bit further before considering it's a bug. There is a more appropriate mailing list if you need help: pgsql-general. You should take a look at your PostgreSQL server logs to see if there are more details about your problem (there should be). When you found it, please provide the PostgreSQL error message and the exact version you're using. -- Guillaume -- 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] operator does not exist: timestamp w/out timezone (similar to bug 3807)
On Sat, Apr 12, 2008 at 4:53 AM, philwalk <[EMAIL PROTECTED]> wrote:
> CREATE TABLE
> psql:pg83bug.sql:16: ERROR: operator does not exist: timestamp without
> time zone ~~ unknown
> LINE 3: where date like '2007-01-19%';
>^
> HINT: No operator matches the given name and argument type(s). You
> might need to add explicit type casts.
This isn't a bug. 8.3 removes a bunch of implicit casts to text which
led to unappropriate behaviours. Prior to 8.3, your timestamp was
casted to text implicitely.
Just use date_trunc
(http://www.postgresql.org/docs/current/static/functions-datetime.html):
update bugtab set
pnum = -8.6
where date_trunc('day', date) = '2007-01-19';
You can add a functional index on date_trunc('day', date) if necessary.
--
Guillaume
--
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.2 and 8.3 postgresql.conf oddity
On Jan 23, 2008 4:22 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > What do you find odd about it? Whatever scale you choose to think these > values are in, they all have to be on the same scale. So they are not defined in relation compared to the sequential page fetch cost as they were before? I mean, if I change seq_page_cost only, it doesn't change the overall behaviour? -- Guillaume ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] 8.2 and 8.3 postgresql.conf oddity
Hi Harald, On Jan 23, 2008 1:36 PM, Harald Armin Massa <[EMAIL PROTECTED]> wrote: > that should be regarded more to be a feature then a bug: That's not my point :). It's just that the comments are misleading or at least a bit absurd. -- Guillaume ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] 8.2 and 8.3 postgresql.conf oddity
Hi -bugs, I just noticed something odd in the Planner constants part of the 8.2 and 8.3 postgresql.conf: # - Planner Cost Constants - #seq_page_cost = 1.0# measured on an arbitrary scale #random_page_cost = 4 # same scale as above #cpu_tuple_cost = 0.01 # same scale as above #cpu_index_tuple_cost = 0.005 # same scale as above #cpu_operator_cost = 0.0025 # same scale as above The "same scale as above" while we have an "arbitrary scale" on the first line is a bit weird. 8.1 was: random_page_cost = 2# units are one sequential page fetch # cost cpu_tuple_cost = 0.01 # (same) cpu_index_tuple_cost = 0.001# (same) cpu_operator_cost = 0.0025 # (same) Which seems better. AFAIK, the unit of random_page_cost and cpu_*_cost is now seq_page_cost. -- Guillaume ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #3876: Problems migrating databases
On Jan 15, 2008 5:52 PM, Ruben Camargo Gomez <[EMAIL PROTECTED]> wrote: > I had this error from my log file: > ERRORROR: missing FROM-clause entry for table "tbldishot" > CONTEXT: SQL statement "update tblalohot set alohot_con = > coalesce(alohot_con,0)+8 where tbldishot.dishot_cod = tblalohot.dishot_cod > and tbldishot.establ_cod = 8699 and tbldishot.tiphah_cod=7 and > tblalohot.establ_cod = 7713 and tbldishot.dishot_fec >= '2007-10-23' and > tbldishot.dishot_fec < '2007-10-24'" > PL/pgSQL function "fun_reg_dis" line 34 at Prior to 8.1, PostgreSQL adds tables missing in the FROM clause automatically. This behaviour has been removed because it could lead to unexpected results. You should fix your query by using the UPDATE FROM syntax and by having tbldishot in the FROM clause. You have several enlightening examples in http://www.postgresql.org/docs/8.1/static/sql-update.html . You can also use add_missing_from = on in your postgresql.conf if you really can't fix your query but it's not recommended. -- Guillaume ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] RHEL4 RPM packages
On 4/11/07, John R Pierce <[EMAIL PROTECTED]> wrote: I think what -I- ran into was that there was no compat-3 in the public repositories, just compat-4... this was about a month ago. devrim indicated he was going to upload compat-3, and showed me where to find it, but I'd already installed compat-4, so -3 refused to install. on the grounds that there are undoutablly software out there which WAS linked with libpq.so.4, it seems to me there should just be one compat-postgresql-libs RPM which provides both 3 and 4 and coexists with current 8.2.3 rpms. There's no software linked with libpq.so.4 on standard RHEL 4. They are all built on libpq.so.3. IMHO, your problem is that it seems to the RPM database that compat 4 is newer than compat. I think we should have 2 different packages with different names compat-3 and compat-4. But you only need the compat package with libpq.so.3 to install 8.1 and 8.2 on RHEL 4. -- Guillaume ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] RHEL4 RPM packages
On 4/11/07, Devrim GÜNDÜZ <[EMAIL PROTECTED]> wrote: On Fri, 2007-03-02 at 09:17 -0800, John R Pierce wrote: > looks like the RPMs for libpq.so.4 and libpq.so.3 can't coexist. Ok, I got lots of complaints about this. I will work on this today and announce new sets. It's not a real problem IMHO. AFAIR the compat RPMs were designed to provide a compatibility layer between newer versions of PostgreSQL and the distribution standard packages and you won't have both libpq versions used by the distro. It's probably easy to fix it but I don't think it's so important. At least it doesn't prevent anyone to have a working system. -- Guillaume ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] Partial index on varchar fields with IN
Hi all,
I recently came accross a problem with the use of IN clause in a
partial index with a varchar(3) field. Int, char and text seems to be
OK (test case is provided below).
Version is 8.2.3 running on a Fedora Core 3 (RPM rebuilt from the PGDG ones).
test=# SELECT version();
version
---
PostgreSQL 8.2.3 on i686-redhat-linux-gnu, compiled by GCC gcc (GCC)
3.4.4 20050721 (Red Hat 3.4.4-2)
(1 ligne)
Here is the test case:
test=# CREATE TABLE test_in (field int);
CREATE TABLE
test=# CREATE INDEX idx_test_in ON test_in(field) WHERE field IN(1, 2);
CREATE INDEX
test=# DROP INDEX idx_test_in;
DROP INDEX
test=# DROP TABLE test_in;
DROP TABLE
-> OK with int
test=# CREATE TABLE test_in (field text);
CREATE TABLE
test=# CREATE INDEX idx_test_in ON test_in(field) WHERE field IN('1', '2');
CREATE INDEX
test=# DROP INDEX idx_test_in;
DROP INDEX
test=# DROP TABLE test_in;
DROP TABLE
-> OK with text
test=# CREATE TABLE test_in (field char(3));
CREATE TABLE
test=# CREATE INDEX idx_test_in ON test_in(field) WHERE field IN('1', '2');
CREATE INDEX
test=# DROP INDEX idx_test_in;
DROP INDEX
test=# DROP TABLE test_in;
DROP TABLE
-> OK with char(3)
test=# CREATE TABLE test_in (field varchar(3));
CREATE TABLE
test=# CREATE INDEX idx_test_in ON test_in(field) WHERE field IN('1', '2');
ERROR: functions in index predicate must be marked IMMUTABLE
-> failed with varchar(3)
This behaviour seems inconsistent and it seems to me it can be a bug.
Any comment?
--
Guillaume
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [BUGS] RHEL4 RPM packages
John, On 3/2/07, John R Pierce <[EMAIL PROTECTED]> wrote: compat-postgresql-libs-4-2PGDG.rhel4.rpm supplies libpq.so.4 and .4.1, but it does NOT include .so.3. I think it should provide a .so.3 which can coexist with the rest of the 8.2.3 stack (or, there should be a compat-postgresql-libs-3 ?) Just use this package: http://developer.postgresql.org/~devrim/rpms/compat/ (and especially http://developer.postgresql.org/~devrim/rpms/compat/compat-postgresql-libs-3-3PGDG.i686.rpm as you don't seem to use 64 bits packages) which includes libpq.so.3. It works well on RHEL4. FYI, Devrim is the PGDG RPM maintainer. -- Guillaume ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #2979: Functional indexes ERROR while updating table
Roman, On 2/7/07, Roman Grigorovich <[EMAIL PROTECTED]> wrote: ERROR: attribute 1 has wrong type DETAIL: Table has type character varying, but query expects character varying. What is it? On version 8.1.2 - ALL OK! This is a known problem of 8.1.7. That's why 8.1.8 has been released. So you should upgrade to 8.1.8 to fix your problem. -- Guillaume ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] [EMAIL PROTECTED]: BUG in logs]
> From: Martin Marques > I encountered a rare BUG in the way PG is logging. Let me first enlight with > some configuration I have and PG version: Perhaps I'm missing something but I think it's not a bug but a configuration problem. > log_min_error_statement| panic If you set this one to error instead of panic, you will have your failed statements logged. > log_statement | all This one only logs successful queries so it's normal you don't have the statement in the log file if it fails. Regards, -- Guillaume ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] BUG #1991: UPPER problem on special characters
The following bug has been logged online: Bug reference: 1991 Logged by: Guillaume Smet Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1b3 Operating system: RHEL 3 Description:UPPER problem on special characters Details: Hi, I'm currently testing 8.1b3 to prepare our migration from 7.4 to 8.1. I have a µ (greek mu) in my database correctly encoded as UTF-8 (database encoding is UTF-8). A SELECT UPPER() on this character gives me an error: ERROR: invalid multibyte character for locale but I can display it with a simple SELECT. We cannot uppercase this character but I don't think it's an invalid character. PHP for example just returns µ when I try to strtoupper it. AFAIK UTF-8 support is stricter in 8.1 but I'm not sure it's the correct behaviour to return an error in this case. Thanks for your help. Regards -- Guillaume ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
