Re: [PATCHES] pg_generate_sequence and info_schema patch (Was: SELECT
Tom Lane wrote: BTW, I think I was beating you over the head with an urban legend. Some idle googling revealed the true facts of the Mariner failure: http://www.rchrd.com/Misc-Texts/Famous_Fortran_Errors Oh well, I've been beat over the head with worse things, at least metaphorically ;-). Interesting reading though. Joe ---(end of broadcast)--- TIP 3: 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: [PATCHES] fix memcpy() overlap
Tom Lane wrote: Stephan Szabo [EMAIL PROTECTED] writes: On Mon, 2 Feb 2004, Tom Lane wrote: This isn't a bug, and I see no reason to clutter the code just to shut up valgrind. Isn't memcpy on overlapping (even entirely overlapping) buffers undefined behavior unless the count is 0? The reason that the spec describes overlapped memcpy as undefined is that it does not want to restrict which direction the copy occurs in (proceeding from lower to higher memory addresses or vice versa). memmove is constrained to do the copy in the direction that will avoid failure when the source and destination partially overlap. But memcpy is expected to do whichever is fastest on the particular architecture, without concern for possible overlap. (Offhand I've never heard of a machine where memcpy doesn't work lower-to-higher, but maybe there is one.) However, when the source and destination buffers are the same, it does not matter which direction you copy in; you are picking up and putting down the same bytes at the same addresses no matter what order you process the bytes in. There is no implementation in existence that will produce an unwanted result. If you want to argue about dependencies on implementation details that are theoretically undefined according to the ANSI C spec, we have tons more beyond this one. F'r instance, depending on twos-complement arithmetic is illegal per spec also ... Isn't memmove() for overlaping regions? That's what my BSD manual page says. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: 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: [PATCHES] Fix memcmp() with different sizes.
On Mon, Feb 02, 2004 at 09:27:46PM -0500, Tom Lane wrote: Kurt Roeckx [EMAIL PROTECTED] writes: - if (memcmp(re_array[i].cre_pat, text_re, text_re_len) == 0 + if (VARSIZE(re_array[i].cre_pat) == text_re_len + memcmp(re_array[i].cre_pat, text_re, text_re_len) == 0 This is not actually broken. The first four bytes of what memcmp is comparing are the length, and so it'll fall out immediately anyway if the lengths differ. That assumes the memcmp starts from the first char and not from the last. If it starts from the last you have undefined behaviour. Kurt ---(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 memcpy() overlap
Bruce Momjian [EMAIL PROTECTED] writes: Isn't memmove() for overlaping regions? That's what my BSD manual page says. If we want to get rid of the valgrind warning, a simpler patch would be to substitute memmove for memcpy in that particular numeric.c subroutine (at least, I assume this will shut valgrind up). I could live with that; it seems a less intrusive fix than a special-case test that will hardly ever trigger. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] fix memcpy() overlap
Tom Lane [EMAIL PROTECTED] writes: If we want to get rid of the valgrind warning, a simpler patch would be to substitute memmove for memcpy I've made this change and committed it to HEAD. -Neil ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [pgsql-hackers-win32] New win32 signals patch (3)
ATM, for review, not for applying. Comments: * Nice to see the fix for pqselect. Still want to object to the memcpy on the record :-) (though, as we've discussed, they'll work as things are now) * memcpy of an array of HANDLES will work seems to be taking advantage of knowledge of the implementation. Use DuplicateHandle? * Better yet, cooperation with the other functions that use the win32_childHND/PIDArrays, by reserving the first slot for event1, could see us doing away with both event 2 and the need for copying. * Alternatively, I personally think the best solution is to simply fire off a baby-sitting thread, in the parent, for each process that gets created, passing it a duplicate of the (single) child handle. Each thread would just sit there forever, waiting for the child handle to be signalled, and then signal (ie. kill/raise) its process and terminate. AFAICS, a 2 line addition to win32_forkexec, and a 5 line thread function to do the waiting/signalling, and we are done. This also has the advantage that it'll work just fine for the pgstat buffer process, which fires off the pgstat collector process... which won't be covered by the proposed approach (and before anyone jumps in to say this is a penalty in creating backends, consider that the previous call would have been to CreateProcess, so a _beginthreadex aint gonna hurt!) Suffice to say that I'd *really* like to see this approach explored. * If you wish to ignore either of the above two suggestions, at least put the SetEvent(win32_sigchld_event1) and WaitForSingleObjectEx calls in a function of their own (win32_signalChildArrayChange). Suggest SignalObjectAndWait here. Also, afaics, no need to use the *Ex functions in any of these cases. * Suggest using a switch statement in win32_sigchld_sender, instead of a nested if. Here's hoping you agree on the baby-sitting thread approach, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see a href=http://www.memetrics.com/emailpolicy.html;http://www.memetrics.com/em ailpolicy.html/a ---(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] pg_generate_sequence and info_schema patch (Was: SELECT Question)
Joe Conway [EMAIL PROTECTED] writes: A first shot at documentation for generate_series() is available here in html form: http://www.joeconway.com/functions-srf.html Feedback welcome. This bit seems unnecessarily vague: Depending on the requested combination of start, stop, and step, it is possible to return zero rows. I think you can provide a precise specification without losing simplicity of explanation. Maybe something like When step is positive, zero rows are returned if start stop. Conversely, when step is negative, zero rows are returned if start stop. It is an error for step to be zero. ... and then carry on with the examples, which seem fine (although the one showing the error for step=0 might be thought redundant with the text). regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
