Re: [PATCHES] Async Commit, v21 (now: v22)
On Tue, 2007-07-24 at 17:53 -0400, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: There is an explicit test for whether the transaction has modified files; if so the commit is always synchronous, even if explicitly requested otherwise. Also, utility commands never perform async commits, so overall there aren't that many of the commonly used DDL commands that could be performed and still have it be an async commit. Huh? I see neither a reason for these restrictions So that we don't lose DROP TABLEs, TRUNCATEs for example. If the database crashed between removing the file and flushing the WAL then the relfilenode would be incorrectly set for a non-temp table and we would have no easy way of working out what to do. That seems like a problem to me, if we let it occur; the patch avoids that trivially. nor any way that you could enforce them without horrid kluges. In RecordTransactionCommit we do smgrGetPendingDeletes(), so we know if there are files to be removed at commit time. If there are files to be removed then in the async commit patch we override the setting of synchronous_commit that was requested for that transaction so that the transaction will always be synchronous. So this works for DROP TABLE, DROP INDEX and TRUNCATE. CREATE TABLE would not be such a problem since if we crash between commit and WAL flush then the reference to the file would not be present, even if the table would be. Data loss, but no catalog integrity issue. We *might* want to override the commit to be synchronous if there is anything at all in the pending delete list, whether atCommit or atAbort. This would then work for both CREATE and DROP. An additional smgr call to do this would be fast and easy, as well as modular since there are already calls from xact.c to smgr. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] msvc const warnings
On Tue, Jul 24, 2007 at 09:43:51PM +0200, Magnus Hagander wrote: Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Tom Lane wrote: Gregory Stark [EMAIL PROTECTED] writes: Can we just disable const checking for MSVCC in general without using the #pragmas? It clearly doesn't understand how const works making that warning from it useless. +1 ... any useful warning of this kind will be had from other compilers. Sure, there are a couple of places we can do it: 1) We can add the pragma at the top of the file, which will turn it off for that file, but keep it for other files. 2) We can turn it off on a per-project basis, meaning we turn it off for the entire backend and the entire psql, but not for other EXEs and DLLs. 3) We can just turn it off for everything Note that it'll of course turn off the warning in *all* cases, not just the free const chra **-one. Which way would be preferred? Turning it off globally is what I had in mind, and I assume Greg too. The point is that if MSVC gets this case wrong, then it probably gets many other cases wrong, and we shouldn't have to work around them one at a time. ok. I'll do it globally when I'm back at a box where I can rebuild the thing fast enough not to get bored :-) Meaning tomorrow. Done. //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] plperl warnings on win32
On Tue, Jul 24, 2007 at 12:11:03PM -0400, Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: An alternative might be to provide a perl script in the tools directory which would fix the perl header file. Seems like more work than it's worth. I'm OK with Magnus' proposed Makefile hack --- though someone should also complain to ActiveState so maybe they'll fix it sometime. Applied and complained, activestate bugid 71303. //Magnus ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] patch win32.mak of libpq
On Wed, Jul 25, 2007 at 02:36:41PM +0900, Hiroshi Saito wrote: Hi Magnus, and Dave. Sorry, I'm a somewhat late reaction... This is the present correspondence. However, VC6 does not support SSAPI. Therefore, the next release makes VC6 the outside of an object. I think VC6 should support it Ok. You probably just need to upgrade your Platform SDK to a version that's for Windows 2000 or newer. I think VC6 shipws with the NT4 SDK by default. It looks like it' just missing secur32.lib. I have applied your patch, since it's used in either case. Thanks! If there is no objection. Let's close support of VC6. What do you think? While I don't disagree in principle, if you can test it with a new Platfrom SDK and see if that works there's no reason to close it (yet). //Magnus ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] patch win32.mak of libpq
Hi Magnus. Thanks! From: Magnus Hagander On Wed, Jul 25, 2007 at 02:36:41PM +0900, Hiroshi Saito wrote: Hi Magnus, and Dave. Sorry, I'm a somewhat late reaction... This is the present correspondence. However, VC6 does not support SSAPI. Therefore, the next release makes VC6 the outside of an object. I think VC6 should support it Ok. You probably just need to upgrade your Platform SDK to a version that's for Windows 2000 or newer. I think VC6 shipws with the NT4 SDK by default. It looks like it' just missing secur32.lib. Ahh yes. However, MS says.! The last SDK that will work with VC 6.0 is the February 2003 Edition. http://www.microsoft.com/msdownload/platformsdk/sdkupdate/ this SDK is newer and does not support VC6.:-( I have applied your patch, since it's used in either case. Thanks! If there is no objection. Let's close support of VC6. What do you think? While I don't disagree in principle, if you can test it with a new Platfrom SDK and see if that works there's no reason to close it (yet). It seems that it is difficult to get public although I have it. Then, I feel that support is difficult I missed something? Regards, Hiroshi Saito Regards, Hiroshi Saito ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
