Re: [PATCHES] HOT synced with HEAD
On 9/17/07, Tom Lane [EMAIL PROTECTED] wrote: Yeah. As the code stands, anything that's XMIN_INVALID will be considered not-HotUpdated (look at the macro...). So far I've seen no place where there is any value in following a HOT chain past such a tuple --- do you see any? No, I don't think we would ever need to follow a HOT chain past the aborted tuple. The only thing that worries about this setup though is the dependency on hint bits being set properly. But the places where this would be used right now for detecting aborted dead tuples, apply HeapTupleSatisfiesVacuum on the tuple before checking for HeapTupleIsHotUpdated, so we are fine. Or should we just check for XMIN_INVALID explicitly at those places ? Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com
Re: [PATCHES] [COMMITTERS] pgsql: Avoid possibly-unportable initializer, per buildfarm warning.
Tom Lane [EMAIL PROTECTED] writes:
Log Message:
---
Avoid possibly-unportable initializer, per buildfarm warning.
This was lost in the tsearch2 merge.
Index: src/backend/tsearch/dict_thesaurus.c
===
RCS file:
/home/stark/src/REPOSITORY/pgsql/src/backend/tsearch/dict_thesaurus.c,v
retrieving revision 1.3
diff -c -r1.3 dict_thesaurus.c
*** src/backend/tsearch/dict_thesaurus.c25 Aug 2007 00:03:59 -
1.3
--- src/backend/tsearch/dict_thesaurus.c17 Sep 2007 13:30:27 -
***
*** 653,663
static LexemeInfo *
findTheLexeme(DictThesaurus * d, char *lexeme)
{
! TheLexeme key = {lexeme, NULL}, *res;
if (d-nwrds == 0)
return NULL;
res = bsearch(key, d-wrds, d-nwrds, sizeof(TheLexeme), cmpLexemeQ);
if (res == NULL)
--- 653,666
static LexemeInfo *
findTheLexeme(DictThesaurus * d, char *lexeme)
{
! TheLexeme key, *res;
if (d-nwrds == 0)
return NULL;
+ key.lexeme = lexeme;
+ key.entries = NULL;
+
res = bsearch(key, d-wrds, d-nwrds, sizeof(TheLexeme), cmpLexemeQ);
if (res == NULL)
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] HOT synced with HEAD
On 9/17/07, Tom Lane [EMAIL PROTECTED] wrote: Meanwhile I've started looking at the vacuum code, and it seems that v16 has made that part of the patch significantly worse. VACUUM will fail to count tuples that are removed by pruning, which seems like something it should report somehow. I understand. I did not give real weight to it because I thought we anyways remove tuples elsewhere during pruning. But I agree that the heap_page_prune_defrag in the VACUUM code path is doing so on behalf of vacuum and hence we should credit that to VACUUM. And you've introduced a race condition: as I just mentioned, it's perfectly possible that the second call of HeapTupleSatisfiesVacuum gets a different answer than what the prune code saw, especially in lazy VACUUM (in VACUUM FULL it'd suggest that someone released lock early ... but we do have to cope with that). Hmm.. you are right. Those extra notices I added are completely unnecessary and wrong. The comments you added seem to envision a more invasive patch that gets rid of the second HeapTupleSatisfiesVacuum pass altogether, but I'm not sure how practical that is, and am not real inclined to try to do it right now anyway ... I agree. I just wanted to leave a hint there that such a possibility exists if someone really wants to optimize, now or later. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com
Re: [PATCHES] WIP - MSVC build script replacements
Andrew Dunstan wrote: Here after much tedious testing are some perl replacements for src/tools/msvc/build.bat and src/tools/msvc/vcregress.bat, as previouslty discussed on -hackers. They do not exhibit the error reporting problems I have had on XP, and they work nicely with a slightly modified buildfarm script. There is one failure - the ECPG checks fail to build. The error I get is shown below - not sure why on earth it can't find MSVCRT.lib. Does it work on the same machine with the .bat file? There are also a few things to tidy up before I commit this, but I'm happy because it has proved much less fragile than the existing scripts in cooperating with the buildfarm. I am also turning my attention to fixing the use of dir in Install.pm. Not having tested it yet, but looked over. Does the #!c:/perl/bin/perl actually make any sense? Does it even work? Should it system(mkvcbuild)? Shouldn't it rather use Mkvcbuild; and go from there? Seems a whole lot cleaner, and that's why we nade Mkvcbuild a module in the first place. As for vcregress, code like: my $schedule = shift ||(($what eq 'CHECK' || $what =~ /PARALLEL/) ? parallel : serial ); is quite hard for me to read, but that could be because I'm not fluent in advanced perl :P Perhaps simplify a bit for those of us? ;) (I perfectly understand what it does after thinking about it a bit, but I have to think and not just read. And since this is a very simple piece of code after all.) Not sure I like the getTests vs GetTests. Sure, it's case sensitive, but again with the easy-to-read. (and usage: foo, but I'm sure you knew that) Other than that, looks fine to me. //Magnus ---(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
