[HACKERS] http access to ftp.postgresql.org files
I am having some problems with our proxy server (wget times out on header) and would like to know whether it would be possible to install http access to the snapshots and other download files ? This would probably also benefit others, no ? Thanks Andreas
[HACKERS] 'postgres -Q' in test/bench
test/bench/{create|runtest}.sh uses switch '-Q' for
postgres, but postgres gives error on it. Otherwise
seems working, only lots of debug output is seen.
--
marko
[ADMIN] Re: NOSUCCESS: m$ access - psql howto ?
On Sat, 24 Feb 2001 18:48:15 -0800 "Richard T. Robino" [EMAIL PROTECTED] wrote: Use binary type for transferring files via FTP. it's the same On Sat, 24 Feb 2001 09:27:43 +0100 Stefan Huber [EMAIL PROTECTED] wrote: wild guess: maybe you must escape the pipe-symbol: ...USING DELIMITERS '\|' the same :( finally I managed to export LANG=es_ES on system then on postmaster.ini I also have LANG=es_ES but when I do: COPY products FROM '/var/lib/postgres/dadesi.txt' USING DELIMITERS '|' \g it causes: SELECT edicion FROM products; edicion - Espaa|Nacional ---puts on the same cell either there's an '|' in the middle!!! SELECT protagonista FROM products; protagonista -- Ferran Adri|Castellano ---puts on the same cell el Bulli taller ICC Ferran Adri|Francs|Francia ---puts on the same cell 2 '|' Also have tried with @ or tabs as delimiters with any result at all!! why this only occurs on some cells? what more could I check? best regards, jaume. On 2/23/01 3:04 AM, "Jaume Teixi" [EMAIL PROTECTED] wrote: Hi, I cannot use any kind of odbc because my customers have his local m$ access db's locally then export them on .txt with tab or | separated, then put on my server trought ftp. and is working ok except that the customers are on spanish databases then a data like: --DATE-NAME-LANG-- 1/6/2000|Ferran Adri|Castellano| when sended trought ftp on my server is converted to: --DATE-NAMELANG-- 1/6/2000|Ferran Adri\xe0|Castellano| so when imported on Postgresql with: COPY products FROM '/var/lib/postgres/iii2.txt' USING DELIMITERS '|' \g --DATE-NAME---LANG-- 1/6/2000|Ferran Adri\xe0|Castellano|NULL on the same cell, ignoring the '|' completelly on 'postmaster.init' I have: LANG=es_ES but doesnt' works... using tabulators as a separators also causes same problem... any pointers to solve this will be really apreciated the other problem is that if a m$ access database has a return carraige on a text cell the import also fails. bests from barcelona, teixi.
AW: [HACKERS] WAL does not recover gracefully from out-of-disk-space
Regardless of whether this particular behavior is fixable, this brings up something that I think we *must* do before 7.1 release: create a utility that blows away a corrupted logfile to allow the system to restart with whatever is in the datafiles. Otherwise, there is no recovery technique for WAL restart failures, short of initdb and restore from last backup. I'd rather be able to get at data of questionable up-to-dateness than not have any chance of recovery at all. It would imho be great if this utility would also have a means to extend a logfile, that was not extended to the full 16Mb, and revert the change that writes the whole file in the init phase. Imho this write at logfile init time adds a substantial amount of IO, that would better be avoided. If we really need this, it would imho be better to preallocate N logfiles and reuse them after checkpoint. Andreas
[HACKERS] Re: http access to ftp.postgresql.org files
On Mon, 26 Feb 2001, Zeugswetter Andreas SB wrote: I am having some problems with our proxy server (wget times out on header) and would like to know whether it would be possible to install http access to the snapshots and other download files ? This would probably also benefit others, no ? See if this works: http://www.postgresql.org/ftpsite/ Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com ==
[HACKERS] Re: http access to ftp.postgresql.org files
Just an FYI -- It works well from behind my proxy.. -Mitch - Original Message - From: "Vince Vielhaber" [EMAIL PROTECTED] To: "Zeugswetter Andreas SB" [EMAIL PROTECTED] Cc: "'The Hermit Hacker'" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, February 26, 2001 7:53 AM Subject: Re: http access to ftp.postgresql.org files On Mon, 26 Feb 2001, Zeugswetter Andreas SB wrote: I am having some problems with our proxy server (wget times out on header) and would like to know whether it would be possible to install http access to the snapshots and other download files ? This would probably also benefit others, no ? See if this works: http://www.postgresql.org/ftpsite/ Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com ==
AW: [HACKERS] Re: http access to ftp.postgresql.org files
I am having some problems with our proxy server (wget times out on header) and would like to know whether it would be possible to install http access to the snapshots and other download files ? This would probably also benefit others, no ? See if this works: http://www.postgresql.org/ftpsite/ Works great !! Wow, what a time to market. I am impressed :-) Many thanks Andreas
Re: [HACKERS] Monitor status
Vince Vielhaber wrote: On Sun, 25 Feb 2001, Kaare Rasmussen wrote: Hi I've tried to search the site, but no usable pages turned up. My question is about monitoring PostgreSQL and if it turns out to be "down" to notify a person to take action. I'm surprised that I couldn't find anything about it. Does anyone have an advice ? Anything that will fit into ordinary NMS. Maybe SNMP will not fit, but then some kind of "database ping", or equal. Have you looked at bigbrother? There is also a component of netsaint (www.netsaint.org) that will check PostgreSQL postmasters. I hope to add to that the ability to do specific queries, (right now, it only does a login, then disconnects). (I am the primary maintainer of the plugins that do the actual service checks, another developer originated the overall project and maintains the core software itself). Netsaint, like big brother, can check a bunch of other services as well. Nesaint has native support for notifications, and if you wish cxan also be set upt to automatically issue restarts and so on (I suspect Big Brother can do so also, but I do not know). Netsaint is Free Software released under GPL. __ Karl DeBisschop [EMAIL PROTECTED] Learning Network Reference http://www.infoplease.com Netsaint Plugin Developer [EMAIL PROTECTED]
Re: [HACKERS] offset and limit in update and subselect
Hmmm... that's good to know. Basically, I'm trying to model fixed order tables in another application through a proxy mechanism (see http://rpgsql.sourceforge.net/). I guess I will have to force row ordering on all proxied tables. Tim Tom Lane wrote: "Timothy H. Keitt" [EMAIL PROTECTED] writes: Basically, I need to update rows by offset from the beginning of the table. I think you'd better rethink your data design. Tuple order in a table is not a defined concept according to SQL. Even if we allowed queries such as you've described, the results would not be well-defined, but would change at the slightest provocation. The implementation feels itself entitled to rearrange tuple order whenever the whim strikes it. As the documentation tries hard to make plain, LIMIT/OFFSET are only guaranteed to produce reproducible results if there's also an ORDER BY that constrains the tuples into a unique ordering. regards, tom lane -- Timothy H. Keitt Department of Ecology and Evolution State University of New York at Stony Brook Phone: 631-632-1101, FAX: 631-632-7626 http://life.bio.sunysb.edu/ee/keitt/
Re: AW: [HACKERS] WAL does not recover gracefully from out-of-disk-sp ace
Zeugswetter Andreas SB [EMAIL PROTECTED] writes: Imho this write at logfile init time adds a substantial amount of IO, that would better be avoided. If we really need this, it would imho be better to preallocate N logfiles and reuse them after checkpoint. Already done. See the WAL_FILES parameter. regards, tom lane
AW: AW: [HACKERS] WAL does not recover gracefully from out-of-disk-sp ace
Imho this write at logfile init time adds a substantial amount of IO, that would better be avoided. If we really need this, it would imho be better to preallocate N logfiles and reuse them after checkpoint. Already done. See the WAL_FILES parameter. I meant something else. I did not mean to write/format the logfile during checkpoint at all, but to reuse logfile number 000 for a later logfile. Doing the format during checkpoint hurts even more, since that is the time when the most writes occur, no ? In my setup initdb, or startup, or whatever would preallocate N logfiles, and those are reused round robin. Andreas
[HACKERS] Release in 2 weeks ...
Morning all ...
Are there any major outstandings that ppl have on their plates,
that should prevent a release? I'd like to put out an RC1 by Friday this
week, with a full release schedualed for March 15th ... this would give
Thomas his two weeks for the docs freeze ...
Basically, RC1 would say to ppl that we're ready to release, there
will be no more core changes that will require an initdb ... feel
comfortable using this version in production, with the only major changes
between now and release being docs related ...
Does this work? Or is there something earth-shattering that still
has to be done?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
AW: [HACKERS] Release in 2 weeks ...
Are there any major outstandings that ppl have on their plates, that should prevent a release? Imho startup after a failing WAL recovery is a 'must do' before release, as Tom pointed out. Remember that you can currently run into this situation with as easy a mistake as running out of diskspace. Also a reasonable default for commit_delay and commit_siblings should be found before release. Andreas
Re: [HACKERS] Re: [PATCHES] A patch for xlog.c
[EMAIL PROTECTED] (Nathan Myers) writes: This is supported on Linux and BSD, but not on Solarix 7. It's not necessary; you can just map /dev/zero on SysV systems that don't have MAP_ANON. HPUX says: The mmap() function is supported for regular files. Support for any other type of file is unspecified. But I don't know of any reason to avoid mapping an actual inode, How about wasted I/O due to the kernel thinking it needs to reflect writes to the memory region back out to the underlying file? Since mmap() is how everybody implements shared libraries, Now *there's* a sweeping generalization. Documentation of this claim, please? The mmap architecture comes to us from the Mach microkernel memory manager, backported into BSD and then copied widely. If everyone copied the Mach implementation, why is it they don't even agree on the spellings of the user-visible flags? This looks a lot like exchanging the devil we know (SysV shmem) for a devil we don't know. Do I need to remind you about, for example, the mmap bugs in early Linux releases? (I still vividly remember having to abandon mmap on a project a few years back that needed to be portable to Linux. Perhaps that colors my opinions here.) I don't think the problems with shmem are sufficiently large to justify venturing into a whole new terra incognita of portability issues and kernel bugs. regards, tom lane
Re: [HACKERS] Re: [PATCHES] A patch for xlog.c
Tom Lane [EMAIL PROTECTED] writes: Since mmap() is how everybody implements shared libraries, Now *there's* a sweeping generalization. Documentation of this claim, please? I've seen a lot of shared library implementations (I used to be the GNU binutils maintainer), and Nathan is approximately correct. Most ELF systems use a dynamic linker inherited from the original SVR4 implementation, which uses mmap. You can see this by running strace on an SVR4 system. The *BSD and GNU dynamic linker implementations are of course independently derived, but they use mmap too. mmap is the natural way to implement ELF style shared libraries. The basic operation you have to do is to map the shared library into the process memory space, and then to process a few relocations. Mapping the shared library in can be done either using mmap, or using open/read/close. For a large file, mmap is going to be much faster than open/read/close, because it doesn't require actually reading the file. There are, of course, many non-ELF shared libraries implementations. SVR3 does not use mmap. SunOS does use mmap (SunOS shared libraries were taken into SVR4 and the ELF standard). I don't know offhand about AIX, Digital Unix, or Windows. mmap is standardized by the most recent version of POSIX.1. Ian
Re: AW: [HACKERS] WAL does not recover gracefully from out-of-disk-space
[ Charset ISO-8859-1 unsupported, converting... ] Regardless of whether this particular behavior is fixable, this brings up something that I think we *must* do before 7.1 release: create a utility that blows away a corrupted logfile to allow the system to restart with whatever is in the datafiles. Otherwise, there is no recovery technique for WAL restart failures, short of initdb and restore from last backup. I'd rather be able to get at data of questionable up-to-dateness than not have any chance of recovery at all. Update OPEN ITEMS list: Source Code Changes --- Allow recovery from corrupted WAL file Finalize commit_delay value -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
AW: [HACKERS] CommitDelay performance improvement
One thing that I remember from a performance test we once did is, that the results are a lot more realistic, better and more stable, if you try to decouple the startup of the different clients a little bit, so they are not all in the same section of code at the same time. We inserted random usleeps, I forgot what range, but 10 ms seem reasonable to me. This was another database, but it might also apply here. Andreas
[HACKERS] stuck spinlock
Can anyone tell me what is going on, when I get a stuck spinlock? Is there a data corruption or anything else to worry about ? I've found some references about spinlocks in the -hackers list, so is that fixed with a later version than beta4 already? Actually I was running a stack of pgbench jobs with varying commit_delay parameter and # of clients, but it doesn't look deterministic on any of their values. I've got those fatal errors, with exactly the same data several times now. I've restarted the postmaster as well as I've dropped the bench database and recreated it, but it didn't really help. That error is still coming *sometimes*. BTW, I think I didn't see this before, when I was running pgbench only once from the command line, but since I use the script with the for loop. Some environment info: bench=# select version(); version - PostgreSQL 7.1beta4 on sparc-sun-solaris2.7, compiled by GCC 2.95.1 checkpoint_timeout = 1800 # range 30-1800 commit_delay = 0 # range 0-1000 debug_level = 0 # range 0-16 fsync = false max_connections = 100 # 1-1024 shared_buffers = 4096 sort_mem = 4096 tcpip_socket = true wal_buffers = 128 # min 4 wal_debug = 0 # range 0-16 wal_files = 10 # range 0-64 pgbench -i -s 10 bench ... PGOPTIONS="-c commit_delay=$del " \ pgbench -c $cli -t 100 -n bench Thanks, Peter = FATAL: s_lock(fcc01067) at xlog.c:2088, stuck spinlock. Aborting. FATAL: s_lock(fcc01067) at xlog.c:2088, stuck spinlock. Aborting. Server process (pid 7889) exited with status 6 at Mon Feb 26 09:17:36 2001 Terminating any active server processes... NOTICE: Message from PostgreSQL backend: The Postmaster has informed me that some other backend died abnormally and possibly corr upted shared memory. I have rolled back the current transaction and am going to terminate your database system connection and exit. Please reconnect to the database system and repeat your query. The Data Base System is in recovery mode Server processes were terminated at Mon Feb 26 09:17:36 2001 Reinitializing shared memory and semaphores DEBUG: starting up DEBUG: database system was interrupted at 2001-02-26 09:17:33 DEBUG: CheckPoint record at (0, 3648965776) DEBUG: Redo record at (0, 3648965776); Undo record at (0, 0); Shutdown FALSE DEBUG: NextTransactionId: 1362378; NextOid: 2362993 DEBUG: database system was not properly shut down; automatic recovery in progress... DEBUG: redo starts at (0, 3648965840) DEBUG: ReadRecord: record with zero len at (0, 3663163376) DEBUG: Formatting logfile 0 seg 218 block 699 at offset 4080 DEBUG: The last logId/logSeg is (0, 218) DEBUG: redo done at (0, 3663163336) -- Best regards, Peter Schindler Synchronicity Inc.| [EMAIL PROTECTED] http://www.synchronicity.com | +49 89 89 66 99 42 (Germany)
[HACKERS] regress test reporting
I just put the regress test tool online. It's just a simple form, I'll add the borders and stuff later. No reporting tool yet, but I'm working on that now. http://www.postgresql.org/~vev/regress/ Be prepared, it's gonna ask you for your regression.out and regression.diff files. I just uploaded mine and it worked, let me know immediately if it doesn't for you! Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com ==
[HACKERS] IPC Shared Memory (fwd)
hi i'm re-sending this mail again to seek more help since i haven't got any solution as yet. Additionaly , could it be an oracle taking up so much resource so that i postgres can't get any of them? Katsu -- Forwarded message -- Date: Sun, 18 Feb 2001 15:27:47 +1100 (EST) From: Katsuyuki Tanaka [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: IPC Shared Memory Hi when i run postmaster i got the following error and postmaser doesn't start, FATAL 1: InitProcGlobal: IpcSemaphoreCreate failed IpcSemaphoreCreate: semget failed (No space left on device) key=014, num=16, permission=600 This type of error is usually caused by an improper shared memory or System V IPC semaphore configuration. For more information, see the FAQ and platform-specific FAQ's in the source directory pgsql/doc or on our i made query to admin and the max shared mem setting is already set to the max possible * * IPC Shared Memory * 4294967295 max shared memory segment size (SHMMAX) 1 min shared memory segment size (SHMMIN) 100 shared memory identifiers (SHMMNI) 10 max attached shm segments per process (SHMSEG) I tried -N and -B but didn't have luck. Could anyone help me on this? This problem appeared after admin changed their config i believe, could that be it? Thanks Katsu
[HACKERS] regression.out and regression.diff
is regression.out and/or regression.diff deleted if the tests pass? I've never seen all tests pass so I don't know but I just had someone tell me that it does. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com ==
Re: [HACKERS] Monitor status
There is also a component of netsaint (www.netsaint.org) that will check PostgreSQL postmasters. I hope to add to that the ability to Thanks. I've also seen a lot of announcements of OpenNMS at freshmeat. All I know is that it's Java based, and as fas as I can tell will work without agents. Can any of these operate in a mixed Linux / Win2000 environment (I'd like to have one tool only for NMS. -- Kaare Rasmussen--Linux, spil,--Tlf:3816 2582 Kaki Datatshirts, merchandize Fax:3816 2501 Howitzvej 75 Åben 14.00-18.00Email: [EMAIL PROTECTED] 2000 FrederiksbergLørdag 11.00-17.00 Web: www.suse.dk
Re: [HACKERS] stuck spinlock
Peter Schindler [EMAIL PROTECTED] writes: FATAL: s_lock(fcc01067) at xlog.c:2088, stuck spinlock. Aborting. Judging from the line number, this is in CreateCheckPoint. I'm betting that your platform (Solaris 2.7, you said?) has the same odd behavior that I discovered a couple days ago on HPUX: a select with a delay of tv_sec = 0, tv_usec = 100 doesn't delay 1 second like a reasonable person would expect, but fails instantly with EINVAL. This causes the spinlock timeout in CreateCheckPoint to effectively be only a few microseconds rather than the intended ten minutes. So, if the postmaster happens to fire off a checkpoint process while some regular backend is doing something with the WAL log, kaboom. In short: please try the latest nightly snapshot (this fix is since beta5, unfortunately) and let me know if you still see a problem. regards, tom lane
Re[2]: [HACKERS] Re: [PATCHES] A patch for xlog.c
On Tue, 27 Feb 2001, jamexu wrote: Hello Tom, Tuesday, February 27, 2001, 12:23:25 AM, you wrote: TL This looks a lot like exchanging the devil we know (SysV shmem) for a TL devil we don't know. Do I need to remind you about, for example, the TL mmap bugs in early Linux releases? (I still vividly remember having to TL abandon mmap on a project a few years back that needed to be portable TL to Linux. Perhaps that colors my opinions here.) I don't think the TL problems with shmem are sufficiently large to justify venturing into TL a whole new terra incognita of portability issues and kernel bugs. TL regards, tom lane the only problem is because if we need to tune Postermaster to use large buffer while system havn't so many SYSV shared memory, in many systemes, we need to recompile OS kernel, this is a small problem to install PGSQL to product environment. What? You don't automatically recompile your OS kernel when you build a system in the first place?? First step on any OS install of FreeBSD is to rid myself of the 'extras' that are in the generic kernel, and enable SharedMemory (even if I'm not using PgSQL on that machine) ...
Re: Re[2]: [HACKERS] Re: [PATCHES] A patch for xlog.c
the only problem is because if we need to tune Postermaster to use large buffer while system havn't so many SYSV shared memory, in many systemes, we need to recompile OS kernel, this is a small problem to install PGSQL to product environment. Of course, if you haven't got mmap(), a recompile won't help ... I'd be somewhat more enthusiastic about mmap if I thought we could abandon the SysV shmem support completely, but I don't foresee that happening for a long while yet. regards, tom lane
Re[3]: [HACKERS] Re: [PATCHES] A patch for xlog.c
On Tue, 27 Feb 2001, jamexu wrote: Hello The, Tuesday, February 27, 2001, 11:00:05 AM, you wrote: THH On Tue, 27 Feb 2001, jamexu wrote: Hello Tom, Tuesday, February 27, 2001, 12:23:25 AM, you wrote: TL This looks a lot like exchanging the devil we know (SysV shmem) for a TL devil we don't know. Do I need to remind you about, for example, the TL mmap bugs in early Linux releases? (I still vividly remember having to TL abandon mmap on a project a few years back that needed to be portable TL to Linux. Perhaps that colors my opinions here.) I don't think the TL problems with shmem are sufficiently large to justify venturing into TL a whole new terra incognita of portability issues and kernel bugs. TL regards, tom lane the only problem is because if we need to tune Postermaster to use large buffer while system havn't so many SYSV shared memory, in many systemes, we need to recompile OS kernel, this is a small problem to install PGSQL to product environment. THH What? You don't automatically recompile your OS kernel when you build a THH system in the first place?? First step on any OS install of FreeBSD is to THH rid myself of the 'extras' that are in the generic kernel, and enable THH SharedMemory (even if I'm not using PgSQL on that machine) ... heihei, why do you think users always using FreeBSD and not other UNIX systemes? your assume is false. I don't ... I personally admin FreeBSD and Solaris boxen ... FreeBSD, first step is to always recompile the kernel after an install, to get rid of crud and add Shared Memory ... the Solaris boxes, you add a couple of lines to /etc/system and reboot, and you have Shared Memory ... I don't know about other 'commercial OSs', but I'd be shocked if a Linux admin never does any kernel config cleanup befor egoing production *shrug*
Re: Re[2]: [HACKERS] Re: [PATCHES] A patch for xlog.c
On Mon, 26 Feb 2001, Bruce Momjian wrote: the only problem is because if we need to tune Postermaster to use large buffer while system havn't so many SYSV shared memory, in many systemes, we need to recompile OS kernel, this is a small problem to install PGSQL to product environment. What? You don't automatically recompile your OS kernel when you build a system in the first place?? First step on any OS install of FreeBSD is to rid myself of the 'extras' that are in the generic kernel, and enable SharedMemory (even if I'm not using PgSQL on that machine) ... He is saying the machine is already in production. Suppose he has run PostgreSQL for a few months, then needs to increase number of buffers. He can't exceed the kernel limit unless he recompiles. Okay ... same applies to MMAP() though, I had to disappoint ... there are kernel limits that, at least under FreeBSD, do require a kernel recompile in order to exceed ... alot of them have been moved (maybe all now) to sysctl settable values ... but, again, under some of the commercial OSs, I don't think that anything but (as in Solaris) modifying something like /etc/system and rebooting will fix ...
Re: [HACKERS] vacuum analyze fails: ERROR: Unable to locate type oid 2230924 in catalog
Tatsuo Ishii [EMAIL PROTECTED] writes: *** parse_coerce.c.orig Sat Feb 3 20:07:53 2001 --- parse_coerce.cTue Feb 27 11:33:01 2001 *** *** 190,195 --- 190,201 Oid inputTypeId = input_typeids[i]; Oid targetTypeId = func_typeids[i]; + if (typeidIsValid(inputTypeId) == false) + return(false); + + if (typeidIsValid(targetTypeId) == false) + return(false); + /* no problem if same type */ if (inputTypeId == targetTypeId) continue; I'd suggest not arbitrarily erroring out when there is no need for a conversion, and not doing the cache lookup implied by typeidIsValid when it's not necessary to touch the type at all. Hence, I'd recommend moving this down a few lines. Also, conform to the surrounding coding style and add a comment: /* don't know what to do for the input type? then quit... */ if (inputTypeId == InvalidOid) return false; + /* don't choke on references to no-longer-existing types */ + if (!typeidIsValid(inputTypeId)) + return false; + + if (!typeidIsValid(targetTypeId)) + return false; /* * If input is an untyped string constant, assume we can convert * it to anything except a class type. */ BTW, is this sufficient to prevent the VACUUM failure, or are there more problems downstream? regards, tom lane
Re: Re[2]: [HACKERS] Re: [PATCHES] A patch for xlog.c
the only problem is because if we need to tune Postermaster to use large buffer while system havn't so many SYSV shared memory, in many systemes, we need to recompile OS kernel, this is a small problem to install PGSQL to product environment. What? You don't automatically recompile your OS kernel when you build a system in the first place?? First step on any OS install of FreeBSD is to rid myself of the 'extras' that are in the generic kernel, and enable SharedMemory (even if I'm not using PgSQL on that machine) ... He is saying the machine is already in production. Suppose he has run PostgreSQL for a few months, then needs to increase number of buffers. He can't exceed the kernel limit unless he recompiles. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] vacuum analyze fails: ERROR: Unable to locate type oid2230924 in catalog
This looks very safe and I believe should be applied. vacuum analyze on pg_type fails if bogus entries remain in pg_operator. Here is a sample script to reproduce the problem. drop table t1; create table t1(i int); drop function foo(t1,t1); create function foo(t1,t1) returns bool as 'select true' language 'sql'; create operator = ( leftarg = t1, rightarg = t1, commutator = =, procedure = foo ); drop table t1; vacuum analyze; To fix the problem I propose following patches. Comments? -- Tatsuo Ishii *** parse_coerce.c.orig Sat Feb 3 20:07:53 2001 --- parse_coerce.cTue Feb 27 11:33:01 2001 *** *** 190,195 --- 190,201 Oid inputTypeId = input_typeids[i]; Oid targetTypeId = func_typeids[i]; + if (typeidIsValid(inputTypeId) == false) + return(false); + + if (typeidIsValid(targetTypeId) == false) + return(false); + /* no problem if same type */ if (inputTypeId == targetTypeId) continue; -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: Re[2]: [HACKERS] Re: [PATCHES] A patch for xlog.c
Okay ... same applies to MMAP() though, I had to disappoint ... there are kernel limits that, at least under FreeBSD, do require a kernel recompile in order to exceed ... alot of them have been moved (maybe all now) to sysctl settable values ... but, again, under some of the commercial OSs, I don't think that anything but (as in Solaris) modifying something like /etc/system and rebooting will fix ... But the mmap() limits are much larger than the SysV limits, aren't they, to the point where you would never have to fiddle with the mmap() limits to get 100mb of buffers, right? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] vacuum analyze fails: ERROR: Unable to locate typeoid 2230924 in catalog
I'd suggest not arbitrarily erroring out when there is no need for a conversion, and not doing the cache lookup implied by typeidIsValid when it's not necessary to touch the type at all. Hence, I'd recommend moving this down a few lines. Also, conform to the surrounding coding style and add a comment: Thanks for the advice. /* don't know what to do for the input type? then quit... */ if (inputTypeId == InvalidOid) return false; + /* don't choke on references to no-longer-existing types */ + if (!typeidIsValid(inputTypeId)) + return false; + + if (!typeidIsValid(targetTypeId)) + return false; I thought "typeidIsValid(targetTypeId) == false" is better than "!typeidIsValid(targetTypeId)"? BTW, is this sufficient to prevent the VACUUM failure, or are there more problems downstream? The patches fix the particular case. However I'm not sure there is no lurking problem. -- Tatsuo Ishii
Re: Re[2]: [HACKERS] Re: [PATCHES] A patch for xlog.c
On Mon, 26 Feb 2001, Bruce Momjian wrote: Okay ... same applies to MMAP() though, I had to disappoint ... there are kernel limits that, at least under FreeBSD, do require a kernel recompile in order to exceed ... alot of them have been moved (maybe all now) to sysctl settable values ... but, again, under some of the commercial OSs, I don't think that anything but (as in Solaris) modifying something like /etc/system and rebooting will fix ... But the mmap() limits are much larger than the SysV limits, aren't they, to the point where you would never have to fiddle with the mmap() limits to get 100mb of buffers, right? Not necessarily ... it depends on the admin of the server ... then again, I don't consider it a hassle to add a couple of lines to my kernel config (or /etc/system) and reboot *shrug* to me, its just part of the admin process ...
Re: Re[2]: [HACKERS] Re: [PATCHES] A patch for xlog.c
But the mmap() limits are much larger than the SysV limits, aren't they, to the point where you would never have to fiddle with the mmap() limits to get 100mb of buffers, right? Not necessarily ... it depends on the admin of the server ... then again, I don't consider it a hassle to add a couple of lines to my kernel config (or /etc/system) and reboot *shrug* to me, its just part of the admin process ... Are the kernel SysV defaults smaller than the mmap() kernel defaults? I know it is easy for you, but the number of reports and problems we hear about shows it is an issue for some. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] vacuum analyze fails: ERROR: Unable to locate type oid 2230924 in catalog
Tatsuo Ishii [EMAIL PROTECTED] writes: I thought "typeidIsValid(targetTypeId) == false" is better than "!typeidIsValid(targetTypeId)"? I've always thought that "== true" and "== false" on something that's already a boolean are not good style. It's a matter of taste I suppose. But note that the existing calls on typeidIsValid are coded that way... regards, tom lane
Re: [HACKERS] vacuum analyze fails: ERROR: Unable to locate typeoid 2230924 in catalog
Tatsuo Ishii [EMAIL PROTECTED] writes: I thought "typeidIsValid(targetTypeId) == false" is better than "!typeidIsValid(targetTypeId)"? I've always thought that "== true" and "== false" on something that's already a boolean are not good style. It's a matter of taste I suppose. But note that the existing calls on typeidIsValid are coded that way... regards, tom lane I see. -- Tatsuo Ishii
Re: Re[2]: [HACKERS] Re: [PATCHES] A patch for xlog.c
Bruce Momjian [EMAIL PROTECTED] writes: I know it is easy for you, but the number of reports and problems we hear about shows it is an issue for some. We hear some reports, but not a lot. We have no idea whatever what problems might ensue if we used mmap instead. I'm dubious that SysV shmem creates enough problems to justify replacing it with a solution of essentially unknown portability characteristics... regards, tom lane
Re[4]: [HACKERS] Re: [PATCHES] A patch for xlog.c
Hello Tom, Tuesday, February 27, 2001, 12:45:18 PM, you wrote: TL Bruce Momjian [EMAIL PROTECTED] writes: I know it is easy for you, but the number of reports and problems we hear about shows it is an issue for some. TL We hear some reports, but not a lot. We have no idea whatever what TL problems might ensue if we used mmap instead. I'm dubious that SysV TL shmem creates enough problems to justify replacing it with a solution TL of essentially unknown portability characteristics... TL regards, tom lane could anyone investigate mmap() in many modern UNIX systems to prove that mmap() is so un-portable? it seems mmap() is a portable problem like you said, but I think SYSV shmem for PGSQL is a installation problem. you push some difficults to end user, and take easy taskes for yourself. Xu Yifeng
Re: [HACKERS] vacuum analyze fails: ERROR: Unable to locate typeoid 2230924 in catalog
I have comitted the fix to parser/parse_coarse.c. My previous patches was not correct and I changed the checking right after typeInheritsFrom. -- Tatsuo Ishii vacuum analyze on pg_type fails if bogus entries remain in pg_operator. Here is a sample script to reproduce the problem. drop table t1; create table t1(i int); drop function foo(t1,t1); create function foo(t1,t1) returns bool as 'select true' language 'sql'; create operator = ( leftarg = t1, rightarg = t1, commutator = =, procedure = foo ); drop table t1; vacuum analyze;
