Re: [PATCHES] [HACKERS] pg_arch.c call to sleep()
Magnus Hagander wrote:
We have the following warning on Windows:
pgarch.c:349: warning: implicit declaration of function `sleep'
To fix it we could include the right header (which appears to be
in the Windows/Mingw case), or we could replace
the call by
a call to pg_usleep().
is included automatically by c.h, so that surely
won't fix it.
I have some recollection that we invented pg_usleep in part
because we wanted to not use sleep() at all in the backend,
but I don't recall why (and the reasoning might not apply to
the archiver process, anyway).
win32 signal handling won't interrupt sleep(), just pg_usleep().
I take this as confirmation that calling pg_usleep is the Right Thing (tm).
Here's the patch.
cheers
andrew
Index: pgarch.c
===
RCS file: /home/cvsmirror/pgsql/src/backend/postmaster/pgarch.c,v
retrieving revision 1.9
diff -c -r1.9 pgarch.c
*** pgarch.c 29 Aug 2004 05:06:46 - 1.9
--- pgarch.c 8 Nov 2004 12:59:49 -
***
*** 338,352
/*
* There shouldn't be anything for the archiver to do except to
! * wait for a signal, so we could use pause(3) here... ...however,
! * the archiver exists to protect our data, so she wakes up
! * occasionally to allow herself to be proactive. In particular
! * this avoids getting stuck if a signal arrives just before we
! * enter sleep().
*/
if (!wakened)
{
! sleep(PGARCH_AUTOWAKE_INTERVAL);
curtime = time(NULL);
if ((unsigned int) (curtime - last_copy_time) >=
--- 338,351
/*
* There shouldn't be anything for the archiver to do except to
! * wait for a signal, ... however, the archiver exists to
! * protect our data, so she wakes up occasionally to allow
! * herself to be proactive. In particular this avoids getting
! * stuck if a signal arrives just before we sleep.
*/
if (!wakened)
{
! pg_usleep(PGARCH_AUTOWAKE_INTERVAL * 100L);
curtime = time(NULL);
if ((unsigned int) (curtime - last_copy_time) >=
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [PATCHES] contrib/xml2: add function xml_encode_special_chars
On Sun, 07 Nov 2004 13:03:33 +, Simon Riggs wrote: > On Sun, 2004-11-07 at 12:56, Markus Bertheau wrote: >> В Вск, 07.11.2004, в 09:33, Simon Riggs пишет: >> > On Sat, 2004-11-06 at 23:42, Markus Bertheau wrote: >> > > В Сбт, 06.11.2004, в 23:13, Simon Riggs пишет: >> > > > On Sat, 2004-11-06 at 00:36, Markus Bertheau wrote: >> > > > > В Сбт, 06.11.2004, в 01:24, Peter Eisentraut пишет: >> > > > > > Markus Bertheau wrote: >> > > > > > > attached is a patch that adds the function >> > > > > > > xml_encode_special_chars >> > > > > > > to the xml2 contrib module. It's against 8.0beta4. It's intended >> > > > > > > for >> > > > > > > commit. >> > > > > > >> > > > > > Would you also tell us what this function does? >> > > > > >> > > > > It calls the similarly named function from libxml2. It replaces >> > > > > characters that carry a special meaning in XML (<, >, &, " and \r) >> > > > > with >> > > > > their respective XML entities. >> > > > >> > > > Wow! Hadn't noticed xml2 didn't do that. Thats pretty important... >> > > >> > > What do you mean, it didn't do that? Where had you expected it to do >> > > that? >> > >> > eh? I'm agreeing that your patch is important... >> >> I didn't question that :) I just don't understand what you mean with >> "xml2 doesn't do that" - do you mean that you thought that that function >> was already there? Or that special character encoding already takes >> place somewhere else in xml2? I can't imagine where that would be, so I >> asked :) > > I mistakenly assumed that the special character encoding took place > automatically, without calling a specific function. > > It's pretty fragile without that, but you could go a long way before the > lack of it hit you in the face, then no further. It's not really fragile, considering the usage scope of contrib/xml2 - Peter E points this out elsewhere, but if the characters are not already escaped then the document is not valid XML. The routines in contrib/xml2 deal with processing incoming XML, in which the characters have to be escaped already - if you used this routine automatically, you'd strip all the XML tags from your document and turn it into a long text string! It's certainly a worthwhile routine to add. I'd consider the lack of exposure of character set management APIs to be a bigger failure of contrib/xml2 (the Brazilian webpage appears to cover this point). This function is (sort of) a "cast" function from text -> XML. One of the things I would really like to do (if I can ever find the time!) is produce a wrapper type for XML possessing relevant operators for XPath etc. and enforcing well-formedness on data. xml_encode_special_chars is then essentially one data-conversion function for composing simple XML documents out of ordinary unescaped text (Strictly, you'd also have to wrap it in tags to make it a well-formed document) My email address is in README.xml2 (hidden in a paragraph near the bottom). Regards John ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[PATCHES] fix compile warning for pg_backup_tar.c
Yet another fix for a useless compile warning. This one is slightly ugly ;-( cheers andrew Index: src/bin/pg_dump/pg_backup_tar.c === RCS file: /home/cvsmirror/pgsql/src/bin/pg_dump/pg_backup_tar.c,v retrieving revision 1.45 diff -c -r1.45 pg_backup_tar.c *** src/bin/pg_dump/pg_backup_tar.c 7 Oct 2004 15:21:55 - 1.45 --- src/bin/pg_dump/pg_backup_tar.c 8 Nov 2004 17:26:03 - *** *** 1019,1025 --- 1019,1029 */ fseeko(tmp, 0, SEEK_END); th->fileLen = ftello(tmp); + #ifdef INT64_IS_BUSTED if (th->fileLen > MAX_TAR_MEMBER_FILELEN) + #else + if (((int64) th->fileLen -1) >= MAX_TAR_MEMBER_FILELEN) + #endif die_horribly(AH, modulename, "archive member too large for tar format\n"); fseeko(tmp, 0, SEEK_SET); ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] fix compile warning for pg_backup_tar.c
Andrew Dunstan <[EMAIL PROTECTED]> writes: > Yet another fix for a useless compile warning. This one is slightly ugly ;-( Why not use off_t in the first place? regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Enhanced PITR doc patch
Simon Riggs <[EMAIL PROTECTED]> writes: > A range of minor enhancements, plus some stronger doc around: > - warnings about overwrites > - additional documentation of recovery.conf parameters Applied with some editorialization. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] fix compile warning for pg_backup_tar.c
Andrew Dunstan wrote: > Yet another fix for a useless compile warning. This one is slightly > ugly ;-( First of all, ugly code needs to be documented in the code. Then, the diff + #ifdef INT64_IS_BUSTED if (th->fileLen > MAX_TAR_MEMBER_FILELEN) + #else + if (((int64) th->fileLen -1) >= MAX_TAR_MEMBER_FILELEN) + #endif seems to imply that the current code corresponds to INT64_IS_BUSTED, which obviously defies reason. I remember when I wrote that code I consciously let the compile warning stand for platforms with busted int64 because it became too confusing to fix. Maybe you can clear that up for us. :) -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] fix compile warning for pg_backup_tar.c
Peter Eisentraut wrote: Andrew Dunstan wrote: Yet another fix for a useless compile warning. This one is slightly ugly ;-( First of all, ugly code needs to be documented in the code. Ok. Perhaps code that is expected to generate warnings should be too ;-) Then, the diff + #ifdef INT64_IS_BUSTED if (th->fileLen > MAX_TAR_MEMBER_FILELEN) + #else + if (((int64) th->fileLen -1) >= MAX_TAR_MEMBER_FILELEN) + #endif seems to imply that the current code corresponds to INT64_IS_BUSTED, which obviously defies reason. I remember when I wrote that code I consciously let the compile warning stand for platforms with busted int64 because it became too confusing to fix. Maybe you can clear that up for us. :) The error I saw was on Windows, for which I don't think int64 is busted, as we have long long int: pg_backup_tar.c:1022: warning: comparison is always false due to limited range of data type ISTM that what is happening here is that the compiler is smart enough to know that what is in MAX_TAR_MEMBER_FILELEN can't be exceeded by any possible value of type off_t. cheers andrew ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] fix compile warning for pg_backup_tar.c
Andrew Dunstan wrote: > ISTM that what is happening here is that the compiler is smart enough > to know that what is in MAX_TAR_MEMBER_FILELEN can't be exceeded by > any possible value of type off_t. Yeah, I think off_t is only 32 bits there. Then using INT64_IS_BUSTED as conditional is really misleading. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] fix compile warning for pg_backup_tar.c
Peter Eisentraut wrote: Andrew Dunstan wrote: ISTM that what is happening here is that the compiler is smart enough to know that what is in MAX_TAR_MEMBER_FILELEN can't be exceeded by any possible value of type off_t. Yeah, I think off_t is only 32 bits there. Then using INT64_IS_BUSTED as conditional is really misleading.\ What would you like me to use? Or maybe we should just do this in all cases instead of using an ifdef? cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[PATCHES] GiST: perf. work, index tuple killing
This patch makes the following changes to GiST: - refactor the code to keep a pin on the buffer currently being examined by a GiST index scan. This avoids the need to invoke ReadBuffer() for each tuple produced by the scan; this should result in a performance improvement. - add support for index tuple killing (once the above refactoring was done, this was easy). This should ensure that GiST performance degrades more gracefully in the presence of expired heap tuples. - remove gistscancache(): per discussion on -hackers, this is useless - fold gistfirst() into gistnext(): there was a bunch of code duplicated here for no good reason - rename some structure fields to be more sensible - add some comments to gistget.c - rename IndexUpdateStats() to IndexCloseAndUpdateStats(), per suggestion from Tom - various other cleanups and improvements Performance results: I ran contrib/rtree_gist/bench/bench.pl to test the effect of these changes. "$NUM" in create_test.pl was set to 400,000, and all tests were run with "-b 40". The machine is a 2-processor Xeon 2.8 ghz, Linux 2.6.9, with a single SCSI 10k disk and 1GB of RAM. I ran the test a few times to warm up the cache first. Results without patch: total: 18.55 sec; number: 40; for one: 0.464 sec; found 1 docs total: 18.44 sec; number: 40; for one: 0.461 sec; found 1 docs total: 18.45 sec; number: 40; for one: 0.461 sec; found 1 docs total: 18.43 sec; number: 40; for one: 0.461 sec; found 1 docs Results with patch: total: 16.97 sec; number: 40; for one: 0.424 sec; found 1 docs total: 16.91 sec; number: 40; for one: 0.423 sec; found 1 docs total: 16.96 sec; number: 40; for one: 0.424 sec; found 1 docs total: 16.94 sec; number: 40; for one: 0.424 sec; found 1 docs I've attached a gzip'd patch against current sources; it includes the previous changes made to GiST for memory management and related cleanups (sorry, I would include an incremental diff, but interdiff(1) seems to be misbehaving...) -Neil gist_work-2.patch.gz Description: GNU Zip compressed data ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] contrib/ sparse code cleanup
On Fri, 2004-11-05 at 15:21, Neil Conway wrote: > This patch makes some cleanups to contrib/ to silence some sparse > warnings Applied. -Neil ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] src/include/Makefile: remove-old-headers
On Sun, 2004-11-07 at 11:33, Alvaro Herrera wrote: > Since the behavior previously known as install-all-headers is now the > default, there's no point in keeping that target. This patch removes it. Looks good -- applied. Note that I believe pre-7.1 would put these extra headers in a different place than 8.0 will put them (pre-7.1 uses $DESTDIR$includedir/foo.h, 8.0 will use $DESTDIR$includedir/server/.../foo.h, where "..." may be vary between headers). Still, worrying about nuking those old headers seems pointless. -Neil ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
