Bruce Momjian wrote:
Have you looked at the CONNX signal code on the Win32 page:
http://momjian.postgresql.org/main/writings/pgsql/win32.html
It uses shared memory and events.
Yes, and I just did again. I guess I must be missing
something, though -
I don't see what in
If you need a response once it has actually run, then the
main thread
needs to do signal polling now and then. This has the bad
sideeffect
that the main thread will block completely until the signal is
delivered, which might be a while.
I don't know what the semantics are for
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?
Magnus, are you working on a second run at this stuff?
Not right this
Note that the migration guide says that threads are not
supported. So if
we ever went to a threaded implementation we could not go
down this path.
POSIX threads are supported on the upcoming version 3.5... The migration
guide is apparantly not updated.
//Magnus
Hello!
The backend signals code today uses pqsignal() instead of signal() at
all places. But it uses kill() and sigsetmask() (through the macro
PG_SETMASK) directly.
I propose to change this to pqkill() and pqsigsetmask(). In pqsignal.h,
these would be #define:d back to kill() and setsigmask()
Tracing the bgwriter process on my machine makes it real
obvious that in
fact the select delay is allowed to finish out when SIGTERM
is received.
In fact worse than that: it's restarted from the beginning. If 5
seconds have already elapsed, another 10 still elapse before
the select
exits.
Title: Message
Without checking into details, this sounds like it could be a broken
ming/msys installation. Are you on the latest release
version?
Also,
check for the Makefile.port file manually. configure cleraly thinks it has
created it... If it's not there, check if you can create
Without checking into details, this sounds like it could be
a broken
ming/msys installation. Are you on the latest release version?
Also, check for the Makefile.port file manually. configure cleraly
thinks it has created it... If it's not there, check if you
can create
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 in
To create symlinked directories on Win2k NTFS see:
http://www.sysinternals.com/ntw2k/source/misc.shtml#junction
I don't think we could use this s/w though, unless the author is
prepared to relicense it. I'm sure implementing a clean room
version of
the relevant parts
The postmaster's use of nominally unsafe stuff in signal
handlers is not
and never has been a problem, because there is only one place in the
main loop where signals are unblocked, thus no possibility for
something
to interrupt something else. I don't like the idea of
redesigning that
Hi!
Could we have the output from psqlscan.l (in src/bin/psql) added to the
nightly snapshots, the same way it's done with with the other flex
output files, please? It would do wonders for those of us too lazy to
fix their broken flex installations. And if the same script is used to
generate the
I have talked to Tom today and he is willing to implement the
discussed method of doing fsync on every file modified
between checkpoints, and add unlink handling for open files for Win32.
Great news. I'm sure this will benefig Unix platforms as well, when
taking into account the discussions
However, some of the porting team felt that it would be
confusing for people
who typed in www.postgresql.net to be presented with the
GForge interface,
and suggested that we use the domain after what we'll be
calling the new
Tool, namely pgFoundry, thus putting stuff at
Hi!
When debugging on win32, I've created myself a little function that I
feel should be added to the backend proper. While it adds a lot of
vlaue on win32, I think it adds quite a bit of value on non-win32
platforms as well...
The function is pg_kill_backend(pid,signal). superuser-only, of
Hi!
When debugging on win32, I've created myself a little function that I
feel should be added to the backend proper. While it adds a lot of
vlaue on win32, I think it adds quite a bit of value on non-win32
platforms as well...
The function is pg_kill_backend(pid,signal). superuser-only, of
Tom Lane wrote:
it would definitely need to be a lot more constrained than
send-any-signal-to-any-postgres-process ... even for a superuser,
that's a mighty fat-gauge foot-gun.
What sort of constraints do you have in mind?
I'd limit it to SIGINT (query cancel) and SIGTERM (fast shutdown),
Killing backends with runaway queries is a routine administrative
task.
Cancelling runaway queries is a routine task. I'm less
convinced that a
remote kill (ie SIGTERM) facility is such a great idea.
Consider a scenario like:
User A starts transaction.
User A issues a LOCK TABLE (or does
Hi!
From what I can see, a make check runs the parallell tests and a make
installcheck runs the serial tests. Is there any special reason for
this? And for not providing a way to run the other kind of test
depending on the installation?
Stumbled across this when doing regress tests on win32,
In this case, SIGINT (query cancel) will not help, because
all locks
held by the transaction will still be held.
Wrong.
Really?
Please point out where I am wrong in this:
SESSION A: BEGIN TRANSACTION
SESSION A: LOCK TABLE foo IN ACCESS EXCLUSIVE MODE
SESSION
Hi!
1) Is this depending on the server, or the fact that there is a
different libpq.dll in the path? Does a non-win32 client work against
the win32 server, and vice versa?
2) Are you using the import library from mingw, or the one from the old
visual C++ compile? If you are using the import
In this case, SIGINT (query cancel) will not help, because
all locks held by the transaction will still be held.
Wrong.
Really?
[ experiments... ] My apologies --- you are correct about
the present behavior. If a SIGINT arrives while waiting for
client input, it's just
if (query_running)
cancel_query
abort transaction
else if (idle in transaction)
abort transaction
else if (idle not in transaction)
graceful shutdown
or if that is too confusing?
Too hazardous. Say you meant to kill a slow query, only it
finishes just before you
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
If we are going to allow session kill then of course we need
PID for that.
I still say we need this.
Well, that seems to be the consensus, so I won't stand in the way.
If you like the cancel-by-XID idea then I'd
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).
I'm running off snapshots (my bison install is badly broken), and
Hi!
Is there any reason why FRONTEND is not specified in the ecpg build
(specifically the pgtypeslib)? I'm running into build problems because
it pulls backend-specific stuff from port.h in
(postgres_fe.h-c.h-port.h) when tweaking the timezone code.
Or should FRONTEND perhaps even be explicitly
While it's a couple of weeks old, in case it hasn't been seen by those
who need it, the folllowing thread on linux kernel discusses the
fsync-and-IDE-writecache interactions. There is also a comment on MacOS
X - I have no idea if that was already known, but I thought it might be
worth pointing
The snapshots in ftp.postgresql.org/pub/dev/ (and mirrors) appears not
to have updated since Apr 5th. These are supposed to be generated
nightly, right? If so, they seem broken.
//Magnus
---(end of broadcast)---
TIP 9: the planner will ignore
Hello!
Here is a temp fix for the locale issues on win32. It passes regression
tests, but is *NOT* ready to be applied (if nothing else, it at least
needs more error checking).
The issue is that locale settings were not inherited by the postgres
backends when they were execed... Instead, the
IMHO it's not all that important where the source is developed (core
cvs, gborg etc) - whichever suits the development/release model best
shuold be used (meaning inside core only if it should be released on the
very same schedule as the main backend only).
What is more important is the exposure
Are there some ports available to various devices?
What is the lowest memory footprint PostgreSQL has achieved?
[8Mb was last quote]
How little disk space has anyone achieved?
Is that an available port, or just a set of configure options?
Is there a definitive list of supported ports?
* Handle sync() by opening all file opened since the last
fsync and fsync'ing those
- Tom's got this one, as is the most crucial outstanding part
Yes, this is defintly the largest part of the code missing.
* Win32 installer
- I believe Magnus already has something in this
Yes, it was vague. The question is now that we are a month away, do
we
want to target June 1, mid-June, or July 1.
If I may humbly chime in here...there currently is no binary
packing for the win32 port. Magnus is currently working on
an installer/service manager (dubbed 'longer
It definitly is there fro Windows Server 2003, in the new port. But
since you are talking handhelds, are you possibly referring
to Windows
Mobile 2003? That is a whole different beast, and *not* included in
the
win32 part (no Win CE variants are)
Nor are they likely to be at a
Does ecpg need to use the same timezone database as the backend?
I just committed code so it will not, but I am not sure.
I think it should not use it, for the following reasons:
* When ecpg is used to write a program, this is a client program. I'd
expect a client program to follow the
I have added a timezone database to CVS, and enabled it for
Win32. This
allows Win32 to pass our pre-1970 regression tests. There are also
plans to enable this code under Unix so we have a standard database for
all installs and so we can query for valid timezone names.
However, this brings up
1) How do we set the default local timezone for our
database? The OS
knows the local timezone. How do we set our local timezone
on Win32?
On Unix? (On Unix, there is usually an /etc/localtime file that is
created during install.) Perhaps we can query the current timezone
specification
Common practice, for one thing. Windows programs are typically
relocatable, and Windows admins regard programs that rely on
hardcoded paths very poorly indeed.
OK, but how can that work in general? How do other programs handle
this? I don't think we should design a solution that goes
like
The only hard facts that we can use are hardcoded/compiled-in
locations and explicit information passed via command-line
arguments or environment variables. None of this seems to be
useful for Windows installations. As far as I recall, the
Windows installation routines only ask you for
I'm not sure how would one send to the other backends.
Maybe write another file on disk, one for each remote
backend? Surely this can be done somehow. I've heard that
on linux-2.6 they are implementing POSIX message queues
(not sure what those are anyway); maybe we can do that on
tested with autoconf 2.59.
Unfortunately, it does not. It does try to copy if a link
fails, unlike what we have now:
ln -s $ac_rel_source $ac_dest 2/dev/null ||
ln $srcdir/$ac_source $ac_dest 2/dev/null ||
cp -p $srcdir/$ac_source $ac_dest ||
We don't have the last line,
We have a feature freeze scheduled for either June 1 or
whenever a major
feature is completed, whichever is last.
For Win32, we have open:
fsync (Tom)
relative installs (Bruce)
timezone (Magnus)
Is timezone still an open item? I thought it was done.
Certainly we pass the
The only downside to removal is that folks without symlinks
(I believe
Win32 only) will loose that functionality with nothing to
replace it.
However, I think the clarity of removing it is worth it.
Also, I think
someone had a special way to do symlinks on Win32 and we should look
into that.
That is the plan ... unless someone knows a reason why they
can't be
built independently of the core?
How about this one: Everything we have moved from the core
to gborg so far has been a miserable failure. The code is no
longer maintained, or maintained by three different
We've looked at it before. Apart from anything else I don't think
its license is compatible with PostgreSQL's.
Well, people can still use it. We just can't distribute
it... We can
always link to it.
But unless there is a GUI tool (actually, unless it shows up in the
*default* GUI
What might be handy is an alpha build of the win32 version
once the folks developing it feel it's stable enough to merit
such a thing...
http://www.hagander.net/pgsql/win32snap/
Merlin has set a job up that compiles it daily.
It may be broken right this minute because of the exec stuff, but
Postgresql 7.3.1 on Linux i386 - but from what I can see it is on all platforms
It seems pg_get_constraintdef does not remember the setting DEFERRABLE on a
constraint. This has the effect that it does not show up in psql \d commands, and it
is also *not* included in backups from pg_dump.
If you're talking about running as a backend for SMS you can be almost
certain it will not work. That one today works only with MS SQL (not
Oracle, DB2 or anybody else that already have native Win32 versions),
and probably uses a *lot* of the non standard features in it. IIRC the
beta of the new
Agreed, but I still keep thinking that despite some peoples
claims that Windows ain't up to it, DB2, SQL and Exchange
Server as well a probably others that don't use raw
partitions have got over this problem, so therefore we should
be able to. Admittedly Microsoft have a bit of an
* Backend should pass its version number, database encoding,
default client encoding, and possibly other data (any ideas?) to
frontend during startup, to avoid need for explicit queries to get
this info. We could also consider eliminating SET commands sent by
libpq in favor of adding
X and Y? Well, the first thing that comes to mind is SSL
support. I'm
not sure if it's still that way, but at least it used to be
a pretty
ugly kludge there with the connection being dropped and
re-connected
in some cases.
SSL support is a bad example, since it would have to be
The x = NULL hack keeps biting people. Innocent people
should not be
exposed to incorrect behaviour because of (supposed) MS Access
breakage. I strongly urge that we do one of the following:
1) Provide a tunable knob to turn this on (cf. KSQO)
2) Confine this to the ODBC driver
I get this since Tom's commit.
--- ./results/horology.out Sun May 23 11:39:49 2004
***
*** 1787,1796
! | Sat Sep 22 18:19:20 2001 PDT | @ 34 years
| Fri Sep 22 18:19:20 1967 PDT
[...]
--- 1787,1796
! | Sat Sep 22 18:19:20 2001 PDT | @ 34
I've spoken to Merlin off-list and confirmed this issue will be fixed in
the locale fix I'll post shortly. The reason being that the backend
thought it was in a non-C locale (the window system default locale which
is specifically *not* C), and in non-C locale LIKE is not indexable.
//Magnus
Today is May 28. So if nobody will not commit above within 3
days, non
of them will be in 7.5(8.0). Am I correct?
Not necessarily ... there are several Win32 related features
that still
haven't been committed (that I've seen) that will push back
the release,
and hopefully give some time
I'm using CVS HEAD in a windows environment. I'm trying to start the
postmaster using postmaster -c
dynamic_library_path=C:/foo/bar. It starts
just fine, then, when I ask it to load a module, an error is
generating
stating:
ERROR: component in parameter dynamic_library_path is not
an
If I were trying to solve Andreas' problem, I'd pipe stderr
to some program that stores recent log output in a file that
I know the location of and can read from the hypothetical
log-grabber function. Actually I don't see that there's any
need to involve Postgres itself in this
And BTW, I was not running the regression in a cygwin shell.
It was a msys shell
only. I am thinking of knowcking off cygwin in favour of
msys. But I
don't find CVS with msys.. I need to find a commandline cvs
for daily
use. WinCVS is just too much GUI for my taste..
If you
What is the recommended way to create mutex objects
(CreateMutex) from
Win32 libraries? There must be a clean way like there is
in pthreads.
A mutex is inherently a global object. CreateMutex(NULL,
FALSE, NULL)
will return a handle to an unowned mutex.
That's not the
I would like to add capability to initdb to accept the password for the
superuser account at invocation. Right now, I can use --pwprompt or -W
to have it ask for a password. But for the win32 GUI installed I'd like
to ask for the password in the installer, and pass it to initdb.
Considering how
I would like to add capability to initdb to accept the
password for the
superuser account at invocation. Right now, I can use
--pwprompt or -W
to have it ask for a password. But for the win32 GUI
installed I'd like
to ask for the password in the installer, and pass it to initdb.
Is it really such a good idea to have trust authentication enabled for
localhost (TCP/IP and Unix sockets) by default? Since this pretty much
means that anybody with shell access on the server (which depending on
the situation can be only dba people, or a whole lot of other people as
well) can do
No, but none of the others are better. See previous discussions in
the archives. I don't think the situation has changed any
since the
last time we hashed this out.
If they supply a password to initdb, shouldn't we then require a
password in pg_hba.conf.
This is further to my
IMO, forcing su password at initdb time (allowing blank
password with
a very stern warning) and bumping localhost to auth is the
right way
to go.
This isn't happening for a number of reasons, the most
obvious being that we cannot require initdb to be run
interactively. (That
It has probably be said before, but new users need to be able
to get up and running on their *development* system quickly.
Throwing new users for a loop with the password configuration
issues would be a problem.
This is exactly the argument that was thrown out when people wanted to
be
This isn't happening for a number of reasons, the most
obvious being
that we cannot require initdb to be run interactively.
(That stern
warning will not impress /dev/null.)
This is the very reason --pwfile was added.
No, that does not address the objection in the least. That
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
Magnus Hagander wrote:
not to mention the
more basic problem that the comments will now be wrong.
That, however, it is correct :-( Sloppy.
How about a text along the line of:
CAUTION: Configuring the system for trust authentication
allows any
local user to connect using any
It occurs to me that with a check this thorough, we might be
able to finesse the problem on Windows with the system
returning very nonstandard timezone abbreviations. That is,
we might simply #ifndef WIN32 the matching of zone names in
try_timezone(). However I do not know whether this would
It occurs to me that with a check this thorough, we might
be able to
finesse the problem on Windows with the system returning very
nonstandard timezone abbreviations.
It does *not* pick up my timezone.
Drat. I assume from your domain name that Europe/Stockholm
would actually be
Over-simplistic answers are not what we need here. The
data structure
you quote cannot even tell what DST transition dates Windows thinks
are in effect this year, let alone what it thinks the dates were in
past years.
Yes, there are other calls for that, obviously. I sent to
Btw, can 7.5 run on WinCE
No.
/XP Media Center/
Probably, but AFAIK not tested.
XP SP2
Yes (haven't tested with the very latest versions of the SP, but it
works with the earlier ones)
/etc?
Works fine on the PDC build of Longhorn...
//Magnus
---(end of
This sounds very much like the known bug that has been
reported several times over the past couple of days on pgsql-hackers-win32.
We're working on tracking it down. At the moment, the non-MSI snapshot at http://www.hagander.net/pgsql/win32snap/
has been "downgraded" to the latest
So what you'd basically need is a separate signal to trigger that
sort of exit, which would be easy ... if we had any spare
signal numbers.
What about multiplexing it onto an existing signal? e.g. set a
shared-mem flag saying exit after cancel then send SIGINT?
Possible, but then
We invent something we could call extended signals that are valid
only in pgsql.
This would be handy, but I dislike your proposal of
implementing it using SysV message queues.
1. Yes, the message facility should theoretically be there if
shmem and semaphores are there, but in the
2. It's even more likely that it would be there but have
unpleasantly small implementation limits. AFAICT your
proposal requires a separate message queue per backend, which
is probably going to stress any conventionally-configured
SysV facility.
Not at all. One message queue with the
With the latest commits, plpgsql no longer compiles on win32, because of
a link failure to pg_strcasecmp().
I fixed this locally by adding -lpgport to SHLIB_LINK in the makefile
in pl/plpgsql/src, but I'm not sure if that is the correct long-term
fix?
//Magnus
---(end
With the latest commits, plpgsql no longer compiles on
win32, because of
a link failure to pg_strcasecmp().
That doesn't make any sense. It should resolve it as a function in the
backend. Why isn't that happening?
Dunno...
Build output without my fix is:
dlltool --export-all --output-def
pg_strcasecmp is *not* included in libpostgres.a. It is in
port/libpgport.a, though. (It's also in postgres.exe, but we
don't link
against that..)
What do you mean we don't link against that? There must be hundreds of
functions in the main backend that plpgsql.dll needs to call. How is
it
If pgevent is a DLL, why is it in src/bin?
We cannot have binary files like MSG1.bin in our source tree, no
matter how convenient it is. The distributors are going to
kill us for
that. Please find another way.
The discussion back when it was decided weighted things back and forth.
The
The discussion back when it was decided weighted things back and
forth. The main thing is that we'd include an extra build dependency
for win32, which would be the Microsoft toolkit, several hundred Mb
to download just to build a 32 byte file.
Think about what open source means. It doesn't
Does anyone have any more?
win32 signal safe socket handler
I thought that was solved long ago?
If this is what I think it is (Merlin - please confirm), this relates to
the SSL code only. And the issue is that there are (I think - haven't
100% verified it yet) paths in the SSL code that will
That's ugly, and unfortunately %z is GNU-specific.
Does Windows' strftime have any short zone name %-spec? Seems like a
quick #ifdef WIN32 to use a more compact zone name would be the best
solution.
No. This is what the cruft in pgtz.c (TZABBREV macro and associated
function) was all about.
Since we do have control over the timezone library now, one possible
answer is to extend the src/timezone API so that it's possible to
convert/format against more than a single timezone. We could then
remember the zone setting inherited from the postmaster and always use
that when formatting
Yes, one :-)
Is your account by any chance a member of a large number of groups? If
so, how many?
There is a fixed buffer of 1024 bytes. I have a feeling ythat one has to
be changed to dynamic.
//Magnus
-Original Message-
From: Thomas Hallgren [mailto:[EMAIL PROTECTED]
Sent: den 17
There is a fixed buffer of 1024 bytes. I have a feeling
ythat one has
to be changed to dynamic.
You're quite right. The 'InfoBufferSize' denotes 1122 bytes
after this call.
if(!GetTokenInformation(AccessToken,TokenGroups,InfoBuffer,102
4,InfoBufferSize))
Ah.
Your stop-gap fix
How about an environment variable that points to a .pgpass type file.
You can do that today: point $HOME at some temp directory or other.
AFAIR pg_dump doesn't make any other use of $HOME ...
Or we could even play games with PGPASSWORD - if it names an
existing file
that satisfies the .pgpass
IIRC there was discussion about the location of the files
(Peter I think
it was suggesting creating a new directory - I'll happily leave that
part up to an eventual committer).
Another discussion was about binary files in the tree (not
being source
files - the source is a binary .AI file
There is already one for the beta. I don't see a need to
add one for
final release.
Might be an idea ... if nothing else, something that at
least reminds them
about reporting bugs and where to do so? I'd hate to see 1000 ppl
install, 90% see bugs adn never have them reported :(
Yes, I
Right. So how would you get the email address, without
starting the mail
reader?
have them enter one in a text box?
We could add a checkbox that takes them to a webpage that permits
subscription. But they are certainly going to need to put
their email
address in there in some way...
Just so you know --- core has agreed that it's about time for beta2.
If you've got any must fix issues, please get 'em in over
the weekend.
The kill(0) patch from Dave for win32 is much needed (assuming it fixes
the issue. Unfortunatly Ive been swamped the past couple of weeks and
not able to do
md5.o(.text+0x1ee):md5.c: undefined reference to `bcopy'
I've fixed these by changing to the more-standard memmove() routine.
crypt-des.o(.text+0x520):crypt-des.c: undefined reference to
[EMAIL PROTECTED]'
crypt-des.o(.text+0xbbe):crypt-des.c: undefined reference to
[EMAIL PROTECTED]'
Title: Message
Known issue, and the patch is in cvs already. You need to
change include/port/win32.h, it has a spelling mistake for
stat.
There was talk of re-wrapping beta-2 with this included,
but I guess it wasn't done. That leaves beta-2 unusable on win32 without
manually applying that
Sorry to be such a pest. Since an administrator will get this error:
creating template1 database in u:/msys/1.0/local/pgsql/data/base/1 ...
execution of PostgreSQL by a user with administrative
permissions is not permitted.
The server must be started under an unprivileged user ID to
Hi
Thanks for PostgreSQL Beta 8.0!
I try to use the native Win32 build
(http://pgfoundry.org/projects/pginstaller)
(Beta 1) but i get an error during DB startup.
failed to get token information: 122
Maybe this is related to
http://groups.google.com/groups?hl=enlr=ie=UTF-8selm=cftihc%
The only argument against it, that I'm aware of, is that
system() is ANSI, while execve() is POSIX: i.e.
portability... does windows have execve()? That could be done
the way the current preprocessor conditionals yield rmdir
instead of rm.
Windows does have execve(), though it's named
IN parameter values are set using the set methods inherited from
PreparedStatement. The type of all OUT parameters must be
registered
prior to executing the stored procedure; their values are retrieved
after execution via the get methods provided here.
A CallableStatement can
I hope to get PL/Python builds on win32 in.
I would like to get the SSL stuff in, but I haven't had the time to look
at it lately, so unless someone else steps up to that one (I know at
least Dave is also working on it) I don't think it'll make it.
//Magnus
-Original Message-
From:
OK, I have applied the following patch that uses Cygwin native
symlink() instead of the Win32 junctions. The reason for this is
that Cygwin symlinks work on Win95/98/ME where junction points do
not
Is this really a Win95/98/ME vs NT distinction or a FAT32
vs NTFS
1 - 100 of 4943 matches
Mail list logo
