Re: [BUGS] PG 9.0 Solaris compile error on Sparc
Dave Page píše v po 19. 07. 2010 v 14:24 +0100: > On Mon, Jul 19, 2010 at 1:56 PM, Zdenek Kotala wrote: > > Dave Page píše v po 19. 07. 2010 v 13:32 +0100: > >> I'm working on setting up a new buildfarm member as we don't seem to > >> have any active Solaris ones :-( > > > > Unfortunately, I had to stop them :(. Sorry. > > > > I cannot remember this bug. However for Solaris 10 is better to use > > SunStudio 11. I see lot of bugs in SunStudio 12 and also postgresql with > > dtrace is not possible compile with sunstudio 12 due some optimization. > > It is bug in solaris 10 which is not fixed(backported) yet. > > > > > Anyway it is strange. I used following switches without any problem: > > > > ./configure --without-readline --enable-cassert --enable-debug > > --enable-nls --enable-integer-datetimes --with-perl --with-python \ > > --with-tcl --with-krb5 --with-gssapi --with-openssl --with-pam \ > > --enable-thread-safety > > --with-includes=/usr/include/kerberosv5:/usr/sfw/include > > --with-libs=/usr/sfw/lib --enable-dtrace --with-libxml --with-libxslt > > Hmm. Perl fails here, as it seems to be 32 bit. I see, you compile it 64bits. 64bits perl does not exist - no PL/PgPerl > OpenSSL fails, due to > lack of libcryto, and TCL seems to fail due to lack of headers (though > I didn't look very hard). You need to set RPATH. Openssl is in /usr/sfw/lib (/usr/sfw/lib/64) You need this for 32bit 'LDFLAGS' => '-R/usr/sfw/lib', 'LDFLAGS_SL' => '-R/usr/sfw/lib', 'TCLSH' => '/usr/sfw/bin/tclsh8.3' and 'LDFLAGS' => '-R/usr/sfw/lib/64', for 64bit. > I'm assuming these issues are largely due to > my inexperience with Solaris, or are there some development packages > or similar I should be downloading? No you need only compiler and full Solaris 10 installation. > > I see also that you use S10U3 which is not optimal for PostgreSQL. You > > need to have S10U4 (at least for kerberos and dtrace). > > Hmm, I'll have to see about upgrading it without annoying other users. > > Thanks! > -- 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] PG 9.0 Solaris compile error on Sparc
Dave Page píše v po 19. 07. 2010 v 13:32 +0100: > I'm working on setting up a new buildfarm member as we don't seem to > have any active Solaris ones :-( Unfortunately, I had to stop them :(. Sorry. I cannot remember this bug. However for Solaris 10 is better to use SunStudio 11. I see lot of bugs in SunStudio 12 and also postgresql with dtrace is not possible compile with sunstudio 12 due some optimization. It is bug in solaris 10 which is not fixed(backported) yet. Anyway it is strange. I used following switches without any problem: ./configure --without-readline --enable-cassert --enable-debug --enable-nls --enable-integer-datetimes --with-perl --with-python \ --with-tcl --with-krb5 --with-gssapi --with-openssl --with-pam \ --enable-thread-safety --with-includes=/usr/include/kerberosv5:/usr/sfw/include --with-libs=/usr/sfw/lib --enable-dtrace --with-libxml --with-libxslt I see also that you use S10U3 which is not optimal for PostgreSQL. You need to have S10U4 (at least for kerberos and dtrace). Anyway it looks like that #include is missing somewhere. Zdenek > cc -Xa -m64 -mt -mt -D_REENTRANT -D_THREAD_SAFE > -D_POSIX_PTHREAD_SEMANTICS -KPIC -DFRONTEND -DUNSAFE_STAT_OK -I. > -I../../../src/include -I../../../src/port -I../../../src/port > -DSO_MAJOR_VERSION=5 -c -o fe-connect.o fe-connect.c > "fe-connect.c", line 1789: undefined symbol: ucred_t > "fe-connect.c", line 1789: undefined symbol: ucred > "fe-connect.c", line 1792: warning: implicit function declaration: > getpeerucred > "fe-connect.c", line 1792: undefined symbol: sock > "fe-connect.c", line 1800: warning: implicit function declaration: > ucred_geteuid > "fe-connect.c", line 1805: warning: implicit function declaration: ucred_free > cc: acomp failed for fe-connect.c > > That is with Sun Studio 12. This is with gcc: > > gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith > -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing > -fwrapv -pthreads -pthreads -D_REENTRANT -D_THREAD_SAFE > -D_POSIX_PTHREAD_SEMANTICS -fPIC -DFRONTEND -DUNSAFE_STAT_OK -I. > -I../../../src/include -I../../../src/port -I../../../src/port > -DSO_MAJOR_VERSION=5 -c -o fe-connect.o fe-connect.c > fe-connect.c: In function `PQconnectPoll': > fe-connect.c:1789: error: `ucred_t' undeclared (first use in this function) > fe-connect.c:1789: error: (Each undeclared identifier is reported only once > fe-connect.c:1789: error: for each function it appears in.) > fe-connect.c:1789: error: `ucred' undeclared (first use in this function) > fe-connect.c:1792: warning: implicit declaration of function `getpeerucred' > fe-connect.c:1792: error: `sock' undeclared (first use in this function) > fe-connect.c:1800: warning: implicit declaration of function `ucred_geteuid' > fe-connect.c:1805: warning: implicit declaration of function `ucred_free' > gmake[3]: *** [fe-connect.o] Error 1 > > Platform: > > -bash-3.00$ uname -a > SunOS suzuka 5.10 Generic_118833-33 sun4u sparc SUNW,Sun-Blade-1000 > > Configured with: > > ./configure --with-perl --with-python --without-readline > > -- > Dave Page > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise Postgres Company > -- 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 #5318: Inconsistent PHP pg_result_error_field PGSQL_DIAG_SOURCE_FUNCTION across instalations
IP píše v ne 14. 02. 2010 v 21:15 +0100: > Hi, > > Thanks, great info. I will retest that, for sure. Nevertheless status of > PostgreSQL packages for Sun Solaris is something really interesting ;-) Here > http://www.postgresql.org/download/solaris we can read that the packages are > produced by Sun. That's the reason I call them that way. They are community packages and people from Sun only produce it but Sun does not guarantee quality and so on. It is same like RPM or other packages. People from different companies do that but companies are not responsible for the content. It could look like little bit schizophrenic :-), but it is how it works. Zdenek -- 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 #5318: Inconsistent PHP pg_result_error_field PGSQL_DIAG_SOURCE_FUNCTION across instalations
We (means postgresql community -> Bjorn or me) will fix it in 8.4.3 packages. It will be confusing to rerelease already released 8.4.2 package. Just for clarification, There is no Sun's Solaris 10 PostgreSQL 8.4 packages. Zdenek IP píše v ne 14. 02. 2010 v 20:39 +0100: > What is the final outcome? Will the Sun Solaris' PostgreSQL 8.4.2 packages > be rebuild so that PGSQL_DIAG_SOURCE_FUNCTION is operational, or rather not? > > > -- > Szybkie i niedrogie... Tylko dla mezczyzn! > Sprawdz >>> http://link.interia.pl/f25a7 > -- 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 #5318: Inconsistent PHP pg_result_error_field PGSQL_DIAG_SOURCE_FUNCTION across instalations
Tom Lane píše v so 06. 02. 2010 v 10:57 -0500: > "IP" writes: > > Issue: no value returned for 8.4.2 Solaris 10 x86 installation > > This isn't necessarily a bug. The source-function report depends > on having used a C compiler that supports the __func__ or __FUNCTION__ > symbol, and not all do. Yes it is the problem > Most likely your Solaris 10 version was > built with a compiler that doesn't. SunStudio has __func__ since version 10. Solaris 10 is compiled with version 11. Problem is that __func__ is defined in C99 and PostgreSQL is compiled with -xc99=none. Which means that compiler should be strict C89 like PostgreSQL ;-). I think that there is no reason to use this flag. Zdenek -- 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 #4494: Memory leak in pg_regress.c
Alvaro Herrera napsal(a): Zdenek Kotala wrote: [EMAIL PROTECTED] napsal(a): In file src/test/regress/pg_regress.c:1112 It seems to me that variables "s" and "tmp" leak memory here if last_dot is false: OK. It seems as a bug. tmp and s should be freed when strrchr fails. Also there is not check when malloc fails. So who's gonna send the patch? I will do that. Still on my TODO. Zdenek -- 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 #4494: Memory leak in pg_regress.c
[EMAIL PROTECTED] napsal(a):
The following bug has been logged online:
Bug reference: 4494
Logged by:
Email address: [EMAIL PROTECTED]
PostgreSQL version: Latest cvs
Operating system: Error in source code
Description:Memory leak in pg_regress.c
Details:
In file src/test/regress/pg_regress.c:1112
It seems to me that variables "s" and "tmp" leak memory here if last_dot is
false:
static char *
get_alternative_expectfile(const char *expectfile, int i)
{
char *last_dot;
int ssize = strlen(expectfile) + 2 + 1;
char *tmp = (char *) malloc(ssize);
char *s = (char *) malloc(ssize);
strcpy(tmp, expectfile);
last_dot = strrchr(tmp, '.');
if (!last_dot)
return NULL;
*last_dot = '\0';
snprintf(s, ssize, "%s_%d.%s", tmp, i, last_dot + 1);
free(tmp);
return s;
}
OK. It seems as a bug. tmp and s should be freed when strrchr fails. Also there
is not check when malloc fails.
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
--
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 #4496: Memory leak in pg_dump.c?
Aggro napsal(a): I think all information is collected and they are used for all pg_dump run. It does not make sense to free them. See line 725. Zdenek But is the memory freed at some point? E.g. when program shuts down? If it is not freed ever, then it is a memory leak. I'm interested in this, because either you have a memory leak or these is a bug in another application called cppcheck which claims that you have a memory leak. But if it is too difficult to find out, I won't bother you about this anymore as it is most likely a minor issue if even that. Keep in mind that onetime allocated local memory is not reclaimed to OS until process finished. See sbrk(2) It does not make sense to free memory at the end (in pg_dump) because it does not have any effect on available memory in OS and OS clean it soon anyway. I agree that from general point of view it is good to release unused memory, because process can reuse it. But when you know what you do then you can break a rule. Zdenek -- Zdenek Kotala Sun Microsystems Prague, Czech Republic http://sun.com/postgresql -- 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] Upgrade from 7.4.5 to 8.3.3
Harvey, Allan AC napsal(a): Zdenek, Hmm, It does not look good. Your OS does not return proper information about codeset. Following code is broken: setlocale(LC_CTYPE, ctype); sys = nl_langinfo(CODESET); sys = strdup(sys); See http://www.opengroup.org/onlinepubs/009695399/functions/nl_lan ginfo.html It seems you need to fix OS first. After that we can add CODESET mapping to PostgreSQL. Zdenek I don't think this is possible. Can you give me an indication what problems I should look out for? Regression testing only showed some date format issues if I remeber correctly. I think, problem could be on two places: 1) libc is broken and does not return correct values. 2) locale definition does not contain CODESET information. Do you use system libc or glibc? You can try create own locale by localedef and test what happen. Zdenek -- 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 #4496: Memory leak in pg_dump.c?
[EMAIL PROTECTED] napsal(a):
The following bug has been logged online:
Bug reference: 4496
Logged by:
Email address: [EMAIL PROTECTED]
PostgreSQL version: Latest cvs
Operating system: Error in source code
Description:Memory leak in pg_dump.c?
Details:
In file src/bin/pg_dump/pg_dump.c:3741
It seems like variables "constrinfo" and "indxinfo" leak memory e.g. at line
3741 and also on many other similar functions. If the memory is released
somewhere I failed to find the location where it is released. So please
either fix the leak if there is a leak or document better where the memory
is released.
I think all information is collected and they are used for all pg_dump run. It
does not make sense to free them. See line 725.
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
--
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] Upgrade from 7.4.5 to 8.3.3
Hmm, It does not look good. Your OS does not return proper information about codeset. Following code is broken: setlocale(LC_CTYPE, ctype); sys = nl_langinfo(CODESET); sys = strdup(sys); See http://www.opengroup.org/onlinepubs/009695399/functions/nl_langinfo.html It seems you need to fix OS first. After that we can add CODESET mapping to PostgreSQL. Zdenek Harvey, Allan AC napsal(a): Zdenek Thanks for your reply. I guess we don't have locale mapping for SCO OpenServer5.7. See http://doxygen.postgresql.org/chklocale_8c-source.html Browser Timed out. (?) Could you run following code: http://archives.postgresql.org/pgsql-hackers/2007-09/msg01168.php and send output. Zdenek Output as requested: bash-2.05$ for LOCALE in `locale -a`; do locale_test $LOCALE; done C_C.C ...- NO MATCH cs_CZ.ISO8859-2 ...- NO MATCH english_uk.ISO8859-15 ...- NO MATCH english_uk.8859 ...- NO MATCH -- Zdenek Kotala Sun Microsystems Prague, Czech Republic http://sun.com/postgresql -- 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 in pageinspect contrib modul
Heikki Linnakangas napsal(a): Zdenek Kotala wrote: The following code is in btreefuncs.c function GetBTPageStatistics: stat->max_avail = BLCKSZ - (BLCKSZ - phdr->pd_special + SizeOfPageHeaderData); I think it should be: stat->max_avail = BLCKSZ - (phdr->pd_special + SizeOfPageHeaderData); Umm, I don't think so. pd_special is the offset to the start of the special area, so (BLCKSZ - pd_special) is the size of the special area. However, that max_avail field actually looks like dead code, anyway. Yeah, you are right. I forgot that pd_special does not contain size but offset. Thanks Zdenek -- Zdenek Kotala Sun Microsystems Prague, Czech Republic http://sun.com/postgresql -- 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] Upgrade from 7.4.5 to 8.3.3
I guess we don't have locale mapping for SCO OpenServer5.7. See http://doxygen.postgresql.org/chklocale_8c-source.html Could you run following code: http://archives.postgresql.org/pgsql-hackers/2007-09/msg01168.php and send output. Zdenek Harvey, Allan AC napsal(a): During an upgrade from 7.4.5 to 8.3.3 the following was dumped during the restore process from psql. psql:roperydb_v7.4_20081021.dmp:49: WARNING: could not determine encoding for locale "C_C.C": codeset is "" DETAIL: Please report this to . So I am reporting it. Back ground. I am using 8.3.3 because it is the latest I have for SCO OpenServer5.7 I used "pg_dumpall -o" from the 8.3.3 release. During the "initdb" process similar errors were dumped and a suggestion of passng a locale with the -E option was used. Explicitly I used: /usr/local/pgsql/bin/initdb -E SQL_ASCII -D /usr/local/pgsql/data which allowed the process to complete. The warning above was then dumped during the restore process. The cluster seems to working OK. Should I be concerned? Thanks for your time. Allan The material contained in this email may be confidential, privileged or copyrighted. If you are not the intended recipient, use, disclosure or copying of this information is prohibited. If you have received this document in error, please advise the sender and delete the document. Neither OneSteel nor the sender accept responsibility for any viruses contained in this email or any attachments. -- Zdenek Kotala Sun Microsystems Prague, Czech Republic http://sun.com/postgresql -- 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 in pageinspect contrib modul
The following code is in btreefuncs.c function GetBTPageStatistics: stat->max_avail = BLCKSZ - (BLCKSZ - phdr->pd_special + SizeOfPageHeaderData); I think it should be: stat->max_avail = BLCKSZ - (phdr->pd_special + SizeOfPageHeaderData); Zdenek -- Zdenek Kotala Sun Microsystems Prague, Czech Republic http://sun.com/postgresql -- 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 #4389: FATAL: could not reattach to shared memory (key=1804, addr=018E0000): 487
could not reattach to shared memory napsal(a): The following bug has been logged online: Bug reference: 4389 Logged by: could not reattach to shared memory Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.3-1 Operating system: any 8.3.* Description:FATAL: could not reattach to shared memory (key=1804, addr=018E): 487 Details: This error came week ago. From that 'black' day I can not use Postgre. I have reinstalled several 8.3.* versions (including last version with vcredist_x86.exe) and nothing helps me. try to remove postgesql.pid file in the data directory. Zdenek -- 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 Problems
Bernard Stewe napsal(a): Hi We are trying to install postgres 8.3.0 on solaris 9. The installation process comes up with the following error. Hi, Please, could you specify what binary do you use? It seems to me that you downloaded PG version which is compiled for Solaris 10 Update 4. Zdenek -- Zdenek Kotala Sun Microsystems Prague, Czech Republic http://sun.com/postgresql -- 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 #4319: lower()/upper() does not know about UNICODE case mapping
Valentine Gogichashvili napsal(a): Hi, Hi I understand, that it is more a feature, but it does not help me anyways... On the UNICODE databases lower and upper functions are using system locale settings (that cannot be changed after initializing DB?) and does not know anything about UNICODE case mapping. The problem really becomes 'a problem' on multilingual systems. I have to store data for German, Russian and Romanian languages together. I understand you and I hope things will be better. See collation per database project: http://wiki.postgresql.org/wiki/Gsoc08-collation Zdenek -- Zdenek Kotala Sun Microsystems Prague, Czech Republic http://sun.com/postgresql -- 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 #4292: directory pg_clog never cleaned
Lampa napsal(a): The following bug has been logged online: Bug reference: 4292 Logged by: Lampa Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.3, 8.1.8 Operating system: Debian x86_64, Debian i686 Description:directory pg_clog never cleaned Details: Directory pg_clog, is never cleaned. My pg_clog directory contains 1070 files. Do you perform vacuum? Only vacuum can do it. Or do you have any very log open transaction which protects vacuum to do its job? Zdenek -- 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] some problem when installing postgresql
If I understand correctly, Is version 8.0.0-rc1 bundled with MoteView? If yes then I highly recommended to install 8.3.1 version. Version 8.0 is unsupported on Windows platform now. Zdenek Yu Qun napsal(a): hey: I am the new one to use PostgreSql, when I install the MoteView including postgresql and postgresqlODBC and so on, I met a problem about PostgreSql installation, it shew that "Failed to set permissions on the installed files. Please see the logfile in "C:\Program Files\PostgreSql\8.0.0-rc 1\tmp\pgperm.log". in the pgperm.log, it says that "No mapping between account names and security IDs was done.". I dont know what is problem? would you like to give me some idea on it? Thanks! Sincerely; Maggie -- 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] postmaster segfault when using SELECT on a table
Tom Lane wrote: My suspicion though is that you'll find that a large portion of that page is damaged; that's usually what we've seen in such cases in the past. I think, It can happen only if corruption is less then TOAST chunk size. In other case, page header or tuple header+chunk id should be corrupted and it should be reported in another place. Zdenek -- 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] postmaster segfault when using SELECT on a table
Karsten Desler wrote:
I don't know much about the postgres architecture and I don't know if bounds
checking on-disk values on a read makes a lot of sense since usually one
should be able to assume that there are no randomly flipped bits; but it
would've been nice to have a sensible log entry as to what really
happened.
I attached backported patch from head to 8.2. You can try it. It has small
performance penalty, but it does not crash on corrupted data.
Zdenek
*** src/backend/utils/adt/pg_lzcompress.c 2006/10/05 23:33:33 1.23
--- src/backend/utils/adt/pg_lzcompress.c 2008/03/08 01:09:36 1.31
*** pglz_compress(const char *source, int32
*** 631,656
void
pglz_decompress(const PGLZ_Header *source, char *dest)
{
! const unsigned char *dp;
! const unsigned char *dend;
! unsigned char *bp;
! unsigned char ctrl;
! int32 ctrlc;
! int32 len;
! int32 off;
! int32 destsize;
!
! dp = ((const unsigned char *) source) + sizeof(PGLZ_Header);
! dend = ((const unsigned char *) source) + VARATT_SIZE(source);
! bp = (unsigned char *) dest;
! while (dp < dend)
{
/*
! * Read one control byte and process the next 8 items.
*/
! ctrl = *dp++;
! for (ctrlc = 0; ctrlc < 8 && dp < dend; ctrlc++)
{
if (ctrl & 1)
{
--- 641,666
void
pglz_decompress(const PGLZ_Header *source, char *dest)
{
! const unsigned char *sp;
! const unsigned char *srcend;
! unsigned char *dp;
! unsigned char *destend;
!
! sp = ((const unsigned char *) source) + sizeof(PGLZ_Header);
! srcend = ((const unsigned char *) source) + VARATT_SIZE(source);
! dp = (unsigned char *) dest;
! destend = dp + source->rawsize;
! while (sp < srcend && dp < destend)
{
/*
! * Read one control byte and process the next 8 items (or as many
! * as remain in the compressed input).
*/
! unsigned char ctrl = *sp++;
! int ctrlc;
!
! for (ctrlc = 0; ctrlc < 8 && sp < srcend; ctrlc++)
{
if (ctrl & 1)
{
*** pglz_decompress(const PGLZ_Header *sourc
*** 661,671
* coded as 18, another extension tag byte tells how much
* longer the match really was (0-255).
*/
! len = (dp[0] & 0x0f) + 3;
! off = ((dp[0] & 0xf0) << 4) | dp[1];
! dp += 2;
if (len == 18)
! len += *dp++;
/*
* Now we copy the bytes specified by the tag from OUTPUT to
--- 671,697
* coded as 18, another extension tag byte tells how much
* longer the match really was (0-255).
*/
! int32 len;
! int32 off;
!
! len = (sp[0] & 0x0f) + 3;
! off = ((sp[0] & 0xf0) << 4) | sp[1];
! sp += 2;
if (len == 18)
! len += *sp++;
!
! /*
! * Check for output buffer overrun, to ensure we don't
! * clobber memory in case of corrupt input. Note: we must
! * advance dp here to ensure the error is detected below
! * the loop. We don't simply put the elog inside the loop
! * since that will probably interfere with optimization.
! */
! if (dp + len > destend)
! {
! dp += len;
! break;
! }
/*
* Now we copy the bytes specified by the tag from OUTPUT to
*** pglz_decompress(const PGLZ_Header *sourc
*** 675,682
*/
while (len--)
{
! *bp = bp[-off];
! bp++;
}
}
else
--- 701,708
*/
while (len--)
{
! *dp = dp[-off];
! dp++;
}
}
else
*** pglz_decompress(const PGLZ_Header *sourc
*** 685,691
* An unset control bit means LITERAL BYTE. So we just copy
* one from INPUT to OUTPUT.
*/
! *bp++ = *dp++;
}
/*
--- 711,720
* An unset control bit means LITERAL BYTE. So we just copy
* one from INPUT to OUTPUT.
*/
! if (dp >= destend) /* check for buffer overrun */
! break; /* do not clobber memory */
!
! *dp++ = *sp++;
}
/*
*** pglz_decompress(const PGLZ_Header *sourc
*** 696,709
}
/*
! * Check we decompressed the right amount, else die. This is a FATAL
! * condition if we tromped on more memory than expected (we assume we
! * have not tromped on shared memory, though, so need not PANIC).
! */
! destsize = (char *) bp - dest;
! if (destsize != source->rawsize)
! elog(destsize > source->rawsize ? FATAL : ERROR,
! "compressed data is corrupt");
/*
* That's it.
--- 725,734
}
/*
! * Check we decompressed the right amount.
! */
! if (dp != destend || sp != srcend)
! elog(ERROR, "compressed data is corrupt");
/*
* That's it.
--
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] problem
The first record ctid=(0,1) is obsolete, you can delete it. It is probably race condition in VACUUM and catalog modification. Did you added or modified any user account (e.g. password change) in related time? Please, can you let us know exact version of PostgreSQL? Zdenek Khobotko Oleg napsal(a): Hello, help me please, I don't know how, but i got 2 postgres users. How can I delete the first one thx alot for your answers. /// select passwd,ctid,xmin,xmax,cmin,cmax from pg_shadow where usesysid =1; passwd| ctid | xmin | xmax | cmin | cmax -+---+--+--+--+- - | (0,1) |1 | 16754522 | 16754522 |0 md510db8c04d26d32185270721fcf32155 | (0,2) |2 |0 |0 |0 (2 rows) // select * from pg_shadow where usesysid=1; usename | usesysid | usecreatedb | usesuper | usecatupd | passwd | valuntil | useconfig --+--+-+--+---+- +--+--- postgres |1 | t | t| t | | | postgres |1 | t | t| t | md510db8c04d231142d5 270721fcf740ed5 | infinity | (2 rows) Tom Lane пишет: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: I have two "postgres" user. How to delete the first one ??? Let's see the system columns (ctid,xmin,xmax,cmin,cmax) for those two rows? 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 #4121: ERROR: could not open relation 1663/16403/469917: Invalid argument
Try to look into base/16403/ directory and check if file 469917 exists. And run
select relname from pg_class where relfilenode=469917
to determine which relation (table) is affected.
Zdenek
PS: 8.1 version of PostgreSQL is not supported on win. Use 8.3
Boldinov napsal(a):
The following bug has been logged online:
Bug reference: 4121
Logged by: Boldinov
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.5
Operating system: Windows Server 2003 Standart
Description:ERROR: could not open relation 1663/16403/469917:
Invalid argument
Details:
2008-04-21 14:35:41 ERROR: could not open relation 1663/16403/469917:
Invalid argument
2008-04-21 14:35:41 STATEMENT: SELECT
_Reference130._IDRRef AS f_3,
_Reference130._Description AS f_4
FROM
_Reference130
WHERE
_Reference130._IDRRef =
'\\200"\\000\\033x0\\004\\032\\021\\334\\250\\246\\360\\024\\017_'::bytea
AND (FALSE = TRUE OR
EXISTS(
SELECT
0 AS f_2
FROM
(
SELECT
TRUE AS _f_1
) _V8TblAli1
INNER JOIN _InfoReg16060 _InfoReg16060_Q_000_T_002
ON _InfoReg16060_Q_000_T_002._Fld16061_TYPE = '\\010'::bytea AND
_InfoReg16060_Q_000_T_002._Fld16061_RTRef = '\\000\\000\\000\\236'::bytea
AND _InfoReg16060_Q_000_T_002._Fld16061_RRRef = _Reference130._OwnerIDRRef
AND _InfoReg16060_Q_000_T_002._Fld16062RRef =
'\\205Y\\011U\\377\\362\\015\\220D''_3\\367\\352\\200\\247'::bytea AND
_InfoReg16060_Q_000_T_002._Fld16063_TYPE = '\\010'::bytea AND
(_InfoReg16060_Q_000_T_002._Fld16063_RTRef ||
_InfoReg16060_Q_000_T_002._Fld16063_RRRef) IN ('\\000\\000\\0002'::bytea ||
'\\200"\\000\\033x0\\004\\032\\021\\334\\262\\273<\\265)4'::bytea,'\\000\\00
0\\0002'::bytea ||
'\\245\\230\\272~\\361\\313\\223fG\\034\\011\\207X\\325q\\016'::bytea,'\\000
\\000\\000\\324'::bytea ||
'\\257\\332\\000\\004#R\\244\\374\\021\\334\\206\\326\\355\\252j\\360'::byte
a) AND _InfoReg16060_Q_000_T_002._Fld16065 = TRUE))
--
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 #4114: Inconsistent shift operator
Roman Kononov napsal(a):
The following bug has been logged online:
Bug reference: 4114
Logged by: Roman Kononov
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.1
Operating system: x86_64 GNU/Linux
Description:Inconsistent shift operator
Details:
The below test cases show the obvious inconsistency between different
integer types.
test=# \t
Showing only tuples.
test=# select 1::int2 << 17;
0
test=# select 1::int4 << 33;
2
test=# select 1::int8 << 65;
2
test=# select 2::int2 >> 17;
0
test=# select 2::int4 >> 33;
1
test=# select 2::int8 >> 65;
1
It seems to be OK regarding how C shift operator works. Try
#include
#include
void fce(int16_t arg1, int32_t arg2)
{
int16_t res = arg1 << arg2;
printf("result: %i\n", res);
}
int main()
{
fce(1,17);
return 0;
}
Zdenek
--
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 #4096: PG 8.3.1. confused about remaining disk space
[EMAIL PROTECTED] napsal(a): I ran today a legacy application with PG 8.3.1 on a test machine. The DB is some ~30 MB. Default tables do have OIDs and BLCKSZ is set system-wide to 16384 (because of another DB). Can you tried your application with standard BLKSZ? Or Can you send testcase? A lot of messages like these do appear wich tend to indicate PG 8.3.1 is confused. This set of SQL scripts used to run from PG 7.0.3 to PG 8.2.6 with no problem. What was BLCKSZ on these servers? WARNING: could not create relation-cache initialization file "base/19693/pg_internal.init.29329": No space left on device DETAIL: Continuing anyway, but there's something wrong. create temp table param0 (max0 date, datelb date) : ERROR: could not create relation 1663/19693/634161: No space left on device row number 0 is out of range 0..-1 row number 0 is out of range 0..-1 WARNING: could not create relation-cache initialization file "base/19693/pg_internal.init.29330": No space left on device DETAIL: Continuing anyway, but there's something wrong. create temp table param0 (max0 date, datelb date) : ERROR: could not create relation 1663/19693/634162: No space left on device row number 0 is out of range 0..-1 row number 0 is out of range 0..-1 Disk saturation, you think ? No at all, as in the meantime : FilesystemSize Used Avail Use% Mounted on /dev/sda3 9.9G 8.5G 874M 91% / udev 125M 88K 125M 1% /dev /dev/sda1 54M 15M 37M 29% /boot /dev/sda4 8.3G 7.4G 966M 89% /home /dev/sdb1 38G 31G 7.2G 81% /var/lib/pgsql As you can see, there is some 200 times the active DB size that remains available. User quota or super user space reservation could take affect. Could you create file as a postgres user on pgsql filesystem? Zdenek -- 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 #4084: Some DST timezones switche to summer time (one week) later
Premysl Paska napsal(a): The following bug has been logged online: Bug reference: 4084 Logged by: Premysl Paska Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.15 Operating system: Linux Description:Some DST timezones switche to summer time (one week) later Details: We use TIMESTAPM WITH TIMEZONE to insert datetime values into our DB. The problem is with the CEST timezone (Central European Summer Time; Prague) and possibly some others. The summer time started on 2008-03-30 02:00 in the CEST timezone shifting offset with respect to UTC from +1 to +2. But PostgreSQL kept inserting with the former +1 offset after this day. We tested it for various other dates and realized that it switches to the summer time one week later (2008-04-06). Do you use system timezone for PostgreSQL or do you use postgres timezone file? But anyway there was not any change in CET timezone for a long time. The same problem was reported with a North American timezone. (BTW we have another problem with TZ, after we change TZ in the system, we must restart Postgres to apply it also to the DB.) Yes, PostgreSQL caches TZ data, however any others application in system could be confused too when you update TZ data as well. Zdenek -- 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 #4068: Failed to compile 8.3.1
Ronald Kuczek napsal(a): The following bug has been logged online: Bug reference: 4068 Logged by: Ronald Kuczek Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.1 Operating system: Open SuSE 10.3 Description:Failed to compile 8.3.1 Details: Compilation from sources failed with error message: make[3]: Entering directory `/usr/src/postgres/postgresql-8.3.1/src/backend/utils/mb/conversion_procs/ut f8_and_shift_jis_2004' make[3]: *** No rule to make target `utf8_and_shift_jis_2004.o', needed by `libutf8_and_shift_jis_2004.so.0.0'. Stop. make[3]: Leaving directory `/usr/src/postgres/postgresql-8.3.1/src/backend/utils/mb/conversion_procs/ut f8_and_shift_jis_2004' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/src/postgres/postgresql-8.3.1/src/backend/utils/mb/conversion_procs' make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/src/postgres/postgresql-8.3.1/src' make: *** [all] Error 2 Please, could you send a configure setup and gcc version could be useful as well. Zdenek -- 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 #3991: pgsql function sum()
I think it is main problem. Try select sum(cast(33.08 as float) - cast(36.09 as float)); you get sum --- -3.010001 Better is to use numeric type if you don't have reason to use float/double. See http://www.postgresql.org/docs/8.3/static/datatype-numeric.html#DATATYPE-FLOAT It describes your problem. Zdenek Mirosław Marek napsal(a): wv and wb are defined as double precision Mirek Zdenek Kotala pisze: mirek napsal(a): The following bug has been logged online: Bug reference: 3991 Logged by: mirek Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.4 Operating system: Linux fedora(for work) and windows(for development) Description:pgsql function sum() Details: I saw a very strange behavior when i used function SUM() in query (used inside pg function), query: select magazyn, ciag, numer, datawp, vat, sum(wnetto-wnettop) as wn, sum(wvat-wvatp) as wv, sum(wbrutto-wbruttop) as wb from vzk_pozycjezinfo where magazyn = $1 and ciag = $2 and numer = $3 and datawp = $4 group by magazyn, ciag, numer, datawp, vat order by magazyn, ciag, numer, datawp, vat vzk_pozycjezinfo is view problem is in: sum(wvat-wvatp) where field in view wvat = 33.08 and wvatp = 36.09 Result is -3.010001 If I ask postgres manualy: select sum(33.08 - 36.09) result is ok -3.01 Now I fix it with round function but i think that is a bug. How are wv and wb attribute defined? Are they number or flout/double? Zdenek __ NOD32 Informacje 2903 (20080226) __ Wiadomosc zostala sprawdzona przez System Antywirusowy NOD32 http://www.nod32.com lub http://www.nod32.pl ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #3991: pgsql function sum()
mirek napsal(a): The following bug has been logged online: Bug reference: 3991 Logged by: mirek Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.4 Operating system: Linux fedora(for work) and windows(for development) Description:pgsql function sum() Details: I saw a very strange behavior when i used function SUM() in query (used inside pg function), query: select magazyn, ciag, numer, datawp, vat, sum(wnetto-wnettop) as wn, sum(wvat-wvatp) as wv, sum(wbrutto-wbruttop) as wb from vzk_pozycjezinfo where magazyn = $1 and ciag = $2 and numer = $3 and datawp = $4 group by magazyn, ciag, numer, datawp, vat order by magazyn, ciag, numer, datawp, vat vzk_pozycjezinfo is view problem is in: sum(wvat-wvatp) where field in view wvat = 33.08 and wvatp = 36.09 Result is -3.010001 If I ask postgres manualy: select sum(33.08 - 36.09) result is ok -3.01 Now I fix it with round function but i think that is a bug. How are wv and wb attribute defined? Are they number or flout/double? Zdenek ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] Bug (#3484) - Missing pg_clog/0AE6
Alexandra Nitzschke napsal(a): We went on with analyzing: - the table was created at 2008/01/03 17:56h - the nightly dump started at 2008/01/03 22:00h - it tried to copy the table 'adresse_080103' at 22:00:08 - the dump crashed at 22:32:10 ( because of the error we reported 2007/12/14; we repaired the database not till 2008/01/11 ) The stat of the database file returns this: File: "/postgres/database/data/base/23144/211593798" Size: 1835008 Blocks: 3592 IO Block: 4096 reguläre Datei Device: 811h/2065d Inode: 18121638Links: 1 Access: (0600/-rw---) Uid: ( 1001/postgres) Gid: (2/ daemon) Access: 2008-02-15 18:19:44.0 +0100 Modify: 2008-01-03 22:00:34.0 +0100 Change: 2008-01-03 22:00:34.0 +0100 We are wondering, that the pg_dump seems to have modified the file. Could you please answer, if the pg_dump modifies the access timestamp in some cases? Just a idea that pg_dump invoked checkpoint but I don't expect that table data spent four hour in a buffer cache. Especially in case when max checkpoint_timeout is one hour. Zdenek ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] Bug (#3484) - Missing pg_clog/0AE6
Alexandra Nitzschke napsal(a): Hi, we retrieved again a database error: pg_dump: Error message from server: ERROR: could not access status of transaction 2926020847 DETAIL: Could not open file "pg_clog/0AE6": Datei oder Verzeichnis nicht gefunden. pg_dump: The command was: COPY public.adresse_080103 (id, adr_id, adt_id, name_1, name_2, name_3, land, plz, stadt, telefon, fax, kurznam e, strasse, wga_id, steuer_nr, report_flags, zahlziel, email, aenderung_ts, aenderung_uid, name_1_old) TO stdout; It occured on the same system the last error was thrown. After the last error in December, we have updated postgres with the patch provided by Zdenek Kotala. We have had a look at the log files if an error message was written by the catch-blocks of this patch. But we haven't found any. My patch only add page header control before write. It cannot catch this problem, because tuple header is damaged in this case. However if following block in a table has damaged header, then problem is not in PostgreSQL itself. Can you run command: SELECT tid FROM public.adresse_080103 to determine where is start of corruption? And after verify next block. Or you can try pg_check (if it is not production system). Robert uploaded latest version two weeks ago. We are wondering about the table that is concerned by the error. It's just a backup from the original table "adresse" and was created at 2008/01/03. Since that time it wasn't used in any case, just by the nightly vacuum and the nightly pg_dump. If there is not any modification from the creation I don't expect that vacuum modified this table after initial cleanup (first day). We have had an error with missing pg_clog-files some months ago, but at that time we used postgres version 8.1.3. By now we are using 8.2.4. It really seems as bugy HW, driver or kernel. Do you use same HW/SW configuration as before? Is it possible to fix the problem by creating the missing file containing only zeros? I read about this on the internet. It should work. But you lost affected tuple/row which is probably damaged anyway. Because the table ist not needed any more, we could experiment to fix the error in this way. If its not possible I will drop the table. But it would be nice to find out the problem and not to run into the same problem on an essential table. Can you compare damaged block with previous occurrence? I also read on the internet that there are problems with pg_clog when the database template1 ist not vaccumed regularly. I think it was fixed in 8.1.7. Zdenek ---(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] BUG #3941: Insert Error
gnp yadav wrote: The following bug has been logged online: Bug reference: 3941 Logged by: gnp yadav Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1 Operating system: Ubuntu Linux Description:Insert Error Details: CREATE TABLE sentence ( sentence_id serial NOT NULL, citation_id int8 NOT NULL, sen_offset int8 NOT NULL, sen_length int8 NOT NULL, sen_type varchar(10)[] NOT NULL, CONSTRAINT sentence_id PRIMARY KEY (sentence_id), CONSTRAINT citation_id FOREIGN KEY (sentence_id) REFERENCES citation (citation_id) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION ) ; INSERT INTO sentence (sentence_id, citation_id, sen_offset, sen_length, sen_type) VALUES (NULL,1,2,3,asd"); use ' instead of ". INSERT INTO sentence (sentence_id, citation_id, sen_offset, sen_length, sen_type) VALUES (NULL,1,2,3,'asd'); Please, next time send this question to -general or -novice lists. These lists are dedicated for this kind of question. -bug list is about serious bug report. Zdenek ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #3913: pg_dump -T option not recognised
Hmm, strange. Can you reproduce it on different machine/system? It seems more problem with getopt in your installation. Check if you have installed updated version of (g)libc. Zdenek David Dunwoody wrote: Checked several times, and I was working in a pair, so I have a witness. :) It is, of course, possible that it's peculiar to something during the compile on my machine, but I've reproduced this on a clean install from source (./configure && make && make install). Seems remarkable that it really is a bug, as I find it hard to believe I'm the first person to use the short opt, but thought it best to report it! Cheers, David On 30/01/2008, *Zdenek Kotala* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: David Dunwoody wrote: > The following bug has been logged online: > > Bug reference: 3913 > Logged by: David Dunwoody > Email address: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > PostgreSQL version: 8.2.6 > Operating system: SuSE 8.2.6 > Description:pg_dump -T option not recognised > Details: > > When running pg_dump, the -T option for table exclusion is ignored, but > --exclude-table does work. > > Compiled from source. It works for me. Can you recheck it again? Zdenek ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #3913: pg_dump -T option not recognised
David Dunwoody wrote: The following bug has been logged online: Bug reference: 3913 Logged by: David Dunwoody Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.6 Operating system: SuSE 8.2.6 Description:pg_dump -T option not recognised Details: When running pg_dump, the -T option for table exclusion is ignored, but --exclude-table does work. Compiled from source. It works for me. Can you recheck it again? Zdenek ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] Bug (#3484) - Invalid page header again
Gregory Stark wrote: "Zdenek Kotala" <[EMAIL PROTECTED]> writes: I got dump of affected two blocks from Alex and it seems that both blocks were overwritten together with some 128bytes length structure (there some pattern) and complete damaged size is 9728bytes (first block is overwritten completely and second one only at the beginning), but another buffer from another relation could be overwritten too. I don't understand this 9728 bytes. Postgres blocks are 8192 bytes. Are you saying one whole block is trashed and then part, but not all, of the next block? What's the block size of the ZFS filesystem? And what exactly does the trash data look like? ZFS has dynamic block size (max 128kB), but this system runs on Linux probably ext3 FS. Please, ale can you confirm used filesystem? Zdenek ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] Bug (#3484) - Invalid page header again
Zdenek Kotala wrote: Zdenek Kotala wrote: I got dump of affected two blocks from Alex and it seems that both blocks were overwritten together with some 128bytes length structure (there some pattern) and complete damaged size is 9728bytes (first block is overwritten completely and second one only at the beginning), but another buffer from another relation could be overwritten too. I'm sorry, It is 129 length (do not trust ghex2 :( ) and probably size of damaged data is about 9728bytes. Zdenek ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] Bug (#3484) - Invalid page header again
Zdenek Kotala wrote: alex wrote: WARNING: relation "transaktion" TID 1240631/12: OID is invalid ERROR: invalid page header in block 1240632 of relation "transaktion" 7. 2007/12/10 : We started the export of the data ( which runs every morning ) for the last days again. These exports use the same SQL-Commands as the automatical run. Alex, please can you provide binary dump of these two pages or if there are sensitive data try to use pg_filedump to get only page and tuple headers? I got dump of affected two blocks from Alex and it seems that both blocks were overwritten together with some 128bytes length structure (there some pattern) and complete damaged size is 9728bytes (first block is overwritten completely and second one only at the beginning), but another buffer from another relation could be overwritten too. I think it is more software bug than hardware, because bad data contains some logic. There is x54 byte which is repeated after each 128 bytes and so on and most data are zeros. My suggestion is apply following patch to catch if data are corrupted by postgreSQL or elsewhere. It should be failed before writing damaged data to the disk. It is for HEAD but similar patch could be backported. Index: backend/storage/buffer/bufmgr.c === RCS file: /zfs_data/cvs_pgsql/cvsroot/pgsql/src/backend/storage/buffer/bufmgr.c,v retrieving revision 1.227 diff -c -r1.227 bufmgr.c *** backend/storage/buffer/bufmgr.c 15 Nov 2007 21:14:37 - 1.227 --- backend/storage/buffer/bufmgr.c 18 Dec 2007 15:50:06 - *** *** 1734,1739 --- 1734,1741 buf->flags &= ~BM_JUST_DIRTIED; UnlockBufHdr(buf); + if (!PageHeaderIsValid((PageHeader) BufHdrGetBlock(buf))) + elog(FATAL, "Buffer cache is damaged!"); smgrwrite(reln, buf->tag.blockNum, (char *) BufHdrGetBlock(buf), *** *** 1966,1971 --- 1968,1976 errcontext.previous = error_context_stack; error_context_stack = &errcontext; + if (!PageHeaderIsValid((PageHeader) BufHdrGetBlock(bufHdr))) + elog(FATAL, "Buffer cache is damaged!"); + smgrwrite(rel->rd_smgr, bufHdr->tag.blockNum, (char *) LocalBufHdrGetBlock(bufHdr), Index: backend/storage/buffer/localbuf.c === RCS file: /zfs_data/cvs_pgsql/cvsroot/pgsql/src/backend/storage/buffer/localbuf.c,v retrieving revision 1.78 diff -c -r1.78 localbuf.c *** backend/storage/buffer/localbuf.c 15 Nov 2007 21:14:38 - 1.78 --- backend/storage/buffer/localbuf.c 18 Dec 2007 16:05:49 - *** *** 16,21 --- 16,22 #include "postgres.h" #include "storage/buf_internals.h" + #include"storage/bufpage.h" #include "storage/bufmgr.h" #include "storage/smgr.h" #include "utils/guc.h" *** *** 161,166 --- 162,169 oreln = smgropen(bufHdr->tag.rnode); /* And write... */ + if (!PageHeaderIsValid((PageHeader) LocalBufHdrGetBlock(bufHdr))) + elog(FATAL, "Local buffer cache is damaged!"); smgrwrite(oreln, bufHdr->tag.blockNum, (char *) LocalBufHdrGetBlock(bufHdr), ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] Bug (#3484) - Invalid page header again
alex wrote: WARNING: relation "transaktion" TID 1240631/12: OID is invalid ERROR: invalid page header in block 1240632 of relation "transaktion" 7. 2007/12/10 : We started the export of the data ( which runs every morning ) for the last days again. These exports use the same SQL-Commands as the automatical run. Alex, please can you provide binary dump of these two pages or if there are sensitive data try to use pg_filedump to get only page and tuple headers? Zdenek ---(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] BUG #3763: crash after create table with primary keydefined
[EMAIL PROTECTED] wrote: I cant get core file now. Can you recompile it as Heikki suggested? It seems more like compiler bug and without core file/stack trace we are not able say more. Zdenek ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #3763: crash after create table with primary keydefined
[EMAIL PROTECTED] wrote: Dnia Wt Listopada 20 2007, 14:20, Simon Riggs napisał(a): On Tue, 2007-11-20 at 11:46 +, Heikki Linnakangas wrote: In logs after this: Nov 20 11:02:04 www postgres[32757]: [4-1] wolni>NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "phpbb_acl_roles_data_pkey" for table Nov 20 11:02:04 www postgres[32731]: [2-1] >LOG: server process (PID 32757) was terminated by signal 11 To me it does look like it was the CREATE TABLE that crashed. The NOTICE shows that it's process ID 32757 that's running the CREATE TABLE, and the LOG line later on says that that's the process that crashed. Yep, agreed. :-( OK so what we can do now? Do you have core file? It is usually stored in data postgreSQL directory. Can you provide stack trace to determine which function fails? It is very important. what's happen when you create primary key by alter table command? what's happen when you create unique index on (role_id, auth_option_id)? Is it fresh database? Can you reproduce it on the same machine with the same postgreSQL installation on new created database cluster? Zdenek ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #3752: query yields "could not find block containing chunk", then server crashes
Michael Charnoky wrote: 2007-11-15 15:38:03.880 PST: ERROR: could not find block containing chunk 0x902fb98 This message appears in AllocSetFree or AllocSetRealloc function in aset.c source. In both function it means that defined context does not contain memory block. By my opinion there should be two more probable scenarios: 1) memory block does not exist -> for AllocSetFree it means e.g. double free or for AllocSetRealloc it means that somebody want to realloc memory which was already freed. 2) memory is still allocated but in different context. However, palloc and pfree should control it. By my opinion it is double free problem, but without stack trace or reproduction scenario it is difficult to find it. Zdenek ---(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] BUG #3754: postgresql+hibernate
RaviKumar.kapa wrote: The following bug has been logged online: Bug reference: 3754 Logged by: RaviKumar.kapa Email address: [EMAIL PROTECTED] PostgreSQL version: 7.1 Operating system: Windows2000 Description:postgresql+hibernate Details: I have the dought.i.e can I Use hibernate to connect postgresql in my struts applications. is it safe technique? it's work fine(postgresql)? postgreqs work fine with hibernate? Please, this is a bug reporting list. If you want to ask this kind of question use general or novice mailing list in the future. However answer is yes, hibernate supports postgreSQL and works fine. Zdenek ---(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] BUG #3752: query yields "could not find block containing chunk", then server crashes
Do you have a core file? Can you provide stack trace output? Thanks Michael Charnoky wrote: The following bug has been logged online: Bug reference: 3752 Logged by: Michael Charnoky Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3beta2 Operating system: Linux (Fedora Core 3) 2.6.17 Description:query yields "could not find block containing chunk", then server crashes Details: I installed PG8.3beta2 and created a db instance using pg_restore. (The dump was created using the pg8.3beta2 pg_dump util, from a db on a pg8.1 server). Data restored with no errors, later our app encountered an sql error while querying data in the db. Here's the relevant log snippet: 2007-11-15 15:38:03.880 PST: ERROR: could not find block containing chunk 0x902fb98 2007-11-15 15:38:03.880 PST: STATEMENT: SELECT path_tag, dayset_tag, time2secs(ts_endtime), segtimes FROM pathtimes where rev=(select rev from projects) ORDER BY time2secs(ts_endtime); 2007-11-15 15:38:29.821 PST: LOG: server process (PID 1) was terminated by signal 11: Segmentation fault 2007-11-15 15:38:29.821 PST: LOG: terminating any other active server processes 2007-11-15 15:38:29.825 PST: LOG: all server processes terminated; reinitializing 2007-11-15 15:38:29.887 PST: LOG: database system was interrupted; last known up at 2007-11-15 15:28:27 PST 2007-11-15 15:38:29.887 PST: LOG: database system was not properly shut down; automatic recovery in progress 2007-11-15 15:38:30.044 PST: FATAL: the database system is in recovery mode 2007-11-15 15:38:30.285 PST: LOG: record with zero length at 0/7CB47A08 2007-11-15 15:38:30.286 PST: LOG: redo is not required 2007-11-15 15:38:30.714 PST: LOG: autovacuum launcher started 2007-11-15 15:38:30.715 PST: LOG: database system is ready to accept connections *** glibc detected *** free(): invalid next size (normal): 0x09045378 *** 2007-11-15 15:38:41.463 PST: LOG: server process (PID 17811) was terminated by signal 6: Aborted 2007-11-15 15:38:41.463 PST: LOG: terminating any other active server processes 2007-11-15 15:38:41.464 PST: LOG: all server processes terminated; reinitializing 2007-11-15 15:38:41.516 PST: LOG: database system was interrupted; last known up at 2007-11-15 15:38:30 PST 2007-11-15 15:38:41.516 PST: LOG: database system was not properly shut down; automatic recovery in progress 2007-11-15 15:38:41.683 PST: LOG: record with zero length at 0/7CB47A48 2007-11-15 15:38:41.683 PST: LOG: redo is not required 2007-11-15 15:38:41.702 PST: FATAL: the database system is in recovery mode 2007-11-15 15:38:41.806 PST: LOG: autovacuum launcher started 2007-11-15 15:38:41.807 PST: LOG: database system is ready to accept connections ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #3713: problem with thread safety???
Tom Lane napsal(a): So somehow src/test/thread/thread_test.c is missing from your source tree. The only reason I've seen for that happening is when people thought that they could download just the "base" tarball and not the whole source distribution. I found this problem as well when I verified BUG3728. I think it is problem with packaging, base should be compiled without any other parts. If it is not possible that I don't see any reason to have and distribute this tarball. Zdenek ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #3728: pthread autoconf hangs
heasley wrote: Thu, Nov 08, 2007 at 11:04:01AM +0100, Zdenek Kotala: heasley napsal(a): The configure is via NetBSD's pkgsrc system. ./configure --sysconfdir=/usr/pkg/etc/postgresql --datadir=/usr/pkg/share/po stgresql --with-docdir=/usr/pkg/share/doc/postgresql --with-template=solaris --w ithout-readline --without-zlib --enable-nls --without-java --without-perl --with out-python --without-tcl --with-openssl --with-readline --with-zlib --enable-thr ead-safety --with-libiconv-prefix=/usr/pkg --with-libintl-prefix=/usr/pkg --pref ix=/usr/pkg --host=sparc-sun-solaris2 --mandir=/usr/pkg/man It is really strange configure. See --with-readline/--without-readline. Unfrotunately I currently does not have system with S9 similar to yours configuration :(. I tested Sun Studio compiler with following configure switch ./configure --without-readline --enable-thread-safety and it works fine. Can you try Sun studio? http://developers.sun.com/sunstudio/downloads/thankyou.jsp?submit=%A0FREE+Download%A0%BB%A0 from config.log: CFLAGS=-g -static-libgcc -static-libgcc -D_LARGEFILE64_SOURCE -mcpu=v9 -mtune=ultrasparc -m64 -D__sparc_v9__ -pipe -I/usr/pkg/include -I/usr/include -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing Can you try build it as 32bit application? If there is not problem with 64bit libraries. www.shrubbery.net/~heas/pg_config.log.txt www.shrubbery.net/~heas/conftest.c.txt I built gcc 4.1, after having some difficulty with other versions. It is a fairly straight forward build, expect that it has a hack to avoid a libiconv bug and is within a wrapper script that forces 64-bit options. I did not have this problem with pre-8.1.5 postgres as I recall; 8.1.4 built fine and I do not believe there have been any pkgsrc changes that would affect this. I don't see any difference in ./configure related to pthread. Do you use same process for building? Do you have same version of all libraries, GCC or did you update some version? Can you compile 8.1.4 with same configuration? It seems to me that it could be something wrong with your GCC compilation. Zdenek ---(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] BUG #3728: pthread autoconf hangs
heasley napsal(a):
The following bug has been logged online:
Bug reference: 3728
Logged by: heasley
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.10
Operating system: sparc-sun-solaris2.9 gcc-4.1.1
Description:pthread autoconf hangs
Details:
If the autoconf script ends-up with a CFLAGS that includes pthreads knobs,
for example -DREENTRANT, it will try to find pthread_join() without linking
in libpthread (ie: without gcc -pthread). The result is a conftest that
hangs because it has some half-baked stub for (among others)
pthread_create() that does nothing and thus it spins waiting for the
thread{1,2}_done variables to be set by a threads that do not exist.
squashing the result of the first check in config/acx_pthread.m4 allows it
find the proper results.
Sorry, I do not know the proper fix given all the platforms that need to
coexist.
Please, can you provide ./configure cmd line and CFLAGS and other related
setting? Also some error output could help. Another question is gcc 4.1 is not
in Solaris 9. How did you install this version?
Zdenek
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #3567: invalid page header in block XXXXof relation
Tom Lane wrote: "sapna kapoor" <[EMAIL PROTECTED]> writes: some tables are giving error : ERROR: invalid page header in block 32655 of relation "" while accessing. Some are giving ERROR: could not access status of transaction 1778384896 DETAIL: could not open file "pg_clog/06A0": No such file or directory If you had just one of these, I might think it suggested a software problem. The similar clog problem was reported there http://archives.postgresql.org/pgsql-bugs/2007-07/msg00124.php. It looks like vacuum truncate clog file but, some tuples still have xmin or xmax from truncated clog. Sapna, can You try following http://pgfoundry.org/projects/pgcheck/ project. It is still in alpha, but page check (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgcheck/pokus/pgcheck_page/) should be work. Zdenek ---(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] Having trouble building 64-bit pgsql 7.4.17 on HPUX ia64
It seems that TAS(mutex) is not supported. Try to compile with --disable-spinlocks, but performance will not be good. I'm not sure if this file is in 7.4 version, but see pgsql/src/backend/port/hpux/tas.c.template Zdenek Rajaram J wrote: Hi I'm having trouble building 64-bit pgsql 7.4.17 on the latest release of HP-UX 11.23 on ia64. Here's my compiler: cc: HP C/aC++ B3910B A.06.15 [May 16 2007] Here's my error: /opt/ansic/bin/cc -Ae +O2 -L../../src/port -Wl,+nodefaultrpath -L/usr/lib -L/opt/openssl/lib -Wl,+b -Wl,/opt/rajaram/postgresql/lib -Wl,-z -Wl,-E access/SUBSYS.o bootstrap/SUBSYS.o catalog/SUBSYS.o parser/SUBSYS.o commands/SUBSYS.o executor/SUBSYS.o lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o nodes/SUBSYS.o optimizer/SUBSYS.o port/SUBSYS.o postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUBSYS.o storage/SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o -lc -lssl -lcrypto -lgen -ldld -lnsl -ldl -lm -lkrb5 -lk5crypto -lcom_err -lpgport -o postgres ld: Unsatisfied symbol "tas" in file access/SUBSYS.o 1 errors. gmake[2]: *** [postgres] Error 1 gmake[2]: *** Deleting file `postgres' gmake[2]: Leaving directory `/postgresql/postgresql-7.4.17/src/backend' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/postgresql/postgresql-7.4.17/src' gmake: *** [all] Error 2 hpdst156 B.11.23 64_bit >cc v cc: warning 1913: `v' does not exist or cannot be read ld: I/O error, file "v": No such file or directory Fatal error. Could anyone please advise on how to make 7.4.17 build here? Regards Rajaram J ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] REVOKE CREATE does not work on default tablespace
Tom Lane wrote: Zdenek Kotala <[EMAIL PROTECTED]> writes: Tom Lane wrote: It's presumed that the right to create tables within a database entails the right to create them someplace; hence no permissions check is made on the database's default tablespace. Without that, not only does plain CREATE TABLE fail (including CREATE TEMP TABLE), but any query complex enough to require a temporary file would fail as well. So you'd pretty much have to grant rights on the tablespace to every user of the database anyway. If only temporary objects are problem I think better solution is to create pg_temp tablespace which will be used as default for temporary data Why are you so eager to make CREATE TABLE fail? (If you really want to do that there are other ways, for instance revoking create privilege within the DB.) I expect it if I revoke rights to do it. This behavior is non documented (I did not find it in documentation) and it is also exception of ACL behavior. If you forgot to revoke create rights on public schema normal user is able to inject own table and override another in different schema during search_path evaluation (see for example security definer issue). I also expect when I use tablespace name in command which is same as default tablespace I get same result. I still does not see any benefit from user side why postgres has this exception. It is confusing and it should generate potential security risk. By the way, there is also strange behavior when for example you want to create table with primary key. Index is stored in default tablespace instead of same as table has. Once you've created a database with a given tablespace as default, the only way to make it stop using the tablespace is to drop the whole DB; there are no half measures because you can't move the system catalogs (particularly not pg_class). So I'm not seeing the point of enforcing tablespace usage against users of the database rather than at the time of DB creation. I don't want to stop usage the default tablespace, I'm only want to stop user create there new tables. Zdenek ---(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] REVOKE CREATE does not work on default tablespace
Tom Lane wrote: Zdenek Kotala <[EMAIL PROTECTED]> writes: Tom Lane wrote: Zdenek Kotala <[EMAIL PROTECTED]> writes: It seems that we not able to revoke create privilege on default tablespace. This is intentional. I don't understand why. It's presumed that the right to create tables within a database entails the right to create them someplace; hence no permissions check is made on the database's default tablespace. Without that, not only does plain CREATE TABLE fail (including CREATE TEMP TABLE), but any query complex enough to require a temporary file would fail as well. So you'd pretty much have to grant rights on the tablespace to every user of the database anyway. If only temporary objects are problem I think better solution is to create pg_temp tablespace which will be used as default for temporary data (if temp_tablespaces is not set) and this table space will have create rights for everyone. It should be stored in separate directory (e.g. data/pg_temp). Maybe add temp flag to tablespace should make sense - It will mean that only temporary object can be created in this tablespace. Zdenek ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] REVOKE CREATE does not work on default tablespace
Tom Lane wrote: Zdenek Kotala <[EMAIL PROTECTED]> writes: It seems that we not able to revoke create privilege on default tablespace. This is intentional. I don't understand why. I did not find any mention about this in the documentation. Please, could you explain it? Thanks Zdenek ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[BUGS] REVOKE CREATE does not work on default tablespace
I try to revoke create privileges (PG8.2.4) on the default tablespace and I found following strange behavior: As superuser: revoke create on TABLESPACE pg_default from u_test1; As u_test1: ns_test=> create table test_06 (id int) tablespace pg_default; ERROR: permission denied for tablespace pg_default ns_test=> create table test_06 (id int); CREATE TABLE ns_test=> select relname, reltablespace from pg_class where relname like '%test_06%'; relname| reltablespace --+--- test_06 | 0 ns_test=# select oid,spcname from pg_tablespace; oid | spcname ---+ 1664 | pg_global 24585 | ts_test 1663 | pg_default -- It seems that we not able to revoke create privilege on default tablespace. I think the main problem is that pg_default has OID=1663, but all objects in this tablespace have reltablespace=0. Is there reason why 0 is used instead of correct oid? Zdenek ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #3403: ver 8.2 can't add serial column to temp table,but 8.1 can
Zdenek Kotala wrote: I looked on it, but I think let parser to fill namespace information in ctx->relation structure should be better then do it in this place. There is also unfilled istemp flag. Ignore this. It is good place. However, I think add following function into namespace.c should be nicer solution. Oid RelnameGetSchemaid(const char *relname); See RelnameGetRelid. You can use snamespaceid = RelnameGetSchemaid(cxt->relation->relname); instead of snamespaceid = RangeVarGetCreationNamespace(cxt->relation); Zdenek ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #3403: ver 8.2 can't add serial column to temp table,but 8.1 can
Heikki Linnakangas wrote: Zdenek Kotala wrote: Jasen Betts wrote: template1=# create temp table foo ( x text); CREATE TABLE template1=# alter table foo add column y text ; ALTER TABLE template1=# alter table foo add column id serial; NOTICE: ALTER TABLE will create implicit sequence "foo_id_seq" for serial colum n "foo.id" ERROR: relation "public.foo" does not exist template1=# It does not work on 8.2.4 as well. It seems PG lost information about schema and try to use default schema. Following command works well: alter table pg_temp.foo add column id serial; It could be use as workaround. 8.1 creates the sequence in wrong schema: postgres=# create temp table foo ( x text); CREATE TABLE postgres=# alter table foo add column id serial; NOTICE: ALTER TABLE will create implicit sequence "foo_id_seq" for serial column "foo.id" ALTER TABLE postgres=# \d List of relations Schema |Name| Type | Owner ---++--+-- pg_temp_1 | foo| table| hlinnaka public| foo_id_seq | sequence | hlinnaka (2 rows) The problem seems to be in transformColumnDefinition, where the schema of the to-be-created sequence is determined from the relation name given. The default creation schema is used, if the user didn't specify the schame of the table explicitly, but since it's an ALTER TABLE, it really should use the schema of the existing table. Correct. Patch against 8.2 attached, seems to apply to 8.1 and CVS head though I haven't tested them.. This is not my area of expertise, so I'm not 100% sure this is the right way to fix it. I looked on it, but I think let parser to fill namespace information in ctx->relation structure should be better then do it in this place. There is also unfilled istemp flag. Zdenek ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #3403: ver 8.2 can't add serial column to temp table,but 8.1 can
Jasen Betts wrote: The following bug has been logged online: Bug reference: 3403 Logged by: Jasen Betts Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.0 Operating system: window XP (vmware) Description:ver 8.2 can't add serial column to temp table,but 8.1 can Details: gymmaster=# select version(); version -- PostgreSQL 8.2.0 on i686-pc-mingw32, compiled by GCC cc.exe (GCC) 3.4.2 (mingw-special) (1 row) template1=# create temp table foo ( x text); CREATE TABLE template1=# alter table foo add column y text ; ALTER TABLE template1=# alter table foo add column id serial; NOTICE: ALTER TABLE will create implicit sequence "foo_id_seq" for serial colum n "foo.id" ERROR: relation "public.foo" does not exist template1=# It does not work on 8.2.4 as well. It seems PG lost information about schema and try to use default schema. Following command works well: alter table pg_temp.foo add column id serial; It could be use as workaround. Zdenek ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #3397: change the pg_setting
Murali Doss napsal(a): The following bug has been logged online: Bug reference: 3397 Logged by: Murali Doss Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.8 Operating system: Linux Description:change the pg_setting Details: Dear All, How to change the pg_setting from en_US.UTF-8 to "C". lc_collate - en_US.UTF-8 lc_ctype- en_US.UTF-8 lc_messages - en_US.UTF-8 lc_monetary - en_US.UTF-8 lc_numeric - en_US.UTF-8 lc_time - en_US.UTF-8 Lc_collate and lc_ctype are possible setup only in initdb phase. see initdb --help or http://www.postgresql.org/docs/8.2/interactive/app-initdb.html More detail you can get on http://www.postgresql.org/docs/8.2/interactive/locale.html Please, this kind of question send to the general mailing list. This list is for bug reporting. Thanks Zdenek ---(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] BUG #3394: Partial search not working
Murali Doss wrote: Hi Michael, Same database dump is there Solaris, Windows and Linux and the partial search query is displaying the expected results in Solaris and Windows OS but the query returning 0 row in Linux OS. SELECT * FROM tablename WHERE colname BETWEEN 'B' AND 'B~'; Any query to find the local settings and encoding. Try SELECT name, setting FROM pg_settings WHERE name LIKE 'lc_%'; The psql -l command shows you database encoding. Client and server encoding is possible get by the following commands: SHOW client_encoding and SHOW server_encoding Zdenek ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #3394: Partial search not working
Murali Doss wrote: The following bug has been logged online: Bug reference: 3394 Logged by: Murali Doss Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.4 Operating system: Linux Description:Partial search not working Details: Dear All, Partial search query is not working Linux OS with postgresql 8.2.4 but the same is working fine in windows and solaris OS. I don't think that it depends on OS. What is difference between working and not working search? I like to know whether i need to run some patch in linux OS to make the partial search to work. SELECT * FROM tablename WHERE colname BETWEEN 'B-' AND 'B~' ORDER BY colname Can you run EXPLAIN on your query and look if it is same on all OS? Zdenek ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] password auth woes on sparc64/FreeBSD
Volodymyr Kostyrko wrote: Zdenek Kotala wrote: I tested on Solaris AMD64 and Sparc v240 (64bit) and it works for me. Do you use 32bit or 64bit version of postgreSQL and what you have in .pgpass? I use sparc64 and my .pgpass file was like: localhost:5432:*:pgsql:password Actually i have already found the cause. Authorization fails when postgresql-client was compiled with -O3 but it works otherwise. Maybe it is just another gcc optimization issue. OK. Good to know. GCC also does not generate much optimal SPARC code. Unfortunately, If you use FreeBSD on SPARC, I think there is no another possibility (another C compiler). Zdenek ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] password auth woes on sparc64/FreeBSD
I tested on Solaris AMD64 and Sparc v240 (64bit) and it works for me. Do you use 32bit or 64bit version of postgreSQL and what you have in .pgpass? Zdenek Volodymyr Kostyrko wrote: It seems to me that auth on the local interface(?) is broken somehow on sparc64. [data/pg_hba.conf] local postgres,template1 all trust local postgres,template1 all md5 host postgres,template1 all 0.0.0.0/0 md5 host postgres,template1 all ::/0 md5 [--] Well, what I really want to do is to remove the trust line from config. But that way i need a .pgpass file so the server can start/control itself without asking me for password. And if i want .pgpass file i need some auth. [session transcript/same machine] > psql -U pgsql postgres Welcome to psql 8.2.4, 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=# alter role pgsql password 'somepass'; ALTER ROLE postgres=# \q > psql -h localhost -U pgsql postgres Password for user pgsql: psql: FATAL: password authentication failed for user "pgsql" [--] It fails for any user and any password. [session transcript/other machine] > psql -h blade -U pgsql postgres Password for user pgsql: Welcome to psql 8.2.4, 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=# [--] But I can log from another machine flawlessly... > uname -a FreeBSD blade.lan 6.2-STABLE FreeBSD 6.2-STABLE #13: Tue Jun 5 17:06:57 EEST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BLADE sparc64 PS: Can assist in debugging if someone would point me what and how. ---(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] BUG #3291: Query tool not returning all results
Todd Frankson wrote: I have not Tried PSQL. I use PG Admin. Forgive me as i am not familiar with Postgres as much as other databases. I open the Query tool from PGAdmin Type Select X from y Where Z I get back only a Portion of a field that is Defined as "text". In the PGAdmin, the Max. Return is set to 5000 Try to connent into database by psql command line tool e.g: psql mydatabase -U myaccount and perform same command. Check if you get the same result. Zdenek ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #3291: Query tool not returning all results
Todd Frankson wrote: When selecting From a Text field that has 4096 characters in it, the query tool only returns a few hundred characters, and exports maybe a hundred more characters than the result set. What happen if you do that in psql? Do you receive all data? And what tool do you use - pgAdmin? Zdenek ---(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] INSTALL appnote for Solaris 10...
John R Pierce wrote: I just built a version of postgres 8.2.4 on Solaris 10 x86 ... a few things that could be mentioned in INSTALL, and or in the Solaris notes Solaris.FAQ is best place for it. http://www.postgresql.org/docs/faqs.FAQ_Solaris.html Solaris has a `crle` command that performs a function similar to ldconfig of the BSD systems. To globally add libreadline and libsl to the library path, I used... crle -l /lib:/usr/lib:/opt/sfw/lib:/usr/sfw/lib if you only wanted to do this for a single user, then put the following in that user's profile, export LD_LIBRARY_PATH; LD_LIBRARY_PATH=/opt/sfw/lib:/usr/sfw/lib for compilation, set the path as.. export PATH; PATH=/usr/bin:/opt/SUNWspro/bin:/usr/sfw/bin:/usr/ccs/bin Better way is use -R linker switch: LDFLAGS="-R /opt/sfw/lib:/usr/sfw/lib" The contrib/start-scripts/freebsd worked adequately as /etc/init.d/postgres if I removed the -l from the `su` commands. On Solaris 10 SMF is recommended instead standard start stop scripts. You can get SMF script for example there: http://www.sun.com/software/solaris/howtoguides/postgresqlhowto.jsp#2 or http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/postgres/postgresql-8.2/Solaris/ Zdenek ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] PSQL support on HP-UX, Solaris and AIX
Sridhar Sourirajan wrote: Is PostgreSQL supported on these UNIX platforms. When I go to www.postgresql.org, I only see binary downloads for Linux and Win32. How about for these other flavors of Unix? Thank you! PostgreSQL is bundled with Solaris 10 (update 2 and newer). There also project on www.pgfoundry.org, but packages is not actual. You can also use some alternative source - www.sunfreeware.com or www.blastwave.org. If you look for pgAdmin community offers Solaris packages on their web page. Zdenek ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] potential integer overflow in md.c
Tom Lane wrote: Zdenek Kotala <[EMAIL PROTECTED]> writes: I found following expression in md.c: seekpos = (long) (BLCKSZ * (blocknum % ((BlockNumber) RELSEG_SIZE))); There's no percentage in touching that code unless you intend to enable the non-segmented behavior; which will probably need more fixes than just this. For non-segment code is following section: seekpos = (long) (BLCKSZ * (blocknum)); and FileSeek function also accept only 32bit offset. Zdenek ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] potential integer overflow in md.c
I found following expression in md.c: seekpos = (long) (BLCKSZ * (blocknum % ((BlockNumber) RELSEG_SIZE))); all variables and constants are int (32-bit) and long (also very often 32-bit). In case when somebody want to change RELSEG_SIZE to value related to 4GB and bigger chunk he can expect data overwriting. This seek problem is on more places, however in standard compilation chunk size is 1GB and this problem does not appear. I'm going to fix it. Zdenek ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [BUGS] BUG #2969: Inaccuracies in Solaris FAQ
Peter Eisentraut wrote: Zdenek Kotala wrote: There is Solaris FAQ update. Please, look on it and let me know any comments. The actual answer to the question "Can I compile PostgreSQL with Kerberos v5 support?" is "Yes, why not?". I don't think "Can I use this weird internal private library that seems to provide a similar interface?" is a "Frequently Asked Question". You have right that it is not frequent question, but my colleagues have bad experience with people who did it with samba server and it is only warning "don't do that" for people who want to try it. If you guess that it is not important, do not hesitate to remove it. Zdenek ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #2969: Inaccuracies in Solaris FAQ
There is Solaris FAQ update. Please, look on it and let me know any comments. Thanks Zdenek Rich Teer wrote: The following bug has been logged online: Bug reference: 2969 Logged by: Rich Teer Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.2 Operating system: Solaris 10 Description:Inaccuracies in Solaris FAQ Details: Hi there, First, many thanks for providing the best open source database! I've spotted a couple of errors/bits of bad advice in doc/FAQ_Solaris, which I think should be updated. 1. The answer to question 3 (Why does configure complain about a failed test program?) says to set LD_LIBRARY_PATH to point to the directory containing the missing libs. While this does work (as does the other suggestion of using LD_RUN_PATH), the correct answer to this question is to include the library's path in the executable by using the -R flag, thus avoiding the need for the end user to mess about with environment variables. For example, I use "LDFLAGS=-R/usr/sfw/lib ./configure ..." to build Postgres which uses Sun's OpenSSL. 2. The answer to question 8 (Can I use DTrace for tracing PostgreSQL?) says that Solaris 10u3 or newer is required to handle probes in static functions. Unfortunately, this is not the case. DTrace can't be enabled when using update 3 (aka 11/06); the (as yet unreleased) update 4 or newer is required. Thanks for reading! Rich Teer, Author of Solaris Systems Programming ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster Index: doc/FAQ_Solaris === RCS file: /projects/cvsroot/pgsql/doc/FAQ_Solaris,v retrieving revision 1.23 diff -c -r1.23 FAQ_Solaris *** doc/FAQ_Solaris 2 Dec 2006 09:29:51 - 1.23 --- doc/FAQ_Solaris 23 Feb 2007 16:12:19 - *** *** 16,21 --- 16,22 6) Where I can download prepared Solaris packages? 7) How can I tune PostgreSQL and Solaris for performance? 8) Can I use DTrace for tracing PostgreSQL? + 9) Can I compile PostgreSQL with Kerberos v5 support? 1) What tools do I need to build and install PostgreSQL on Solaris? *** *** 72,85 This is probably a case of the run-time linker being unable to find some library, probably libz, libreadline or some other non-standard library such as libssl. To point it to the right location, set the ! LD_LIBRARY_PATH environment variable, e.g., ! LD_LIBRARY_PATH=/usr/sfw/lib:/opt/sfw/lib:/usr/local/lib ! export LD_LIBRARY_PATH ! and restart configure. You will also have to keep this setting whenever ! you run any of the installed PostgreSQL programs. Alternatively, set ! the environment variable LD_RUN_PATH. See the ld(1) man page for more information. --- 73,84 This is probably a case of the run-time linker being unable to find some library, probably libz, libreadline or some other non-standard library such as libssl. To point it to the right location, set the ! LDFLAGS environment variable, e.g., ! LDFLAGS="-R /usr/sfw/lib:/opt/sfw/lib:/usr/local/lib" ! export LDFLAGS ! and restart configure. See the ld(1) man page for more information. *** *** 145,150 --- 144,153 Yes, see the chapter "Monitoring Database Activity" in the documentation for further information. + You can also find more information here: + + http://blogs.sun.com/robertlor/entry/user_level_dtrace_probes_in + If you see the linking of the postgres executable abort with an error message like *** *** 157,164 gmake: *** [postgres] Error 1 your DTrace installation is too old to handle probes in static ! functions. You need Solaris 10u3 or newer. - You can also find more information here: - - http://blogs.sun.com/robertlor/entry/user_level_dtrace_probes_in --- 160,176 gmake: *** [postgres] Error 1 your DTrace installation is too old to handle probes in static ! functions. You need Solaris 10u4 or newer. Workaround is remove static ! keyword from AbortTransaction and CommitTransaction functions declaration in ! src/backend/access/transam/xact.c. ! ! See http://sunsolve.sun.com/search/document.do?assetkey=1-1-2139224-1 ! (registration required). ! ! 9) Can I compile PostgreSQL with Kerberos v5 support? ! ! Kerberos is integrated in OpenSolaris and will be integrated in Solaris 10u4. GSS security ! mechanism contains internal Kerberos v5 library implementation which provide all necessary ! krb5 function. However, usage this library is only on own risk. It is private library ! and interface may change without notice. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2969: Inaccuracies in Solaris FAQ
I work on it. It will be ready until Friday. Zdenek Bruce Momjian wrote: I have not seen an updated patch for FAQ_Solaris yet. --- Zdenek Kotala wrote: Rich Teer wrote: The following bug has been logged online: Bug reference: 2969 Logged by: Rich Teer Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.2 Operating system: Solaris 10 Description:Inaccuracies in Solaris FAQ Details: Hi there, First, many thanks for providing the best open source database! I've spotted a couple of errors/bits of bad advice in doc/FAQ_Solaris, which I think should be updated. 1. The answer to question 3 (Why does configure complain about a failed test program?) says to set LD_LIBRARY_PATH to point to the directory containing the missing libs. While this does work (as does the other suggestion of using LD_RUN_PATH), the correct answer to this question is to include the library's path in the executable by using the -R flag, thus avoiding the need for the end user to mess about with environment variables. For example, I use "LDFLAGS=-R/usr/sfw/lib ./configure ..." to build Postgres which uses Sun's OpenSSL. Yes you have right we use -R for official Solaris package as well. Good comment. 2. The answer to question 8 (Can I use DTrace for tracing PostgreSQL?) says that Solaris 10u3 or newer is required to handle probes in static functions. Unfortunately, this is not the case. DTrace can't be enabled when using update 3 (aka 11/06); the (as yet unreleased) update 4 or newer is required. Original plan was release new version of DTrace in the update 3. Thanks for comment. But if you want to use Dtrace on Solaris 10u3 or older you can remove static from affected function in the transaction manager. It is not much clean but it works. Thanks for the comments and I will prepare a patch asap together with another improvements. Thanks Zdenek ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #2969: Inaccuracies in Solaris FAQ
Rich Teer wrote: The following bug has been logged online: Bug reference: 2969 Logged by: Rich Teer Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.2 Operating system: Solaris 10 Description:Inaccuracies in Solaris FAQ Details: Hi there, First, many thanks for providing the best open source database! I've spotted a couple of errors/bits of bad advice in doc/FAQ_Solaris, which I think should be updated. 1. The answer to question 3 (Why does configure complain about a failed test program?) says to set LD_LIBRARY_PATH to point to the directory containing the missing libs. While this does work (as does the other suggestion of using LD_RUN_PATH), the correct answer to this question is to include the library's path in the executable by using the -R flag, thus avoiding the need for the end user to mess about with environment variables. For example, I use "LDFLAGS=-R/usr/sfw/lib ./configure ..." to build Postgres which uses Sun's OpenSSL. Yes you have right we use -R for official Solaris package as well. Good comment. 2. The answer to question 8 (Can I use DTrace for tracing PostgreSQL?) says that Solaris 10u3 or newer is required to handle probes in static functions. Unfortunately, this is not the case. DTrace can't be enabled when using update 3 (aka 11/06); the (as yet unreleased) update 4 or newer is required. Original plan was release new version of DTrace in the update 3. Thanks for comment. But if you want to use Dtrace on Solaris 10u3 or older you can remove static from affected function in the transaction manager. It is not much clean but it works. Thanks for the comments and I will prepare a patch asap together with another improvements. Thanks Zdenek ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] Compiling problem on Solaris
SAKAI Kiyotaka wrote: I compiled PostgreSQL-8.2.0 on Solaris 8, but I cannot execute binaries because it cannot find linked shared libraries, like libgcc_s.so. % cd src/interfaces/libp % rm libpq.so* % make gcc -shared -h libpq.so.5 fe-auth.o fe-connect.o fe-exec.o fe-misc.o fe-print.o fe-lobj.o fe-protocol2.o fe-protocol3.o pqexpbuffer.o pqsignal.o fe-secure.o md5.o ip.o wchar.o encnames.o noblock.o pgstrcasecmp.o thread.o inet_aton.o strlcpy.o getaddrinfo.o -L../../../src/port -lsocket -lnsl -Wl,-R'/usr/local/pgsql/lib' -o libpq.so.5.0 rm -f libpq.so.5 ln -s libpq.so.5.0 libpq.so.5 rm -f libpq.so ln -s libpq.so.5.0 libpq.so % ldd libpq.so libsocket.so.1 =>/usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libgcc_s.so.1 => (file not found) libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 /usr/platform/SUNW,Sun-Blade-100/lib/libc_psr.so.1 Gcc compiler is not part of Solaris 8. You can use LD_LIBRARY_PATH in runtime or LDFLAGS for ./configure setup. I guess, that your suggested patch could be generate unexpected result for other people. By the way, sun studio compiler is significantly better on SPARC cpu than gcc. You can download it from sun webpage. Also if you can upgrade OS than Solaris 10 is faster and you can use DTrace probes in postgres. Zdenek ---(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] PostgreSQL 8.1.5: regression tests fail on sparc
Дейтер Александр Валериевич wrote: Hi, PostgreSQL 8.1.5 have a problem with division by zero on sparc. Solaris 9 sparc, gcc 4.0.2, 4.1.1: $ ./configure --enable-thread-safety --disable-nls --without-perl --without-python --without-krb5 --without-openssl --without-readline ... I found that you logged this as gcc bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29968 However, SunStudio is much better for SPARC platform and now is free. GCC does not have good code optimalizer for SPARC. Zdenek ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] 8.2bet2 failed build on Solaris 10 / x86-64 / SUN Studio
Andreas Lange wrote: Zdenek Kotala wrote: Main problem is -fast switch. It modifies behavior of floating point operation (it is reason why It is not good option for postgres) and use another floating point libraries and some function are inlined. It is reason why pow test passed with -fast switch without -lm switch. Detail description of -fast you can found on http://docs.sun.com/source/819-3688/cc_ops.app.html I noticed that the Sun FAQ now has changed from hinting that -fast might be very beneficial to recomend staying away from it. Yes, because there was some problem with regression test. Using -fast is an old habit, has been building with it for years. I've seen that the testsuite breaks (in date/time) with only -fast, but it seems the only option one has to disable to normalize floating point enough is -fns. I hope passing the testsuite really means that fp math behaves correctly. If I'm wrong about that, I'll have to change our build routine. I little bit played with compiler switches and only -xO5 had significant deal for postgres. But I only tested it with pgbench. Very important thing is that backend sends floating point number in binary form. It means that you must compile also client library and client application with -fast switch. If you don't do this, the result should be nonsense. Beeing lazy, it is a good bit easier to go with -fast and turn of the problematic optimization with: -fast -fns=no than expanding the -fast macro and having to add all parameters: -dalign -nofstore -fsimple=2 -fsingle -xalias_level=basic -native -xdepend -xlibmil -xlibmopt -xO5 -xregs=frameptr Parameters -fsimple=2 -xlibmopt -xlibmil also break IEEE floating point arithmetic and also break errno behavior (does not report errno). If you look in adt/float.c source code, you can see comment from Tom about problems with errno on Linux many years ago. This should happen also with -xlibmil and -xlibmopt switch. My suggestion is do not use -fast anyway. Let me know if I'm not correct. Zdenek ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] 8.2bet2 failed build on Solaris 10 / x86-64 / SUN Studio
Tom Lane wrote: Andreas Lange <[EMAIL PROTECTED]> writes: Tom Lane wrote: I suppose there is something funny about pow() on your platform causing that probe to fail. What does config.log have at the "checking for library containing pow" step? configure:5168: checking for library containing pow configure:5198: /sw/sun-studio-11/SUNWspro/bin/cc -Xa -o conftest -fast -fns=no -fsimple=1 -xtarget=opteron -xarch=amd64a conftest.c >&5 configure:5204: $? = 0 configure:5208: test -z || test ! -s conftest.err configure:5211: $? = 0 configure:5214: test -s conftest configure:5217: $? = 0 configure:5287: result: none required Interesting. Could pow() actually be in libc on your machine? The other possible explanation is that it's a macro, but the AC_SEARCH_LIBS code seems to go out of its way to fail if that's the case. Anyway this illustrates the dilemma we face in trying to do a real probe for libm: the common functions (pow) are likely to be macro-ized, while uncommon ones might not be there at all (cbrt). Anyone have a better idea than reverting to the unconditional AC_CHECK_LIB(m, main) call? Main problem is -fast switch. It modifies behavior of floating point operation (it is reason why It is not good option for postgres) and use another floating point libraries and some function are inlined. It is reason why pow test passed with -fast switch without -lm switch. Detail description of -fast you can found on http://docs.sun.com/source/819-3688/cc_ops.app.html Zdenek ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #2651: 8.2 - beta 1 does now compile with Sun Studio 11
Remy Beaumont napsal(a): The following bug has been logged online: Bug reference: 2651 Logged by: Remy Beaumont Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2 - beta 1 Operating system: Solaris 10 on T2000 Description:8.2 - beta 1 does now compile with Sun Studio 11 Details: When we try to compile 8.2 - beta 1 on a T2000 wth Sun Studio 11, the build fails at the following file: make[5]: Entering directory `/usr/home/remy/postgresql-8.2beta1/src/backend/utils/adt' /opt/SUNWspro/bin/cc -Xa -xtarget=ultraT1 -fast -I../../../../src/include -c -o float.o float.c "float.c", line 112: identifier redeclared: cbrt current : static function(double) returning double previous: function(double) returning double : "/usr/include/iso/math_c99.h", line 126 cc: acomp failed for float.c make[5]: *** [float.o] Error 2 The flags used for compiling are: CC=/opt/SUNWspro/bin/cc 'CFLAGS=-xtarget=ultraT1 -fast' The cbrt function is not part of libc. It is located in the libm. Try export LDFLAGS='-lm' Zdenek ---(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] pgsql on Solaris 10
[EMAIL PROTECTED] napsal(a): Compiling PostgreSQL 8.1.4 under Solaris 10, I ran into a problem documented back on 2006-05-30. Apparently in order to compile successfully, one has to remove an unreferenced function pqsignalinquire() in src/interfaces/libpq/pqsignal.c. Since I stepped into this hole, is there anything I can do to help ensure that nobody else has to get lost on Google for several hours tracking down the same problem? I have been a Free Software user for some time but am not familiar with ways of feeding back into the process. Thanks, Victor Odhner - Details of the problem: Removing the function eliminated the following error when linking "initdb": Undefined symbol--first referenced in file sigmask --../../../src/interfaces/libpq/libpq.so sigblock --../../../src/interfaces/libpq/libpq.so ld: fatal: Symbol referencing errors. No output written to initdb The postgresql 8.1.4 is standard part of solaris 10 update 2. You can download prepared packages from pgfoundry. However, if you want to compile by yourself, check if you have correct setup of LD_LIBRARY_PATH to the related libc. I have never had problem with postgres compilation on solaris 10 and opensolaris (nevada). Zdenek ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2546: PostgreSQL does not have native spinlock support
Tom Lane wrote: "John Weekley" <[EMAIL PROTECTED]> writes: Platform is 64 bit Solaris x86. ... "../../../../src/include/storage/s_lock.h", line 814: #error: PostgreSQL does not have native spinlock support on this platform. To continue the compilation, rerun configure using --disable-spinlocks. However, performance will be poor. Please report this to [EMAIL PROTECTED] It looks like s_lock.h currently has coverage for amd64 using gcc, or sparc64 using either compiler, but not for amd64 using Sun's cc. Please feel free to send a patch, or you could pester Sun to send us one (Josh?) SunStudio is supported on the HEAD (8.2). Spin lock problem is know issue in version 8.1.4. I don't know if latest 8.1 branch contains backport. Zdenek ---(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
