Re: [ADMIN] asm/ia64regs.h not found on FreeBSD 8.1 IA64
Hi Tom, thanks for this really fast reply. I've removed the line #include and it compiles now. The function __getReg(_IA64_REG_AR_BSP) In postgres.c seems to be called only on Intel compilers. And I see in asm/ia64regs.h (found on a Linux box) #define _IA64_REG_AR_BSP3089 in a section /* * Register Names for getreg() and setreg(). * * The "magic" numbers happen to match the values used by the Intel compiler's * getreg()/setreg() intrinsics. */ So I assume asm/ia64regs.h is only needed for Intel compilers on Linux. Since this is not the default behavior are there any concerns to install this version into production? I'm thinking of stability or future updates. Many thanks Frank Am 27.01.2011 18:25, schrieb Tom Lane: > "Frank Brendel" writes: >> I can't compile PostgreSQL 9.0.2 on FreeBSD 8.1 for IA64. >> The error message is >> postgres.c:2998:26: error: asm/ia64regs.h: No such file or directory > Hmm, the need for that header file is a very recent addition. I'm not > very surprised to hear of portability issues around it. What you need > to look into is what's needed to compile this patch: > http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=ba007262a7661234588b1ebe297e3a95924ba587 > > If you're using gcc it's quite possible you don't need the header file > at all --- try just diking it out. Please report back. > > regards, tom lane > -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
[ADMIN] WARNING: transaction log file "....." could not be archived: too many failures
Hello. The following message appears continuously in the log file of postgresql : Jan 28 11:35:01 abcd postgres[28359]: [81-1] LOG: archive command "cp "pg_xlog/00010085" /u10/postgres/archive/"00010085"" failed: return Jan 28 11:35:01 abcd postgres[28359]: [81-2] code 256 Jan 28 11:35:02 abcd postgres[28359]: [82-1] LOG: archive command "cp "pg_xlog/00010085" /u10/postgres/archive/"00010085"" failed: return Jan 28 11:35:02 abcd postgres[28359]: [82-2] code 256 Jan 28 11:35:03 abcd postgres[28359]: [83-1] LOG: archive command "cp "pg_xlog/00010085" /u10/postgres/archive/"00010085"" failed: return Jan 28 11:35:03 abcd postgres[28359]: [83-2] code 256 Jan 28 11:35:03 abcd postgres[28359]: [84-1] WARNING: transaction log file "00010085" could not be archived: too many failures The problem is that the requested file is not available anymore. How can I tell postgres to bypass this file ? Thanks Joby
Re: [ADMIN] pg_upgrade 8.3 to 9.0, shutdown is to slow
Am Donnerstag, den 27.01.2011, 13:12 -0500 schrieb Bruce Momjian: > Bernhard Schrader wrote: > > Am Donnerstag, den 27.01.2011, 12:09 -0500 schrieb Bruce Momjian: > > > Scott Marlowe wrote: > > > > > My initial reaction is that something is wrong with your system, > > > > > either > > > > > the I/O or the way it is being shutdown by the script. ?I would start > > > > > to > > > > > look in the script and do some pg_ctl tests starting/stopping the > > > > > server. > > > > > > > > It could be that his application or whatever is making connections > > > > while he's trying to do this. An open connection that's actually > > > > doing something will stop a normal shutdown. > > > > > > > > Is there a reason the pg upgrade script does not use -m fast? > > > > > > Uh, well, I assume that the person has already shut down all db > > > connections, and opened it only for super-users. If the system is not > > > shutting down, that should signal to the user that they have not locked > > > down the system properly. We would not want someone to connect during > > > pg_upgrade processing, and doing -m fast is not going to help with that. > > > > > > -- > > > Bruce Momjian http://momjian.us > > > EnterpriseDB http://enterprisedb.com > > > > > > + It's impossible for everything to be true. + > > > > > > > Hi, > > > > well, i shut down every client connection that could occur, but with a > > ps auxf i get following output: > > > > postgres 26255 0.0 0.0 426396 2044 ? Ss 14:21 0:00 \_ postgres: writer > > process > > postgres 26257 0.0 0.0 154368 1616 ? Ss 14:21 0:00 \_ postgres: stats > > collector process > > postgres 26258 0.0 0.1 427612 4188 ? Ss 14:21 0:00 \_ postgres: grepo > > DB_NAME LOCAL_IP(PORT) idle > > > > so there are some connections, but as far as i can say, nothing from a > > client program, these connections belong to postgres itself??!? is that > > possible? pg_upgrade has to check the tables anyway, so there must be > > this connection, or am i wrong?!? > > The first two are normal processes you will see when you start Postgres. > That last one looks odd --- did you mask it somehow? That looks like an > active idle connection for user 'grepo'. > > -- > Bruce Momjian http://momjian.us > EnterpriseDB http://enterprisedb.com > > + It's impossible for everything to be true. + > good hint, thanks a lot. Well, I stopped all services, also a java daemon which connects to the db as this user. the init skript told me that the javaserver was shut down properly, but it didnt, kill -9 helped here. after that i tried the shutdown again and it worked well. :) thanks a lot so far, now i can migrate all of our dbs :) regards Bernhard -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] WARNING: transaction log file "....." could not be archived: too many failures
Joby Joba wrote: > Jan 28 11:35:01 abcd postgres[28359]: [81-1] LOG: archive command > "cp "pg_xlog/00010085" > /u10/postgres/archive/"00010085"" failed: return > Jan 28 11:35:01 abcd postgres[28359]: [81-2] code 256 > The problem is that the requested file is not available anymore. > How can I tell postgres to bypass this file ? Get a new base backup and start the recovery over. Be sure to fix whatever broken process caused the WAL file to be discarded while it might still be needed. -Kevin -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] asm/ia64regs.h not found on FreeBSD 8.1 IA64
"Frank Brendel" writes: > I've removed the line > #include > and it compiles now. OK, thanks for confirming that. > Since this is not the default behavior are there any concerns to install > this version into production? No, it will be the default behavior come Monday ;-) http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=67dbe720f6ba18393cd85574718aa2683b77a212 regards, tom lane -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] asm/ia64regs.h not found on FreeBSD 8.1 IA64
Cool! Thanks a lot! Frank Am 28.01.2011 16:17, schrieb Tom Lane: > "Frank Brendel" writes: >> I've removed the line >> #include >> and it compiles now. > OK, thanks for confirming that. > >> Since this is not the default behavior are there any concerns to install >> this version into production? > No, it will be the default behavior come Monday ;-) > http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=67dbe720f6ba18393cd85574718aa2683b77a212 > > regards, tom lane -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] Warm Standby looking for already applied log files
"Kevin Grittner" writes: > that script to not delete. Personally, I like to keep the last two > base backups and all the WAL files needed to restore from the > earlier of those forward. We have cleanup script that deletes the > oldest backup and WAL files only needed for recovery from it when we > receive a new one. PostgreSQL 9.0 now ships with such a script per default: http://www.postgresql.org/docs/9.0/interactive/pgarchivecleanup.html Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] Warm Standby looking for already applied log files
Dimitri Fontaine wrote: > "Kevin Grittner" writes: >> that script to not delete. Personally, I like to keep the last >> two base backups and all the WAL files needed to restore from the >> earlier of those forward. We have cleanup script that deletes >> the oldest backup and WAL files only needed for recovery from it >> when we receive a new one. > > PostgreSQL 9.0 now ships with such a script per default: > > http://www.postgresql.org/docs/9.0/interactive/pgarchivecleanup.html Thanks for pointing that out. Next time we touch the scripts, I'll see about using this instead of the bash script we call to do the equivalent. I don't suppose there's something which looks *into* a backup file and deletes all WAL files not needed to restore the related base backup? That would eliminate an even *uglier* bash script here. -Kevin -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] Warm Standby looking for already applied log files
"Kevin Grittner" writes: > I don't suppose there's something which looks *into* a backup file > and deletes all WAL files not needed to restore the related base > backup? That would eliminate an even *uglier* bash script here. Well with some luck Magnus will be able to complete pg_basebackup in 9.1 so that it's able to include all necessary WAL files, and just them… I could have missed it but I didn't read about any effort towards shipping a base backup cleaning tool in 9.1, or even after that. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
[ADMIN] Drop Schema Error
Hello! I'm trying to: DROP SCHEMA "_old_permissions"; And I get this error: ERROR: cannot drop schema _old_permissions because other objects depend on it DETAIL: function 17059 depends on schema _old_permissions function 17060 depends on schema _old_permissions HINT: Use DROP . CASCADE to drop the dependant objects too. So, naturally I: DROP SCHEMA "_old_permissions" CASCADE; Which produces: NOTICE: drop cascades to 2 other objects DETAIL: drop cascades to function 17059 drop cascades to function 17060 [Err] ERROR: cache lookup failed for function 17060 What is this trying to tell me?
