[HACKERS] FW: PGBuildfarm member snake Branch REL8_0_STABLE Status changed from OK to Make failure
Oops. 8.0, 8.1 and dev failed on Snake last night :-( /D -Original Message- From: PG Build Farm [mailto:[EMAIL PROTECTED] Sent: Wed 2/1/2006 2:08 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: PGBuildfarm member snake Branch REL8_0_STABLE Status changed from OK to Make failure The PGBuildfarm member snake had the following event on branch REL8_0_STABLE: Status changed from OK to Make failure The snapshot timestamp for the build that triggered this notification is: 2006-02-01 02:05:48 The specs of this machine are: OS: Windows / Server 2003 SP1 Arch: i686 Comp: gcc / 3.4.2 For more information, see http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=snakebr=REL8_0_STABLE ---(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
[HACKERS] system triggers
HEY!!! Are You going to implement some system triggers like in ORACLE i.e. on login trigger ?? -- Best regards LaroG ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] system triggers
Hello, Propably not. But You can use this patch http://gorda.di.uminho.pt/community/pgsqlhooks/ regards Pavel Stehule HEY!!! Are You going to implement some system triggers like in ORACLE i.e. on login trigger ?? -- Best regards LaroG ---(end of broadcast)--- TIP 6: explain analyze is your friend _ Chcete sdilet sve obrazky a hudbu s prateli? http://messenger.msn.cz/ ---(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: [HACKERS] A note about testing EXEC_BACKEND on recent Linuxen
Added code comment: /* * Attach process to shared data structures. If testing * EXEC_BACKEND on Linux, you must run this as root * before starting the postmaster: * * echo 0 /proc/sys/kernel/randomize_va_space * * This prevents a randomized stack base address that causes * child shared memory to be at a different address than * the parent, making it impossible to attached to shared * memory. Return the value to '1' when finished. */ CreateSharedMemoryAndSemaphores(false, 0); --- Tom Lane wrote: I just wasted a couple hours trying to determine why an EXEC_BACKEND build would randomly fail on Fedora Core 4. It seems the reason is that by default, recent Linux kernels randomize the stack base address --- not by a lot, but enough to cause child processes to sometimes be unable to attach to the shared memory segment at the same place the postmaster did. You can work around this by doing (as root) echo 0 /proc/sys/kernel/randomize_va_space before starting the postmaster. You'll probably want to set it back to 1 when done experimenting with EXEC_BACKEND, since address randomization is a useful security hack. Just seems like something that should be in our archives ... regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Cleaning up the INET/CIDR mess
Peter Eisentraut wrote: Bruce Momjian wrote: I agree. Let's do the zeroing and see if people complain about it. I'm complaining. Losing data on a cast is not common behavior. [ Sorry for the delay.] OK, that's clear. :-) I looked around to see if I could find any places where we implicitly cast and lose data. I tried factorial(3.2), and that cast failed. However, if I do this explicit cast: test= SELECT '3.4'::float8::integer; int4 -- 3 (1 row) it works. Can't we consider this: test= SELECT '1.2.3.4/24'::inet::cidr; cidr 1.2.3.0/24 (1 row) a similar situation? inet is like float8 (bits beyond the masklen), while cidr is like int4. Is it only implicit casts you are worried about? Do we have any of those left? All functions that take cidr also have an inet version, so I don't see how an implicit cast to cidr could happen. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Cleaning up the INET/CIDR mess
Bruce Momjian pgman@candle.pha.pa.us writes: Is it only implicit casts you are worried about? Do we have any of those left? All functions that take cidr also have an inet version, so I don't see how an implicit cast to cidr could happen. The cast to cidr isn't implicit anymore anyway. What I currently have it marked as is assignment. You could make the argument that it should be marked explicit only to avoid silent loss of data. But we have the numeric downcasts marked as assignment so I don't see why this case is different. If you do insert into int4_tbl values(7.7); what's inserted into the integer column is 8, and I've not heard anyone complaining that that represents unacceptable data loss. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Backslashes in string literals
Kevin Grittner wrote: We found a bug in the code from my first patch. Since it was a low frequency, non-destructive type of problem for us, I was able to take my time and look over the task a little more closely. Attached is a patch which should come close to implementing the TODO. In particular, it is now implemented as a configurable option, which can be set in the postgresql.conf file or at run time. There are some remaining issues: (1) I couldn't figure out the best way to obtain a value for standard_conforming_strings in the psql version of the scanner. For our needs, could just assume it is always on, so I left it that way. Someone with a better handle on this issue can hopefully finish that part. Alternatively, if you give me some direction, I might have time to generalize it. As far as I can tell from some testing today, everything works fine issuing statements through a connection, but psql isn't settled down. Sounds like you made great progress! The proper way to do (1) is to call libpq's pqSaveParameterStatus() from psql. Take a look for psql's session_username(). It is called everytime the prompt is printed if the username is required. One great feature of using pqSaveParameterStatus() is that it reads server packets and keeps the tracked value updated for you without query overhead. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(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: [HACKERS] Some platform-specific MemSet research
My guess is that there is some really fast assembler for memory copy on AIX, and only libc memset() has it. If you want, we can make MEMSET_LOOP_LIMIT in c.h a configure value, and allow template/aix to set it to zero, causing memset() to be always used. Are you prepared to make this optimization decision for all AIX users using gcc, or only for certain versions? --- Seneca Cunningham wrote: Martijn van Oosterhout wrote: On Tue, Jan 24, 2006 at 05:24:28PM -0500, Seneca Cunningham wrote: After reading the post on -patches proposing that MemSet be changed to use long instead of int32 on the grounds that a pair of x86-64 linux boxes took less time to execute the long code 64*10^6 times[1], I took a look at how the testcode performed on AIX with gcc. While the switch to long did result in a minor performance improvement, dropping the MemSetLoop in favour of the native memset resulted in the tests taking ~25% the time as the MemSetLoop-like int loop. The 32-bit linux system I ran the expanded tests on showed that for the buffer size range that postgres can use the looping MemSet instead of memset (size = 1024 bytes), MemSet generally had better performance. Could you please check the asm output to see what's going on. We've had tests like these produce odd results in the past because the compiler optimised away stuff that didn't have any effect. Since every memset after the first is a no-op, you want to make sure it's still actually doing the work... Well, on both linux and AIX, all 30 of the 6400 iterations loops from the source exist (10 int, 10 long, 10 memset). According to my understanding of the assembler, memset itself is only called for values = 64 bytes on both platforms and the memset is called in each iteration. The assembler for the 64 byte loops, with prepended line number, first loop MemSetLoop int-variant, second loop memset, third loop MemSetLoop long-variant: 64-bit AIX: 419 addi 3,1,112 420 li 4,0 421 bl .gettimeofday 422 nop 423 lis 10,0x3d0 424 cmpld 6,26,16 425 li 11,0 426 ori 10,10,36864 427 L..41: 428 bge 6,L..42 429 mr 9,26 430 li 0,0 431 L..44: 432 stw 0,0(9) 433 addi 9,9,4 434 cmpld 7,16,9 435 bgt 7,L..44 436 L..42: 437 addi 0,11,1 438 extsw 11,0 439 cmpw 7,11,10 440 bne+ 7,L..41 441 li 4,0 442 mr 3,22 443 lis 25,0x3d0 444 li 28,0 445 bl .gettimeofday 446 nop 447 li 4,64 448 addi 5,1,112 449 ld 3,LC..9(2) 450 mr 6,22 451 ori 25,25,36864 452 bl .print_time 453 addi 3,1,112 454 li 4,0 455 bl .gettimeofday 456 nop 457 L..46: 458 mr 3,26 459 li 4,0 460 li 5,64 461 bl .memset 462 nop 463 addi 0,28,1 464 extsw 28,0 465 cmpw 7,28,25 466 bne+ 7,L..46 467 li 4,0 468 mr 3,22 469 bl .gettimeofday 470 nop 471 li 4,64 472 addi 5,1,112 473 ld 3,LC..11(2) 474 mr 6,22 475 bl .print_time 476 addi 3,1,112 477 li 4,0 478 bl .gettimeofday 479 nop 480 lis 10,0x3d0 481 cmpld 6,26,16 482 li 11,0 483 ori 10,10,36864 484 L..48: 485 bge 6,L..49 486 mr 9,26 487 li 0,0 488 L..51: 489 std 0,0(9) 490 addi 9,9,8 491 cmpld 7,9,16 492 blt 7,L..51 493 L..49: 494 addi 0,11,1 495 extsw 11,0 496 cmpw 7,11,10 497 bne+ 7,L..48 498 li 4,0 499 mr 3,22 500 bl .gettimeofday 501 nop 502 li 4,64 503 addi 5,1,112 504 ld 3,LC..13(2) 505 mr 6,22 506 bl .print_time 32-bit Linux: 387 popl%ecx 388 popl%edi 389 pushl $0 390 leal-20(%ebp), %edx 391 pushl %edx 392 callgettimeofday 393 xorl%edx, %edx 394 addl$16, %esp 395 .L41: 396 movl-4160(%ebp), %eax 397 cmpl%eax, -4144(%ebp) 398 jae .L42 399 movl-4144(%ebp), %eax 400 .L44: 401 movl$0, (%eax) 402 addl$4, %eax 403 cmpl%eax, -4160(%ebp) 404 ja .L44 405 .L42: 406 incl%edx 407 cmpl$6400, %edx 408 jne .L41 409 subl$8, %esp 410 pushl $0 411 leal-28(%ebp), %edx 412 pushl %edx 413 callgettimeofday 414 leal-28(%ebp), %eax 415 movl%eax, (%esp) 416 leal-20(%ebp), %ecx
Re: [HACKERS] autovacuum
matthew@zeut.net (Matthew T. O'Connor) writes: Legit concern. However one of the things that autovacuum is supposed to do is not vacuum tables that don't need it. This can result in an overal reduction in vacuum overhead. In addition, if you see that autovacuum is firing off vacuum commands during the day and they are impacting your response time, then you can play with the vacuum cost delay settings that are design to throttle down the IO impact vacuum commands can have. In addition if you use 8.1, you can set per table thresholds, per table vacuum cost delay settings, and autovacuum will respect the work done by non-autovacuum vacuum commands. Meaning that if you manually vacuum tables at night during a maintenance window, autovacuum will take that into account. Contrib autovacuum couldn't do this. Hope that helps. Real world feed-back is always welcome. I have a question/suggestion... Something we found useful with Slony-I was the notion of checking the eldest XID on the system to see if there was any point at all in bothering to vacuum. I don't see anything analagous in autovacuum.c; this might well be a useful addition. In the Slony-I cleanup thread loop, we collect, in each iteration, the current earliest XID. In each iteration of this loop, we check to see if that XID has changed. - First time thru, it changes from 0 to 'some value' and so tries to do a vacuum. - But supposing you have some long running transaction (say, a pg_dump that runs for 2h), it becomes pretty futile to bother trying to vacuum things for the duration of that transaction, because that long running transaction will, via MVCC, hold onto any old tuples. It strikes me as a slick idea for autovacuum to take on that behaviour. If the daily backup runs for 2h, then it is quite futile to bother vacuuming a table multiple times during that 2h period when none of the tuples obsoleted during the 2h period will be able to be cleaned out until the end. Presumably this means that, during that 2h period, pg_autovacuum would probably only issue ANALYZE statements... -- let name=cbbrowne and tld=ntlug.org in String.concat @ [name;tld];; http://www.ntlug.org/~cbbrowne/languages.html Rules of the Evil Overlord #51. If one of my dungeon guards begins expressing concern over the conditions in the beautiful princess' cell, I will immediately transfer him to a less people-oriented position. http://www.eviloverlord.com/ ---(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: [HACKERS] autovacuum
Chris Browne wrote: It strikes me as a slick idea for autovacuum to take on that behaviour. If the daily backup runs for 2h, then it is quite futile to bother vacuuming a table multiple times during that 2h period when none of the tuples obsoleted during the 2h period will be able to be cleaned out until the end. Hmm, yeah, sounds useful. There's one implementation issue to notice however, and it's that the autovacuum process dies and restarts for each iteration, so there's no way for it to remember previous state unless it's saved somewhere permanent, as the stats info is. However this seems at least slightly redundant with the maintenance window feature -- you could set a high barrier to vacuum during the daily backup period instead. (Anybody up for doing this job?) -- Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC No single strategy is always right (Unless the boss says so) (Larry Wall) ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] autovacuum
Alvaro Herrera wrote: Chris Browne wrote: It strikes me as a slick idea for autovacuum to take on that behaviour. If the daily backup runs for 2h, then it is quite futile to bother vacuuming a table multiple times during that 2h period when none of the tuples obsoleted during the 2h period will be able to be cleaned out until the end. Hmm, yeah, sounds useful. There's one implementation issue to notice however, and it's that the autovacuum process dies and restarts for each iteration, so there's no way for it to remember previous state unless it's saved somewhere permanent, as the stats info is. However this seems at least slightly redundant with the maintenance window feature -- you could set a high barrier to vacuum during the daily backup period instead. (Anybody up for doing this job?) I can't promise anything, but it's on my list of things to hopefully find time for in the coming months. No way I can start it in Feb, but maybe sometime in March. Anyone else? Matt ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] TODO-Item: B-tree fillfactor control
ITAGAKI Takahiro wrote: Hi Hackers, I'm trying the following TODO item: [Indexes] - Add fillfactor to control reserved free space during index creation I have already made an patch and it seemed to work well. Great. And now, I need advice on some issues. - Is it appropriate to use GUC variables to control fillfactors? Is it better to extend CREATE INDEX / REINDEX grammar? I think it has to be part of CREATE INDEX and ALTER INDEX. Is there a use for separate node and leaf settings? This patch needs documentation, and if we have separate items, we are going to have to explain when to use node or leaf. - Should indexes remember their fillfactors when they are created? The last fillfactors will be used on next reindex. They should remember, for sure, and REINDEX should use it. It think this is similar to the ALTER TABLE ALTER [ COLUMN ] ... SET STATISTICS functionality. It will need to be dumped as well by pg_dump. If you need help with any of this, let me know. - Is fillfactor useful for hash and gist indexes? I think hash does not need it, but gist might need it. Not sure. We don't know what type of index a GIST will be so we have no way of knowing. I am thinking we can implement just btree now and the GIST folks can add it later if they want. My guess is that each GIST is going to behave differently for different fill-factors, so if allow it to be set for GIST, GIST developers can pull the value if they want. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] log_min_messages and debug levels
FYI, this will be fixed in 8.1.3. --- Jaime Casanova wrote: Hi, in my machine (win xp) i was trying to start psql (8.1.1) with log_min_messages to debug5 (just to see the messages :) but even the service start i cannot use psql nor pgadmin i receive an error of server closed the connection unexpectedly postgres=# select version(); version -- PostgreSQL 8.1.1 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.4.2 (mingw-special) (1 fila) Sorry, my postgres is in spanish but maybe you can recognize the message... ;) C:\Archivos de programa\PostgreSQL\8.1\binpsql -U postgres pruebas psql: el servidor ha cerrado la conexi?n inesperadamente, probablemente porque termin? de manera anormal antes o durante el procesamiento de la petici?n. is this expected on windows platforms? -- regards, Jaime Casanova (DBA: DataBase Aniquilator ;) ---(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 -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] autovacuum
[EMAIL PROTECTED] (Alvaro Herrera) writes: Chris Browne wrote: It strikes me as a slick idea for autovacuum to take on that behaviour. If the daily backup runs for 2h, then it is quite futile to bother vacuuming a table multiple times during that 2h period when none of the tuples obsoleted during the 2h period will be able to be cleaned out until the end. Hmm, yeah, sounds useful. There's one implementation issue to notice however, and it's that the autovacuum process dies and restarts for each iteration, so there's no way for it to remember previous state unless it's saved somewhere permanent, as the stats info is. Hmm. It restarts repeatedly??? Hmmm... However this seems at least slightly redundant with the maintenance window feature -- you could set a high barrier to vacuum during the daily backup period instead. (Anybody up for doing this job?) In effect, this would be an alternative to the window feature. You open the window by starting pg_dump; pg_autovacuum would automatically notice that as the eldest XID, and stop work until the pg_dump actually finished. In a way, it strikes me as more elegant; it would automatically notice backup windows, noticing *exact* start and end times... -- select 'cbbrowne' || '@' || 'ntlug.org'; http://www.ntlug.org/~cbbrowne/linuxxian.html I'm sorry, Mr. Kipling, but you just don't know how to use the English Language. -- Editor of the San Francisco Examiner, informing Rudyard Kipling, who had one article published in the newspaper, that he needn't bother submitting a second, 1889 ---(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: [HACKERS] TODO-Item: B-tree fillfactor control
Bruce Momjian pgman@candle.pha.pa.us writes: - Should indexes remember their fillfactors when they are created? The last fillfactors will be used on next reindex. They should remember, for sure, and REINDEX should use it. It think this is similar to the ALTER TABLE ALTER [ COLUMN ] ... SET STATISTICS functionality. It will need to be dumped as well by pg_dump. If you want it to be dumped by pg_dump (which is debatable IMHO) then it MUST NOT be a syntax extension, it has to be driven by a GUC variable, else we have compatibility problems with the dumps. We just went through this with WITH/WITHOUT OIDS. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] TODO-Item: B-tree fillfactor control
Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: - Should indexes remember their fillfactors when they are created? The last fillfactors will be used on next reindex. They should remember, for sure, and REINDEX should use it. It think this is similar to the ALTER TABLE ALTER [ COLUMN ] ... SET STATISTICS functionality. It will need to be dumped as well by pg_dump. If you want it to be dumped by pg_dump (which is debatable IMHO) then it MUST NOT be a syntax extension, it has to be driven by a GUC variable, else we have compatibility problems with the dumps. We just went through this with WITH/WITHOUT OIDS. OK, so we are going to issue a GUC to set the fill factor in pg_dump, but still have a fillfactor syntax for use by users? That is how we do WITH/WITHOUT OIDS. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] autovacuum
Alvaro Herrera [EMAIL PROTECTED] writes: Hmm, yeah, sounds useful. There's one implementation issue to notice however, and it's that the autovacuum process dies and restarts for each iteration, so there's no way for it to remember previous state unless it's saved somewhere permanent, as the stats info is. I think you'd really need to remember the previous oldest XID on a per-table basis to get full traction out of the idea. But weren't we thinking of tracking something isomorphic to this for purposes of minimizing anti-wraparound VACUUMs? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] A note about testing EXEC_BACKEND on recent Linuxen
On Wed, Feb 01, 2006 at 10:59:39AM -0500, Bruce Momjian wrote: * Attach process to shared data structures. If testing * EXEC_BACKEND on Linux, you must run this as root * before starting the postmaster: * * echo 0 /proc/sys/kernel/randomize_va_space * * This prevents a randomized stack base address that causes * child shared memory to be at a different address than * the parent, making it impossible to attached to shared * memory. Return the value to '1' when finished. Hmm, are there no other ways that this problem can manifest itself? ISTM that we're relying completely on the kernel to map it in the same place each time. Maybe one day someone changes the startup procedure to allocate some more memory and it gets mapped somewhere else. A better solution would be to explicitly map it in the child processes. Basically, store the shared memory base at the beginning of the shared memory block. Then when the child maps it it can verify the location. It if doesn't match, unmap and remap at the right place. The first half should probably at least be implemented to detect the situation (ERROR: Shared memory block mapped at wrong location). But given that you could probably solve the problem completely... Ofcourse, there's the risk the child has already allocated memory where it should be (the randomize space flag might cause this). Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. signature.asc Description: Digital signature
Re: [HACKERS] A note about testing EXEC_BACKEND on recent Linuxen
Martijn van Oosterhout kleptog@svana.org writes: Hmm, are there no other ways that this problem can manifest itself? ISTM that we're relying completely on the kernel to map it in the same place each time. Maybe one day someone changes the startup procedure to allocate some more memory and it gets mapped somewhere else. In the normal non-EXEC_BACKEND scenario, there's no issue, so I see no great need to worry about this unduly. A better solution would be to explicitly map it in the child processes. Basically, store the shared memory base at the beginning of the shared memory block. Then when the child maps it it can verify the location. It if doesn't match, unmap and remap at the right place. That is utterly irrelevant to the problem, unfortunately; the shmat request already specifies where we need to map it, and the problem arises when that bit of address space is already taken in the child process. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] A note about testing EXEC_BACKEND on recent Linuxen
Tom Lane wrote: Martijn van Oosterhout kleptog@svana.org writes: Hmm, are there no other ways that this problem can manifest itself? ISTM that we're relying completely on the kernel to map it in the same place each time. Maybe one day someone changes the startup procedure to allocate some more memory and it gets mapped somewhere else. In the normal non-EXEC_BACKEND scenario, there's no issue, so I see no great need to worry about this unduly. A better solution would be to explicitly map it in the child processes. Basically, store the shared memory base at the beginning of the shared memory block. Then when the child maps it it can verify the location. It if doesn't match, unmap and remap at the right place. That is utterly irrelevant to the problem, unfortunately; the shmat request already specifies where we need to map it, and the problem arises when that bit of address space is already taken in the child process. FYI, the shared memory address was originally relocatable by using offsets to address it from the child, but now that we use fork() on Unix, it isn't an issue, and Win32 seems to be OK. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] A note about testing EXEC_BACKEND on recent Linuxen
Bruce Momjian pgman@candle.pha.pa.us writes: FYI, the shared memory address was originally relocatable by using offsets to address it from the child, but now that we use fork() on Unix, it isn't an issue, and Win32 seems to be OK. In the worst case we could go back to using offsets everywhere, but I'm really reluctant to do that for reasons of code clarity and reliability. The main problem with it is that you have to explicitly cast to and from the correct pointer type, which is not only ugly but completely defeats any chance of the compiler catching wrong-type errors. What I am seeing on Fedora 4 (I suppose it's common to most recent Linux versions) is that the system preferentially maps the shared memory segment just below the stack, which is good from the point of view of preserving maximum address space for the heap, but not so great if stack size changes or the stack moves a bit. It'd be possible to get a little more flexibility by requesting a non-default attach location for the postmaster's initial shmat call. I'm not interested in getting into that if we don't absolutely have to, but it might be the best answer if we find ourselves seeing similar issues on specific platforms (ie Windows) in the future. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] autovacuum
[EMAIL PROTECTED] (Tom Lane) writes: Alvaro Herrera [EMAIL PROTECTED] writes: Hmm, yeah, sounds useful. There's one implementation issue to notice however, and it's that the autovacuum process dies and restarts for each iteration, so there's no way for it to remember previous state unless it's saved somewhere permanent, as the stats info is. I think you'd really need to remember the previous oldest XID on a per-table basis to get full traction out of the idea. But weren't we thinking of tracking something isomorphic to this for purposes of minimizing anti-wraparound VACUUMs? I think I'd like that even better :-). In the Slony-I case, the tables being vacuumed are ones where the deletion is taking place within the same thread, so that having one XID is plenty enough because the only thing that should be touching the tables is the cleanup thread, which is invoked every 10 minutes. One XID is enough protection for that, as least as a reasonable approximation. Tracking just the one eldest XID is still quite likely to be *reasonably* useful with autovacuum, assuming there isn't a by-table option. By-table would be better, though. -- (reverse (concatenate 'string gro.mca @ enworbbc)) http://www3.sympatico.ca/cbbrowne/sgml.html Politics is not a bad profession. If you succeed there are many rewards, if you disgrace yourself you can always write a book. -- Ronald Reagan ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] A note about testing EXEC_BACKEND on recent Linuxen
Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: FYI, the shared memory address was originally relocatable by using offsets to address it from the child, but now that we use fork() on Unix, it isn't an issue, and Win32 seems to be OK. In the worst case we could go back to using offsets everywhere, but I'm really reluctant to do that for reasons of code clarity and reliability. The main problem with it is that you have to explicitly cast to and from the correct pointer type, which is not only ugly but completely defeats any chance of the compiler catching wrong-type errors. As I remember, the offsets also had a performance and/or storage impact we don't want either. What I am seeing on Fedora 4 (I suppose it's common to most recent Linux versions) is that the system preferentially maps the shared memory segment just below the stack, which is good from the point of view of preserving maximum address space for the heap, but not so great if stack size changes or the stack moves a bit. It'd be possible to get a little more flexibility by requesting a non-default attach location for the postmaster's initial shmat call. I'm not interested in getting into that if we don't absolutely have to, but it might be the best answer if we find ourselves seeing similar issues on specific platforms (ie Windows) in the future. Agreed. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(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
[HACKERS] Question about ALTER TABLE SET TABLESPACE locing behaviour
Does ALTER TABLE SET TABLESPACE lock the table while copying data to new location ? If so, then does it lock the whole table, or just the tuples belonging to currently copied 1G file ? Hannu ---(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: [HACKERS] Question about ALTER TABLE SET TABLESPACE locing behaviour
Hannu Krosing [EMAIL PROTECTED] writes: Does ALTER TABLE SET TABLESPACE lock the table It had better ... see nearby discussion about relaxing locking for TRUNCATE. Exactly the same problem that at commit we'd be cutting the ground out from under any concurrent query. regards, tom lane ---(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
[HACKERS] 8.1.3?
Hey guys, When do you reckon 8.1.3 will be released? That has the massive speedup on GiST index creation, right? I'm planning on a major upgrade soon, but the greatest time in reload is taken up by index creation time, so I'll hang out for 8.1.3. Any ETA? Chris ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] TODO-Item: B-tree fillfactor control
If you want it to be dumped by pg_dump (which is debatable IMHO) then it MUST NOT be a syntax extension, it has to be driven by a GUC variable, else we have compatibility problems with the dumps. We just went through this with WITH/WITHOUT OIDS. Compatibility problems? CREATE INDEX isn't an SQL standard command is it? Chris ---(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: [HACKERS] TODO-Item: B-tree fillfactor control
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Compatibility problems? CREATE INDEX isn't an SQL standard command is it? No, but it'll cause unnecessary cross-version compatibility issues for us. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.1.3?
Christopher Kings-Lynne [EMAIL PROTECTED] writes: When do you reckon 8.1.3 will be released? We haven't really thought about it yet ... if you're desperate for that tsearch2 patch, you could pull REL8_1_STABLE branch tip from CVS and use that ... regards, tom lane ---(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: [HACKERS] TODO-Item: B-tree fillfactor control
Tom Lane wrote: Christopher Kings-Lynne [EMAIL PROTECTED] writes: Compatibility problems? CREATE INDEX isn't an SQL standard command is it? No, but it'll cause unnecessary cross-version compatibility issues for us. It is true it isn't SQL standard, but I think our CREATE INDEX syntax matches many vendor's syntax in most cases. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
