[BUGS] BUG #4564: multi threaded queries corrupt client when server debugging levels are hi
The following bug has been logged online: Bug reference: 4564 Logged by: Diez Roggisch Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3 Operating system: Debian Lenny Description:multi threaded queries corrupt client when server debugging levels are hi Details: We yesterday hunted down a bug that made our python/psycopg2/libpq.so.5-based apache processes segfault at random. In the end, we could reproduce the error with this script http://www.initd.org/svn/psycopg/psycopg2/trunk/examples/threads.py locally on the machine, regardless of tcp or socket being used. It occured after turning all logging facilities like log_min_error_statement to the highest level possible. The problem can't be reproduced on my developer machine (ubuntu hardy) -- 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 #4563: Translation of errors.
The following bug has been logged online: Bug reference: 4563 Logged by: Eugene Pimenov Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.5 Operating system: MacOS X, FreeBSD, whatever Description:Translation of errors. Details: Hello, I'm using ActiveRecord to connect to a postgresql database. One day it said me: “неверный входной синтаксис для типа bytea”. I said: "wtf?! what's going on”. I knew that the problem is in ActiveRecord, so I copied the error, and googled it. I found nothing. I downloaded the source code of postgresql, wrote a magick string: “grep -R "$(echo 'неверный входной синтаксис для типа bytea' | iconv -t koi8-r)" .” and found: msgid "invalid input syntax for type bytea" msgstr " bytea" Then I googled for “invalid input syntax for type byte rails” and found http://dev.rubyonrails.org/ticket/1745 which seems to be the solution for my problem. Conclusion: translation of error messages is not helpful! It's harmful. My proposal: 1) Remote all translations for errors and shoot everyone in the head who wants to translate it. 2) Write a code to every translation (e.g. Error 424242 inccorrect ...), so people can actually google out a solution for their problems. Thank you. -- 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 #4565: nextval not updated during wal replication, leading to pk violations
The following bug has been logged online: Bug reference: 4565 Logged by: Marc Schablewski Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.5 Operating system: Debian, 2.6.24-19 kernel Description:nextval not updated during wal replication, leading to pk violations Details: Hi! We are using "Continuous Archiving" of WAL to keep a warm standby database server. We recently switch over to that backup database for testing purpose. We first took an online backup of the master database, let the WAL shipping run for some days and finally started the backup for normal use. A job tried to insert some records into a few tables and complained about a PK violation. PK are of type bigint. The column is populated by a sequence and a "default nextval()" on the PK column. We found that the sequence's currval was lower than the maximum value in the table and that this value was already present. Further investigation showed us that the last records in the table were inserted on the former master server while taking the initial online backup for the replication. It seems that the records got replicated but not the currval/nextval of the sequence. When running "select nextval()" on the backup database it returned the PK value of the first record inserted during that last run on the former master server. I couldn't reproduce the problem with two different servers and a simple database containing one table. Right now, I don't have any idea how to narrow down the problem or what to check next. So any hint would be helpful. Marc -- 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 #4563: Translation of errors.
"Eugene Pimenov" <[EMAIL PROTECTED]> writes: > 2) Write a code to every translation (e.g. Error 424242 inccorrect ...), so > people can actually google out a solution for their problems. RTFM: http://www.postgresql.org/docs/8.3/static/errcodes-appendix.html 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 #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION
The following bug has been logged online:
Bug reference: 4566
Logged by: Randy Isbell
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.4
Operating system: FreeBSD 6.2
Description:pg_stop_backup() reports incorrect STOP WAL LOCATION
Details:
An inconsistency exists between the segment name reported by
pg_stop_backup() and the actual WAL file name.
SELECT pg_start_backup('filename');
pg_start_backup
-
10/FE1E2BAC
(1 row)
Later:
SELECT pg_stop_backup();
pg_stop_backup
10/FF00
(1 row)
The resulting *.backup file:
START WAL LOCATION: 10/FE1E2BAC (file 0002001000FE)
STOP WAL LOCATION: 10/FF00 (file 0002001000FF)
CHECKPOINT LOCATION: 10/FE1E2BAC
START TIME: 2008-11-09 01:15:06 CST
LABEL: /bck/db/sn200811090115.tar.gz
STOP TIME: 2008-11-09 01:15:48 CST
In my 8.3.4 instance, WAL file naming occurs as:
...
0001000300FD
0001000300FE
00010004
000100040001
...
WAL files never end in 'FF'. This causes a problem when trying to collect
the ending WAL file for backup.
- r.
--
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] installation bug-cannot create user name
>>> <[EMAIL PROTECTED]> wrote: > installing postgreSQL it brings up an error message that last part of > the install saying "could not create user name" and then some other > stuff about how this may affect post-install operations. People will have a hard time offering useful suggestions without more detail. What operating system? What version of PostgreSQL? How are you installing it? What is the exact and full text of the messages, including any user name? Does the user name it can't create already exist on your system? -Kevin -- 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] Fall back to alternative tsearch dictionary directory
Martin Pitt [2008-12-02 5:29 -0800]:
> Tom Lane [2008-12-01 19:51 -0500]:
> > I can't see any reason whatever to not put them into
> > ${sharepath}/tsearch_data/. It's not like you're expecting to be
> > able to share them with other applications.
>
> Oh, forgot yesterday, there is one case: the data can be shared
> between the 8.3, 8.4, and any future version. (In Debian/Ubuntu you
> can install different 8.x versions in parallel)
>
> But that can easily be achieved in the distro packaging by adding
> symlinks, so if you prefer just looking for
> ${sharedir}/tsearch_data/system_ll_cc.affix, that would still work for
> me.
Right, so I changed the patch accordingly.
Thanks,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
# Description: If a tsearch/stem dictionary is not found in sharedir/tsearch_data/ll_cc.{dict,affix}, fall back to sharedir/tsearch_data/system_ll_cc.{dict,affix}, where postgresql-common creates them from system directories.
# Ubuntu: https://launchpad.net/bugs/301770
diff -Nur -x '*.orig' -x '*~' postgresql-8.3/build-tree/postgresql-8.3.5/src/backend/tsearch/ts_utils.c postgresql-8.3.new/build-tree/postgresql-8.3.5/src/backend/tsearch/ts_utils.c
--- postgresql-8.3.5/src/backend/tsearch/ts_utils.c 2008-06-19 09:52:31.0 -0700
+++ postgresql-8.3.5/src/backend/tsearch/ts_utils.c 2008-12-05 12:48:02.0 -0800
@@ -15,6 +15,7 @@
#include "postgres.h"
#include
+#include
#include "miscadmin.h"
#include "tsearch/ts_locale.h"
@@ -36,7 +37,7 @@
const char *extension)
{
char sharepath[MAXPGPATH];
- char *result;
+ char *result, *system_result;
/*
* We limit the basename to contain a-z, 0-9, and underscores. This may
@@ -58,6 +59,21 @@
snprintf(result, MAXPGPATH, "%s/tsearch_data/%s.%s",
sharepath, basename, extension);
+ /* fall back to a system-supplied one */
+ if (access(result, R_OK) != 0)
+ {
+ system_result = palloc(MAXPGPATH);
+ snprintf(system_result, MAXPGPATH, "%s/tsearch_data/system_%s.%s",
+ sharepath, basename, extension);
+ if (access(system_result, R_OK) == 0)
+ {
+ pfree(result);
+ result = system_result;
+ }
+ else
+ pfree(system_result);
+ }
+
return result;
}
signature.asc
Description: Digital signature
Re: [BUGS] BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION
On Fri, Dec 5, 2008 at 11:41 PM, Randy Isbell <[EMAIL PROTECTED]> wrote:
>
> The following bug has been logged online:
>
> Bug reference: 4566
> Logged by: Randy Isbell
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.3.4
> Operating system: FreeBSD 6.2
> Description:pg_stop_backup() reports incorrect STOP WAL LOCATION
> Details:
>
> An inconsistency exists between the segment name reported by
> pg_stop_backup() and the actual WAL file name.
>
>
> SELECT pg_start_backup('filename');
> pg_start_backup
>-
> 10/FE1E2BAC
>(1 row)
>
> Later:
> SELECT pg_stop_backup();
> pg_stop_backup
>
> 10/FF00
>(1 row)
>
> The resulting *.backup file:
>
> START WAL LOCATION: 10/FE1E2BAC (file 0002001000FE)
> STOP WAL LOCATION: 10/FF00 (file 0002001000FF)
> CHECKPOINT LOCATION: 10/FE1E2BAC
> START TIME: 2008-11-09 01:15:06 CST
> LABEL: /bck/db/sn200811090115.tar.gz
> STOP TIME: 2008-11-09 01:15:48 CST
>
> In my 8.3.4 instance, WAL file naming occurs as:
>
> ...
> 0001000300FD
> 0001000300FE
> 00010004
> 000100040001
> ...
>
> WAL files never end in 'FF'. This causes a problem when trying to collect
> the ending WAL file for backup.
It's a bug of pg_stop_backup(), which has been talked before.
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00108.php
Attached is a patch against HEAD. I think that we should
also backport.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
? GNUmakefile
? config.log
? config.status
? src/Makefile.global
? src/backend/postgres
? src/backend/catalog/postgres.bki
? src/backend/catalog/postgres.description
? src/backend/catalog/postgres.shdescription
? src/backend/snowball/snowball_create.sql
? src/backend/utils/probes.h
? src/backend/utils/mb/conversion_procs/conversion_create.sql
? src/bin/initdb/initdb
? src/bin/pg_config/pg_config
? src/bin/pg_controldata/pg_controldata
? src/bin/pg_ctl/pg_ctl
? src/bin/pg_dump/pg_dump
? src/bin/pg_dump/pg_dumpall
? src/bin/pg_dump/pg_restore
? src/bin/pg_resetxlog/pg_resetxlog
? src/bin/psql/psql
? src/bin/scripts/clusterdb
? src/bin/scripts/createdb
? src/bin/scripts/createlang
? src/bin/scripts/createuser
? src/bin/scripts/dropdb
? src/bin/scripts/droplang
? src/bin/scripts/dropuser
? src/bin/scripts/reindexdb
? src/bin/scripts/vacuumdb
? src/include/pg_config.h
? src/include/stamp-h
? src/interfaces/ecpg/compatlib/exports.list
? src/interfaces/ecpg/compatlib/libecpg_compat.so.3.1
? src/interfaces/ecpg/ecpglib/exports.list
? src/interfaces/ecpg/ecpglib/libecpg.so.6.1
? src/interfaces/ecpg/include/ecpg_config.h
? src/interfaces/ecpg/pgtypeslib/exports.list
? src/interfaces/ecpg/pgtypeslib/libpgtypes.so.3.1
? src/interfaces/ecpg/preproc/ecpg
? src/interfaces/libpq/exports.list
? src/interfaces/libpq/libpq.so.5.2
? src/port/pg_config_paths.h
? src/test/regress/log
? src/test/regress/pg_regress
? src/test/regress/results
? src/test/regress/testtablespace
? src/test/regress/tmp_check
? src/test/regress/expected/constraints.out
? src/test/regress/expected/copy.out
? src/test/regress/expected/create_function_1.out
? src/test/regress/expected/create_function_2.out
? src/test/regress/expected/largeobject.out
? src/test/regress/expected/largeobject_1.out
? src/test/regress/expected/misc.out
? src/test/regress/expected/tablespace.out
? src/test/regress/sql/constraints.sql
? src/test/regress/sql/copy.sql
? src/test/regress/sql/create_function_1.sql
? src/test/regress/sql/create_function_2.sql
? src/test/regress/sql/largeobject.sql
? src/test/regress/sql/misc.sql
? src/test/regress/sql/tablespace.sql
? src/timezone/zic
Index: src/backend/access/transam/xlog.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/access/transam/xlog.c,v
retrieving revision 1.323
diff -c -r1.323 xlog.c
*** src/backend/access/transam/xlog.c 3 Dec 2008 08:20:11 - 1.323
--- src/backend/access/transam/xlog.c 6 Dec 2008 04:21:05 -
***
*** 6710,6716
*/
stoppoint = RequestXLogSwitch();
! XLByteToSeg(stoppoint, _logId, _logSeg);
XLogFileName(stopxlogfilename, ThisTimeLineID, _logId, _logSeg);
/* Use the log timezone here, not the session timezone */
--- 6710,6716
*/
stoppoint = RequestXLogSwitch();
! XLByteToPrevSeg(stoppoint, _logId, _logSeg);
XLogFileName(stopxlogfilename, ThisTimeLineID, _logId, _logSeg);
/* Use the log timezone here, not the session timezone */
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
