> main file. WIth Claudio's fix, this isn't necessary.
Bruce, are you sure this is true? The fix is only for files than are
open()'d, not fopen()'d (as per AllocateFile).
Cheers,
Claudio
---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these di
Claudio found that his new delete fix for Win32 also works for rename on
files open by other processes, so I have applied the following patch to
remove the special rename() handling on Win32. What it used to do was
to rename a file to a *.new, release locks, then do the rename to the
main file. W
> Agreed, we still need dirmod.c in case someone has opened it using a
non-unix mode.
Ok. Wanted to make sure I was on the same page.
> My only question was whether this new mode makes rename
> possible on a target file opened by another backend.
Looks good. Wrote a pair of 2 liner driver pr
Claudio Natoli wrote:
>
>
> > Claudio, how does this handle renames if the file is open by someone
> > else? Does this remove the need to loop over the rename?
>
> To be honest, I don't know that it does. [Will report back later.]
>
> Two points though:
>
> a) This could doesn't alleviate th
> a) This could doesn't alleviate the needs for dirmod.c, as
This CODE doesn't alleviate the NEED for...
Sheesh,
Claudio
---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
http://www.memetrics.com/emailpolicy.h
> Claudio, how does this handle renames if the file is open by someone
> else? Does this remove the need to loop over the rename?
To be honest, I don't know that it does. [Will report back later.]
Two points though:
a) This could doesn't alleviate the needs for dirmod.c, as far as I'm aware.
For application to HEAD, following community review. [open.c destined for
src/port]
Win32 people: This has been kicked around on the thread for a bit, I've not
been able to break it, but am still uncomfortable that it appears a novel
solution. If you can see any reason why this approach should no
Hi,
Here are some updates of the french .po files.
## pg_dump-fr.po
391 messages traduits.
## pg_resetxlog-fr.po
57 messages traduits.
## pgscripts-fr.po
112 messages traduits.
## psql-fr.po
455 messages traduits.
pg_resetxlog, pg_dump and pgscripts .po files are new ones.
They need to be apply
On Sun, Mar 14, 2004 at 09:11:27AM -0500, Bruce Momjian wrote:
> > I just applied this patch and the last one.
>
> I assume you mean you applied:
>
> Update tests & memory leak fix
>
> and
>
> ECPG - Remove need for "AT connection" when using threads
Yes. Sorry, should have said so
On Sun, Mar 07, 2004 at 09:43:31PM -, Lee Kindness wrote:
> Attached diff improves the handling of connections in ecpg when threading is
> used. The "current connection" is now the last connection made/set for the
I just applied this patch and the last one.
Michael
--
Michael Meskes
Email: M
Patch applied. File added. Thanks.
---
Lee Kindness wrote:
Content-Description: message body text
> The "cvs add" of test_thread_implicit.pgc seems to have been missed,
> i've attached this again.
>
> Additionally I inc
The "cvs add" of test_thread_implicit.pgc seems to have been missed,
i've attached this again.
Additionally I include a small patch to remove mutex locking when a
DEFAULT/NULL connection is being retrieved. This is consistent with
libpq.
Thanks, L.
Michael Meskes writes:
> On Sun, Mar 14, 2004
Patch applied. Thanks.
---
Claudio Natoli wrote:
>
> For application to HEAD. Minor cleanup.
>
> * postmaster.c: cleanup pmdaemonize under win32; missed failure message in
> CreateOptsFile
> * s_lock.c: minor comment fix
Patch applied. Thanks.
---
Matthew T. O'Connor wrote:
> Tom Lane wrote:
>
> >"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> >
> >
> >>! new_tbl->relid = atol(PQgetvalue(res, row, PQfnumber(res, "oid")));
> >>!
Patch applied. Thanks.
---
Andrew Dunstan wrote:
>
>
> I believe that the attached patch may solve this setlocale() problem,
> but I do not have a Windows box handy on which to test it. Can somebody
> who does please t
Patch applied. Thanks.
---
Andrew Dunstan wrote:
> Bruce Momjian wrote:
>
> >Tom Lane wrote:
> >
> >
> >>Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> >>
> >>
> Please don't. Declare them obsolete for 7
Hi Tom,
Having been working with the PostGIS team to implement a custom analyze
routine for R-Tree selectivity, we have a question regarding the new
vacuum_delay_point() which is present in analyze.c. Is it the
responsibility of the programmers to remember to do a
vacuum_delay_point() before calli
Dear patchers,
Please find attached my first patch which sets an initial
"hint" infrastructure into the sql parser. At the time
it is pretty simple as I'm not yet convinced yet that I'll
need a "hint stack" or something like that to cope with
recursions, despite initial implementations I've alrea
Fabien COELHO <[EMAIL PROTECTED]> writes:
> I'll keep that in mind. However, from other projects I've worked on, I
> found that large regression tests are not wasted.
> Maybe two level of tests wouldn't be bad, as when you're about to release
> a new version, it's better to pass large tests, but w
> > > scroffset += 1;/* XXX fix me when we have screen width info */
> > >
> > > with calls to a get-the-screen-width-of-this-character subroutine should
> > > do the job.
I have committed changes adding "PQdsplen()" which should do the job
above. Quick test with EUC-JP indicates
Bruce Momjian wrote:
Andrew Dunstan wrote:
Also, what is the default connection mode of psql? It should probably be
equivalent to "-h localhost", shouldn't it?
Now that is something I had not thought of. Seems we can assume a Win32
psql can never use unix domain sockets, so defaulting th
Dear Tom,
> > scroffset += 1;/* XXX fix me when we have screen width info */
> >
> > with calls to a get-the-screen-width-of-this-character subroutine should
> > do the job.
>
> I also looked into it, and it is also a little bit more complex, as the
> extract width must be though
> I have applied this patch,
Thanks!
> after some considerable whacking around to make it ready to cope with
> multicolumn Kanji characters. It does not actually cope yet, since the
> necessary knowledge is not available from the character encoding logic.
> But replacing the two places that say
Dear Tom,
On Sat, 13 Mar 2004, Tom Lane wrote:
>
> I have reviewed and applied this, with some tweaking. I attach the
> patch as applied. Some comments on the changes:
>
> * You were careless about updating the comments to match the code.
> This is an essential activity to keep things intelli
24 matches
Mail list logo
