Zach Irmen said:
Tom Lane [EMAIL PROTECTED] writes:
What happens if getenv(HOME) returns NULL?
Yeah, the strdup fails. I'll take it out to fix that.
You also need to think about Windows
Can I just ifndef WIN32 and not think about it? I'm not sure how that
would work either.
If we are
Hi!
Here is a first sketch at Win32 signal handling. First a couple of
comments:
* This is just two files. It is not integrated with postgresql yet.
* Uses named pipes. Shared mem was slightly faster, named pipes a lot
cleaner. And the signal handlers themselves should not be performance
Here's the latest win32 signals code, this time in the form of a patch
against the latest shapshot. It also includes the replacement of kill()
with pqkill() and sigsetmask() with pqsigsetmask().
Passes all tests fine on my linux machine once applied. Still doesn't
link completely on Win32 - there
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
Ok, here we go again.
Taking into account Claudios comments on the previous patch, as well as
some more fooling around here of my own, here's a fourth (and final?)
one.
If there are no further comments from Claudio or anyone else, I feel
this is now ready to be applied.
Differences from last
Ok, so apparantly I was supposed to attach a file there.
//Magnus
-Original Message-
From: Magnus Hagander
Sent: den 4 februari 2004 23:09
To: [EMAIL PROTECTED]
Cc: pgsql-hackers-win32; Claudio Natoli
Subject: [pgsql-hackers-win32] win32 signals, part 4
Ok, here we go again.
Taking
Oops. Naturally, if this is accepted, the same change needs to be done
in xlog.c. I can update the patch if you want me to, or you can jus
tmanually copy the code over :)
//Magnus
-Original Message-
From: Magnus Hagander
Sent: den 4 februari 2004 23:44
To: [EMAIL PROTECTED]
Subject
Taking into account Claudios comments on the previous patch,
as well as
some more fooling around here of my own, here's a fourth
(and final?)
one.
Actually, please hold just a second :-)
I have an updated version of this patch that fixes the remaining small
issue (FATAL on failure to set
Hello!
Here is an updated version of the win32 readdir patch.
1) Now puts in exactly the same change as the current-cvs mingw code
does. (see
http://cvs.sourceforge.net/viewcvs.py/mingw/runtime/mingwex/dirent.c?r1=
1.3r2=1.4, second part of the patch).
2) Updates both xlog.c and slru.c in
Actually, it seems I forgot to attach the actual patch *again*. Sheesh.
Here goes.
//Magnus
Here's the new one. Turns out I had already fixed the one part
I thought
I still had, so it was already ready.
Changes since last patch:
1) Error messages in pgwin32_signal_initialize() are now all
Here is an updated version of the win32 readdir patch.
1) Now puts in exactly the same change as the current-cvs mingw code
does. (see
http://cvs.sourceforge.net/viewcvs.py/mingw/runtime/mingwex/dir
ent.c?r1=3D
1.3r2=3D1.4, second part of the patch).
I don't really agree with cluttering
Claudio Natoli [EMAIL PROTECTED] writes:
Under Win32, stat() returns an st_ino field, but it has no
meaning (on
Win2K, and possibly all Win32 variants, it is always 0).
MSDN says:
Number of the information node (the inode) for the file
(UNIX-specific). On UNIX file systems,
This patch makes the block on semaphore interruptible by signals on
win32. Without this, you can't kill a backend when it's waiting on a
lock.
//Magnus
win32_semint.patch
Description: win32_semint.patch
---(end of broadcast)---
TIP 8: explain
Hello!
Here is a patch that implements setitimer() on win32. With this patch
applied, deadlock detection and statement_timeout now works.
The file timer.c goes into src/backend/port/win32/.
The patch also removes two lines of printf debugging accidentally left
in pqsignal.h, in the console
For application to HEAD, following community review.
* Mostly, casting etc to remove compilation warnings in win32
only code.
* main.c: set _IONBF to stdout/stderr under win32 (under
win32, _IOLBF defaults to full buffering)
* pg_resetxlog/Makefile: ensures dirmod.o gets cleaned (got
This patch adds initial eventlog support on win32. It's good enough for
most purposes, but we will probably want a specific message DLL later to
format the messages nicer.
The patch mimcs the syslog handling in most cases. It also hijacks the
syslog guc variable. Since syslog is not available on
Magnus Hagander wrote:
The patch mimcs the syslog handling in most cases. It also hijacks
the syslog guc variable.
I'm less happy about this. In fact the 0 | 1 | 2 for syslog is very
hokey anyway. What is more, it is not inconceivable that
someone would
run syslogd on a Windows
Here's a patch implementing the thread method to
workaround the bug
with socket calls in signal handlers. See details in mail to
pgsql-hackers-win32 a couple of minutes ago.
Looks ok, but wouldn't it be better placed in pgstat.c?
Actually, I don't think so. I considered it,
Thanks. I was getting to that, but hadn't started :-)
Per our discussion off-list, I agree with this method, and the patch
looks fine to me.
//Magnus
-Original Message-
From: Claudio Natoli [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 25, 2004 2:07 AM
To: '[EMAIL PROTECTED]'
Claudio Natoli [EMAIL PROTECTED] writes:
+ #ifdef WIN32
+/* Interrupted by socket/APC interaction? */
+if (n 0 GetLastError() == ERROR_IO_PENDING)
+errno = EINTR;
+ #endif
This seems a bit schizophrenic; if you can assign to errno,
why can't you
read from it? Would
Ugh. Is there a way we can insert a wrapper layer without
modifying the
call sites? I'm thinking of some kind of macro hack, say
[snip]
Sure. Think we've even done this before (also, prevents
developers needing to remember to use pg_*).
Yup, it's done to redefine kill() to pqkill(). See
Hopeless, or cute, work-around?
It's possibly workable in the limited context of the postmaster, but
I've got doubts about doing it in libpq where we can't assume we know
what the surrounding application will do.
No need to touch the frontend parts at all. Our APCs are server side
only, so it's
Hopeless, or cute, work-around?
It's possibly workable in the limited context of the postmaster, but
I've got doubts about doing it in libpq where we can't
assume we know
what the surrounding application will do.
No need to touch the frontend parts at all. Our APCs are server side
only,
I don't think it's a good idea in general to redefine something as
fundamental as select, send, recv etc from libpq-fe.h (or
files included
from there).
Certainly not; the redefinition would have to be in files that are not
part of the exported API. However this is not difficult.
port.h is
The third option is to redefine all these functions into our own, and
implement our own emulation layer. This means our own
select(), send(),
recv() (more? I don't think so). And have these call the
native winsock
APIs (WSAEventSelect(), WSASend(), WSARecv() etc). These
functions are
On 23-Mar-04, at 4:57 PM, Magnus Hagander wrote:
Something about like this?
Looks good. One trivial gripe: you need to update psql/tab-complete.c
Thanks. Since I've heard nothing else, here is an updated patch that
does this, and also adds some documentation (please double check that
part
A thought about this - how about converting pgpiperead() and
pgpipewrite() into functions intead of macros (on win32 - still
redifining them on != win32), mimicking the behaviour of read() and
write()? Then we could do awya with the #ifdefs at the points where its
used, and just expect the normal
A thought about this - how about converting pgpiperead() and
pgpipewrite() into functions intead of macros (on win32 - still
redifining them on != win32), mimicking the behaviour of read() and
write()?
And #def'ing them to be read + write under win32? Don't want
to change every
for consistency
//Magnus
-Original Message-
From: Magnus Hagander
Sent: den 4 april 2004 22:08
To: [EMAIL PROTECTED]
Subject: [PATCHES] New socket code for win32
Here's an attempt at new socket and signal code for win32.
It works on the principle of turning sockets into
non-blocking
Per discussion earlier today, here is a fix that lets ereport() on win32
report socket errors.
//Magnus
win32_socketerror.patch
win32_socketerror.patch
Description: win32_socketerror.patch
---(end of broadcast)---
TIP 5: Have you checked our
1. You forgot to check localsystem, as well as domain
admins. These two have even higher permissions than the ones
you test for, and one of them is the default if Postgre ever
makes it to become a service.
Not at all. Local System is a member of the Administrators group (no, it
doesn't
Why? If we refuse to run as root on Unix, I do not see an
argument
for being more forgiving on Windows.
I am not sure it is as easy to run as non-admin on Win32 as
it is to
run as non-root on Unix. Is it?
It is a little bit more tricky, but not much. I'd say it's more a factor
I played a bit with that code. According to Microsoft samples
for service managers, errors and events should be logged to
eventlog. so I added a function (almost copy of sample
service code), it's a messy, but it was enough to see what is
happening with the service.
Consider using
. if the installer is running as Administrator, it should create a
Postgres user
IOW, we need to make it as easy as possible to be secure.
No objection to that idea ...
I don't think we should create a postgres user. We should tell the guy
who installs it to do that, and have him tell
For application to HEAD, following community review.
sysv_shmem.c patch is to correct a bug that prevents the
postmaster recovering from an unexpected backend termination.
Great to see you caught that. That's one more off my list of things to
dig into. I expected it was something that easy,
Great to see you caught that. That's one more off my list
of things to
dig into.
Are there any not listed here:
http://momjian.postgresql.org/main/writings/pgsql/win32.html
If so, they probably should be put up.
I don't think so. It's mostly sub-issues under the known locale
For review, comments and possible application to HEAD.
This code implements a warning when the postmaster is started as a
high-privilege account on win32 (administrator or power users).
Previously, postgresql has exited out on Unix when running as root -
this is a similar check, with the
so it has to be earlier. I can put it much earlier in
both postgres
and postmaster, but by having it in main.c, I have it in only one
place. It doesn't do any palloc or anything fancy, because of
course it is also used by client apps.
Patch attached and applied.
And
Per previous discussions, here are two functions to send INT and TERM
signals to other backends.They permit only INT and TERM, and permits
sending only to postgresql backends (as registered in pgstat).
Documentation to follow. I'd appreciate some pointers as to where to put
this. A new section
This patch fixes the find_my_exec code for pgstat backends. Required for
TZ stuff (and possibly others) to work in the pgstat backends.
//Magnus
pgstat_exec_cleanup.patch
Description: pgstat_exec_cleanup.patch
---(end of broadcast)---
TIP 8:
Per previous discussions, here are two functions to send INT and TERM
signals to other backends.They permit only INT and TERM, and permits
sending only to postgresql backends (as registered in pgstat).
Why does this depend on pgstat? ISTM it would be better to use the
per-backend PGPROC
The other thought is that you're not going to have much use
of this if
you don't have pgstat anyway - how are you going to find out which
backends actually exist?
Uh, what about ps(1)?
Well, if you ran run ps(1), then you can probably run kill(1) too. The
main point of this patch was to be
-Original Message-
From: Neil Conway [mailto:[EMAIL PROTECTED]
Sent: den 22 maj 2004 10:00
To: Magnus Hagander
Cc: [EMAIL PROTECTED]
Subject: Re: [PATCHES] Cancel/Kill backend functions
Magnus Hagander wrote:
Per previous discussions, here are two functions to send INT and TERM
signals
This patch changes the order of libraries on the link command when
linking things with pgport. This is required for win32 to build when
modules in libpgport refer to global variables in the backend (right
now, specifically path.c does this). And I don't see that it should
cause any problems on
The following patch fixes locale support under win32.
* Saves and reloads LC_COLLATE and LC_CTYPE when a new backend is
execed. Also preserved in pgstat even though it's supposedly not used
there at the moment, to be on the safe side for the future. With this
patch, passes regression tests with
As for how to do it - on Windows you *can* get the
path of the
DLL that is executing your code, using GetModuleFileName().
Hardly cross-platform, but can be done.
That sounds pretty reasonable to me.
True, and we already have our own find_my_exec() which
works
Arrgh, when will I ever learn :-(
Attached.
//Magnus
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: den 26 maj 2004 20:50
To: Magnus Hagander
Cc: Neil Conway; [EMAIL PROTECTED]
Subject: Re: [PATCHES] Cancel/Kill backend functions
Magnus, would you please
Okay, here is an updated patch. now uses IsBackendPid(), which is
closely modeled (read cut-and-pasted) from
TransactionIdIsInProgress().
I wonder what can happen if a backend passes the
IsBackendPid() test and
terminates just before the kill() signal? It should be pretty unlikely
but
The purpose of this patch is to fix an error when
log_destination is set to 'eventlog' value in postgresql.conf files.
Looks good to me, just a couple of tiny things:
snip
After discussion on win32 mailing list, I suggest to store
source under src/bin/pg_event
I assume you mean
It certainly doesn't. There still was a bug with the locale stuff,
though - the GUC variable was not set in the child
processes. So show
lc_collate would *always* return C, for example. attached
patch fixes
this.
Hm. Why were these vars not propagated by the regular
mechanism for GUC
Per previous patch, win32 required the check for admin privs to be moved
from main.c into postmaster.c, because elog was not available at this
time. While working on fixing that all the way (moving the unix one as
well), I realised this wasn't good, and did it this way instead:
* Created function
* Created function write_stderr(const char *fmt, ...), used
before elog
can be used. This function will write to stderr on unix and on win32
fconsole. It will write to the eventlog on win32 when running as a
service.
* Changed all (most? I think I got all) fprintf(stderr,...)
to use this
snip
Oh, and I notice the use of the PowerUsers group - iirc,
there is no such group on NT4 domains, so the attempt to get
the SID will fail.
That is one weird NT4.. :-)
First of all, Power Users is not a domain group, it is a local group.
It has nothing to do with your domain. As such,
This will prevent PostgreSQL being runable on NT4 by anyone
with admin
privileges, except as a service.
Are we actually supporting NT4? I recall quite a bit of
discussion long ago about which versions of Windows were
really reasonable to support, but I don't recall if there was
a
If you mean only run one instance of postmaster as service,
that's not true.
If you like two pgsql servers (i.e. db clusters), you can
install two services, both using the same binary with
different cmd line arguments.
In which case, what would 'net stop postgresql' do? What you suggest
It hasn't been discussed, but it would be fairly trivial to
add this to the service installer. (A bit more work on the MSI
installer, but we could do with that one just installing the
default instance at least for starters).
Correcting myself on this one - the MSI installer already supports
It hasn't been discussed, but it would be fairly trivial to
add this to the service installer. (A bit more work on the MSI
installer, but we could do with that one just installing the
default instance at least for starters).
Correcting myself on this one - the MSI installer already supports
Some nitpicking on details:
The comment above AutoVacMain() claims:
! * Main entry point for bgwriter process
I also see a bunch of // comments, I think those are not appreciated.
Haven't had time to look much at the actual functionality. Just did a
quick look-through for win32
[mailto:[EMAIL PROTECTED]
Magnus, where are we on this refactoring process.
---
Magnus Hagander wrote:
* Created function write_stderr(const char *fmt, ...), used
before elog
can be used. This function will write
We require the MS MC compiler to build the BIN file (note - this is
not C - this is the Message Compiler). The Ccode should compile fine
in mingw.
Not requiring it is the reason we'd include the .BIN file in CVS. MC is
only needed to *rebuild* it.
//Magnus
-Original Message-
From:
Amended patch attached.
Claudio
Hi!
Been testing this, and found a couple of small issues. Attached is a
patch that fixes these. (Note - Claudios patch is included in this one,
since it hasn't been applied yet..)
The issues:
1) When something goes bad, output went to stderr. No way to see
-Original Message-
From: Magnus Hagander
Sent: den 19 juni 2004 13:55
To: Bruce Momjian
Cc: Tom Lane; [EMAIL PROTECTED]
Subject: Re: [PATCHES] stderr win32 admin check
I plan to resubmit this patch shortly (hopefully during the weekend)
including supprot for detecting if running as a service
Attached is a patch that adds the option --pwfile=filename to initdb.
The first line of this file is used to set the new superuser password
(the same way --pwprompt asks for one).
This feature is needed for the win32 GUI installer (possibly other
installers?), which need a way to specify the
to
model it on stuff that's nearby. If not, let me know where I missed and
I'll update it.
//Magnus
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: den 2 juni 2004 23:30
To: Magnus Hagander
Cc: Neil Conway; [EMAIL PROTECTED]
Subject: Re: [PATCHES] Cancel/Kill
You probably would've been a lot less confused if I had actually
included the *patch* along with the C file..
Sorry!
//Magnus
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: den 20 juni 2004 20:27
To: Magnus Hagander
Cc: Tom Lane; [EMAIL PROTECTED]
Subject: Re
The only part of this discussion that I'd really be prepared
to buy into
is the part about *if* you use -W or --pwfile, then set up pg_hba.conf
with MD5 as the default auth (because that's probably what the user
wants anyway). But otherwise I think we should leave initdb's behavior
alone. I do
The only part of this discussion that I'd really be prepared=20
to buy into
is the part about *if* you use -W or --pwfile, then set up
pg_hba.conf
with MD5 as the default auth (because that's probably what the user
wants anyway).
Ok. Here is a patch that does this.
... and rather severely
Here is a patch required to build plperl with win32. The issues were:
* perl_useshrplib gets set to yes and not to true. I assume it's set
to true on unix, so I left both.
* Need to translate backslashes into slashes
* The linker config coming out of perl was for MSVC and not for mingw
Some of
Readline is pretty badly broken under mingw. Basically, it disables the
alt-gr key, which renders psql almost useless on most locales (no way to
type backslash, and a whole lot of other characters, for example).
This patch disables readline on win32. (meaning it's back to working the
way it did
Ok, here is one more try at the initdb default authentication stuff.
This one adds the switches --ident and --trust, which will configure
pg_hba.conf with ident and trust authentication respectively. If trust
authentication is selected, a warning is written to pg_hba.conf. The old
switches for
This one makes it mandatory to pick some kind of
authentication. If
that's not wanted, it's easy to change it to default to
trust (which
I think is wrong, but we've been through that already..)
I don't think I like any of this. Sooner rather than later, people
need to look
Magnus, why is this reassignment needed, basically the 'else' part:
! ifeq ($(PORTNAME), win32)
! xperl_archlibexp=$(subst \,/,$(perl_archlibexp))
! xperl_privlibexp=$(subst \,/,$(perl_privlibexp))
! perl_embed_ldflags=-L $(xperl_archlibexp)/CORE -lperl58
! else
!
Here's a version of this patch that includes documentation updates.
//Magnus
-Original Message-
From: Magnus Hagander
Sent: den 15 juli 2004 23:02
To: [EMAIL PROTECTED]
Subject: [PATCHES] initdb authentication
Ok, here is one more try at the initdb default authentication stuff
has been fixed by the disabling of readline)
//Magnus
-Original Message-
From: Mark Cave-Ayland [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 21, 2004 12:38 PM
To: Magnus Hagander; 'Mark Kirkwood'; 'Peter Eisentraut'
Cc: [EMAIL PROTECTED]
Subject: RE: [PATCHES] win32 readline
Hmm. And this is a cvs pull that was before Bruce actually disabled
readline? What locale are you in?
Actually, I just just typed away in the bash shell, which
uses readline as well.
Ok, then we're testing completely different things. I'm talking about
the psql client when running under
Ok, here is another one.
Doc patches coming up if/when this one is approved.
//Magnus
+ /* Kerberos methods not listed because they are not supported
+* over local connections and are rejected in hba.c */
Is this true of all local connections, or only Unix socket
Remove 'syslog' GUC variable, and add more logical 'log_destination'
variable to control logoutput location on Unix and Win32.
I just noticed that this patch seems to have replaced a PGC_SIGHUP
config item (the syslog flag) with a PGC_POSTMASTER config item
(log_destination). What was the
Aggh, nevermind. Now that I pulled new cvs again I see this has already
been committed. Sorry about the noise.
//Magnus
-Original Message-
From: Magnus Hagander
Sent: den 24 juli 2004 19:30
To: [EMAIL PROTECTED]
Subject: [PATCHES] win32 missing header
Here is again a missing part
Bruce Momjian [EMAIL PROTECTED] writes:
This needs to be applied soon so the installer can be tested.
I can't speak to the details of the Windows process-launch code,
but it looked okay to me otherwise.
One point: if I understood correctly, this is necessary only for
Windows 2000, because we've
OK, I see your point. Can anyone remember why this was needed? I
remember Magnus wanted query cancel, but what was the logic
for session
termination?
I think the argument for it went along the lines of what if you've got
a misbehaving client that continually issues expensive queries, so
That's not quite the argument I think I had :-) But withuot
being able
to kill the backends, there just no way for me to handle the
sitaution
when I have a hundred clients eating up all available
connections and/or
memory, just sitting idle, because of some freak bug in a
client. Yes,
if
This patch along with the attached files (.tar.gz unpacks in src/) adds
VERSIONINFO to all binaries under win32. This is generally considered a
good thing (actually, I think it's required to be allowed to call your
program Designed for Microsoft Windows. We're not going to get that
anyway, but it
This patch along with the attached files (.tar.gz unpacks in src/)
adds VERSIONINFO to all binaries under win32. This is generally
considered a good thing
Out of curiosity: Why?
Well, because it allows the user as well as other programs to identify
what version of a file is installed. For
This patch along with the attached files (.tar.gz unpacks in
src/) adds
VERSIONINFO to all binaries under win32.
Ya know, this is the sort of invasive junk that I was afraid people
would try to force on us for the Windows port :-(.
I fail to see how this is so invasive. And I definitly don't
Well, because it allows the user as well as other programs to
identify what version of a file is installed.
psql --version
That works for an executable. And that works for the user. Doesn't work
as well for a piece of software that does this. How is it supposed to
know which .EXEs it can send
Makefile.global or similar could define the build rule once, like
%.o: %.rc
windres -DFILEDESC=$(FILEDESC) $ -o $@
--include-dir=$(top_builddir)/src/include
Actually, I was wondering if we could not include this in a build rule
for executables, so that it's not necessary for the
All that is then needed is to teach each binary to link in
win32ver.o.
For initdb, I've done this like:
ifeq ($(PORTNAME), win32)
FILEDESC=initdb - initialize a new database cluster
OBJS+=win32ver.o
endif
I assume what you would like is to have just the FILEDESC
row in there?
One more thing I realised - we need two different types of
versioninfo
structures, because one fields tells wether it's a DLL or
an app. How
would you prefer this done - either using
$(WIN32VERDLL)/$(WIN32VERAPP) (or
$(PORTOBJSHLIB)/$(PORTOBJAPP) if we
go down that route), or
Oh, and for the record, we version libpq.dll on windows in the 7.x.y
manner, and have been doing so ever since we first added
win32 support.
We can't really back that one down, so we'd need an
exception for that
one.
This one *does* matter, because it's the main library other
The crash people are getting in initdb is due to the 1.19
revision to
pgtz.c. Not sure why yet...looking into it...
Unfortunate behavior when probing pre-1970 dates, maybe?
Indeed that was the problem. Attached patch fixes the issue
here and for Merlin :-)
I've also figured out
Perhaps a compromise would be to set versioninfo on
libpq.dll (which
we alerady do), and on all the EXEs, and ignore the rest of
the DLLs.
It's not ideal, but it's a great deal better than nothing at all.
If that is an option, why not just put versions into the
build-time linkable
Per discussion off-list with Tom, here is a patch to redo the way the
system timezone is detected on win32. Instead of trying to figure out
what to do, it just looks in a lookup table for all available timezones
(there is a finite and stable number of timezones on a win32 system,
unlike unixes
Per discussion off-list with Tom, here is a patch to redo the way the
system timezone is detected on win32.
Er ... no patch attached?
Heh. Oops.
//Magnus
tz_map.patch
Description: tz_map.patch
---(end of broadcast)---
TIP 2: you can get off
Seems bootstrapmain() never called find_my_exec(), and therefor never
manged to fill in the path to the timezone directory. With the new
timezone code that actully picks up a decent timezone on my system, that
causes initdb to fail because it can't find any acceptable timezone at
all.
This patch
Here's another attempt at adding version info to win32 stuff. Lots of
changes since last try :-)
* Build rules in Makefile.global builds the .o or .rc file required.
Each makefile defines PGFILEDESC with a file description that gets
imported.
* Full version number is pulled from pg_config.h. The
* Just two files to add - both go in src/port. (Moved the icon there
per discussion on IM with Bruce)
Can you post the rationale? It seem an odd place for it.
We might want to link it into other binaries in the future, therefor it
should not go under psql/.
It's platform specific, therefor
It's platform specific, therefor it should go in port/.
The criterion for port/ is not whether something is
platform-specific.
It's whether it's a module that helps porting source code. Which this
is not. Maybe we should add a new directory that contains icons and
other random auxiliary
This patch fixes the open item:
o use dynamic buffer for token buffer in win32 admin check
//Magnus
token_buffer.patch
Description: token_buffer.patch
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
Message-
From: Magnus Hagander [mailto:[EMAIL PROTECTED]
Sent: 25 August 2004 14:59
To: Tom Lane
Cc: Dave Page; [EMAIL PROTECTED]
Subject: RE: [pgsql-hackers-win32] postmaster.pid
Ok, if you say so :-) I had the general impression we
wanted that. But
then let's go with the
send-signal-0
This patch attempts to fix the issue with localized timezones on
Windows.
Recap: When running on a localized windows version, the timezone name
returned is also localized, and therefor does not match our lookup
table.
Solution: The registry contains both the name of the timezone in english
and
1 - 100 of 588 matches
Mail list logo
