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
> > > nu
> > 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 Ker
> >> ... 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
> > 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
> >
"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
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 sy
>
> 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: "
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,
(errmsg("rec
>> 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. O
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 :)
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Josh Berkus 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
>
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 ref
Tom Lane wrote:
> Josh Berkus 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
Josh Berkus 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 Kerberos-support pa
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 Postgr
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 s
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 e
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 w
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 a
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 th
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 a
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
> 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 simpl
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 encrypting
* 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 a
> 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:
> 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.
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 som
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
<[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
> > 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 us
* 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 expect
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
> uninitia
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 immediat
<[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
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 i
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 t
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 cen
> 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 the
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 init
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 ha
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 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 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
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
<[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)
> {
> Tup
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
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 i
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, Rel
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 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 yo
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 s
"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 desig
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 fri
"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 PI
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 re
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 unp
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 m
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:
> CREA
-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
> > * 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
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 comm
62 matches
Mail list logo
