For application to HEAD, pending community review (rationale provided below
in previous message; no responses hopefully indicates agreement :-)
Following application, dirmod.c must be moved to src/backend/port/win32 (ie.
add to src/backend/port/win32, and remove from src/port).
[changes to conf
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> folklore has it that Mariner II was lost to exactly such a bug).
> Ouch -- got the point.
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.rc
> -Original Message-
> From: Peter Eisentraut [mailto:[EMAIL PROTECTED]
>
> LC_ALL overrides LANG, so please just one.
Don't do it! I just tried it with only LC_ALL and it did not
work. Same "tags file is not sorted" error message from vi.
Maybe sort does not honor LC_* variables, or som
> I'd not recommend spending a lot of time on patching the existing code.
> Erroring out rather than crashing is probably sufficient.
Agreed.
This fixes the ones bugging me now. I'll provide others as I trip over them.
[Note: this'll mean some changes to the tests for Win32]
Cheers,
Claudio
David Fetter wrote:
> > > \? for help with psql commands
> If you wanted to pick one of the two patches, which one would it be?
> If not, what should the patch look like?
There seems to be a consensus on the form left standing above. That
seems OK to me.
---(end of bro
Nicolai Tufar wrote:
> > -Original Message-
> > From: Peter Eisentraut [mailto:[EMAIL PROTECTED]
> >
> > LC_ALL overrides LANG, so please just one.
>
> Don't do it! I just tried it with only LC_ALL and it did not
> work. Same "tags file is not sorted" error message from vi.
On second look,
Tom Lane wrote:
> As an example, it might make more sense to create a separate flag bit
> that simply grants the ability to add and delete users
> (non-superusers, presumably), with none of the other attributes of a
> superuser. If I recall your original concern properly, this would be
> a safer f
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Nicolai Tufar wrote:
>> Don't do it! I just tried it with only LC_ALL and it did not
>> work. Same "tags file is not sorted" error message from vi.
> On second look, the patch is completely wrong anyway, because it does
> not export the variables; it
On Mon, Feb 02, 2004 at 03:12:41PM +0100, Peter Eisentraut wrote:
> David Fetter wrote:
> > > > \? for help with psql commands
>
> > If you wanted to pick one of the two patches, which one would it
> > be? If not, what should the patch look like?
>
> There seems to be a consensus on the form lef
Tom Lane wrote:
> I saw that, but it seemed a non-problem to me: if the variables have
> not been exported then they won't affect the sort program anyway.
He probably had LANG, but not LC_ALL, already exported in his
environment. So when the shell program writes:
LC_ALL=C
then sort doesn't see
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I saw that, but it seemed a non-problem to me: if the variables have
>> not been exported then they won't affect the sort program anyway.
> He probably had LANG, but not LC_ALL, already exported in his
> environment.
Ah, right, th
Hi Tom,
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 29 January 2004 15:31
> To: Mark Cave-Ayland
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PATCHES] ANALYZE patch for review
>
>
OK, I've had another attempt at writing the code as you suggested but
the more I
"Mark Cave-Ayland" <[EMAIL PROTECTED]> writes:
> So I'd like to propose a slightly different solution. I think that
> examine_attribute() should return a pointer to a custom structure
> containing any information that needs to be passed to the datatype
> specific routine (not the entire VacAttrStat
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> OK, then *This* patch does it the way I think is clearest. Most of it
> is just reindenting.
Okay, I applied this patch, and made a few additional cleanups along
the way (the whole function and a couple other things don't need to be
declared in hba.h, f
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I saw that, but it seemed a non-problem to me: if the variables have
> >> not been exported then they won't affect the sort program anyway.
>
> > He probably had LANG, but not LC_ALL, already exported in his
>
Neil Conway wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
OK, then *This* patch does it the way I think is clearest. Most of it
is just reindenting.
Okay, I applied this patch, and made a few additional cleanups along
the way (the whole function and a couple other things don't need t
Korea PostgreSQL Users' Group wrote:
> src/backend/commands/user.c file has some parse error at repalloc(), palloc()
> functions
Fixed. Thanks.
> src/backend/postmaster/pgstat.c miss
> #include "tcop/tcopprot.h" line.
Fixed.
> src/utils/dllinit.c wrong include header line at MinGW.
> #includ
Wiseguy wrote:
Is there a good reason why minor source revisions are not posted to
the ftp mirrors as unified diff patchfiles? I mean, both 7.4.0 and
7.4.1 were nearly 10MB in size as bz2 archives. That's a 40 minute
download per file for a 56kb modem connection. Whereas, I created a
bz2 patc
Claudio Natoli wrote:
[Of course, whether or not this is the best behaviour (as opposed to error)
is an arguable point.]
Thanks for the input. I think I'll go with Tom's nearby advice and make
it an error.
Joe
---(end of broadcast)---
TIP 1: subs
This patch brings up to date what I did last year (now unfortunately
bitrotted) to allow the logging of the end of a session, enabled by the
config setting "log_session_end - true". It produces lines like these:
for a local connection:
[21340] LOG: session end: duration: 0:00:23.41 user=andrew
Andrew Dunstan wrote:
> This patch brings up to date what I did last year (now unfortunately
> bitrotted) to allow the logging of the end of a session, enabled by
> the config setting "log_session_end - true". It produces lines like
> these:
If we log "session" end, shouldn't we also log "session"
Another error reported by valgrind on the postmaster (& children) is
the following:
==30568== Source and destination overlap in memcpy(0xBFFFEA30, 0xBFFFEA30, 24)
==30568==at 0x40024224: memcpy (mac_replace_strmem.c:93)
==30568==by 0x82081F3: set_var_from_var (numeric.c:2732)
==30568==
Neil Conway <[EMAIL PROTECTED]> writes:
> I don't know of a memcpy() implementation that would actually bail out
> if called with two equal pointers, but perhaps there is one in
> existence somewhere.
This isn't a bug, and I see no reason to clutter the code just to shut
up valgrind.
Tom Lane <[EMAIL PROTECTED]> writes:
> This isn't a bug
If that's the case I'm content with not changing the code, but I'd
rather not just take it on faith: can you point me to some authority
that says two objects with the same address do not "overlap"?
(I checked C99 (draft 843) and while it ref
Hello!
Here's step #2 in win32 signals handling, containing the following:
1) Per discussion with Bruce, reverts the change from kill() to pqkill()
on all platforms. Instead, #define away kill() to pqkill() in
port/win32.h, and just use kill() directly on unix platforms. Similar
changes for pqsi
Thanks to Peter Eisentraut, Bruce Momjian and Tom Lane.
With the second CVS commit by Bruce Momjian it works fine now.
Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> > On second look, the patch is completely wrong anyway, because it
> > does not export the variables; it depends on the user having
Thanks to Peter Eisentraut, Bruce Momjian and Tom Lane.
With the second CVS commit by Bruce Momjian it works fine now.
Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> > On second look, the patch is completely wrong anyway, because it
does
> > not export the variables; it depends on the user having e
On Mon, 2 Feb 2004, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > I don't know of a memcpy() implementation that would actually bail out
> > if called with two equal pointers, but perhaps there is one in
> > existence somewhere.
>
> This isn't a bug, and I see no reason to clutter
Claudio Natoli wrote:
>
> For application to HEAD, pending community review (rationale provided below
> in previous message; no responses hopefully indicates agreement :-)
>
> Following application, dirmod.c must be moved to src/backend/port/win32 (ie.
> add to src/backend/port/win32, and remove
Claudio Natoli wrote:
>
> For application to HEAD, pending community review (rationale provided below
> in previous message; no responses hopefully indicates agreement :-)
>
> Following application, dirmod.c must be moved to src/backend/port/win32 (ie.
> add to src/backend/port/win32, and remove
Not everything in the re_array is the same size. This patch
first checks that they actually are the same size in the first
place.
Kurt
Index: src/backend/utils/adt/regexp.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/u
Ehh, scratch that. That file had pqselect call itself..
Here is an updated version of select.c for backend/port/win32. The patch
stays the same.
//mha
>-Original Message-
>From: Magnus Hagander
>Sent: den 2 februari 2004 22:35
>To: pgsql-hackers-win32
>Cc: [EMAIL PROTECTED]
>Subject:
On Mon, Feb 02, 2004 at 01:23:15PM -0800, Stephan Szabo wrote:
>
> Isn't memcpy on overlapping (even entirely overlapping) buffers undefined
> behavior unless the count is 0?
The C standard says: "If copying takes place between objects that overlap,
the behaviour is undefined". SUSv3 says the sam
Stephan Szabo wrote:
On Mon, 2 Feb 2004, Tom Lane wrote:
Neil Conway <[EMAIL PROTECTED]> writes:
I don't know of a memcpy() implementation that would actually bail out
if called with two equal pointers, but perhaps there is one in
existence somewhere.
This isn't a bug, and I see
> I have fixed dirmod.c in CVS so it uses the same logic as
> crypt. Please review and tell me how you like it.
Looks good. Thanks.
Claudio
---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
http://www.memetri
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
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 t
37 matches
Mail list logo
