* Henry B. Hotz ([EMAIL PROTECTED]) wrote:
I've been looking at adding SASL or GSSAPI as an auth
method. I have
some questions about how to handle the flow of control changes.
Great! I'd love to see that implemented, personally, so if you're
looking for help, please let me know.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Nov 01, 2006 at 07:16:37PM -0300, Alvaro Herrera wrote:
[EMAIL PROTECTED] wrote:
[...]
a functional trigram index? (this would be very cool).
Heh :-) I meant an index, using the pg_trgm opclass (which indexes
trigrams; hence the
On Wed, 2006-11-01 at 11:31 -0500, Chuck McDevitt wrote:
But, stepping back from all that, what is it the users want?
1) When re-creating a CREATE TABLE statement from whatever catalog
info, they'd like the names to come back exactly as then entered them.
If I do:
CREATE
On Wed, 2006-11-01 at 12:05 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Enclose a patch for new WAL records for relcache invalidation.
I don't think this works. RelationCacheInitFileInvalidate is executed
post-commit, which means that there's a window between commit and
Hi.
I have some encoding problems.
1.) Expression of output of log of server
http://inet.winpg.jp/~saito/pg_bug/postgresql-2006-11-02_192633.log
This is not in the output for the translation by GetText and is ..Native..
message.
(Japanese windows--Shift_jis message)
2.) The message makes a
Tom, Simon et al; Please clarify.
PostgreSQL 8.1.5 on sparc-sun-solaris2.9, compiled by GCC gcc (GCC) 3.4.2
We're getting ready to init a new warm standby instance based on last
night's snapshot of running prod server. I see a few of these
pg_internal.init files in the cluster as it's being
On Thu, 2006-11-02 at 09:36 -0500, Jerry Sievers wrote:
Is it safe to delete the .init files now (before starting recovery),
or perhaps unconditionally right after going live?
You're safe to delete those files from the restored version of your base
backup prior to commencing startup with a
Simon Riggs [EMAIL PROTECTED] writes:
On Wed, 2006-11-01 at 12:05 -0500, Tom Lane wrote:
I don't think this works.
Surely you are pointing out a bug, no?
If a backend did crash, the init file would be wrong and we'd get
exactly the same wrong relfilenode errors we got after that PITR.
Jerry Sievers [EMAIL PROTECTED] writes:
Is it safe to delete the .init files now (before starting recovery),
Should be OK as far as I can see.
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your
Simon Riggs [EMAIL PROTECTED] writes:
We have namespaces to differentiate between two sources of object names,
so anybody who creates a schema where MyColumn is not the same thing as
myColumn is not following sensible rules for conceptual distance.
I'd agree that that is not a good design
I am running versions 8.1.2 and I installed 8.2B last week. I dumped
the data from a rather large (several million records) from the old into the
new version.
My two observations are as follows... Also, keep in mind these are truly
just observations, I didn't use any benchmarking tools. If
On Nov 2, 2006, at 1:18 AM, Magnus Hagander wrote:
* Henry B. Hotz ([EMAIL PROTECTED]) wrote:
I've been looking at adding SASL or GSSAPI as an auth
method. I have
some questions about how to handle the flow of control changes.
Great! I'd love to see that implemented, personally, so if
On Mon, 2006-10-23 at 13:36 -0500, [EMAIL PROTECTED] wrote:
2. I have a tsearch2 index which is 756MB in size in 8.1.2 but balloons to
910MB in 8.2! These numbers were taken right after a REINDEX. Normally, I
wouldn't care about physical index size, but this particular index is
sitting on
I've noticed a trend in the PostgreSQL code base - for some reason, we tend to avoid initializing automatic variables (actually, the code base is pretty mixed on this point).
For example in _bt_check_unique() we have:
static TransactionId
_bt_check_unique(Relation rel, IndexTuple itup,
Sorry about the premature send.
On Nov 2, 2006, at 1:18 AM, Magnus Hagander wrote:
* Henry B. Hotz ([EMAIL PROTECTED]) wrote:
I've been looking at adding SASL or GSSAPI as an auth
method. I have
some questions about how to handle the flow of control changes.
Great! I'd love to see that
Shouldn't we turn on warnings by the compiler on uninitialized
variables? This can also be helpful.
--Imad
www.EnterpriseDB.com
On 11/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I've noticed a trend in the PostgreSQL code base - for some reason, we tend
to avoid initializing automatic
[EMAIL PROTECTED] writes:
I would probably write that as:
static TransactionId
_bt_check_unique(Relation rel, IndexTuple itup, Relation heapRel,
Buffer buf, ScanKey itup_scankey)
{
TupleDesc
On Thu, 2006-11-02 at 23:53 +0500, imad wrote:
Shouldn't we turn on warnings by the compiler on uninitialized
variables? This can also be helpful.
Those warnings should already be enabled, at least with GCC.
-Neil
---(end of broadcast)---
TIP
On Thu, Nov 02, 2006 at 10:45:24AM -0800, Henry B. Hotz wrote:
Well, unless you have an unusually good PKI infrastructure, SSL
doesn't provide any cryptographic connection between the client
identity and the data received by the server. (At least that's true
for the way it's used by Web
Gregory Stark wrote:
[EMAIL PROTECTED] writes:
I would probably write that as:
static TransactionId
_bt_check_unique(Relation rel, IndexTuple itup, Relation heapRel,
Buffer buf, ScanKey itup_scankey)
On 11/2/06, Gregory Stark [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] writes:
I would probably write that as:
static TransactionId
_bt_check_unique(Relation rel, IndexTuple itup, Relation heapRel,
Gregory Stark [EMAIL PROTECTED] writes:
People expect initializers to be simple expressions, macro calls, accessor
functions, and so on. Not to call out to complex functions that implement key
bits of the function behaviour.
Yeah, I agree with that. But as Andrew noted, we don't really have
The disadvantage of using initializers is that you end up contorting the code
to allow you to squeeze things into the initializers and it limits what you
can do later to the code without undoing them.
For example, if later you find out you have to, say, lock a table before the
itupdesc
Shouldn't we turn on warnings by the compiler on uninitialized
variables? This can also be helpful.
Those warnings should already be enabled, at least with GCC.
Yes, the compiler can detect unitialized variables,
But, that introduces a new problem. There are a lot of tools out there
imad [EMAIL PROTECTED] writes:
Well, its about the coding style. And I doubt there exists a data type
which may not have
an initializer. A NULL / Zero is an option in all cases and you can do
whatever you want to assign it a value immediately after the
initialization section. My two cents!
Yeah, I agree with that. But as Andrew noted, we don't really have any
hard and fast coding rules --- the only guideline is to do your best to
make your code readable, because other people *will* have to read it.
I'm not really looking for hard/fast rules. Just picking brains.
In
On Nov 2, 2006, at 11:04 AM, Martijn van Oosterhout wrote:
On Thu, Nov 02, 2006 at 10:45:24AM -0800, Henry B. Hotz wrote:
In my case I have good control over the Kerberos infrastructure, but
none over the Federal PKI infrastructure. I also want the data
channel encryption tied to the client
[EMAIL PROTECTED] writes:
initializers also force you to declare variables in the scope where they
are needed. Instead of declaring every variable at the start of the
function, it's better to declare them as nested as practical (not as
nested as possible, but as nested as practical).
I agree
On 11/3/06, Tom Lane [EMAIL PROTECTED] wrote:
imad [EMAIL PROTECTED] writes:
Well, its about the coding style. And I doubt there exists a data type
which may not have
an initializer. A NULL / Zero is an option in all cases and you can do
whatever you want to assign it a value immediately
On Thu, 2006-11-02 at 14:23 -0500, [EMAIL PROTECTED] wrote:
Yes, the compiler can detect unitialized variables,
In most situations, anyway.
I've seen too many less-scarred developers add an = NULL to quiet
down the tool. But that's (arguably) worse than leaving the variable
uninitialized
* Martijn van Oosterhout (kleptog@svana.org) wrote:
In postgresql the client and server can specify what certificates
thay'll accept, there are no default trusted CAs. You can require the
client to have a certain certificate, for example. The client can also
verify the server has the expected
In postgresql the client and server can specify what certificates
thay'll accept, there are no default trusted CAs. You can
require the
client to have a certain certificate, for example. The
client can also
verify the server has the expected certificate. How much
it's used I
[EMAIL PROTECTED] writes:
initializers also force you to declare variables in the scope where they
are needed. Instead of declaring every variable at the start of the
function, it's better to declare them as nested as practical (not as
nested as possible, but as nested as practical).
I
Well, clearly you should only assign meaningful values to variables, but
I don't see anything wrong with omitting an initializer, initializing
the variable before using it, and letting the compiler warn you if you
forget to do this correctly.
The problem that that introduces is that you
On Thu, 2 Nov 2006, Magnus Hagander wrote:
I expect we'll need a mapping of some sort, or perhaps a
sasl_regexp or similar to what is done in OpenLDAP. I don't
recall PG supporting using the DN from a client cert in an
SSL connection as a PG username but perhaps I missed it somewhere...
* Richard Troy ([EMAIL PROTECTED]) wrote:
Would signed certificates be preferred? Well, sure, they're nice. I don't
object, and in fact welcome some improvements here. For example, I'd love
the choice of taking an individual user's certificate and authenticating
completely based upon that.
Username/password is not acceptable in a number of situations. This is
not intended to replace them. This would be in *addition* to supporting
the current auth methods. I don't understand at all how you feel it'd
be nice to have yet shouldn't be done.
Thanks,
* Richard Troy ([EMAIL PROTECTED]) wrote:
...I thought you said this _needs_ to be done - by using words like
unacceptible and required - and I disagree. There's a difference
between what needs to be done and what is desired to be done. Further, I
never said shouldn't.
For PG to be an option
On Nov 2, 2006, at 12:26 PM, Richard Troy wrote:
Well, there's simply no need. While I can agree that more could be
done,
I'm not convinced there's a need because what we have now works
fine. Let
me support my view by stating first that I perceive that combining the
conception of
Would signed certificates be preferred? Well, sure, they're
nice. I don't object, and in fact welcome some improvements
here. For example, I'd love the choice of taking an
individual user's certificate and authenticating completely
based upon that. However, while this _seems_ to simplify
I wrote:
* pg_clog is truncated according to the oldest pg_database.datvacuumxid.
While testing this patch I realized that there's a bit of an issue here.
It's usually going to be the case that the oldest datvacuumxid is
template0's, meaning that it will never be possible to truncate clog
until
On Thu, Nov 02, 2006 at 01:10:14PM -0800, Henry B. Hotz wrote:
standard protocols and libraries that support real security: SASL
and GSSAPI in particular. You may for various reasons decide that
[. . .]
Part of establishing a secure connection is establishing that the end
points are
On Thu, Nov 02, 2006 at 08:58:37PM +0100, Magnus Hagander wrote:
I don't think you can tie the SSL certificate to a specific
user though... I certainly can't recall any way to do that
today in PG.
You can't. It's been talked about, but never done.
Oops, sorry. You can verify the user
Yesterday I wrote:
* On successful completion, the cutoff XID is stored in
pg_class.relvacuumxid, and pg_database.datvacuumxid is updated
if appropriate. (The minxid columns are now useless, but unless there
is another reason to force initdb before 8.2, I'm inclined to leave them
there and
On Thu, Nov 02, 2006 at 10:48:29PM +0100, Magnus Hagander wrote:
The same could apply to SSL cert based authentication, for users
connecting from machines outside of my realm. Once you have unlocked
the certificate, you can authenticate any number of times to any number
of services that will
On Thu, Nov 02, 2006 at 05:22:39PM -0500, Tom Lane wrote:
I prefer to avoid forcing initdb in late beta, because it causes extra
work for our long-suffering beta testers, but at the moment I'm thinking
this is worth fixing now rather than later. Comments?
Given that the column name change
On Thu, 2006-11-02 at 16:50 -0500, Tom Lane wrote:
I wrote:
* pg_clog is truncated according to the oldest pg_database.datvacuumxid.
Shortening the freeze horizon will reduce the size
that pg_clog occupies just *after* that happens, but we're still going
to see pg_clog bloating up to
All,
For what it's worth, I heartily support this effort. For most cases,
it probably isn't necessary, but I can think of several applications
for SASL/GSSAPI where something weaker will simply not do; in the
absence of the proposed functionality, I simply wouldn't be able to
use Postgres
Josh Berkus josh@agliodbs.com writes:
... Why would we reject a piece of useful functionality based on a
published standard?
Well, size and maintainability of the proposed patch are certainly
factors in any such decision. As a closely related example, I bet
we'd have rejected the original
Tom Lane wrote:
Josh Berkus josh@agliodbs.com writes:
... Why would we reject a piece of useful functionality based on a
published standard?
Well, size and maintainability of the proposed patch are certainly
factors in any such decision. As a closely related example, I bet
we'd have
On Thursday 02 November 2006 17:48, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
pagila=# select to_date('3232098', 'MM/DD/');
to_date
---
4568-06-26 BC
(1 row)
to_date's absymal lack of error checking is well known. It should
surely refuse that input
* Tom Lane ([EMAIL PROTECTED]) wrote:
Josh Berkus josh@agliodbs.com writes:
... Why would we reject a piece of useful functionality based on a
published standard?
Well, size and maintainability of the proposed patch are certainly
factors in any such decision. As a closely related
On Thu, Nov 02, 2006 at 07:49:01PM -0800, Joshua D. Drake wrote:
To be honest, I have often wondered *why* we support kerberos outside of
the uber l33t geek factor. I have not once in a commercial deployment
had a business requirement for the beast. LDAP? Now that is a whole
other issue :)
but again to_date doesn't:
regression=# select to_date('4714-01-27 BC', '-MM-DD BC');
to_date
---
4714-01-27 BC
(1 row)
I'm not concerned about to_date so much as I am that timestamp_in lets you
store values you can't read with timestamp_out. Once the value is
There have been several reports that people could not vacuum any more or
observed strange locks even after server restart. The reason was that they
still had uncommitted prepared transactions around.
I wonder if it could help to change the log level from
ereport(LOG,
postgres=# select '4714-01-27 BC'::date;
ERROR: date out of range: 4714-01-27 BC
postgres=# select cast(test as date) from timetest;
test
---
4714-01-27 BC
(1 row)
postgres=#
postgres=# select cast('4714-01-27 BC' as date);
ERROR: date out of range: 4714-01-27 BC
Joachim Wieland [EMAIL PROTECTED] writes:
There have been several reports that people could not vacuum any more or
observed strange locks even after server restart. The reason was that they
still had uncommitted prepared transactions around.
I wonder if it could help to change the log level
The same could apply to SSL cert based authentication, for users
connecting from machines outside of my realm. Once you have
unlocked
the certificate, you can authenticate any number of times to any
number of services that will accept this certificate
*without* having
to re-enter
... Why would we reject a piece of useful functionality based on a
published standard?
Well, size and maintainability of the proposed patch are certainly
factors in any such decision. As a closely related example, I bet
we'd have rejected the original Kerberos-support patch if
To be honest, I have often wondered *why* we support
kerberos outside
of the uber l33t geek factor. I have not once in a commercial
deployment had a business requirement for the beast. LDAP?
Now that is
a whole other issue :)
Isn't NFSv4 a big application that uses Kerberos? I
On Fri, Nov 03, 2006 at 08:05:05AM +0100, Magnus Hagander wrote:
The same could apply to SSL cert based authentication, for users
connecting from machines outside of my realm. Once you have
unlocked
the certificate, you can authenticate any number of times to any
number of
Robert Treat [EMAIL PROTECTED] writes:
I'm not concerned about to_date so much as I am that timestamp_in lets you
store values you can't read with timestamp_out.
Your example does not demonstrate any such thing. What it demonstrates
is that to_date will let an out-of-range date into the
62 matches
Mail list logo
