> > > Why not use an anonymous pipe to send data from the parent to the
> > > child process?
> >
> > Doesn't that require the postmaster to stay around to feed that
> > information into the pipe or can the postmaster just shove the data
> > and continue on, and how do the old pipes get cleaned
>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 w
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
critica
You need to make all variable access (including libpq, I think) in the
handler threadsafe. The control handler will execute on a different
thread from the main one (see
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc
/base/handlerroutine.asp).
One way to do this could be t
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
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
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 PROT
Ok, time for yet another signals patch :-)
This one replaces the one I posted yesterday - I managed to mess up my
build environment pretty bad, so while that patch worked in that one, it
would not work on a clean system. There was also a clean bug in pqselect
with regards to NULL timeouts.
As be
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 ver
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
>
&g
Ok, so I know this is pretty ugly. But there is a bug in mingw (current
release - it's fixed in the snapshot version) with regards to readdir()
(see previous mails on win32-hackers). Basically, it doesn't set errno
correctly.
This patch will catch this error with regards to the readdir(), wrap a
c
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 PROTECT
>> 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 s
>>> 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 f
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.3&r2=1.4, second part of the patch).
2) Updates both xlog.c and slru.c in backe
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 no
>> 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.3&r2=3D1.4, second part of the patch).
> I don't really agree wit
> 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 fi
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 an
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 con
just a new timer.c
//Magnus
>-Original Message-
>From: Claudio Natoli [mailto:[EMAIL PROTECTED]
>Sent: den 17 februari 2004 12:25
>To: Magnus Hagander; [EMAIL PROTECTED];
>[EMAIL PROTECTED]
>Subject: RE: [pgsql-hackers-win32] win32 setitimer implementation
>
>
> 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 clea
Hi!
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.
//Magnus
<>
apc_socket.patch
Description: apc_socket.patch
---(end of broadcast)---
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 w
> > 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
> > 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,
>> > > 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 th
L PROTECTED]
>Sent: den 23 mars 2004 16:02
>To: Magnus Hagander
>Cc: Andrew Dunstan; [EMAIL PROTECTED]
>Subject: Re: [PATCHES] Initial eventlog support on win32
>
>
>"Magnus Hagander" <[EMAIL PROTECTED]> writes:
>> Based on what Andrew wrot
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
>> 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
>> 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
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
>> 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.
>> 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
>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 do
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 U
Here's an attempt at new socket and signal code for win32.
It works on the principle of turning sockets into non-blocking, and then
emulate blocking behaviour on top of that, while allowing signals to
run. Signals are now implemented using an event instead of APCs, thus
getting rid of the issue of
> > 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
EINTR 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 pri
Per discussion earlier today, here is a fix that lets ereport() on win32
report socket errors.
//Magnus
<>
win32_socketerror.patch
Description: win32_socketerror.patch
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
This mail apparantly didn't make it through because it was too large.
Resending it without the largest file, tzlib.tgz. I've put this file (+
the patches) on http://www.hagander.net/pgsql/.
//Magnus
> -Original Message-
> From: Magnus Hagander
> Sent: Sunday, Apr
> Andrew Dunstan wrote:
> > Attached are 2 files needed to create a pgkill facility for
> Windows,
> > and a complementary patch for src/bin/Makefile
>
> If it's only for the regression tests, then it should go into
> that directory.
It is not. It is a tool required to do any "controlled backe
> > >>Attached are 2 files needed to create a pgkill facility
> for Windows,
> > >>and a complementary patch for src/bin/Makefile
> > >>
> > >>
> > >
> > >If it's only for the regression tests, then it should go into that
> > >directory.
> > >
> > >
> > >
> > >
> >
> > In effect you need
> 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
does
> >> 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 mor
> 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 e
> > . 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
> > The installer-skeleton I have right now permits
> installation as local
> > system but recommends a user account. But that's just
> functionality to
> > remove, so that's easily done. In the other case, it prompts for
> > username and password to run as.
>
> How would it install on an XP
> > Yes, you need to create another user.
> > When running as a service, just tell the installer. It
> should set up
> > required permissions. Then start the service as normal using the
> > Service Control Manager.
> >
> > When running manually, you will have to grant the postgres user the
> >
> * timezone/private.h looks like it should be picking up its
> constants in another way (ie. had to comment out
> HAVE_SYMLINK). Looks like we'll need to spend some time in
> this file if we want it platform independent.
Yes, that's the place that the tz lib stores these things. Though in
tha
> 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 ea
> > 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 loca
> Spoke about this off-list with Magnus; he's strongly for
> stand-alone; I'm fence-sitting. We see that clearly there are
> some niceties to having this in the postmaster (one less exe
> to build/configure; same install set for win/*nix; etc), but
> the downsides include minor impact on the co
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 following
.
Sorry about not checking this before I sent it.
//Magnus
> -Original Message-
> From: Magnus Hagander
> Sent: Monday, May 17, 2004 10:57 PM
> To: [EMAIL PROTECTED]
> Subject: [PATCHES] Timezone code, one more try
>
> Ok, here is another attempt at the timezone
> > > 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 ap
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 "Ma
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: expla
>> 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 PGPR
>> 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
ternative.
//Magnus
>-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 dis
limits.h needed in oracle_compat.c to compile on win32. See attached
patch.
//Magnus
<>
oracle_compat.patch
Description: oracle_compat.patch
---(end of broadcast)---
TIP 8: explain analyze is your friend
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 othe
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 re
Seems it needs an implementation of the "pgwin32 special kill". Try
stealing the one from backend/port/win32/signal.c (look for pqkill).
Perhaps this function (not the rest of signal.c!) should be moved into
port/, instead of backend/port. IIRC it depends on no other backend
code.
//Magnus
> --
> > You wouldn't expect the environment var to be set by an app
> in those
> > cases - it would be set by a sysadmin or an installer on a
> system-wide
> > basis when pg is installed in other than the hardcoded location. At
> > least, that's the way I understood Bruce's suggestion.
>
> Strang
> > > > > 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 fi
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
>
&
>> >> 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
> After patching postmaster.c (see previous post) I'm unable to
> link on win32 (mingw). I get the following errors:
>
> gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
> -Wmissing-declaratio
> ns -L../../src/port -o postgres.exe -Wl,--base-file,postgres.base
> postgres.exp access/SUBS
> 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:
> After discussion on win32 mailing list, I suggest to store
> source under src/bin/pg_event
I assume you mean src/bin/pg
>> Here is what I think happened (this might be a bug, might not): Each
>> night I run initdb but I use a special postgresql.conf which is
>> optimized for quick data loading. This is copied over the
>default one
>> after the server is started. This contains the locale
>information which
>> is
This patch updates pgpipe() on win32 to log exactly which part of the
call fails when it does. (As it is now, there is no way to figure out
the point of error). Shouldn't be a problem since it's most defintily
not a performance-critical path (only called on pgstat startup ATM).
This should help us
>> 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
>mechan
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
> 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
>> 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 yo
>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 alread
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 showstoppers,
omjian [mailto:[EMAIL PROTECTED]
>
>
>
>Magnus, where are we on this refactoring process.
>
>---
>
>
>Magnus Hagander wrote:
>> >> * Created function write_stderr(const char *fmt, ...),
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 t
>-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 s
Attached is a patch that adds the option --pwfile= 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 password to b
(or even work at all). I tried 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 C
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 La
> > The reason it will help with support is because newbies will go
> > "SQL_ASCII! I don't want ascii!".
>
> No they won't. They will likely not even notice this message
> in the sea of other messages they've never seen before; and
> even if they do notice it, they will certainly not realize
>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.
>>> 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.
>
>...
> > Probably the big thing this program was trying to solve was for the
> > server to know the output file name, even with log file
> rotation, and
> > I don't see a pipe and 'rotatelogs' process really addressing this.
>
> It could be done. Given the infrastructure we have now, it's
> possib
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
Som
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 in
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
>
>
>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
>! xperl_archlibexp=$(perl
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
1 - 100 of 685 matches
Mail list logo
