-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Apr 24, 2009 at 03:48:16PM -0400, Bill Moran wrote:
> In response to to...@tuxteam.de:
>
[...]
> > > It is generally much safer to keep keys and the
> > > decryption process on a separate server.
> >
> > Or just clie
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Apr 24, 2009 at 03:45:16PM -0400, Bill Moran wrote:
> In response to to...@tuxteam.de:
[...]
> Someone hijacking your live server does not automatically give anyone
> the key, unless you implement this wrong (which is, of course, possible).
>
On Fri, Apr 24, 2009 at 10:49 PM, Tom Lane wrote:
> Robert Haas writes:
>> As far as I can tell, the focus on trying to estimate the number of
>> tuples per bucket is entirely misguided. Supposing the relation is
>> mostly unique so that the values don't cluster too much, the right
>> answer is
Robert Haas writes:
> As far as I can tell, the focus on trying to estimate the number of
> tuples per bucket is entirely misguided. Supposing the relation is
> mostly unique so that the values don't cluster too much, the right
> answer is (of course) NTUP_PER_BUCKET.
But the entire point of tha
On Fri, Apr 24, 2009 at 8:09 PM, Tom Lane wrote:
> So it appears to me that instead of taking an average-case correction
> as is done in this patch and the old coding, we have to explicitly model
> the matched-tuple and unmatched-tuple cases separately. For hashjoins,
> what I think we should do
Robert Haas writes:
> Upon further review, it appears that a big part of this problem is
> that cost_hashjoin() doesn't understand that it needs cost semi-joins
> differently from inner or left joins.
> ...
> The planner costs the semi-join as two orders of magnitude more
> expensive than the hash
reloptions.c: In function âextractRelOptionsâ:
reloptions.c:731: warning: value computed is not used
heapam.c: In function âheapgettupâ:
heapam.c:458: warning: value computed is not used
heapam.c:458: warning: value computed is not used
heapam.c: In function âheapgettup_pagemodeâ:
heapa
In response to to...@tuxteam.de:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Thu, Apr 23, 2009 at 01:31:39PM -0700, Marc Munro wrote:
>
> [...]
>
> > In principle it could be used in the way that Bill Moran suggests though
> > I have never used it that way. I am somewhat suspiciou
In response to to...@tuxteam.de:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Thu, Apr 23, 2009 at 10:38:55AM -0400, Bill Moran wrote:
> [...]
>
> > It's possible that this could be accomplished by something like Veil,
> > or the built-in implementation that's coming in some future v
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Apr 23, 2009 at 01:31:39PM -0700, Marc Munro wrote:
[...]
> In principle it could be used in the way that Bill Moran suggests though
> I have never used it that way. I am somewhat suspicious of passing
> encryption keys to the database serve
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Apr 23, 2009 at 10:38:55AM -0400, Bill Moran wrote:
[...]
> It's possible that this could be accomplished by something like Veil,
> or the built-in implementation that's coming in some future version of
> PG (is it scheduled for 8.5 at this po
Peter Eisentraut writes:
> GCC 4.4 produces a bunch of new compiler warnings against 8.4; see attached
> output. Some of these are related to our old friend fastgetattr(), but it's
> a
> bit too late for me to make sense of it now.
> As we have grown accustomed to warnings-free builds, it wou
Tom Lane wrote:
>> I don't know what it should be doing if it can't find a match, so I
>> haven't changed that behavior.
>
> As things stand, it should throw error, except in the case of SQL_ASCII;
> there is no excuse for any other database encoding to not be in the
> table. However, what seems
Hi,
Upon applying synchronous replication patch and subsequent compilation
of psqlODBC sources will lead to compilation errors.
As a workaround users can compile the psqlODBC sources using the
mainstream postgres source tree and then apply the sync rep patch.
But this restriction will need to be
Dne 24.04.09 07:17, Heikki Linnakangas napsal(a):
This diff in tsearch2.out surprised me:
@@ -2390,7 +2390,7 @@
Sea view wow foo bar qq
http://www.google.com/foo.bar.html"; target="_blank">YES
- ff-bg
+ ff-bg
document.write(15);
Any idea what's causing that?
Hmm. I
15 matches
Mail list logo
