Magnus Hagander writes:
> Now, I still twist my head around the lines:
> if ((fd = _open_osfhandle((long) h, fileFlags & O_APPEND)) < 0
> ||
> (fileFlags & (O_TEXT | O_BINARY) && (_setmode(fd,
> fileFlags & (O_TEXT | O_BINARY)) < 0)))
>
>
> With the _setmode() call deep in th
Hello guys,
it's been a while, but...
> What's bugging me is that 0 and O_EXCL give the same answer, and
> O_TRUNC and O_TRUNC | O_EXCL give the same answer,
This is ok, as (iirc) O_EXCL only has effect in the presence of O_CREAT.
(a comment to this effect would help here, as well as perhaps l
Tom Lane writes:
> Claudio Natoli <[EMAIL PROTECTED]> writes:
> > The plpgsql regression test for Win32 fails; appears to not obey the
> > statement timeout. Might be a known problem.
>
> [ rolls eyes... ] That's been like that for some time. Hasn't an
Just a quick heads-up.
The plpgsql regression test for Win32 fails; appears to not obey the
statement timeout. Might be a known problem.
Lines 395-6 of exec.c need to have the operator changed from equality to
assignment (busted fix for pg_dumpall on win32).
Cheers,
Claudio
-Original Messa
Tom Lane writes:
> Hm, is this a Windows box? We already suspected that we'd
> have to fudge on matching the timezone abbreviations on Windows ..,
In my case, yes, Win XP.
Cheers,
Claudio
---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these
> So what *is* your zone, exactly? I don't see how you expect us to
> figure out why it's not matching when we don't know what it's not
> matching.
In my case, one of these should be right:
DEBUG: Reject TZ "Australia/NSW": at 1086048000 "EST" versus "AUS Eastern
Standard Time"
DEBUG: Rejec
Christopher Kings-Lynne writes:
> Any reason why postgres can't detect time zone on my machine
> automatically?
>
> LOG: could not recognize system timezone, defaulting to "Etc/GMT-8"
> HINT: You can specify the correct timezone in postgresql.conf.
> postmaster starting
> -bash-2.05b$ LOG: d
Greg Copeland writes:
> My primary fear about delivering Win32 with all of these other great
> features is that, IMO, there is a higher level of risk associated with
> these advanced features. At the same time, this will be the
> first trial for many Win32 users. Should there be some problems,
Andrew Dunstan writes:
> How about if we have a configuration flag --enable-relocation which would
> require a fixed layout based on an indeterminate root. This would have the
> following effects:
>
> . if prefix did not contain 'postgres' or 'pgsql' then
> 'postgresql' would be appended.
> . al
Peter Eisentraut wrote:
> Claudio Natoli wrote:
> > Peter Eisentraut wrote:
> > > Claudio Natoli wrote:
> > > > I'm yet to see a convincing argument for why we can't adopt the
> > > > "binary-location/../share" approach as submitted la
Peter Eisentraut wrote:
> Claudio Natoli wrote:
> > I'm yet to see a convincing argument for why we can't adopt the
> > "binary-location/../share" approach as submitted late March. AFAICS,
> > it was rejected on the basis that it was not platform indepen
Andrew Dunstan wrote:
> >For Win32, we could use the registry. For Unix, we can't use /etc
> >because we can't be sure we are root. Can we create a dot-file in the
> >user's home directory during install?
> >
>
> We can't be sure we are Administrator either.
Exactly. IMHO, using the registr
> >5) We only had a compiled-in location for /lib in the past for dynamic
> >loading, and had a GUC variable to override it. initdb always used
> >/share in a fixed location, but it has a flag to override it. With
> >/share/timezone, the server now requires the timezone
> database to be in
> >
> > Win32 has continued on a steady pace for six months now.
>
> Be honest ... 6 months ago, did you believe the Win32 work would have
> taken >6 months? How many of the current issues could you have
> anticipated? How many will crop up in the next month?
FWIW, the backend porting effort sta
> The other point, especially about Win32, is to see if we can
> spread the load a bit. Perhaps Claudio, Magnus, Merlin and Bruce
> should start trying to farm out specific tasks.
Here are the tasks, off the Win32 page, I see as necessary to drop in:
* Handle sync() by opening all file ope
Hi Dann,
> > Which version
> > are you using?
>
> Msys version is 1.0.
Ok, probably the same I'm using (MSYS-1.0.10 and MSYS-1.0.9)
> [EMAIL PROTECTED] /u/postgresql-snapshot
> $ gcc --version
> gcc.exe (GCC) 3.3.3 (mingw special)
I'm using MinGW-3.1.0-1, which has:
gcc.exe (GCC) 3.2.3 (mi
Hi Dann,
whilst I have, on rare occasions, observed the symlink failure under MingW,
I've never come across the other issues you've mentioned (I build from cvs,
instead of snapshots, but I can't imagine that causes these problems).
Is it possible your MingW install is a broken? Which version are
> email. The current patch is attached -- Tom hasn't yet gotten back to
> me on whether this fixes the problem for him on HPUX, but it fixes my
> OS X box.
Fixes issues under win32. Thanks.
Claudio
---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text
Tom Lane wrote:
> I don't like the idea of redesigning that
> code just because someone misunderstands it.
Fair enough, on both counts. However, the original question which was asked
out of ignorance (that I'll freely admit) doesn't seem to have been directly
addressed:
> If that is indeed the case, I withdraw all my comments and misdirected
> ideas, and say we go for a win32 specific workaround :-)
We just need to be very careful on what this work-around is though...
For instance, whilst the idea of an "APCcalled" flag will work just fine,
mechanically, I'm ex
Hi all,
Was just discussing the issues related to the above off list with Magnus:
http://archives.postgresql.org/pgsql-hackers-win32/2004-03/msg00041.php
Whilst we can think of a number of work-arounds (the simplest being a
suggestion by Magnus: set a flag, like APCcalled, to false before the
se
Bruce Momjian writes:
> I just checked from the MinGW console and I see:
> [snip]
> It accepts ln -s, but does nothing with it.
And even if it had worked, it wouldn't really matter, since we don't
actually want to *run* the system under MinGW/msys, just build it.
I think the idea of implementing
Gavin Sherry wrote:
> I'm going to focus on implementing this on the system(s) I'm used to
> developing on (ie, those which support symlinks). Once that is done, I'll
> talk with the Win32 guys about what, if anything, we can do about getting
> this to work on Win32 (and possibly other non-symlin
> > I will look at c) unless someone comes up with a better idea
> > or someone else gets in first.
>
> That would be great. Grab a hold of the cygwin sources.
> winsup/cygwin/localtime.cc claims that it is in the public
> domain... needs a closer look that I've given it, but might be a
> goo
> I will look at c) unless someone comes up with a better idea
> or someone else gets in first.
That would be great. Grab a hold of the cygwin sources.
winsup/cygwin/localtime.cc claims that it is in the public domain... needs a
closer look that I've given it, but might be a good starting point.
Hi all,
my next TODO item for the Win32 port was to try to bring all the regression
tests up.
Pleased to report that, with a great deal of hackage + kludges (which I hope
to refine and submit as patches for review over the next couple weeks), all
but 10 tests pass!
7 of these fail pretty much
> > Attached is the test program I used.
>
> Can folks please try this on other platforms?
[after some minor changes] Can confirm that LoadLibrary (aka dlopen) does
not reduce the files limit under Win32.
Cheers,
Claudio
---
Certain disclaimers and policies apply to all email sent from Memetr
> Shutdown of an idle postmaster used to take about two or three seconds
> (mostly due to the sync/sleep(2)/sync in md_sync). For the last couple
> of days it's taking more like a dozen seconds. I presume somebody broke
> something, but I'm unsure whether to pin the blame on bgwriter or
> Wind
> 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
Under Win32, localtime returns NULL for dates pre 1970.
A number of places in the code fail to check from a NULL return from
localtime, with none seemingly more problematic than those calls within
DetermineLocalTimeZone, which causes SEGVs in a number of tests (which
clearly pass pre 1970 dates t
> One thought I had was that there should be a common subroutine to do the
> stuff that a new postmaster subprocess needs to do immediately at
> startup. This includes setting IsUnderPostmaster, MyProcPid,
> on_exit_reset in the fork() case, reloading global variables in the
> exec() case, and m
Tom Lane wrote:
> What does SSDataBaseInit have to do with acquiring configuration
> parameters? (Answer: nothing.) Why is it being called here at all,
> and why only in the EXEC_BACKEND case? Sure can't figure
> that out from
> the uncommented code. Is it a good idea to do it? I rather doub
> It needs rewritten. The hacks inserted for ExecBackend have largely
> destroyed the former structure (such as it was), and the lack of any
> commentary added with said hacks didn't help. I am thinking
> of tackling that rewrite once the dust has settled.
Anything in particular?
With your
> Looking at postmaster.c, my head started to spin a little. I think I
> understood that exec case or not, by the time we get to BackendRun we
> have already done all the fork/exec action. Have I read this correctly?
Yes. In the normal case, fork() then BackendRun. In the EXEC_BACKEND case,
fo
The current version of dirmod.c causes a compilation failure under MingW:
../../../src/port/libpgport.a(dirmod.o.b)(.text+0xe1): In function
`pgrename':
e:/cygwin/opt/diff8c/pgsql/src/port/dirmod.c:38: undefined reference to
`errstart'
../../../src/port/libpgport.a(dirmod.o.b)(.text+0xef):e:/cygw
Tom Lane wrote:
> Claudio Natoli <[EMAIL PROTECTED]> writes:
> > One important thing I forgot, that someone could start looking at now:
> > * backends keeping files open when other backends are trying to
> > delete/rename them
>
> > We must do better f
Some fool wrote:
> It will then be a matter of fixing things like:
> * installation directory issues (/usr/local/pgsql/bin won't work too
>well outside of the MingW environment :-)
> * general directory handling (ie. whitespaces in directory names;
>forward/backslash path canonicalizatio
> Where can I get the latest tarball for Win32 development?
There isn't a specific Win32 tarball, but you can get nightly snapshots from
the usual place (ftp://ftp.postgresql.org/pub/dev/), or pull down the tip
from CVS.
Reading back through the thread though, you'll find that the code is not y
Andrew Dunstan wrote:
> Claudio Natoli wrote:
>
> > * installation directory issues (/usr/local/pgsql/bin won't work too
> > well outside of the MingW environment :-)
>
>
> Clearly we will need an installer for a binary distribution.
Yes. To be more precise,
> I would like very much to help any way possible in solving any last
> remaining issues. Once the CVS sources are compliable, it will be
> easier to make meaningful contributions. I'm really looking
> forward to testing and benchmarking the win32 port. A big thanks
> to all who continue to w
> > > 1. setjmp/longjmp stack manipulation (i.e. ELOG)
> >
> > Wrote a small program to check this out. As we
> > hoped/assumed/expected, it looks just fine.
> Great!
> Just checking - we're talking doing this from inside a user APC, right?
Yes, of course! :-)
[From a user APC executing on th
> 1. setjmp/longjmp stack manipulation (i.e. ELOG)
Wrote a small program to check this out. As we hoped/assumed/expected, it
looks just fine.
Magnus, are you working on a second run at this stuff?
Cheers,
Claudio
---
Certain disclaimers and policies apply to all email sent from Memetrics.
F
> IMO, it's time for a second run of the code, and a functional test which
> simulates the command processing loop which should include:
>
> 1. setjmp/longjmp stack manipulation (i.e. ELOG)
> 2. in process/out of process generates signals
> 3. all thread mechanisms.
Definitely. Magnus, I assume
> Tom Lane said:
> >
> > Actually, I was expecting you to complain that the s_lock.h coding is
> > gcc-specific. Which compilers do we need to support on Windows?
> >
>
> AFAIK the only target build environment for Windows right now is
> MinGW/gcc
Yes, I'm working with MingW.
> If anyone kno
> Ok, I think having a native win32 spin-lock implementation
> (say, based on InterlockedCompareExchange?) is the minimal
> impact answer. I'll work on producing that.
Or, maybe we'll just use the tas() implementation that already exists for
__i386__/__x86_64__ in s_lock.h. How did I miss that?
Tom Lane writes:
> [cvs is your friend...] It appears to have been added as part of the
> MinGW porting work last May. I don't have much faith in it; as far as
> I heard the MinGW port never got further than making the client-side
> code work, and so this file has no real-world testing.
FWIW,
Tom Lane writes:
> > Just working with what we've already got. There seems to be very
> > usable code in src/backend/port/win32/sema.c, which gets invoked
> > as Win32 does not have spin-locks, but unfortunately relies on
> > ShmemInitStruct.
>
> Win32 certainly has spinlocks; it does not run
> You have broken stuff before by rearranging the sequence of
operations...
Ah, yeah, well, FWIW, if that is the only thing that gets broken in the
process of making this port, I'll be more than satisfied. Will that be held
against me forever?
> what exactly have you got in mind here?
Moving
In CreateSharedMemoryAndSemaphores, there is the following comment, just
before CreateLWLocks():
/*
* Now initialize LWLocks, which do shared memory allocation and are
* needed for InitShmemIndex.
*/
Also, in InitShmemAllocation, there is:
/* ShmemInde
Bruce Momjian wrote:
> > * a workable pipe replacement
>
> I don't have 'pipe' mentioned on the win32 patch. Can you
> give details?
Yeah you do. The second point under "Problems with select()".
Basically, the Win32 call to pipe() returns a file descriptor which is
invalid to pass on to W
Hi all,
just a small note to anyone who is interested in the status of this port.
Firstly, the fork/exec changes are coming along well. The first patch, for
fork/exec'ing of backends has been accepted and applied. A second patch, for
fork/exec'ing of the remainder of the postgres process has jus
> Claudio Natoli <[EMAIL PROTECTED]> writes:
> > So this means we'll have to pull relHash out of the shared FreeSpaceMap
> > structure and make it a variable in it's own right?
>
> Hm. The freespace.c code is relatively new and might not be jumping
&g
> I'm not sure if you're confusing backend-local hashes with shared
> hashes, or hash control headers with the actual shared data. But
> the above is a false statement. DynaHashCxt is not shared.
No, wasn't confused over that. Was confused over something else though :-)
> Shared hashes are a
Hi all,
I'm working on getting BackendFork converted to a fork/exec model, and have
hit the following wall.
All the ShmemInitHash structures are allocated using DynaHashCxt. Clearly,
this context is going to have to be shared across backends in the fork/exec
case, but I can't see a non-trivial w
Bruce Momjian wrote:
> > Speaking of which, any ETA on this? Bruce? If anyone from
> core can indicate
> > how they'd like this architected (from the perspective of code
> > rearrangement), I'm willing to have a crack at this.
>
> http://momjian.postgresql.org/main/writings/pgsql/win32.h
Andrew Dunstan wrote:
> Here's the situation as I see it:
> . there have been lots of requests for a native Win32 port
> . this is important to some people and not important to others
> . the decision has long ago been made to do it, and some work
> has been done, and more is being done
>
> Isn
> > Claudio Natoli wrote:
Claudio Natoli wrote nothing of the sort :-P
---
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.html";>http://www.memetrics.com/em
> > I'm sorry if I'm being alow here - is there any problem with running a
> > production server on cygwin's postgresql? Is the cygwin port of lesser
> > quality, or otherwise inferior?
>
> Performance, performance, perfomance... and perfomance... it is (almost)
> always worse perfomance when
I'm for putting it in Win32... my 2c.
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> Sent: Friday, 10 October 2003 11:39 AM
> To: Andrew Dunstan
> Cc: Postgresql Hackers; pgsql-hackers-win32
> Subject: Re: [pgsql-hackers-win32] [HACKERS] initdb
>
>
>
> I have add
> Another option would be to create thread local hashtable or other lookup
> structure to which you would register a structure for a particular .c
> file or group of files.
>
> You could then define the structures you need locally without
> affecting other parts of the codebase.
>
>
>
> Myr
> Claudio Natoli <[EMAIL PROTECTED]> writes:
> > FWIW, I've got a threaded version of the WIN32_DEV branch more or less
> > "running" (it is a terrible hack job, so NO, no patches... yet :-), as a
> > proof of concept. Still a work in progress (ok
Tom Lane writes:
> BTW, I've been wondering lately if we'd not be better off to look at
> using threading in the Windows port, if it'd help us get around the
> fork/exec data transfer problem. I'm not sure that it would,
> mind you, but if it would give an answer it might be a lot less painful
t
> Uh, the two big items are Win32 signal code, and reordering
> the startup code to allow exec without fork. Both are pretty
> complicated, but I do ask for assistance on the hackers list.
Ok. I guess we'll just keep our eyes peeled for the next time we can help
out.
Thanks for the replies...
> I am already leading it, I think.
Ok. How do the willing get involved?
Cheers,
Claudio
---
WE HAVE MOVED - PLEASE NOTE OUR NEW CONTACT DETAILS:
THE BASEMENT, 33 EWELL STREET, BALMAIN NSW 2041
TEL: +61 2 9555 1544 FAX: +61 2 9555 6911
Certain disclaimers and policies apply to all email sen
Hi all,
This probably more than a little premature/ill-timed, but I was hoping to
start a groundswell of support for Win32 port.
I, and I imagine quite a number of capable lurkers on the list, would love
to get involved. Is there a way that work can be doled out now/soon, so that
we can make the
Hi all,
just wondering if the guys involved in the Win32 port could give a quick
update?
I'm just (one of the many?) hanging out for this, to justify continued use
of Postgres to the powers that be. Seems like there has been no word on this
for a couple weeks, and I'm not even sure whether or no
66 matches
Mail list logo
