On Wed, July 18, 2007 11:07, [EMAIL PROTECTED] wrote:
Eecently, I have downloaded the postgresql-8.1.9.tar.gz from the official
website,and then I install in my linux System ,whose gcc version is
2.9.6.Although I can install it successfully,then result version I check
is 7.2.1~£¬and how can
[EMAIL PROTECTED] wrote:
Eecently, I have downloaded the postgresql-8.1.9.tar.gz from the
official website,and then I install in my linux System ,whose gcc
version is 2.9.6.Although I can install it successfully,then result
version I check is 7.2.1~£¬and how can this happen,can u tell me the
Magnus Hagander wrote:
Dave Page wrote:
Magnus Hagander wrote:
So what we'd need in that case is a new libpq connectionstring
parameter. Which can be done, but it'd require that all frontends that
use libpq add support for it - such as pgadmin. I'm not sure if the ODBC
driver will support
On Wed, 2007-07-18 at 01:01 +0100, Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Where are we on this?
Well Simon just sent the reworked patch yesterday so the answer is we haven't
started tuning this parameter. (Bruce's message is referring to the discussion
about what
Sorry for dealy.
On Tue, May 29, 2007 20:51, Tatsuo Ishii wrote:
Thinking more, it striked me that users can define arbitarily growing
rate by using CFREATE CONVERSION. So it seems we need functionality to
define the growing rate anyway.
Would it make sense to define just the longest
The conclusion of the discussion appears that we could reduce
MAX_CONVERSION_GROWTH from 4 to 3 safely with all existing built-in
conversions.
However, since user defined conversions could set arbitrary growth
rate, probably it would be better leave it as it is now.
For 8.4, maybe we could
On Wed, Jul 18, 2007 at 09:44:02AM +0100, Dave Page wrote:
Magnus Hagander wrote:
Dave Page wrote:
Magnus Hagander wrote:
So what we'd need in that case is a new libpq connectionstring
parameter. Which can be done, but it'd require that all frontends that
use libpq add support for it -
Now that we have working GSSAPI authentication, I'd like to see the
following done:
* Deprecate krb5 authentication in 8.3. At least in documentation, possibly
with a warning when loading pg_hba.conf?
* Remove krb5 authenticatino completely in 8.4.
The reasons for this is:
* krb5 auth doesn't do
On Tue, Jul 17, 2007 at 11:00:35AM -0700, Paul Silveira wrote:
This is great. I've worked on 2 projects in the last year that desperately
needed this. It will certainly make the security model more seamless...
Thanks for letting us know.
Are you interested in just the SSPI parts, or also
Here's what I think we should do to the HOT patch:
1. Get rid of row-level fragmentation and handling dealing with
LP_DELETEd line pointers. Instead, take a vacuum lock opportunistically,
and defrag pages using the normal PageRepairFragmentation function. I'm
not sure where exactly we would do
Magnus Hagander wrote:
Now that we have working GSSAPI authentication, I'd like to see the
following done:
* Deprecate krb5 authentication in 8.3. At least in documentation, possibly
with a warning when loading pg_hba.conf?
* Remove krb5 authenticatino completely in 8.4.
libpq would still
On Wed, Jul 18, 2007 at 11:45:19AM +0100, Heikki Linnakangas wrote:
Magnus Hagander wrote:
Now that we have working GSSAPI authentication, I'd like to see the
following done:
* Deprecate krb5 authentication in 8.3. At least in documentation, possibly
with a warning when loading
Magnus Hagander wrote:
libpq would still work against older server versions, right?
Not once krb5 is removed. Assuming the older server version used krb5 auth.
OK, well thats a problem. pgAdmin supports back to 7.3...
/D
---(end of
On Wed, Jul 18, 2007 at 11:57:19AM +0100, Dave Page wrote:
Magnus Hagander wrote:
libpq would still work against older server versions, right?
Not once krb5 is removed. Assuming the older server version used krb5 auth.
OK, well thats a problem. pgAdmin supports back to 7.3...
You have a
Magnus Hagander wrote:
On Wed, Jul 18, 2007 at 11:57:19AM +0100, Dave Page wrote:
Magnus Hagander wrote:
libpq would still work against older server versions, right?
Not once krb5 is removed. Assuming the older server version used krb5 auth.
OK, well thats a problem. pgAdmin supports back to
Magnus Hagander wrote:
On Wed, Jul 18, 2007 at 11:57:19AM +0100, Dave Page wrote:
Magnus Hagander wrote:
libpq would still work against older server versions, right?
Not once krb5 is removed. Assuming the older server version used krb5 auth.
OK, well thats a problem. pgAdmin supports back to
On Wed, Jul 18, 2007 at 12:16:49PM +0100, Heikki Linnakangas wrote:
Magnus Hagander wrote:
On Wed, Jul 18, 2007 at 11:57:19AM +0100, Dave Page wrote:
Magnus Hagander wrote:
libpq would still work against older server versions, right?
Not once krb5 is removed. Assuming the older server
Magnus Hagander wrote:
But sure, we might leave it in there until there's a direct problem with it
(other than the ones we already know). Can I still get my deprecation of it
though? ;-)
I'm not sure what the deprecation would mean in the client-side. You're
going to need it if you want to
On Wed, Jul 18, 2007 at 12:26:28PM +0100, Heikki Linnakangas wrote:
Magnus Hagander wrote:
But sure, we might leave it in there until there's a direct problem with it
(other than the ones we already know). Can I still get my deprecation of it
though? ;-)
I'm not sure what the deprecation
Dave Page wrote:
Magnus Hagander wrote:
libpq would still work against older server versions, right?
Not once krb5 is removed. Assuming the older server version used krb5
auth.
OK, well thats a problem. pgAdmin supports back to 7.3...
I think you need to put forward an alternative
Andrew Dunstan wrote:
Dave Page wrote:
Magnus Hagander wrote:
libpq would still work against older server versions, right?
Not once krb5 is removed. Assuming the older server version used krb5
auth.
OK, well thats a problem. pgAdmin supports back to 7.3...
I think you need to put
Just an observation, but when we cluster (or any other time we rebuild a heap)
we are creating a useless record type and array type for the temporary heap we
use which is subsequently dropped.
postgres=# cluster;
DEBUG: drop auto-cascades to type pg_temp_16474
DEBUG: drop auto-cascades to
On Tue, 17 Jul 2007, Bruce Momjian wrote:
Oleg Bartunov wrote:
On Tue, 17 Jul 2007, Bruce Momjian wrote:
I think the tsearch documentation is nearing completion:
http://momjian.us/expire/fulltext/HTML/textsearch.html
but I am not happy with how tsearch is enabled in a user table:
Am Mittwoch, 18. Juli 2007 13:21 schrieb Magnus Hagander:
The main reasons would be to have less code to maintain,
I don't think the krb5 support has needed all that much maintenance in the
last few years.
and to make life
easier for packagers. For example, win32 would no longer need to
Dave Page wrote:
Magnus Hagander wrote:
libpq would still work against older server versions, right?
Not once krb5 is removed. Assuming the older server version used krb5
auth.
OK, well thats a problem. pgAdmin supports back to 7.3...
How many people actually use kerberos... How many
Dave Page wrote:
Andrew Dunstan wrote:
Dave Page wrote:
Magnus Hagander wrote:
libpq would still work against older server versions, right?
Not once krb5 is removed. Assuming the older server version used
krb5 auth.
OK, well thats a problem. pgAdmin supports back to 7.3...
I think
Joshua D. Drake wrote:
pgAdmin was just one example. This prevents anyone with kerberos5 in a
similar situation upgrading their client libraries - including users
of the myriad of apps that use psqlODBC.
Who likely don't use kerberos.
Probably not in the majority of cases - but we have a
Magnus Hagander [EMAIL PROTECTED] writes:
But sure, we might leave it in there until there's a direct problem with it
(other than the ones we already know). Can I still get my deprecation of it
though? ;-)
In the krb4 case, we left it in there until there was very little
probability anyone was
[EMAIL PROTECTED] (Peter Eisentraut) writes:
Am Mittwoch, 18. Juli 2007 13:21 schrieb Magnus Hagander:
The main reasons would be to have less code to maintain,
I don't think the krb5 support has needed all that much maintenance in the
last few years.
and to make life
easier for
On Wed, Jul 18, 2007 at 10:46:58AM -0400, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
But sure, we might leave it in there until there's a direct problem with it
(other than the ones we already know). Can I still get my deprecation of it
though? ;-)
In the krb4 case, we
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Tatsuo Ishii wrote:
The conclusion of the discussion appears that we could reduce
MAX_CONVERSION_GROWTH from 4 to
On Wed, 2007-07-18 at 11:41 +0100, Heikki Linnakangas wrote:
I've done some experimenting on those items, producing several badly
broken versions of the patch partly implementing those ideas. It looks
like the patch size will go down from ~240 kB to ~210 kB, and more
importantly, there will
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Jul 18, 2007 at 10:46:58AM -0400, Tom Lane wrote:
This needs to be fixed.
Non, GSSAPI and krb5 are *not* mutually exclusive.
SSPI and GSSAPI are mutually exclusive.
Color me confused then. What's the difference?
Joshua D. Drake wrote:
Dave Page wrote:
Andrew Dunstan wrote:
Dave Page wrote:
Magnus Hagander wrote:
libpq would still work against older server versions, right?
Not once krb5 is removed. Assuming the older server version used
krb5 auth.
OK, well thats a problem. pgAdmin supports
Tom Lane [EMAIL PROTECTED] writes:
The real problem in my mind is this business of the gssapi and krb5
support being mutually exclusive.
Oh, I didn't catch that. That's wrong anyways, there could be multiple
applications on the same machine, some of which use krb4 and some which use
gssapi.
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Jul 18, 2007 at 10:46:58AM -0400, Tom Lane wrote:
This needs to be fixed.
Non, GSSAPI and krb5 are *not* mutually exclusive.
SSPI and GSSAPI are mutually exclusive.
Color me confused then. What's the difference?
SSPI
* Tom Lane ([EMAIL PROTECTED]) wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Jul 18, 2007 at 10:46:58AM -0400, Tom Lane wrote:
This needs to be fixed.
Non, GSSAPI and krb5 are *not* mutually exclusive.
SSPI and GSSAPI are mutually exclusive.
Color me confused then.
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
But we're talking two different issues. Deprecating/removing krb5 is a
different thing from having GSSAPI and SSPI mutually exclusive or not.
To the extent that keeping krb5 around implies a much lower burden on
GSSAPI support under Windows, I
* Dave Page ([EMAIL PROTECTED]) wrote:
Probably not in the majority of cases - but we have a large userbase these
days, and a small percentage may still equate to a large number. I know at
least two people that do use psqlODBC + Kerberos.
I certainly use it alot! Of course, we'll move to
* Joshua D. Drake ([EMAIL PROTECTED]) wrote:
OK, well thats a problem. pgAdmin supports back to 7.3...
How many people actually use kerberos... How many people who are using
kerberos are going to be running 7.3. 7.3 is no longer supported so by
postgresql.org so who cares.
AOL, MIT, CMU,
Stephen Frost wrote:
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
But we're talking two different issues. Deprecating/removing krb5 is a
different thing from having GSSAPI and SSPI mutually exclusive or not.
To the extent that keeping krb5 around implies a much lower burden on
GSSAPI
Stephen Frost wrote:
* Tom Lane ([EMAIL PROTECTED]) wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Jul 18, 2007 at 10:46:58AM -0400, Tom Lane wrote:
This needs to be fixed.
Non, GSSAPI and krb5 are *not* mutually exclusive.
SSPI and GSSAPI are mutually exclusive.
Color me confused
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
The maintenance part of me suggesting getting rid of krb5 is the
smallest one. It being a non-standard protocol is more important, and
the fact that the exchange breaks the libpq protocol and is not
protected by SSL is the big reason.
Erm, it
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
Certainly not just minor adjustments, since we need to do dynamic
loading and checking for the functions. That's the big one, which will
If we're supporting krb5 anyway, and shipping the bits that go along
with that, do we need to do dynamic loading
Just the SSPI piece.
Right now we run a mixture of PostgreSQL and SQL Server and the one
fustrating thing is that we have to have separate security architectures for
them. The SQL Server environment is nice because it allows SSPI and
eliminates the need to pass around passwords everywhere.
Stephen Frost wrote:
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
The maintenance part of me suggesting getting rid of krb5 is the
smallest one. It being a non-standard protocol is more important, and
the fact that the exchange breaks the libpq protocol and is not
protected by SSL is the big
Stephen Frost wrote:
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
Certainly not just minor adjustments, since we need to do dynamic
loading and checking for the functions. That's the big one, which will
If we're supporting krb5 anyway, and shipping the bits that go along
with that, do we
Stephen Frost wrote:
* Joshua D. Drake ([EMAIL PROTECTED]) wrote:
OK, well thats a problem. pgAdmin supports back to 7.3...
How many people actually use kerberos... How many people who are using
kerberos are going to be running 7.3. 7.3 is no longer supported so by
postgresql.org so who
On 7/18/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Here's what I think we should do to the HOT patch:
I am all for simplifying the code. That would not only help us make it less
buggy but also improve its maintainability. But we would also need
to repeat the tests and run new tests to
Oleg Bartunov wrote:
I agree, that there are could be more examples, but text search doesn't
require something special !
*Example* of trigger function is documented on
http://momjian.us/expire/fulltext/HTML/textsearch-opfunc.html
Yes, I see that in tsearch() here:
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
No, no requirement. But you would certainly expect it to use it if you
have SSL on the connection.
Uhh, perhaps, but my recollection is that it's generally *not* done that
way in other things.. Honestly, it doesn't matter to me, just wanted to
clear
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
Stephen Frost wrote:
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
Certainly not just minor adjustments, since we need to do dynamic
loading and checking for the functions. That's the big one, which will
If we're supporting krb5 anyway, and
* Joshua D. Drake ([EMAIL PROTECTED]) wrote:
Stephen Frost wrote:
* Joshua D. Drake ([EMAIL PROTECTED]) wrote:
How many people actually use kerberos... How many people who are using
kerberos are going to be running 7.3. 7.3 is no longer supported so by
postgresql.org so who cares.
AOL,
Stephen Frost wrote:
* Joshua D. Drake ([EMAIL PROTECTED]) wrote:
Oh, yea, and every place that uses Active Directory ..
Note that we are talking about Kerberos + PostgreSQL, not Kerberose in
general.
I was referring to your first question, which, in my view, is the more
appropriate one
Stephen Frost wrote:
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
Stephen Frost wrote:
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
Certainly not just minor adjustments, since we need to do dynamic
loading and checking for the functions. That's the big one, which will
If we're supporting
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
Well, since you're the only one who've asked for the feature, I guess
that's good enough for me unless someone else complains. If you have a
good suggestion for a name for it, let me know, otherwise I'll just cook
something up.
Mozilla uses
Stephen Frost wrote:
Honestly, for now I'm happy w/ it being a connectionstring option. It
seems the most appropriate place for it to go. That does mean that
applications may need to be modified to support gssapi (where they might
not have to be for sspi since it's the default), but since
On Wed, 18 Jul 2007, Bruce Momjian wrote:
Why are we allowing my_filter_name here? Isn't that something for a
custom trigger. Is calling it tsearch() a good idea? Why not
tsvector_trigger().
I don't see any benefit from the tsvector_trigger() name. If you want to add
some semantic, than
Heikki Linnakangas wrote:
Stephen Frost wrote:
Honestly, for now I'm happy w/ it being a connectionstring option. It
seems the most appropriate place for it to go. That does mean that
applications may need to be modified to support gssapi (where they might
not have to be for sspi since it's
Magnus Hagander wrote:
Heikki Linnakangas wrote:
Stephen Frost wrote:
Honestly, for now I'm happy w/ it being a connectionstring option. It
seems the most appropriate place for it to go. That does mean that
applications may need to be modified to support gssapi (where they might
not have
On 7/3/07, Tom Lane [EMAIL PROTECTED] wrote:
wombat long-standing configuration error (no Tk installed)
My apologies for not responding earlier. I see 7.3 contrib problems
for wombat but I don't see a config error for Tk with HEAD or any of
the other 8.x releases. I have the
* Heikki Linnakangas ([EMAIL PROTECTED]) wrote:
Uh, this is really confusing. Let's see if I got this right. So we're
talking about two orthogonal changes here:
It is kinda confusing. :)
1. Wire protocol. In 8.2 and below, we used the krb5 protocol. 8.3
server and libpq will use the GSSAPI
Heikki Linnakangas [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
The wire protocol is the same for them. It's a matter of which *client
library* should be used to produce the packets that go over the network.
...
On Windows, why would you need GSSAPI, if SSPI comes with the operation
Magnus Hagander [EMAIL PROTECTED] writes:
The issue is *not* about GSSAPI vs krb5. It's with GSSAPI vs SSPI.
The wire protocol is the same for them. It's a matter of which *client
library* should be used to produce the packets that go over the network.
Oh, they're fully interchangeable at the
Mark Wong [EMAIL PROTECTED] writes:
On 7/3/07, Tom Lane [EMAIL PROTECTED] wrote:
wombat long-standing configuration error (no Tk installed)
My apologies for not responding earlier. I see 7.3 contrib problems
for wombat but I don't see a config error for Tk with HEAD or any of
the
* Gregory Stark ([EMAIL PROTECTED]) wrote:
Am I right in thinking that while the client-postgres protocol may be the
same the actual authentication tokens are different? That is, if you have a
Windows Active Directory server then using SSPI will use your Windows
credentials obtained from that
* Tom Lane ([EMAIL PROTECTED]) wrote:
Oh, they're fully interchangeable at the wire level? Is this true both
with respect to the PG client/backend protocol and the protocol to the
authentication server?
I believe that's the case, yes.
If there's no interoperability issues then I
agree that
Mark Wong wrote:
On 7/3/07, Tom Lane [EMAIL PROTECTED] wrote:
wombat long-standing configuration error (no Tk installed)
My apologies for not responding earlier. I see 7.3 contrib problems
for wombat but I don't see a config error for Tk with HEAD or any of
the other 8.x releases.
Andrew Dunstan [EMAIL PROTECTED] writes:
I don't think we're ever going to fix things for the 7.3 error you're
getting - please take it out of your rotation. 7.3 isn't quite as dead
as Joshua suggested earlier, but it's certainly on life support.
I checked the CVS logs and it appears that we
BTW, while I'm thinking of it --- it'd be real nice if the buildfarm
configuration printout included the flex and bison version numbers.
Maybe gcc too (I know not every buildfarm member is compiling with gcc,
but it comes in enough different versions that this is likely to be
useful info).
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
BTW, while I'm thinking of it --- it'd be real nice if the buildfarm
configuration printout included the flex and bison version numbers.
Interestingly, none of our tools actually outputs the bison/flex
versions - perhaps configure
Tom Lane wrote:
BTW, while I'm thinking of it --- it'd be real nice if the buildfarm
configuration printout included the flex and bison version numbers.
Maybe gcc too (I know not every buildfarm member is compiling with gcc,
but it comes in enough different versions that this is likely to be
Oleg Bartunov wrote:
On Wed, 18 Jul 2007, Bruce Momjian wrote:
Why are we allowing my_filter_name here? Isn't that something for a
custom trigger. Is calling it tsearch() a good idea? Why not
tsvector_trigger().
I don't see any benefit from the tsvector_trigger() name. If you
Oleg, Teodor,
I am confused by the following example. How does gin know to create a
tsvector, or does it? Does gist know too?
FYI, at some point we need to chat via instant messenger or IRC to
discuss the open items. My chat information is here:
http://momjian.us/main/contact.html
On Wed, 18 Jul 2007, Bruce Momjian wrote:
Oleg, Teodor,
I am confused by the following example. How does gin know to create a
tsvector, or does it? Does gist know too?
No, gist doesn't know. I don't remember why, Teodor ?
For GIN see
75 matches
Mail list logo
