[BUGS] BUG #5570: global hash %_SHARED does not work in the new version
The following bug has been logged online: Bug reference: 5570 Logged by: Milen Email address: m...@avangardsolutions.com PostgreSQL version: v9.0beta2 Operating system: Linux Description:global hash %_SHARED does not work in the new version Details: Hello, We can't find the global hash %_SHARED in the new version of plperl.c. The error that we receive from the server when we try to use the global hash %_SHARED is : ERROR: Global symbol %_SHARED requires explicit package name Please inform us for any progress on this issue. Thanks in advance -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] no sufficient privileges to start system service
Hi. i can't complete the installation process as i have persisting problem. it gives me the following error message: Service pgsql 8.3 failed to start. Verify that you have sufficient privileges to start system service. where's the problem? can you help?
[BUGS] Re: BUG #4616: Create Database with another encoding as the encoding from postgres
Said Noucair написа: > The following bug has been logged online: > > Bug reference: 4616 > Logged by: Said Noucair > Email address: nouc...@gmail.com > PostgreSQL version: 8.3 > Operating system: Suse 2.6 > Description:Create Database with another encoding as the encoding > from postgres > Details: > > Hi, > > I tried to create a second database other than postgres with different > encoding "WIN", but it keep gave me errors: > Error: encoding WIN does not match server's locale UTF-8 >> DETAIL: The server's LC_CTYPE setting requires encoding... > > Any hint? Known restriction: "Any character set encoding specified for the new database must be compatible with the server's LC_CTYPE locale setting." (http://www.postgresql.org/docs/current/static/sql-createdatabase.html). -- Milen A. Radev -- 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 #4861: Incorrect log_line_prefix default value in postgresql.conf
Tom Lane написа: "Dmitry Ryabov" writes: Description:Incorrect log_line_prefix default value in postgresql.conf log_line_prefix = '%%t ' (must be log_line_prefix = '%t ') Uh, the default setting is an empty string. Are you sure this is not your own error? If it isn't, perhaps it is a problem in some packaging of Postgres, but you did not say which package you are using. The line looks like that after using the One-click installer available here - http://www.enterprisedb.com/products/pgdownload.do. Probably should be sorted out by EnterpriseDB. -- Milen A. Radev -- 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 #4861: Incorrect log_line_prefix default value in postgresql.conf
Bruce Momjian написа: Milen A. Radev wrote: Tom Lane ??: "Dmitry Ryabov" writes: Description:Incorrect log_line_prefix default value in postgresql.conf log_line_prefix = '%%t ' (must be log_line_prefix = '%t ') Uh, the default setting is an empty string. Are you sure this is not your own error? If it isn't, perhaps it is a problem in some packaging of Postgres, but you did not say which package you are using. The line looks like that after using the One-click installer available here - http://www.enterprisedb.com/products/pgdownload.do. Probably should be sorted out by EnterpriseDB. I just checked the one-click 8.4rc1 installer on Ubuntu and it is fine: #log_line_prefix = '' # special values: so I am unclear why Windows would have a different default. How are you viewing this default? From the command line? I've attached the unmodified "postgresql.conf" just after a successful installation (it is in "C:\Program Files\PostgreSQL\8.4\data"). Connecting to the server locally with psql gives: Server [localhost]: Database [postgres]: Port [5432]: Username [postgres]: psql (8.4rc1) WARNING: Console code page (866) differs from Windows code page (1251) 8-bit characters might not work correctly. See psql reference page "Notes for Windows users" for details. Type "help" for help. postgres=# show log_line_prefix; log_line_prefix - %%t (1 row) postgres=# -- Milen A. Radev # - # PostgreSQL configuration file # - # # This file consists of lines of the form: # # name = value # # (The "=" is optional.) Whitespace may be used. Comments are introduced with # "#" anywhere on a line. The complete list of parameter names and allowed # values can be found in the PostgreSQL documentation. # # The commented-out settings shown in this file represent the default values. # Re-commenting a setting is NOT sufficient to revert it to the default value; # you need to reload the server. # # This file is read on server startup and when the server receives a SIGHUP # signal. If you edit the file on a running system, you have to SIGHUP the # server for the changes to take effect, or use "pg_ctl reload". Some # parameters, which are marked below, require a server shutdown and restart to # take effect. # # Any parameter can also be given as a command-line option to the server, e.g., # "postgres -c log_connections=on". Some parameters can be changed at run time # with the "SET" SQL command. # # Memory units: kB = kilobytesTime units: ms = milliseconds #MB = megabytes s = seconds #GB = gigabytes min = minutes # h = hours # d = days #-- # FILE LOCATIONS #-- # The default values of these variables are driven from the -D command-line # option or PGDATA environment variable, represented here as ConfigDir. #data_directory = 'ConfigDir' # use data in another directory # (change requires restart) #hba_file = 'ConfigDir/pg_hba.conf' # host-based authentication file # (change requires restart) #ident_file = 'ConfigDir/pg_ident.conf' # ident configuration file # (change requires restart) # If external_pid_file is not explicitly set, no extra PID file is written. #external_pid_file = '(none)' # write an extra PID file # (change requires restart) #-- # CONNECTIONS AND AUTHENTICATION #-- # - Connection Settings - listen_addresses = '*' # what IP address(es) to listen on; # comma-separated list of addresses; # defaults to 'localhost', '*' = all # (change requires restart) port = 5432 # (change requires restart) max_connections = 100 # (change requires restart) # Note: Increasing max_connections costs ~400 bytes of shared memory per # connection slot, plus lock space (see max_locks_per_transaction). #superuser_reserved_connections = 3 # (change requires restart) #unix_socket_directory = '' # (change requires
[BUGS] Re: BUG #5290: Simple loop with insert into and check to avoid duplicate values fails
Heikki Linnakangas написа: Wild Wezyr wrote: 2010/1/20 Heikki Linnakangas I happen to have access to a Win32 virtual machine just now. CVS HEAD, built from sources on the VM. Seems to work fine. The test case runs for ages, I'm at about 1/3 through it, and no errors this far. I'm going to have to kill it now. What OS you have on this Win32 box? Is it Windows Vista (like mine)? The login screen says: Windows Server 2003 R2, Datacenter x64 Edition What version of Postgres you have used? Is it 8.3.3 or 8.4.2 like mine? A fresh checkout from CVS HEAD. What encoding/collation was your DB created with? Was it UTF8 / 'Polish_Poland.1250' ? Yes. I used: bin\initdb -D data3 -E UTF-8 --locale=Polish_Poland.1250 and CREATE DATABASE spb WITH OWNER = "Administrator" ENCODING = 'UTF8' LC_COLLATE = 'Polish_Poland.1250' LC_CTYPE = 'Polish_Poland.1250' CONNECTION LIMIT = -1; I reproduced it on Windows Vista 64-bit SP2 with version 8.4.2 (installed by using the One-click installer from EnterpriseDB): ... NOTICE: i = 642200 NOTICE: i = 642300 NOTICE: i = 642400 NOTICE: i = 642500 ERROR: duplicate key value violates unique constraint "spb_word_word_key" CONTEXT: SQL statement "insert into spb_word (word) values ( $1 )" PL/pgSQL function "spb_runmesimple2" line 15 at SQL statement -- Milen A. Radev -- 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: BUG #5290: Simple loop with insert into and check to avoid duplicate values fails
Tom Lane написа: "Milen A. Radev" writes: I reproduced it on Windows Vista 64-bit SP2 with version 8.4.2 (installed by using the One-click installer from EnterpriseDB): OK, so that means WildWezyr isn't just seeing things. Possibilities that occur to me now: 1. Maybe it's specific to Vista and/or Win64? 2. I wonder whether setting LC_COLLATE/LC_CTYPE during database creation is really sufficient to establish the locale fully on Windows. If wcscoll() is partially dependent on some other bit of state, maybe that would explain the problem. What is the "surrounding" locale in your test case? [...] For the test I changed all regional settings to "Polish (Poland)", restarted the machine, created a new cluster and a new database (using the commands from the last mail from Heikki). A side-note: tested exactly the same function but on "Bulgarian (Bulgaria)" system locale and cluster and database created with "Bulgarian_Bulgaria.1251" locale - no errors. -- Milen A. Radev -- 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: BUG #5290: Simple loop with insert into and check to avoid duplicate values fails
WildWezyr написа:
On Jan 21, 6:17 pm, mi...@radev.net ("Milen A. Radev") wrote:
[...]
For the test I changed all regional settings to "Polish (Poland)",
restarted the machine, created a new cluster and a new database (using
the commands from the last mail from Heikki).
A side-note: tested exactly the same function but on "Bulgarian
(Bulgaria)" system locale and cluster and database created with
"Bulgarian_Bulgaria.1251" locale - no errors.
--
Milen A. Radev
No error for Bulgarian locale might be related to absence of Bulgarian
national characters in words generated by my test code. I've put only
polish characters (ąćęłńóśźż) - and it fails with polish collation,
but after removing polish characters - i get no error with polish
collation. I thing it may behave exactly the same for Bulgarian - to
produce errors you must modify letters to include Bulgarian chars
(line: letters varchar(255) := 'ąćęłńóśźżjklmnopqrstuvwxyz'; --<--
put these letters here).
Have you tried this?
Yes, actually I tried it yesterday but just to be sure I tried it again
today - no errors:
NOTICE: i = 800
NOTICE: i = 900
NOTICE: i = 1000
Total query runtime: 2231947 ms.
1 row retrieved.
The "letters" variable used in the test (in case you have the time to
try it yourself):
letters varchar(255) := 'юяьъщшчцфjklmnopqrstuvwxyz';
And the database definition:
CREATE DATABASE spb
WITH OWNER = postgres
ENCODING = 'UTF8'
LC_COLLATE = 'Bulgarian_Bulgaria.1251'
LC_CTYPE = 'Bulgarian_Bulgaria.1251'
CONNECTION LIMIT = -1;
The system locale is "Bulgarian (Bulgaria)".
--
Milen A. Radev
--
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: BUG #5290: Simple loop with insert into and check to avoid duplicate values fails
Tom Lane написа: "Milen A. Radev" writes: I reproduced it on Windows Vista 64-bit SP2 with version 8.4.2 [...] 1. Maybe it's specific to Vista and/or Win64? [...] Also reproduced it on 32-bit Vista SP2 (with Postgres 8.4.2). Couldn't reproduced it on neither Windows 7 32-bit RC nor Windows XP SP3 32-bit. I have no access to 64-bit Windows XP or 64-bit Windows 7. -- Milen A. Radev -- 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 #2684: Memory leak in libpq
The following bug has been logged online:
Bug reference: 2684
Logged by: Milen A. Radev
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.4
Operating system: Debian 3.1
Description:Memory leak in libpq
Details:
Source:
#include
#include
int main(int argc, char *argv[])
{
PGconn *pgcon;
int i;
int count = 1;
if(argc > 1)
{
count = atoi(argv[1]);
if(count < 1)
{
count = 1;
}
}
for(i = 0; i < count; i++)
{
pgcon = PQsetdbLogin("mydbserver", "5432", "", "", "mydb",
"myuser",
"mypass");
printf("[%d] Successfuly opened connection to the database:
pgcon=%p\n",
i, pgcon);
if(PQstatus(pgcon) != CONNECTION_OK)
{
printf("Failed to open connection to the database.
Reason: %s\n",
PQerrorMessage(pgcon));
PQfinish(pgcon);
return -1;
}
printf("[%d] Closing the connection: pgcon=%p\n", i, pgcon);
PQfinish(pgcon);
}
return 0;
}
Compile and link:
#gcc -I/usr/local/pgsql/include -o pgtest pgtest.c -L/usr/local/pgsql/lib
-lpq
Valgring output:
#valgrind --tool=memcheck --leak-check=yes --show-reachable=yes
--num-callers=20 --error-limit=no ./pgtest 1
==23845== Memcheck, a memory error detector.
==23845== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==23845== Using LibVEX rev 1658, a library for dynamic binary translation.
==23845== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==23845== Using valgrind-3.2.1, a dynamic binary instrumentation framework.
==23845== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==23845== For more details, rerun with: -v
==23845==
--23845-- DWARF2 CFI reader: unhandled CFI instruction 0:50
--23845-- DWARF2 CFI reader: unhandled CFI instruction 0:50
[0] Successfuly opened connection to the database: pgcon=0x41c8028
[0] Closing the connection: pgcon=0x41c8028
==23845== Invalid free() / delete / delete[]
==23845==at 0x401C285: free (vg_replace_malloc.c:233)
==23845==by 0x414CA3B: (within /lib/tls/libc-2.3.2.so)
==23845==by 0x414C6C4: __libc_freeres (in /lib/tls/libc-2.3.2.so)
==23845==by 0x40184BA: _vgnU_freeres (vg_preloaded.c:60)
==23845==by 0x406A1C5: exit (in /lib/tls/libc-2.3.2.so)
==23845==by 0x405497D: (below main) (in /lib/tls/libc-2.3.2.so)
==23845== Address 0x4026518 is not stack'd, malloc'd or (recently) free'd
==23845==
==23845== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 27 from 2)
==23845== malloc/free: in use at exit: 156 bytes in 11 blocks.
==23845== malloc/free: 124 allocs, 114 frees, 44,465 bytes allocated.
==23845== For counts of detected errors, rerun with: -v
==23845== searching for pointers to 11 not-freed blocks.
==23845== checked 271,364 bytes.
==23845==
==23845==
==23845== 156 (36 direct, 120 indirect) bytes in 1 blocks are definitely
lost in loss record 1 of 3
==23845==at 0x401B6EE: malloc (vg_replace_malloc.c:149)
==23845==by 0x4126EE6: (within /lib/tls/libc-2.3.2.so)
==23845==by 0x4126788: __nss_database_lookup (in
/lib/tls/libc-2.3.2.so)
==23845==by 0x42CAAFB: ???
==23845==by 0x40E7D4B: getpwuid_r (in /lib/tls/libc-2.3.2.so)
==23845==by 0x40E7590: getpwuid (in /lib/tls/libc-2.3.2.so)
==23845==by 0x403BD0B: pqGetpwuid (in
/usr/local/pgsql-8.1.4/lib/libpq.so.4.1)
==23845==by 0x402BF77: pg_fe_getauthname (in
/usr/local/pgsql-8.1.4/lib/libpq.so.4.1)
==23845==by 0x402DEE6: conninfo_parse (in
/usr/local/pgsql-8.1.4/lib/libpq.so.4.1)
==23845==by 0x402E123: connectOptions1 (in
/usr/local/pgsql-8.1.4/lib/libpq.so.4.1)
==23845==by 0x402EEE3: PQsetdbLogin (in
/usr/local/pgsql-8.1.4/lib/libpq.so.4.1)
==23845==by 0x804864D: main (in /home/slav/rate_engine/pgtest)
==23845==
==23845==
==23845== 40 bytes in 5 blocks are indirectly lost in loss record 2 of 3
==23845==at 0x401B6EE: malloc (vg_replace_malloc.c:149)
==23845==by 0x4126AAD: __nss_lookup_function (in
/lib/tls/libc-2.3.2.so)
==23845==by 0x42CAB21: ???
==23845==by 0x40E7D4B: getpwuid_r (in /lib/tls/libc-2.3.2.so)
==23845==by 0x40E7590: getpwuid (in /lib/tls/libc-2.3.2.so)
==23845==by 0x403BD0B: pqGetpwuid (in
/usr/local/pgsql-8.1.4/lib/libpq.so.4.1)
==23845==by 0x402BF77: pg_fe_getauthname (in
/usr/local/pgsql-8.1.4/lib/libpq.so.4.1)
==23845==by 0x402DEE6: conninfo_parse (in
/usr/local/pgsql-8.1.4/lib/libpq.so.4.1)
==23845==by 0x402E123: connectOptions1 (in
/usr/local/pgsql-8.1.4/lib/libpq.so.4.1)
==23845==by 0x402EEE3: PQsetdbLogin
Re: [BUGS] BUG #2684: Memory leak in libpq
On 10/10/06, Tom Lane <[EMAIL PROTECTED]> wrote: "Milen A. Radev" <[EMAIL PROTECTED]> writes: > The same test programme has grown (after ~1 million iterations) from 2KB to > around 40MB used physical memory (as reported by "top"). I couldn't duplicate any such leak using your test program here. What authentication method is being selected by your pg_hba.conf file, and what are your pg_config settings? The client and the server were on different machines - that's why I believe "md5" was used. I'm sending only the client machine's pg_config output. Tell me if you need the server's too. Client's pg_config (built from source) output: DOCDIR = /usr/local/pgsql-8.1.4/doc INCLUDEDIR = /usr/local/pgsql-8.1.4/include PKGINCLUDEDIR = /usr/local/pgsql-8.1.4/include INCLUDEDIR-SERVER = /usr/local/pgsql-8.1.4/include/server LIBDIR = /usr/local/pgsql-8.1.4/lib PKGLIBDIR = /usr/local/pgsql-8.1.4/lib LOCALEDIR = MANDIR = /usr/local/pgsql-8.1.4/man SHAREDIR = /usr/local/pgsql-8.1.4/share SYSCONFDIR = /usr/local/pgsql-8.1.4/etc PGXS = /usr/local/pgsql-8.1.4/lib/pgxs/src/makefiles/pgxs.mk CONFIGURE = '--prefix=/usr/local/pgsql-8.1.4' CC = gcc CPPFLAGS = -D_GNU_SOURCE CFLAGS = -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing CFLAGS_SL = -fpic LDFLAGS = -Wl,-rpath,/usr/local/pgsql-8.1.4/lib LDFLAGS_SL = LIBS = -lpgport -lz -lreadline -lcrypt -lresolv -lnsl -ldl -lm VERSION = PostgreSQL 8.1.4 Client's pg_config (from the backports.org package) output: BINDIR = /usr/lib/postgresql/8.1/bin DOCDIR = /usr/share/doc/postgresql-doc-8.1 INCLUDEDIR = /usr/include/postgresql PKGINCLUDEDIR = /usr/include/postgresql INCLUDEDIR-SERVER = /usr/include/postgresql/8.1/server LIBDIR = /usr/lib PKGLIBDIR = /usr/lib/postgresql/8.1/lib LOCALEDIR = /usr/share/locale MANDIR = /usr/share/postgresql/8.1/man SHAREDIR = /usr/share/postgresql/8.1 SYSCONFDIR = /etc/postgresql PGXS = /usr/lib/postgresql/8.1/lib/pgxs/src/makefiles/pgxs.mk CONFIGURE = '--build=i386-linux' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--libexecdir=/usr/lib/postgresql-8.1' '--srcdir=.' '--disable-maintainer-mode' '--mandir=/usr/share/postgresql/8.1/man' '--with-docdir=/usr/share/doc/postgresql-doc-8.1' '--datadir=/usr/share/postgresql/8.1' '--bindir=/usr/lib/postgresql/8.1/bin' '--includedir=/usr/include/postgresql/' '--enable-nls' '--enable-integer-datetimes' '--enable-thread-safety' '--enable-debug' '--disable-rpath' '--with-tcl' '--with-perl' '--with-python' '--with-pam' '--with-krb5' '--with-openssl' '--with-gnu-ld' '--with-tclconfig=/usr/lib/tcl8.4' '--with-tkconfig=/usr/lib/tk8.4' '--with-includes=/usr/include/tcl8.4' '--with-pgport=5432' 'CFLAGS=-g -Wall -O2 -fPIC' 'LDFLAGS=-Wl,--as-needed' 'CC=cc' 'build_alias=i386-linux' CC = cc CPPFLAGS = -D_GNU_SOURCE -I/usr/include/tcl8.4 CFLAGS = -g -Wall -O2 -fPIC -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wendif-labels -fno-strict-aliasing -g CFLAGS_SL = -fpic LDFLAGS = -Wl,--as-needed LDFLAGS_SL = LIBS = -lpgport -lpam -lssl -lcrypto -lkrb5 -lz -lreadline -lcrypt -lresolv -lnsl -ldl -lm VERSION = PostgreSQL 8.1.4 Server's pg_hba.conf: # Database administrative login by UNIX sockets local all postgres ident sameuser # TYPE DATABASEUSERCIDR-ADDRESS METHOD # "local" is for Unix domain socket connections only local all all ident sameuser # IPv4 local connections: hostall all 127.0.0.1/32 md5 hostall all 10.0.0.0/8md5 # IPv6 local connections: hostall all ::1/128 md5 -- Milen A. Radev ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #2684: Memory leak in libpq
On 10/10/06, Tom Lane <[EMAIL PROTECTED]> wrote: "Milen A. Radev" <[EMAIL PROTECTED]> writes: > On 10/10/06, Tom Lane <[EMAIL PROTECTED]> wrote: >> I couldn't duplicate any such leak using your test program here. > The client and the server were on different machines - that's why I > believe "md5" was used. I'm sending only the client machine's > pg_config output. Tell me if you need the server's too. I cannot duplicate a leak using a cross-machine connection with md5 auth, either. I tested this using Fedora Core 5 and the current FC5 libpq (postgresql-libs-8.1.4-1.FC5.1 RPM). I'm wondering if the leak you see is actually the fault of the glibc version on your machine. You're most probably right - I could reproduce this results only with libc6 2.3.x (Slackware 9.1, Debian stable), but not with version 2.4 (FC5). -- Milen A. Radev ---(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] GRANT RULE IN 8.2
Prischepa Vladimir написа: > PostgreSQL 8.2 / WIN XP > > When I execute sql with GRANT RULE statement. > In sistem table "pg_class", field "relacl" don't change. Statament 'R' is > not introduce in Access privileges. Another privileges work god. > > P.S. In 8.0 version all good ! Please, read the release notes for 8.2 (http://www.postgresql.org/docs/current/static/release-8-2.html) "Remove RULE permission for tables, for security reasons (Tom) As of this release, only a table's owner can create or modify rules for the table. For backwards compatibility, GRANT/REVOKE RULE is still accepted, but it does nothing. " -- Milen A. Radev ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #3026: 8.2 FOR DEBIAN !!! plzzzz ^^
Skatepark Insaen написа: > The following bug has been logged online: > > Bug reference: 3026 > Logged by: Skatepark Insaen > Email address: [EMAIL PROTECTED] > PostgreSQL version: 7.4.7-6sarge4 > Operating system: Linux - Debian - Sarge > Description:8.2 FOR DEBIAN !!! pl ^^ > Details: > > Whats up with the new versions for postgres Also look here - http://www.backports.org/. -- Milen A. Radev ---(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] psql prompting for password. Can we suppress it?
Pradeep Rai написа: > Hello, > > We are trying to perform bulk insert into PostGre database with the help of > a text file (containing n INSERT statements), and then invoking psql command > from a batch file. > > "psql -d -f -h -U " > > The issue is that the psql command window prompts for the password. Have you > got any idea how to suppress it? 1.http://www.postgresql.org/docs/current/static/libpq-pgpass.html 2.http://www.postgresql.org/docs/current/static/auth-methods.html#AUTH-TRUST -- Milen A. Radev ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] Documentation
karol dzięgielewski написа: > Hi, > Where can I find documentation in pdf format? > Regards Karol Dzięgielewski That's not a bug. http://www.postgresql.org/docs/manuals/ -- Milen A. Radev ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #3641: Concat fails in update
Curt написа: > The following bug has been logged online: > > Bug reference: 3641 > Logged by: Curt > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.1.9-1.el5 > Operating system: Centos 5 > Description:Concat fails in update > Details: > > UPDATE table content=content || 'constant' where idx=101; > > Content field is overwritten with 'constant'. Is this the real statement you've used? Because it's not a valid UPDATE statement - it's missing the 'SET' part before the name of the column. Could you send the real statement _and_ the error message you've got. -- Milen A. Radev ---(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 #3854: pg_dump dumps renamed primary key constraints by their old name
The following bug has been logged online: Bug reference: 3854 Logged by: Milen A. Radev Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.6 Operating system: Debian Etch Description:pg_dump dumps renamed primary key constraints by their old name Details: After a table and the implicit index related to its primary key are renamed, pg_dump still creates a statement for the primary key using its old name. Most of the time that's probably harmless but not when there are clustered tables. Steps to reproduce the problem: === dev:~# /usr/local/postgresql-8.2.6/bin/psql -U postgres -p 6543 Welcome to psql 8.2.6, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit postgres=# create table x (x_id integer primary key, foo integer); NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "x_pkey" for table "x" CREATE TABLE postgres=# \d x Table "public.x" Column | Type | Modifiers +-+--- x_id | integer | not null foo| integer | Indexes: "x_pkey" PRIMARY KEY, btree (x_id) postgres=# CLUSTER x_pkey ON x; CLUSTER postgres=# \d x Table "public.x" Column | Type | Modifiers +-+--- x_id | integer | not null foo| integer | Indexes: "x_pkey" PRIMARY KEY, btree (x_id) CLUSTER postgres=# alter table x rename to a; ALTER TABLE postgres=# alter index x_pkey rename to a_pkey; ALTER INDEX postgres=# \d a Table "public.a" Column | Type | Modifiers +-+--- x_id | integer | not null foo| integer | Indexes: "a_pkey" PRIMARY KEY, btree (x_id) CLUSTER postgres=# \q dev:~# /usr/local/postgresql-8.2.6/bin/pg_dump -U postgres -p 6543 postgres -- -- PostgreSQL database dump -- SET client_encoding = 'SQL_ASCII'; SET standard_conforming_strings = off; SET check_function_bodies = false; SET client_min_messages = warning; SET escape_string_warning = off; -- -- Name: SCHEMA public; Type: COMMENT; Schema: -; Owner: postgres -- COMMENT ON SCHEMA public IS 'Standard public schema'; SET search_path = public, pg_catalog; SET default_tablespace = ''; SET default_with_oids = false; -- -- Name: a; Type: TABLE; Schema: public; Owner: postgres; Tablespace: -- CREATE TABLE a ( x_id integer NOT NULL, foo integer ); ALTER TABLE public.a OWNER TO postgres; -- -- Data for Name: a; Type: TABLE DATA; Schema: public; Owner: postgres -- COPY a (x_id, foo) FROM stdin; \. -- -- Name: x_pkey; Type: CONSTRAINT; Schema: public; Owner: postgres; Tablespace: -- ALTER TABLE ONLY a ADD CONSTRAINT x_pkey PRIMARY KEY (x_id); ALTER TABLE a CLUSTER ON a_pkey; -- -- Name: public; Type: ACL; Schema: -; Owner: postgres -- REVOKE ALL ON SCHEMA public FROM PUBLIC; REVOKE ALL ON SCHEMA public FROM postgres; GRANT ALL ON SCHEMA public TO postgres; GRANT ALL ON SCHEMA public TO PUBLIC; -- -- PostgreSQL database dump complete -- dev:~# === The problematic statements are: ALTER TABLE ONLY a ADD CONSTRAINT x_pkey PRIMARY KEY (x_id); ALTER TABLE a CLUSTER ON a_pkey; ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] Re: BUG #3894: JDBC DatabaseMetaData.getTables is inconsistently case-sensitive with schema name
Adam Hardy написа: [...] it seems to me from what you just said that PostgreSQL server and JDBC driver require the schema name to be lower case deliberately, and that any given name that is not all lower case is converted to lower case by the server or the driver. Am I correct? http://www.postgresql.org/docs/current/static/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS, (especially the last paragraph of 4.1.1.), -- Milen A. Radev ---(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 #1505: [enhancement] Better link styles for the included documentation
The following bug has been logged online:
Bug reference: 1505
Logged by: Milen A. Radev
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.7
Operating system: Debian GNU/Linux 3.0
Description:[enhancement] Better link styles for the included
documentation
Details:
I have problem with the look of the links in the included html documentation
($PG_INSTALL_DIR/doc/html/stylesheet.css). Now they have the following style
defined:
A:link { color: #66; }
A:visited { color: #99; }
A:active { color: #FF; }
And such styled unvisited links look a lot like the non-styled visited links
and vice versa. It would be better if they were left unstyled or with a
style that does not resembles the default style for links but in reverse.
---(end of broadcast)---
TIP 3: 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] BUG #2195: log_min_messages crash server when in DEBUG3 to 5
Tom Lane writes: > "Jaime Casanova" <[EMAIL PROTECTED]> writes: >> in my machine (win xp) i was trying to start psql (8.1.1) with >> log_min_messages to debug5 (just to see the messages :) but even the >> service start i cannot use psql nor pgadmin i receive an error of >> server closed the connection unexpectedly > > Can't reproduce this on Linux using 8.1 branch tip, so either it's > Windows-specific or it's been fixed recently ... > Should be windows-specific - I can reproduce it with 8.1.2 on WinXP SP2 and I can't reproduce it with 8.1.2 on Slackware Linux 9.1 (kernel 2.6.15). By the way I have the crash report files Windows created - postgres.exe.hdmp, postgres.exe.mdmp, appcompat.txt and manifest.txt. -- Milen A. Radev ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #5552: incorrect returned value of time
На 12.07.2010 г. 10:16, Konstantin Kulikov написа:
The following bug has been logged online:
Bug reference: 5552
Logged by: Konstantin Kulikov
Email address: k.e.kuli...@gmail.com
PostgreSQL version: 8.3
Operating system: unix
Description:incorrect returned value of time
Details:
select current_timestamp at time zone 'GMT+3';
will return actually 'GMT-3'
Excerpts from the docs ("8.5.3. Time Zones",
http://www.postgresql.org/docs/8.3/static/datatype-datetime.html#DATATYPE-TIMEZONES):
" - In addition to the timezone names and abbreviations, PostgreSQL will
accept POSIX-style time zone specifications of the form STDoffset or
STDoffsetDST, where STD is a zone abbreviation, offset is a numeric
offset in hours west from UTC, and DST is an optional daylight-savings
zone abbreviation, assumed to stand for one hour ahead of the given
offset..."
and:
"Another issue to keep in mind is that in POSIX time zone names,
positive offsets are used for locations west of Greenwich. Everywhere
else, PostgreSQL follows the ISO-8601 convention that positive timezone
offsets are east of Greenwich. ..."
--
Milen A. Radev
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
