[BUGS] BUG #4095: Out of memory when restore db
The following bug has been logged online: Bug reference: 4095 Logged by: Pavel Zaitsev Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.4 Operating system: Windows 2003 Server SP1 Description:Out of memory when restore db Details: I made the backup of database named avtopzipbuh: pg_dump -f%DRIVETO%\Backup\%DIRNAME%\%FILENAME% -Upostgres avtozipbuh then, I tried to restore it: psql -davtozipbuh -Upostgres -fF:\Backup\avtozipbuh -oF:\Backup\logrestore.txt but I had an error "psql:F:/Backup/avtozipbuh:214116: ERROR: out of memory DETAIL: Failed on request of size 536870912. CONTEXT: COPY config, line 6800" here is the log: TopMemoryContext: 49152 total in 5 blocks; 9504 free (22 chunks); 39648 used TopTransactionContext: 8192 total in 1 blocks; 7336 free (0 chunks); 856 used CFuncHash: 8192 total in 1 blocks; 4936 free (0 chunks); 3256 used Rendezvous variable hash: 8192 total in 1 blocks; 3848 free (0 chunks); 4344 used PLpgSQL function cache: 8192 total in 1 blocks; 5904 free (0 chunks); 2288 used MessageContext: 8192 total in 1 blocks; 6952 free (1 chunks); 1240 used Operator class cache: 8192 total in 1 blocks; 4872 free (0 chunks); 3320 used smgr relation table: 24576 total in 2 blocks; 6792 free (4 chunks); 17784 used TransactionAbortContext: 32768 total in 1 blocks; 32752 free (0 chunks); 16 used Portal hash: 8192 total in 1 blocks; 3912 free (0 chunks); 4280 used PortalMemory: 8192 total in 1 blocks; 8040 free (0 chunks); 152 used PortalHeapMemory: 536976464 total in 8 blocks; 30496 free (24 chunks); 536945968 used ExecutorState: 8192 total in 1 blocks; 7928 free (0 chunks); 264 used ExprContext: 8192 total in 1 blocks; 8176 free (0 chunks); 16 used Relcache by OID: 57344 total in 3 blocks; 30680 free (4 chunks); 26664 used CacheMemoryContext: 4329016 total in 22 blocks; 673640 free (8 chunks); 3655376 used pg_toast_1406616_index: 1024 total in 1 blocks; 288 free (0 chunks); 736 used pg_class_relname_nsp_index: 1024 total in 1 blocks; 288 free (0 chunks); 736 used pg_index_indrelid_index: 1024 total in 1 blocks; 352 free (0 chunks); 672 used pg_attribute_relid_attnam_index: 1024 total in 1 blocks; 288 free (0 chunks); 736 used pg_type_oid_index: 1024 total in 1 blocks; 352 free (0 chunks); 672 used pg_cast_oid_index: 1024 total in 1 blocks; 352 free (0 chunks); 672 used pg_shdepend_depender_index: 1024 total in 1 blocks; 216 free (0 chunks); 808 used pg_shdepend_reference_index: 1024 total in 1 blocks; 288 free (0 chunks); 736 used pg_depend_depender_index: 1024 total in 1 blocks; 216 free (0 chunks); 808 used pg_depend_reference_index: 1024 total in 1 blocks; 216 free (0 chunks); 808 used pg_description_o_c_o_index: 1024 total in 1 blocks; 216 free (0 chunks); 808 used pg_type_typname_nsp_index: 1024 total in 1 blocks; 288 free (0 chunks); 736 used pg_statistic_relid_att_index: 1024 total in 1 blocks; 328 free (0 chunks); 696 used pg_proc_oid_index: 1024 total in 1 blocks; 352 free (0 chunks); 672 used pg_proc_proname_args_nsp_index: 1024 total in 1 blocks; 216 free (0 chunks); 808 used pg_operator_oprname_l_r_n_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used pg_namespace_oid_index: 1024 total in 1 blocks; 392 free (0 chunks); 632 used pg_namespace_nspname_index: 1024 total in 1 blocks; 352 free (0 chunks); 672 used pg_language_oid_index: 1024 total in 1 blocks; 392 free (0 chunks); 632 used pg_language_name_index: 1024 total in 1 blocks; 352 free (0 chunks); 672 used pg_inherits_relid_seqno_index: 1024 total in 1 blocks; 328 free (0 chunks); 696 used pg_database_oid_index: 1024 total in 1 blocks; 352 free (0 chunks); 672 used pg_conversion_oid_index: 1024 total in 1 blocks; 392 free (0 chunks); 632 used pg_conversion_name_nsp_index: 1024 total in 1 blocks; 328 free (0 chunks); 696 used pg_conversion_default_index: 1024 total in 1 blocks; 192 free (0 chunks); 832 used pg_opclass_oid_index: 1024 total in 1 blocks; 352 free (0 chunks); 672 used pg_opclass_am_name_nsp_index: 1024 total in 1 blocks; 216 free (0 chunks); 808 used pg_cast_source_target_index: 1024 total in 1 blocks; 288 free (0 chunks); 736 used pg_authid_oid_index: 1024 total in 1 blocks; 352 free (0 chunks); 672 used pg_authid_rolname_index: 1024 total in 1 blocks; 352 free (0 chunks); 672 used pg_auth_members_role_member_index: 1024 total in 1 blocks; 328 free (0 chunks); 696 used pg_auth_members_member_role_index: 1024 total in 1 blocks; 328 free (0 chunks); 696 used pg_amop_opr_opc_index: 1024 total in 1 blocks; 288 free (0 chunks); 736 used pg_aggregate_fnoid_index: 1024 total in 1 blocks; 352 free (0 chunks); 672 used pg_trigger_tgrelid_tgname_index: 1024 total in 1 blocks; 288 free (0 chunks); 736 used pg_rewrite_rel_rulename_index: 1024 total in 1 blocks; 328 free (0 chunks); 696 used pg_operator_oid_index: 1024 total in 1 blocks; 352 free (0 chunks); 672 used pg_amproc_opc_proc_index: 1024 total in 1 blocks; 216 free (0 chunks); 808 used pg_amop_opc_strat_index: 1024 tot
Re: [BUGS] BUG #4090: ECPG Selecting table with NULL values
> In ECPG when I have "$select a into :a from table where b = :b;" this query > raises an error if the value a is NULL. > If I have added the indicator value "$select a int :a, :a_ind from table > where b = :b;" this also raises the same error. I cannot read rows including > null values without raising this error. From the documentation the > indicator value should prevent raising this error but it is not. > > I compile with INFORMIX compablity mode from ESQL sourcecode ported to > PostgreSQL. Could you send us a test case? Does it work when not using INFORMIX mode? Do you use the "-r no_indicator" option? Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use 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 #4095: Out of memory when restore db
"Pavel Zaitsev" <[EMAIL PROTECTED]> writes: > I made the backup of database named avtopzipbuh: > pg_dump -f%DRIVETO%\Backup\%DIRNAME%\%FILENAME% -Upostgres avtozipbuh > then, I tried to restore it: > psql -davtozipbuh -Upostgres -fF:\Backup\avtozipbuh > -oF:\Backup\logrestore.txt > but I had an error > "psql:F:/Backup/avtozipbuh:214116: ERROR: out of memory > DETAIL: Failed on request of size 536870912. Is it true that you've got any extremely wide lines (100MB or more) in that COPY data? 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 #3983: pgxs files still missing in win32 install (8.3.1)
Dave Page wrote: On Tue, Mar 18, 2008 at 12:47 AM, Alvaro Herrera <[EMAIL PROTECTED]> wrote: Mike Leahy wrote: > Is this actually a bug, or is there a specific reason that the pgxs > files omitted in the windows installer? I noticed the 8.3.1 installer > has been posted (as the updates had appeared on my linux machines). From > what I can tell, the 8.3.1 version of the win32 installer is still > missing pgxs.mk and any related files. It is a bug in the Win32 installer. Please report it on the Win32 installer project, http://pgfoundry.org/projects/pginstaller/ It's not an installer bug - pgxs doesn't make sense to the VC++ PostgreSLQ build because we don't use (or configure) any of the build system on which it relies. I wonder if we can either build whatever is needed to make pgxs work (I'm guessing Makefile.global and more) when we run the perl scripts that generate the project files, or come up with a VC++ alternative to pgxs. I'm finally getting back to this, and finding that plr.dll built against a MinGW compiled postgres will not load in running cluster built with VC++ (i.e. the standard binary install). Is that to be expected? If so, can you give me pointers (either direct guidance or literal URLs) on how to build postgres and related extensions with VC++? Thanks, Joe -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] CREATEDB and CREATEROLE privileges cannot vacuum pg_authid and others
Hello, By documentation advice in: http://www.postgresql.org/docs/8.3/interactive/role-attributes.html Tip: It is good practice to create a role that has the CREATEDB and CREATEROLE privileges, but is not a superuser, and then use this role for all routine management of databases and roles. This approach avoids the dangers of operating as a superuser for tasks that do not really require it. I created a user "dba" with above privileges, with it create one database , but fails to run the vacuum command( vacuum, analyze, and full all fail with the same error) in some tables with error as: WARNING: skipping "pg_authid" --- only table or database owner can vacuum it so its a bug(by the message "database owner can vacuum it" because is the owner but fails to vacuum it), or vacuum isn't considered a routine management of databases. second this is totally apart, this user "dba" can grant privileges in schema public, but cannot drop that schema (I create my own schemas) because the owner of schema public is set to postgres, so dba can create a database but don't own it fully. postgres 8.3.1, Mac OS X 10.4.11, gcc 3.0.1, Xcode 2.4, macports 1.600, sequence of commands and output follows ~$ createdb test01 -e -E UTF8 -U dba -W Password: CREATE DATABASE test01 ENCODING 'UTF8'; ~$ psql -U dba test01 Password for user dba: Welcome to psql 8.3.1, 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 test01=> \l List of databases Name| Owner | Encoding +--+-- postgres | postgres | UTF8 template0 | postgres | UTF8 template1 | postgres | UTF8 test01 | dba | UTF8 (5 rows) test01=> CREATE TABLE mytable ( test01(> id serial PRIMARY KEY, test01(> mydata varchar(10) test01(> ); NOTICE: CREATE TABLE will create implicit sequence "mytable_id_seq" for serial column "mytable.id" NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "mytable_pkey" for table "mytable" CREATE TABLE test01=> vacuum full analyze; WARNING: skipping "pg_authid" --- only table or database owner can vacuum it WARNING: skipping "pg_database" --- only table or database owner can vacuum it WARNING: skipping "pg_shdepend" --- only table or database owner can vacuum it WARNING: skipping "pg_shdescription" --- only table or database owner can vacuum it WARNING: skipping "pg_auth_members" --- only table or database owner can vacuum it WARNING: skipping "pg_tablespace" --- only table or database owner can vacuum it WARNING: skipping "pg_pltemplate" --- only table or database owner can vacuum it VACUUM test01=> drop schema public; ERROR: must be owner of schema public test01=> \dn List of schemas Name| Owner +-- information_schema | postgres pg_catalog | postgres pg_toast | postgres pg_toast_temp_1| postgres public | postgres (5 rows) test01=> thanks in advance, Gabriel -- e-mail: [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: [BUGS] CREATEDB and CREATEROLE privileges cannot vacuum pg_authid and others
Gabriel Ramirez <[EMAIL PROTECTED]> writes: > Tip: It is good practice to create a role that has the CREATEDB > and CREATEROLE privileges, but is not a superuser, and then use this > role for all routine management of databases and roles. This approach > avoids the dangers of operating as a superuser for tasks that do not > really require it. Nowhere does that say, or even suggest, that database-wide vacuuming is a task that doesn't require superuser. 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 #3983: pgxs files still missing in win32 install (8.3.1)
Joe Conway wrote: > Dave Page wrote: > > On Tue, Mar 18, 2008 at 12:47 AM, Alvaro Herrera > > <[EMAIL PROTECTED]> wrote: > >> Mike Leahy wrote: > >> > Is this actually a bug, or is there a specific reason that the > >> > pgxs files omitted in the windows installer? I noticed the > >> > 8.3.1 installer has been posted (as the updates had appeared on > >> > my linux machines). From what I can tell, the 8.3.1 version of > >> > the win32 installer is still missing pgxs.mk and any related > >> > files. > >> > >> It is a bug in the Win32 installer. Please report it on the Win32 > >> installer project, http://pgfoundry.org/projects/pginstaller/ > > > > It's not an installer bug - pgxs doesn't make sense to the VC++ > > PostgreSLQ build because we don't use (or configure) any of the > > build system on which it relies. > > > > I wonder if we can either build whatever is needed to make pgxs work > > (I'm guessing Makefile.global and more) when we run the perl scripts > > that generate the project files, or come up with a VC++ alternative > > to pgxs. > > I'm finally getting back to this, and finding that plr.dll built > against a MinGW compiled postgres will not load in running cluster > built with VC++ (i.e. the standard binary install). Is that to be > expected? If so, can you give me pointers (either direct guidance or > literal URLs) on how to build postgres and related extensions with > VC++? In general, mingw built modules should load just fine in msvc built postgres. AFAIK, that's how PostGIS does it for 8.3 (though I know Mark is working on getting MSVC build support for them). Debugging may be a bit harder (since they use different kinds of debug symbols - postgres uses Windows style and mingw uses mingw style), but it should certainly load. What trouble exactly are you seeing? //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
