Re: [BUGS] Bug with Tsearch and tsvector
On 2010-04-29, Tom Lane wrote: > Jasen Betts writes: >> \ is popular in URIs on some platfroms, or is URI a different beast > > I hope not, because \ is explicitly disallowed by both the older and > newer versions of that RFC. I should have known better than to assume that Microsoft was using a term correctly. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] CVS build problem - make world target
Hi,
System Configuration:
--
Architecture :
2 x Intel(R) Pentium(R) 4 CPU 3.20GHz, MMX SSE SSE2
Operating System :
DISTRIB_ID=Ubuntu, DISTRIB_RELEASE=10.04,
DISTRIB_CODENAME=lucid,DISTRIB_DESCRIPTION="Ubuntu 10.04 LTS"
Linux vlD-kuci 2.6.32-22-generic #33-Ubuntu SMP Wed Apr 28 13:27:30 UTC
2010 i686 GNU/Linux
PostgreSQL version :
PostgreSQL CVS
Compiler used :
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
openjade 1.4devel
docbook 4.5-4
xsltproc 1.1.26-1ubuntu1
opensp 1.5.2-8
Please enter a FULL description of your problem:
I have tried to build CVS version with make world target, but something is
wrong.
build.sh
#!/bin/sh
set -v
set -e
cd /media/sda5/postgresql-9.0devel/build
export CFLAGS="-g3 -gdwarf-2"
../../tmp/postgresql-cvs/pgsql/configure
'--srcdir=../../tmp/postgresql-cvs/pgsql' '--enable-cassert' '--enable-nls'
'--enable-integer-datetimes' '--with-perl' '--with-python' '--with-tcl'
'--with-krb5' '--with-openssl' '--enable-thread-safety' '--with-ldap'
'--prefix=/media/sda5/postgresql-9.0devel/9.0cvs20100429' >
configure-out1.log 2>&1
make world > make-out1.log 2>&1
make install-world > make-install-out1.log 2>&1
exit 0
configure-out1.log
...
checking for onsgmls... onsgmls
checking for openjade... openjade
checking for DocBook V4.2... yes
checking for DocBook stylesheets...
/usr/share/sgml/docbook/stylesheet/dsssl/modular
checking for collateindex.pl... /usr/bin/collateindex.pl
checking for xsltproc... xsltproc
checking for osx... osx
...
make-out1.log
--
make -C doc all
make[1]: Entering directory `/media/sda5/postgresql-9.0devel/build/doc'
make -C src all
make[2]: Entering directory `/media/sda5/postgresql-9.0devel/build/doc/src'
make -C sgml all
make[3]: Entering directory
`/media/sda5/postgresql-9.0devel/build/doc/src/sgml'
{ \
echo ""; \
echo ""; \
} >version.sgml
"/usr/bin/perl"
/media/sda5/postgresql-9.0devel/build/../../tmp/postgresql-cvs/pgsql/doc/src/sgml/
mk_feature_tables.pl YES
/media/sda5/postgresql-9.0devel/build/../../tmp/postgresql-cvs/pgsql/src/backend/catalog/sql_feature_packages.txt
/media/sda5/postgresql-9.0devel/build/../../tmp/postgresql-cvs/pgsql/src/backend/catalog/sql_features.txt
> features-supported.sgml
"/usr/bin/perl"
/media/sda5/postgresql-9.0devel/build/../../tmp/postgresql-cvs/pgsql/doc/src/sgml/
mk_feature_tables.pl NO
/media/sda5/postgresql-9.0devel/build/../../tmp/postgresql-cvs/pgsql/src/backend/catalog/sql_feature_packages.txt
/media/sda5/postgresql-9.0devel/build/../../tmp/postgresql-cvs/pgsql/src/backend/catalog/sql_features.txt
> features-unsupported.sgml
openjade -wall -wno-unused-param -wno-empty -wfully-tagged -D . -D
/media/sda5/postgresql-9.0devel/build/../../tmp/postgresql-cvs/pgsql/doc/src/sgml
-c /usr/share/sgml/docbook/stylesheet/dsssl/modular/catalog -d
stylesheet.dsl -t sgml -i output-html -V html-index
/media/sda5/postgresql-9.0devel/build/../../tmp/postgresql-cvs/pgsql/doc/src/sgml/postgres.sgml
LC_ALL=C "/usr/bin/perl" /usr/bin/collateindex.pl -f -g -i 'bookindex' -o
bookindex.sgml HTML.index
Processing HTML.index...
1954 entries loaded...
0 entries ignored...
Done.
/bin/mkdir -p html
openjade -wall -wno-unused-param -wno-empty -wfully-tagged -D . -D
/media/sda5/postgresql-9.0devel/build/../../tmp/postgresql-cvs/pgsql/doc/src/sgml
-c /usr/share/sgml/docbook/stylesheet/dsssl/modular/catalog -d
stylesheet.dsl -t sgml -i output-html -i include-index
/media/sda5/postgresql-9.0devel/build/../../tmp/postgresql-cvs/pgsql/doc/src/sgml/postgres.sgml
cp
/media/sda5/postgresql-9.0devel/build/../../tmp/postgresql-cvs/pgsql/doc/src/sgml/stylesheet.css
html/
touch html-stamp
make[3]: Circular postgres.xml <- postgres.sgml dependency dropped.
osx -D. -x lower
/media/sda5/postgresql-9.0devel/build/../../tmp/postgresql-cvs/pgsql/doc/src/sgml/acronyms.sgml
| \
"/usr/bin/perl" -p -e
's/\[(amp|copy|egrave|gt|lt|mdash|nbsp|ouml|pi|quot|uuml) *\]/\&\1;/g;' \
-e '$_ .= qq{http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd";>\n}
if $. == 1;' \
>postgres.xml
osx:/media/sda5/postgresql-9.0devel/build/../../tmp/postgresql-cvs/pgsql/doc/src/sgml/acronyms.sgml:3:0:E:
prolog can't be omitted unless CONCUR NO and LINK EXPLICIT NO and either
IMPLYDEF ELEMENT YES or IMPLYDEF DOCTYPE YES
osx:/media/sda5/postgresql-9.0devel/build/../../tmp/postgresql-cvs/pgsql/doc/src/sgml/acronyms.sgml:3:0:E:
no document type declaration; will parse without validation
xsltproc --stringparam pg.version '9.0devel'
/media/sda5/postgresql-9.0devel/build/../../tmp/postgresql-cvs/pgsql/doc/src/sgml/stylesheet-man.xsl
postgres.xml
Erro: no refentry: No refentry elements found in "Acronyms". Acronyms
touch man-stamp
make[3]: Leaving directory
`/media/sda5/postgresql-9.0devel/build/doc/src/sgml'
...
gcc -g3 -gdwa
[BUGS] PostgreSQL 8.4 - dumping database connection privileges
Hi, I've recently upgraded to PostgreSQL 8.4 as Redhat had begun supporting it. I have tried to dump database grants, but have only found an obscure way to do it. I would expect; postgres$ pg_dump -Fc database_name > backup.pgdump would include all of the GRANT CONNECT on database_name TO "Role"; commands. It does not. Second I tried; postgres$ pg_dumpall -g > globals.sql This also did not produce any GRANT CONNECT statements. The only method I found that works is; postgres$ pg_dumpall -s | grep 'ON DATABASE' This method is not exactly fool proof and isn't what I expected to have to do. Is this considered a bug that the only way to do a dump/restore with database privileges is to use pg_dumpall? I expect that pg_dump of a database would include all of that information. I would argue it is at least a misfeature and difficult for even an experienced user to understand. Regards Russell -- 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 #5444: Database Backup Restore - Out of memory problem
On Fri, Apr 30, 2010 at 4:37 AM, Chaminda Jayawardana wrote: > The following bug has been logged online: > > Bug reference: 5444 > Logged by: Chaminda Jayawardana > Email address: wpgchami...@gmail.com > PostgreSQL version: 8.3 > Operating system: Windows Server 2003 > Description: Database Backup Restore - Out of memory problem > Details: > > I have postgres sql database backup file around 1.4GB size. when I'm trying > to restore it, it is giving a following error message. > > pg_restore: restoring data for table "cms_gib_image" > pg_restore: restoring data for table "cms_imagess" > pg_restore: [custom archiver] out of memory > pg_restore: *** aborted because of error > > Process returned exit code 1. > > generally we are taking weekly backups of our production server > databases(All the databases are Postgres sql 8.3) but now we are facing > problem of restore them. > Please advise us how to resolve this database restore problem. That sort of sounds like a corrupted dump file to me. Are you restoring it on the same machine you took the dump on, or a different one? Maybe you did something like FTP it in ASCII mode? Just guessing here, really... ...Robert -- 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] PostgreSQL 8.4 - dumping database connection privileges
Russell Smith writes: > Is this considered a bug that the only way to do a dump/restore with > database privileges is to use pg_dumpall? No, that's the intended place for them given the current division of labor between pg_dump and pg_dumpall. There have been complaints before about this, but no one has proposed a better approach (where better means "fixes this without breaking use-cases that work now"). 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] [9.0beta5/cvs head] build failure due to unchecked results
Tom Lane [2010-04-30 12:51 -0400]: > I concur, those two changes look worthwhile. The proposed Assert() > additions are right out, though, as they would turn write failures > into database crashes. Right, that might be too strong. > The current code doesn't even think that such a failure is worth > testing for, so that's surely an overreaction. (And in any case, if > Asserts are disabled, this change would fail to suppress the > warning, no?) It seems gcc is happy enough if you assign the returned value to a variable. At least I have done a build without --enable-cassert (where the entire Assert() was thrown away), and it didn't complain about the unchecked result any more. I guess that heuristics gets it only so far.. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- 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] plpython memory leak uppon empty resultsets in all versions
Andres Freund writes:
> The one I measured was 9.0 only:
> diff --git a/src/pl/plpython/plpython.c b/src/pl/plpython/plpython.c
> index 6063628..a6dd9d0 100644
> *** a/src/pl/plpython/plpython.c
> --- b/src/pl/plpython/plpython.c
> *** plpython_inline_handler(PG_FUNCTION_ARGS
> *** 538,546
> --- 538,548
> PLy_procedure_compile(proc, codeblock->source_text);
> PLy_curr_procedure = proc;
> PLy_function_handler(&fake_fcinfo, proc);
> + PLy_free(proc);
> }
> PG_CATCH();
> {
> + PLy_free(proc);
> PLy_curr_procedure = save_curr_proc;
> PyErr_Clear();
> PG_RE_THROW();
> Found by running something like:
> while true; do echo 'DO LANGUAGE plpythonu $$import
> gc;gc.collect();plpy.execute("SELECT unknown"); $$;';done|psql -h /tmp -p
> 5433
> postgres
I tried this and found there was still a leak after applying your patch.
What seems like the correct thing is to use PLy_procedure_delete(),
as in the attached applied patch. With this, I see zero leak rate for
either this test or the no-error-thrown variant.
This shows that there is a pre-existing leak in PLy_procedure_delete(),
since it was failing to release the proc block itself. I did not bother
to back-patch that, though, because the one pre-existing call was not in
a place where it'd be likely to get executed over and over.
Thanks for the report!
regards, tom lane
Index: plpython.c
===
RCS file: /cvsroot/pgsql/src/pl/plpython/plpython.c,v
retrieving revision 1.142
diff -c -r1.142 plpython.c
*** plpython.c 30 Apr 2010 19:15:45 - 1.142
--- plpython.c 1 May 2010 17:03:35 -
***
*** 541,552
--- 541,555
}
PG_CATCH();
{
+ PLy_procedure_delete(proc);
PLy_curr_procedure = save_curr_proc;
PyErr_Clear();
PG_RE_THROW();
}
PG_END_TRY();
+ PLy_procedure_delete(proc);
+
/* Pop the error context stack */
error_context_stack = plerrcontext.previous;
***
*** 1664,1669
--- 1667,1673
}
if (proc->argnames)
PLy_free(proc->argnames);
+ PLy_free(proc);
}
/*
--
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] CVS build problem - make world target
Vladimir Kokovic writes: > make[3]: Circular postgres.xml <- postgres.sgml dependency dropped. [ followed by havoc as make passes the wrong $< file to osx ] I can reproduce this when doing "make all" in doc/src/sgml in a VPATH build, but not when doing it in the regular source tree. I'm not sure if this is a make bug or something weird in our make rules. Any ideas? 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] CVS build problem - make world target
I wrote: > Vladimir Kokovic writes: >> make[3]: Circular postgres.xml <- postgres.sgml dependency dropped. > [ followed by havoc as make passes the wrong $< file to osx ] > I can reproduce this when doing "make all" in doc/src/sgml in a > VPATH build, but not when doing it in the regular source tree. > I'm not sure if this is a make bug or something weird in our > make rules. Any ideas? I'm currently of the opinion that this is a gmake bug. (For the record, I'm seeing it with make 3.81 in Fedora 11.) I found a pretty simple workaround, though, which I have now committed. 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] PostgreSQL 8.4 - dumping database connection privileges
On 02/05/10 01:36, Tom Lane wrote: > Russell Smith writes: > >> Is this considered a bug that the only way to do a dump/restore with >> database privileges is to use pg_dumpall? >> > No, that's the intended place for them given the current division of > labor between pg_dump and pg_dumpall. There have been complaints before > about this, but no one has proposed a better approach (where better > means "fixes this without breaking use-cases that work now"). > > regards, tom lane > I have just spent an hour searching the archives and have been unable to find any discussions on this issue. I must be searching the wrong terms. Any ideas? I would like to discuss this further, but it's a little futile without reading the background material. Also are use-cases that work now covered in the previous discussions, I'd like to know what they are. Regards Russell -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
