Am Tuesday 18 May 2004 07:40 schrieb Greg Copeland:
From the FAQ (http://www.drbd.org/316.html):
Q: Can XFS be used with DRBD?
A: XFS uses dynamic block size, thus DRBD 0.7 or later is needed.
Hope we're talking about the same project. ;)
Hmmm, interesting. But I did not find 0.7 on
Marc G. Fournier wrote:
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
Joshua D. Drake wrote:
Uhhh?? Are you ripping out all core pls then? plPerlNG is supposed to
replace plPerl, I was talking with Bruce and he seemed to think that
(as long as the code was good enough) that we could incorporate
plPHP???
One reason against including plPHP in the core would be
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 competing groups, the documentation has
disappeared, the portability is no longer taken care of, and only the
If you run NTFS, it's still possible to use arbitrary links. In the Windows
world, they are called junctions. Microsoft does not provide a junction tool
for some reason (perhaps because it's limited to NTFS). A good tool, free
and with source, can be found here
Peter Eisentraut wrote:
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 competing groups, the documentation has
disappeared, the portability is no longer taken care of, and
Bruce Momjian wrote:
Also, I came upon this gem:
$ echo '\\copy test to stdout' | psql -o /tmp/z test
444
444
444
444
444
Seems 'copy to stdout' also has this split idea of sending \copy output
to a different place from other output.
I guess my big
Marko Karppinen wrote:
I guess the key thing is that pgFoundry shouldn't be a community
distinct from the core. The same community standards need to apply
on both sides of the fence.
[snip]
Thanks Marko, you just wrote exactly what I was concerned about with
features rather than applications
On Mon, 17 May 2004, Alvaro Herrera Munoz wrote:
On Mon, May 17, 2004 at 04:55:50PM +0200, Zeugswetter Andreas SB SD wrote:
Can we try to do the 2PC patch now instead of waiting for subtransactions ?
The last post from Heikki I read said that he discovered some serious
problems with his
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
I'm trying to implement getUDT for the jdbc driver.
It requires the basetype of a type.
If I do create type testint8 as (i int8) and then select typbasetype
from pg_type where typname='testint8' the value is 0?
While I'm asking how can I find all of the user defined types, assuming
that the
Marc G. Fournier wrote:
On Sat, 15 May 2004, Bruce Momjian wrote:
Fabien COELHO wrote:
Dear hackers,
I wish to submit a small patch so that server includes and
all necessary configuration files could be installed *by default*.
The current status is that server includes files are only
Dear Jan,
Depending on the OS you also need funny things like mkldexport shell
scripts and the like.
Possibly, yes... I don't know. I really need a list, then it is pretty
easy to update all makefiles.
I thought we had a consensus of providing a template build environment
for external
Bruce Momjian wrote:
Jan Wieck wrote:
I think if we go for the plan outlined, we will not need a special
configure flag. (People might decide to move the install dir long after
they install it.) By default, everything sits under pgsql as pgsql/bin,
pgsql/lib, etc. I can't see how making it
In tcop/utility.c, the isolation level is set with a call like:
SetPGVariable(transaction_isolation, makeList(item-arg), false)
when a BEGIN SERIALIZABLE etc. call is made.
Why is the isLocal-parameter false? Couldn't it be true as well? It works
as it is, since the XactIsoLevel variable is
On Tue, 18 May 2004, Dave Cramer wrote:
If I do create type testint8 as (i int8) and then select typbasetype
from pg_type where typname='testint8' the value is 0?
You've created a complex type here, not a domain. See typtype and
typrelid for this case.
create domain testint8 as int8;
a release, etc ...
I'd almost say that time would be better spent on coming up with an
effective upgrade method so that upgrading to new releases is easier ...
Please note that I'm not against the backporting, but do understand the
arguments against it in terms of time and manpower ...
I
Peter Eisentraut wrote:
Joshua D. Drake wrote:
Uhhh?? Are you ripping out all core pls then? plPerlNG is supposed to
replace plPerl, I was talking with Bruce and he seemed to think that
(as long as the code was good enough) that we could incorporate
plPHP???
One reason
On Mon, 2004-05-17 at 19:39, Marc G. Fournier wrote:
On Mon, 17 May 2004, Mike Mascari wrote:
Greg Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I can't complete by 1 June. Think worse of me if you choose.
...
So in my perfect world I picture 7.5 freezing June 1 and
On Tue, 18 May 2004, Robert Treat wrote:
Just like Bruce has often asked the community how they feel about him
balancing his time between things like speaking engagements and patch
applications, core developers have a limited amount of time they can
spend on any given development effort. If I
Magnus Hagander wrote:
If you run NTFS, it's still possible to use arbitrary links.
In the Windows
world, they are called junctions. Microsoft does not provide
a junction tool
for some reason (perhaps because it's limited to NTFS). A
good tool, free
and with source, can be found here
Jan Wieck [EMAIL PROTECTED] writes:
You know how much trouble that causes? The existance of LD_LIBRARY_PATH in your
environment disables setuid() for security reasons on some platforms. So one
would have to wrap every PG related program into equally named shell scripts or
aliases to just set
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
On Sun, May 16, 2004 at 02:46:38PM -0400, Jan Wieck wrote:
fact that checkpoints, vacuum runs and pg_dumps bog down their machines
to the state where simple queries take several seconds care that much
for any Win32 port? Do you think it is a good sign for those who have
Yes. I am one such
Hi all,
may be this was already discussed, I'm quite new to postgres
( only 3 years ), I try however.
I seen the debate around the time freeze for 7.5, who say to
wait in order to have more chance to have PITR, Win32, 2PC...
and who say that wait a month more will not change nothing.
I well
Jan Wieck wrote:
Bruce Momjian wrote:
Jan Wieck wrote:
I think if we go for the plan outlined, we will not need a special
configure flag. (People might decide to move the install dir long after
they install it.) By default, everything sits under pgsql as pgsql/bin,
pgsql/lib, etc.
Greg Stark wrote:
Jan Wieck [EMAIL PROTECTED] writes:
You know how much trouble that causes? The existance of LD_LIBRARY_PATH in your
environment disables setuid() for security reasons on some platforms. So one
would have to wrap every PG related program into equally named shell scripts
Marc G. Fournier wrote:
On Tue, 18 May 2004, Robert Treat wrote:
Just like Bruce has often asked the community how they feel about him
balancing his time between things like speaking engagements and patch
applications, core developers have a limited amount of time they can
spend on any
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
[ Sorry for the latency of my response, Chris -- this got buried in my
inbox... ]
Fabien COELHO wrote:
I don't know where these standards are available online... It seems they
are not available:-(
A copy that claims to represent an almost indistinuishable delta on the
actual SQL 2003 database
Gaetano Mendola wrote:
I well understand the reason to wait a 7.5 in order to delivery
BIG changes that are requiring a initdb, but I don't understand
why little enhancement can not be delivered in a 7.4.3 ( may be
with a short period with a 7.4.3beta ) like the vacuum delayed.
I don't think this
[EMAIL PROTECTED] wrote:
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
On Tue, May 18, 2004 at 12:39:08PM -0400, Neil Conway wrote:
A copy that claims to represent an almost indistinuishable delta on the
actual SQL 2003 database standard is available online here:
http://www.wiscorp.com/sql/sql_2003_standard.zip
Those are PDFs AFAIR, not easily greppable ...
[EMAIL PROTECTED] wrote:
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
On Tue, 2004-05-18 at 09:30, Andrew Sullivan wrote:
On Sun, May 16, 2004 at 02:46:38PM -0400, Jan Wieck wrote:
fact that checkpoints, vacuum runs and pg_dumps bog down their machines
to the state where simple queries take several seconds care that much
for any Win32 port? Do you think
[EMAIL PROTECTED] wrote:
Let's just make sure we keep records of the generic sources of where we
find things. I get *really* scared when I see sentences like I assume
we
can just look at the source and write our own version bypassing any
license. That is categorically a false asumption
Alvaro Herrera Munoz wrote:
Those are PDFs AFAIR, not easily greppable
Not greppable, but any half-decent PDF viewer should have a search
feature that should allow much the same thing. Checking the index is
another way to go, although it is somewhat time-consuming.
I don't have access to an
Marc G. Fournier wrote:
On Tue, 18 May 2004, Robert Treat wrote:
Just like Bruce has often asked the community how they feel about him
balancing his time between things like speaking engagements and patch
applications, core developers have a limited amount of time they can
spend
[EMAIL PROTECTED] wrote:
This makes me worried. That's the way we *used* to do things, but the
sleazy IP lawyers are looking for anything with which they can create
the
impression of impropriety. The open source and free projects are ground
zero for this crap.
We *really* need to be
Greg Stark wrote:
Jan Wieck [EMAIL PROTECTED] writes:
You know how much trouble that causes? The existance of LD_LIBRARY_PATH in your
environment disables setuid() for security reasons on some platforms. So one
would have to wrap every PG related program into equally named shell scripts or
aliases
Joshua D. Drake wrote:
Except you miss one key point here ... if Bruce/Tom/Jan have that sort of
time, why aren't they doing it now?
Well I think you might of missed his point. His point was if he could
pick their priorities. I would kind
of agree with Robert except that there are
Bruce Momjian wrote:
Jan Wieck wrote:
Bruce Momjian wrote:
Jan Wieck wrote:
I think if we go for the plan outlined, we will not need a special
configure flag. (People might decide to move the install dir long after
they install it.) By default, everything sits under pgsql as pgsql/bin,
Bruce Momjian [EMAIL PROTECTED] writes:
Greg Stark wrote:
Jan Wieck [EMAIL PROTECTED] writes:
You know how much trouble that causes? The existance of LD_LIBRARY_PATH in your
environment disables setuid() for security reasons on some platforms. So one
would have to wrap every PG
Jan Wieck wrote:
Static linking of our binaries? Hmmm. Makes sense. We would need a
special flag for that. I can add it to the TODO.
Seems my testing was flawed because I didn't clean out my hard-coded
directory properly. I see now:
$ bin/initdb
bin/initdb: can't
Joshua D. Drake wrote:
One reason against including plPHP in the core would be that it
would create a circular build dependency between the packages
postgresql and php. I think we should rather avoid that.
It is no different that the dependency between plPerl and Perl,
plPython and Python
Marko Karppinen wrote:
I guess the key thing is that pgFoundry shouldn't be a community
distinct from the core. The same community standards need to apply
on both sides of the fence.
Yes, and the best way to achieve that would be to not have anything to
pgfoundry and keep everything in the
Jan Wieck wrote:
If I remore the whole -rpath thing, and remove the two -L options and
the -lpq and -lpgport, and add the libpq.a and libpgport.a explicitly
to the linker call, the psql executable on my Linux box grows from
421761 to 677682 bytes in size. It is still shared linked against
This is very much different, because the PHP distribution contains the
PostgreSQL driver, whereas the other languages do not. So you would
have
PHP build depends on PostgreSQL
Ahh I see your point, EXCEPT :) plPHP does not require PostgreSQL
support to be built into PHP.
Sincerely,
Joshua
The basic problem is that Pg seeks far too much when performing an index
scan. I have saved an strace of a backend which is selecting 170,000
rows from a 240,000,000 row table via index scan. The strace shows
134,000 seeks and reads, or almost one seek for every tuple in the
result set.
That is irrelevant. A normal binary package of PHP does build the
PostgreSQL support (which is surely in our interest), so the build
dependency holds.
Then I am afraid I don't understand the actual problem. plPHP does not
create a circular dependency because it doesn't require PHP to have
Joshua D. Drake wrote:
This is very much different, because the PHP distribution contains
the PostgreSQL driver, whereas the other languages do not. So you
would have
PHP build depends on PostgreSQL
Ahh I see your point, EXCEPT :) plPHP does not require PostgreSQL
support to be built
Bruce Momjian wrote:
We already have --disable-rpath. Seems we would just need something
to use the *.a files.
I think it is perfectly sufficient to say that if you want a relocatable
install, don't use rpath. Static linking will lead to all other kinds
of madness.
Also, some platforms
Peter Eisentraut wrote:
Bruce Momjian wrote:
We already have --disable-rpath. Seems we would just need something
to use the *.a files.
I think it is perfectly sufficient to say that if you want a relocatable
install, don't use rpath. Static linking will lead to all other kinds
of
Peter Eisentraut wrote:
Bruce Momjian wrote:
We already have --disable-rpath. Seems we would just need something
to use the *.a files.
I think it is perfectly sufficient to say that if you want a relocatable
install, don't use rpath. Static linking will lead to all other kinds
of
Peter Eisentraut wrote:
Bruce Momjian wrote:
We already have --disable-rpath. Seems we would just need something
to use the *.a files.
I think it is perfectly sufficient to say that if you want a relocatable
install, don't use rpath. Static linking will lead to all other kinds
of madness.
Boy,
Bruce Momjian wrote:
Peter Eisentraut wrote:
Bruce Momjian wrote:
We already have --disable-rpath. Seems we would just need something
to use the *.a files.
I think it is perfectly sufficient to say that if you want a relocatable
install, don't use rpath. Static linking will lead to all other
Neil Conway wrote:
Gaetano Mendola wrote:
I well understand the reason to wait a 7.5 in order to delivery
BIG changes that are requiring a initdb, but I don't understand
why little enhancement can not be delivered in a 7.4.3 ( may be
with a short period with a 7.4.3beta ) like the vacuum delayed.
Joshua D. Drake wrote:
Also PHP does not compile the PostgreSQL support by default.
But most binary packages do, and they are the ones I'm talking about.
And surely you do not advocate that, in order to build PL/PHP, the
packagers instead disable the client side support in PHP?
Peter Eisentraut wrote:
Bruce Momjian wrote:
Peter Eisentraut wrote:
Bruce Momjian wrote:
We already have --disable-rpath. Seems we would just need
something to use the *.a files.
I think it is perfectly sufficient to say that if you want a
relocatable install, don't use
Jan Wieck wrote:
Boy, nobody was suggesting 100% static linking. What kind of madness
are you getting into if you link libpq.a into psql? There is
something between all or nothing, isn't there?
It's not going to be only psql and libpq. The next thing is, someone
wants to have a relocatable
Joshua D. Drake wrote:
Of course not, but I still don't see your point. plPHP doesn't need
PHP+PostgreSQL support. Nor does PHP+PostgreSQL conflict with using
plPHP...
PHP doesn't even need to be installed for plPHP to work... You just
need the source tree for building.
I don't talk about
Fabien COELHO wrote:
Any idea? The best I have would be to create a src subdir in the
installation, so that top_builddir could be set to
.../include/postgresql/config and everything would work from that
point of view.
This is from an extension module author's point of view. My module will
Peter Eisentraut wrote:
Joshua D. Drake wrote:
Of course not, but I still don't see your point. plPHP doesn't need
PHP+PostgreSQL support. Nor does PHP+PostgreSQL conflict with using
plPHP...
PHP doesn't even need to be installed for plPHP to work... You just
need the source tree for building.
Bruce Momjian wrote:
Peter Eisentraut wrote:
Jan Wieck wrote:
Boy, nobody was suggesting 100% static linking. What kind of madness
are you getting into if you link libpq.a into psql? There is
something between all or nothing, isn't there?
It's not going to be only psql and libpq. The next
Heikki Linnakangas [EMAIL PROTECTED] writes:
Why is the isLocal-parameter false? Couldn't it be true as well? It works
as it is, since the XactIsoLevel variable is reset to default value in
StartTransaction anyway, but it looks silly to me to define the variable
as a session variable when in
Dave Cramer [EMAIL PROTECTED] writes:
While I'm asking how can I find all of the user defined types, assuming
that the user is the owner of the cluster. I see that pg_dump can do
this ?
IIRC, what pg_dump actually does is look for types that are not in the
pg_catalog schema. Plus you probably
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I guess what you are saying is we should have a configure-time option to
address configured directories via relative paths from the executable's
directory, rather than absolute paths? Seems reasonable ...
Yep.
Peter Eisentraut wrote:
Tom Lane wrote:
What use could printing the relative path possibly have?
Debugging. If I can't see it, I *know* I'm going to wish I could.
Well, you can just look inside, it's not that big. Supporting extra
options might make the script twice as big and thus
Neil Conway [EMAIL PROTECTED] writes:
Fabien COELHO wrote:
Neil - can you check your SQL2003 copy to see if it mentions standard
aggregates on bit types?
I couldn't see any mention of any aggregates specific to the bit types,
There certainly are none, since in fact SQL2003 removes the BIT
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
What can be done? Well, money from Fujitsu and other companies
(Afilias/Sloney, Command Prompt/ecpg-plPHP), is allowing us to hit
some of these bigger items, so hopefully that will move us forward
in these complex areas. I am not sure what
Seriously though, we all have the roles that we play. I don't think
redirecting specific resources to other
resources will help beyond slowing up the original resources.
And now Neil's on holidays :)
Perhaps we need more committers. The deluge of patches is starting to
strain the major
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
Fabien COELHO wrote:
Neil - can you check your SQL2003 copy to see if it mentions standard
aggregates on bit types?
I couldn't see any mention of any aggregates specific to the bit types,
There certainly are none, since in fact
Greg Copeland writes:
My primary fear about delivering Win32 with all of these other great
features is that, IMO, there is a higher level of risk associated with
these advanced features. At the same time, this will be the
first trial for many Win32 users. Should there be some problems, in
On Tuesday 18 May 2004 17:33, Joshua D. Drake wrote:
But most binary packages do, and they are the ones I'm talking about.
And surely you do not advocate that, in order to build PL/PHP, the
packagers instead disable the client side support in PHP?
Of course not, but I still don't see your
I'm following up on my own email and cross posting to hackers, because
there is a bug that needs fixed. I spent some more time digging into
this, and I found the cause of the problem.
reltuples in pg_class is defined as a real, reltuples in pg_autovacuum
is defined as an int. the query
So you then have to build PHP twice, in an RPM build environment. You mean I
can't just have the headers installed to build plPHP? So, follow the
No you need to make sure that PHP is available as a shared lib.
1.) Build PostgreSQL
2.) Build PHP (with PostgreSQL client support)
3.) Build plPHP
I think we already fixed that in 7.4.2. We also have a few bugs still
in 7.4.2 and we need to get those fixed soon and release 7.4.3.
---
Brian Hirt wrote:
I'm following up on my own email and cross posting to hackers,
there might be another similar bug that was fixed in 7.4.2
i just doubled checked the 7.4.2 tarball, and it does have this problem.
you might want to double check to see if it's fixed in 7.4.3, or i can
grab cvs and check it if you like.
On May 18, 2004, at 8:06 PM, Bruce Momjian wrote:
I think
On Tuesday 18 May 2004 21:58, Joshua D. Drake wrote:
So you then have to build PHP twice, in an RPM build environment. You
mean I can't just have the headers installed to build plPHP? So, follow
the
No you need to make sure that PHP is available as a shared lib.
Which requires you to
I run psql and I get this:
-bash-2.05b$ psql template1
Welcome to psql 7.5devel, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q
I get a similar failure running pg_dumpall and initdb as well.
Chris
Christopher Kings-Lynne wrote:
I run psql and I get this:
-bash-2.05b$ psql template1
Welcome to psql 7.5devel, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
On Tue, 18 May 2004, Heikki Linnakangas wrote:
I'd like to get the patch committed as soon as the 7.6 release cycle
begins, with whatever limitations it has at that time.
The nice thing of this is that then you have a development cycle for
others to help ... your patch lays down the this is
On Tue, 18 May 2004, Joshua D. Drake wrote:
Actually plPHP doesn't require the PostgreSQL source tree... you would
just have to modify the Make file to point to the right places.
So, why tie it into the PostgreSQL source tree? Won't it be popular
enough to live on its own, that it has to be
Nikola Milutinovic [EMAIL PROTECTED] writes:
[ about NaN on Tru64 ]
This compiles on Tru64 4.0D (the compiler swallows it), but fails on
Tru64 UNIX 5.1B. Both basic CC and DTK Compaq CC break on that file
complaining on that constant evaluation. The best way to solve it is to
use system
James William Pye [EMAIL PROTECTED] writes:
I know I can use RegisterExprContextCallback and the RSI's econtext to
register a callback for SRFs, but this--or similar
functionality--does not appear to be available for non-SRFs.
Hm? That functionality works for any function, whether it returns
On Mon, 17 May 2004, Alvaro Herrera Munoz wrote:
I have some confidence in that I will be able to deliver it maybe the last
week of May. I can only hope, however, that it will not be rejected because
it's presented too close to feature freeze.
There is no such thing as too close to feature
On Tue, 18 May 2004, Joshua D. Drake wrote:
Actually plPHP doesn't require the PostgreSQL source tree... you would
just have to modify the Make file to point to the right places.
So, why tie it into the PostgreSQL source tree? Won't it be popular
enough to live on its own, that it has
Marc G. Fournier wrote:
On Mon, 17 May 2004, Alvaro Herrera Munoz wrote:
I have some confidence in that I will be able to deliver it maybe the last
week of May. I can only hope, however, that it will not be rejected because
it's presented too close to feature freeze.
There is no such
Christopher Kings-Lynne wrote:
I run psql and I get this:
-bash-2.05b$ psql template1
Welcome to psql 7.5devel, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or
On Tue, 2004-05-18 at 22:21, Brian Hirt wrote:
there might be another similar bug that was fixed in 7.4.2
This bug is fixed, but it didn't make in 7.4.2, it is in CVS (both 7.4
and HEAD). Please grab pg_autovacuum.c and .h from CVS, if that doesn't
fix it please let me know.
Thanks,
Matthew
So, why tie it into the PostgreSQL source tree? Won't it be popular
enough to live on its own, that it has to be distributed as part of the
core?
Honestly, I don't know if it would be popular enough on its own. Now the
plPerlNG that Andrew
and us are working, yes but plPHP? It is nifty, it
Tatsuo Ishii wrote:
At least in Japan PHP is much more popular than Python. If we have
plpython in core, I see no reason we do not have plPHP in core at
least from the "popularity" point of view.
Well I don't know anywhere that PHP isn't more popular than Python. The
question I think
92 matches
Mail list logo
