Dear Bruce:
Included is the abstract for my replication system I promised to you.
PGCluster is a replication system for PostgreSQL.
Features of PGCluster include:
- synchronized multi-master replication
- load balancing
- re-synchronizing database cluster which is in
lost-synchronization
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()
On Unix, the general rule for a shared library is to prepend lib and
append .so. On Windows, nothing is prepended and you add .dll. Thus for
a module named pljava you'd get:
libpljava.so on Unix and:
pljava.dll on Windows.
This is in fact so common that the Java Native Interface (JNI) uses it as
Magnus Hagander wrote:
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
Hello,
I think it's safe to say there is a working implementation of a signal
handler. The one tricky part left is to identify some smart places for
the backend to check the awaiting signal queue. The first one is easy:
switch recv() with select() with a reasonable timeout and a poll.
If and
Simon,
have you read src/backend/storage/buffer/README of current CVS tip?
The algorithm in the new replacement strategy is an attempt to figure
that SMALL_TABLE_THRESHOLD automatically. Do you see anything that can
be improved in that algorithm?
Jan
Simon Riggs wrote:
This discussion seems
On Wed, 21 Jan 2004, Tom Lane wrote:
The GEQO planner module contains six different recombination algorithms,
only one of which is actually used --- the others are ifdef'd out, and
have been ever since we got the code. Does anyone see a reason not to
prune the deadwood?
considering the
Simon Riggs [EMAIL PROTECTED] writes:
Any comments?? Takers?
Um, did you read the discussion of the ARC buffer management algorithm
that's already been implemented for 7.5?
The main objection I have to doing it Oracle's way is that that creates
more parameters that DBAs have to get right for
Jan Wieck [EMAIL PROTECTED] writes:
While talking about it, I think our usage of signals is way overloaded
anyway. Any ideas how to replace it all with just one signal and a
regular message queue?
Fooling with the definitions of SIGTERM, SIGINT, SIGQUIT would be a
really bad idea, since we
scott.marlowe [EMAIL PROTECTED] writes:
On Wed, 21 Jan 2004, Tom Lane wrote:
The GEQO planner module contains six different recombination algorithms,
considering the recent discussion about REALLY slow query planning by the
GEQO module, it might be worth testing each one to see which works
On Thu, 22 Jan 2004, Tom Lane wrote:
scott.marlowe [EMAIL PROTECTED] writes:
On Wed, 21 Jan 2004, Tom Lane wrote:
The GEQO planner module contains six different recombination algorithms,
considering the recent discussion about REALLY slow query planning by the
GEQO module, it might be
Dear friends,
In the past, there were several discussions in order to find suitable answers
for MS Windows users willing to install and run PostgreSQL.
Some of you suggested that users should install GNU/Linux over Windows. Not
so easy for the basic MySQL or Ms Windows user, who need technical
Jean-Michel POURE said:
Morphix could be a possible solution to the MS Windows migration
problems. It probably involves 50 times less work than migrating
PostgreSQL to MS Windows (and is a complete different project except
for the fact that it could well bring as much new users to
Tom Lane [EMAIL PROTECTED] writes:
I'm assuming that the original author of the GEQO code already did
that testing ...
Removing the code without bothering to verify this assumption is a
little unwise, IMHO: given the low quality of the rest of the GEQO
code, I wouldn't be surprised to learn
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 work
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. But for now
I suggest that the default prefix on Windows is
C:\Program Files\PostgreSQL
cheers
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, my point was that doing so will require
Hi all,
Might I just suggest good old C:\PostgreSQL ?
MS SQL server defaults to C:\MSSQL, so I don't think that a directory in the
root path is unreasonable. Further, it makes it look more important if it
installs in the root directory :)
All the best,
-David Felstead
Claudio Natoli wrote:
I needed these, so I went and implemented them myself. I have to admit
I'm not so wise on PostgreSQL backend stuff, and so I abstained from
editing the fmgrtab.c and postgres.bki.
Sorry for that, but it just seemed too complicated. Perhaps there
should really be a script to do this? I could
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
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 canonicalization)
Might I just suggest good old C:\PostgreSQL ?
MS SQL server defaults to C:\MSSQL, so I don't think that a directory in
the
root path is unreasonable. Further, it makes it look more important if it
installs in the root directory :)
Don't do that. I hate software that does that. To me it
On Jan 21, 2004, at 12:19 PM, Peter Eisentraut wrote:
I think output XML is just buzz. Give us a real use scenario and an
indication that a majority also has that use scenario (vs. the other
ones listed above), then we can talk.
I do this all the time.
I have JDBC code to take a
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 for the official port,
Why? The procedure you mentioned seems perfectly
I have spent the past 10 days doing work for SRA, my employer, and
attending LinuxWorld in New York City. Our BOF was well attended, with
35 people, and there were a lot of good PostgreSQL usage reports at the
event. I have told people to post their news items to the web site or
advocacy.
I
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 for the official port,
Why? The procedure you
Robert Treat wrote:
On Monday 05 January 2004 12:51, Peter Eisentraut wrote:
Jean-Eric Cuendet wrote:
- User permissions based on columns? (Ex: User1 has Select on Column
CompayName but User2 has update on column CompanyName while User3
has create new row on table).
Well, I have
Well, I have about half a patch for column privileges lying around, but
I've never had enough motivation to do the other, more complicated
half...
Is there a TODO and TODO.detail warrented here?
I thought views took care of this. Comments?
They're needed for SQL99 anyway I think.
Chris
Bruce Momjian [EMAIL PROTECTED] writes:
On Monday 05 January 2004 12:51, Peter Eisentraut wrote:
Jean-Eric Cuendet wrote:
- User permissions based on columns?
Well, I have about half a patch for column privileges lying around, but
I've never had enough motivation to do the other, more
Andrew Dunstan wrote:
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
If anyone knows how to get the M$
Tom Lane wrote:
Claudio Natoli [EMAIL PROTECTED] writes:
Tom Lane writes:
I'm not sure there's any need for
src/backend/port/win32/sema.c at all.
(Do you have any idea on the historical
context of this code? I wondered as to, if we have no win32 port, why there
would be a seemingly
Tom Lane wrote:
Claudio Natoli [EMAIL PROTECTED] writes:
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?
Move along. Nothing to see here.
Actually, I was expecting you to complain that the s_lock.h coding is
Claudio Natoli wrote:
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
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
On Monday 05 January 2004 12:51, Peter Eisentraut wrote:
Jean-Eric Cuendet wrote:
- User permissions based on columns?
Well, I have about half a patch for column privileges lying around, but
I've never had enough motivation to
Neil Conway [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
I'm assuming that the original author of the GEQO code already did
that testing ...
Removing the code without bothering to verify this assumption is a
little unwise, IMHO:
Fair enough. I did a little bit of poking
Bruce Momjian [EMAIL PROTECTED] writes:
Andrew Dunstan wrote:
AFAIK the only target build environment for Windows right now is MinGW/gcc
If anyone knows how to get the M$ compilers to work nicely with our build
system that might be interesting, but probably at a later stage.
MS C compiler
Tom Lane [EMAIL PROTECTED] writes:
Where are we going to find a representative test set of
dozen-or-more- way SQL join queries?
Interesting that you should mention that. I've been thinking for a
while that we need a much more extensive test suite for the query
optimizer. This would allow us to
Neil Conway [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
The latter is a really bad idea IMHO. The io_in_progress lock can be
held for eons (in CPU terms) and should not be blocking people who
simply want to bump their refcount up and down.
My reasoning was that the
38 matches
Mail list logo
