Re: [PATCHES] slru.c race condition (was Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags 0x01),)

2005-10-31 Thread Tom Lane
I wrote: OK, I think I see it. The problem is that the code in slru.c is careful about not modifying state when it doesn't hold the proper lock, but not so careful about not *inspecting* state without the proper lock. ... I'm still thinking about how to make a real fix without introducing

Re: [PATCHES] slru.c race condition (was Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags

2005-10-31 Thread Bruce Momjian
Good analysis. I guess the question is what patch would we put into a subrelease? If you go for a new state code, rather than a separate boolean, does it reduce the size of the patch? --- Tom Lane wrote: I wrote: OK, I

Re: [PATCHES] slru.c race condition (was Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags 0x01),)

2005-10-31 Thread Tom Lane
Bruce Momjian pgman@candle.pha.pa.us writes: If you go for a new state code, rather than a separate boolean, does it reduce the size of the patch? No, and it certainly wouldn't improve my level of confidence in it ... regards, tom lane ---(end

Re: [PATCHES] slru.c race condition (was Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags

2005-10-31 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: If you go for a new state code, rather than a separate boolean, does it reduce the size of the patch? No, and it certainly wouldn't improve my level of confidence in it ... Well, then what real options do we have? It seems the

Re: [PATCHES] slru.c race condition (was Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags 0x01),)

2005-10-31 Thread Tom Lane
Bruce Momjian pgman@candle.pha.pa.us writes: Well, then what real options do we have? It seems the patch is just required for all branches. I think it would be possible to fix it in a less invasive way by taking and releasing the ControlLock an extra time in SimpleLruReadPage and

Re: [PATCHES] [HACKERS] FKs on temp tables: hard, or just omitted?

2005-10-31 Thread Bruce Momjian
I have applied a more limited patch that mentions this. I do not want to mention _why_ we do not implement it because it is partly performance and partly complexity, I think, and some combinations make no sense, like temporary primary and non-temp foreign.

Re: [PATCHES] slru.c race condition (was Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags

2005-10-31 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: Well, then what real options do we have? It seems the patch is just required for all branches. I think it would be possible to fix it in a less invasive way by taking and releasing the ControlLock an extra time in

Re: [PATCHES] slru.c race condition (was Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags 0x01),)

2005-10-31 Thread Tom Lane
Bruce Momjian pgman@candle.pha.pa.us writes: To me a performance problem is much harder get reports on and to locate than a real fix to the problem. I think if a few people eyeball the patch, it is OK for application. Are backpatches significantly different? Well, the logic is the same all

Re: [PATCHES] slru.c race condition (was Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags 0x01),)

2005-10-31 Thread Tom Lane
I wrote: I think it would be possible to fix it in a less invasive way by taking and releasing the ControlLock an extra time in SimpleLruReadPage and SimpleLruWritePage. What's indeterminate about that is the performance cost. Attached is an alternative patch that does it this way. I

Re: [PATCHES] slru.c race condition (was Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags

2005-10-31 Thread Bruce Momjian
OK, this is the way to fix for 8.0 and earlier. It is up to you about 8.1. I think we can handle the larger patch if we do another RC. --- Tom Lane wrote: I wrote: I think it would be possible to fix it in a less

Re: [PATCHES] slru.c race condition (was Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags 0x01),)

2005-10-31 Thread Tom Lane
Bruce Momjian pgman@candle.pha.pa.us writes: OK, this is the way to fix for 8.0 and earlier. It is up to you about 8.1. I think we can handle the larger patch if we do another RC. Well, I'd like not to do another RC, so I'll hold the larger patch for 8.2. We still need a test to confirm it

Re: [PATCHES] Partitioning docs

2005-10-31 Thread Simon Riggs
On Mon, 2005-10-31 at 02:46 +, Simon Riggs wrote: I've been working on some docs for Constraining Exclusion Partitioning for some time now. Deadlines seem to be looming, or may even have passed, so it seems sensible to submit what I have now. Many thanks to Josh Berkus for providing the

Re: [PATCHES] Partitioning docs

2005-10-31 Thread Neil Conway
On Mon, 2005-31-10 at 22:41 +, Simon Riggs wrote: I believe this is now complete and ready for application. The changes need a fair bit of copy editing and SGML policy work, but that is probably easier to do once it has been applied. Barring any objections I'll apply the patch within 24

Re: [PATCHES] Partitioning docs

2005-10-31 Thread Tom Lane
Neil Conway [EMAIL PROTECTED] writes: On Mon, 2005-31-10 at 22:41 +, Simon Riggs wrote: I believe this is now complete and ready for application. The changes need a fair bit of copy editing and SGML policy work, but that is probably easier to do once it has been applied. Barring any

Re: [PATCHES] Partitioning docs

2005-10-31 Thread Neil Conway
On Mon, 2005-31-10 at 23:15 -0500, Tom Lane wrote: I'd argue for editing first and then applying. I'll take up the job if you don't have time for the editing part Okay. I'll do a round of copy editing and then commit to CVS -- there will likely be room for additional improvements, so once

Re: [PATCHES] Partitioning docs

2005-10-31 Thread Simon Riggs
On Mon, 2005-10-31 at 23:27 -0500, Neil Conway wrote: On Mon, 2005-31-10 at 23:15 -0500, Tom Lane wrote: I'd argue for editing first and then applying. I'll take up the job if you don't have time for the editing part Okay. I'll do a round of copy editing and then commit to CVS -- there