The series of patches are the proposal of Security-Enhanced PostgreSQL
(SE-PostgreSQL) for the upstreamed PostgreSQL 8.4 development cycle.
[1/4] sepostgresql-pgace-8.4devel-3.patch
provides PGACE (PostgreSQL Access Control Extension) framework
[2/4] sepostgresql-sepgsql-8.4devel-3.patc
It seems to me some of SE-PostgreSQL patches are not delivered yet,
although [3/4] and [4/4] were already done.
Does anti-spam system caught my previous three messages?
If necessary, I will send them again.
Thanks,
Kohei KaiGai wrote:
> The series of patches are the proposal of Security-Enhanced
Cristian Gafton <[EMAIL PROTECTED]> writes:
> On Sun, 16 Mar 2008, Tom Lane wrote:
>> While thinking about your report I was considering having VACUUM and
>> ANALYZE always set relpages to at least 1. Then seeing relpages=0
>> would indeed indicate a never-analyzed table, whereas relpages=1
>> whe
[3/4] - sepostgresql-pg_dump-8.4devel-3.patch
This patch gives us a feature to dump database with security attribute.
It is turned on with '--enable-selinux' option at pg_dump/pg_dumpall,
when the server works as SE- version.
No need to say, users need to have enough capabilities to dump whole of
[4/4] - sepostgresql-policy-8.4devel-3.patch
This patch gives us the default security policy for SE-PostgreSQL.
You can build it as a security policy module. It can be linked with
the existing distributor's policy, and reloaded.
--
OSS Platform Development Division, NEC
KaiGai Kohei <[EMAIL PROT
There are several places in tuplesort.c (and perhaps elsewhere) where
we explicitly work around limitations of various platforms' qsort()
functions. Notably, there's this bit in comparetup_index_btree
/*
* If key values are equal, we sort on ItemPointer. This does not affect
* vali
On Sun, 16 Mar 2008, Bruce Momjian wrote:
Oh, what I would really like is to be able to pull up
archives.postgresql.org emails based on message id so I can link to the
entire thread. Unfortunately, it doesn't work there, nor does Google or
any of the other Postgres email archive sites.
This
On Sun, 16 Mar 2008, Tom Lane wrote:
> > Ah, that is indeed a possibility. If I am to understand correctly, there is
> > no way to represent the difference between an un-analyzed table and a
> > zero-sized analyzed table as far as the query planner is concerned?
>
> While thinking about your re
Gregory Stark <[EMAIL PROTECTED]> writes:
> We currently execute a lot of joins as Nested Loops which would be more
> efficient if we could batch together all the outer keys and execute a single
> inner bitmap index scan for all of them together.
Please give an example of what you're talking about
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I can go along with this as a jury-rig setup for our first commit fest,
> >> but it just seems like another powerful argument for moving to something
> >> wiki-based as soon as we can get that sorted.
>
> > We cou
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I can go along with this as a jury-rig setup for our first commit fest,
>> but it just seems like another powerful argument for moving to something
>> wiki-based as soon as we can get that sorted.
> We could move to a wiki if someone f
Gregory Stark wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> > You want the message-id on the listing page? Sure, I was doing that
> > before but I didn't know anyone wanted it and it looked a little
> > cluttered. Let me know.
>
> I agree it was too cluttered for normal use.
>
> Wha
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Gregory Stark wrote:
> >> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
> >>> The comments are stored at JS-Kit:
> >>> http://js-kit.com/comments/
> >>
> >> It's stored in their server?
>
> > Yes, that was the beauty of it --- I just
Gregory Stark wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> > You want the message-id on the listing page? Sure, I was doing that
> > before but I didn't know anyone wanted it and it looked a little
> > cluttered. Let me know.
>
> I agree it was too cluttered for normal use.
>
> Wha
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Gregory Stark wrote:
> >> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
> >>> The comments are stored at JS-Kit:
> >>> http://js-kit.com/comments/
> >>
> >> It's stored in their server?
>
> > Yes, that was the beauty of it --- I just
Tom Lane wrote:
> The idea that's becoming attractive to me while contemplating the
> multiple-maps problem is that we should adopt something similar to
> the old Mac OS idea of multiple "forks" in a relation. In addition
> to the main data fork which contains the same info as now, there could
>
Cristian Gafton <[EMAIL PROTECTED]> writes:
> On Sun, 16 Mar 2008, Tom Lane wrote:
>> Is it possible that the temp table ever has exactly zero rows?
> Ah, that is indeed a possibility. If I am to understand correctly, there is
> no way to represent the difference between an un-analyzed table and
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> I've started working on revamping Free Space Map, using the approach
> where we store a map of heap pages on every nth heap page. What we need
> now is discussion on the details of how exactly it should work.
You're cavalierly waving away a whol
On Sun, 16 Mar 2008, Tom Lane wrote:
> > I have a weird query execution plan problem I am trying to debug on
> > Postgresql 8.2.6. I have a query that joins against a temporary table that
> > has very few rows.
>
> Is it possible that the temp table ever has exactly zero rows?
Ah, that is inde
I've started working on revamping Free Space Map, using the approach
where we store a map of heap pages on every nth heap page. What we need
now is discussion on the details of how exactly it should work.
Here's my rough plan on the implementation. It's long, sorry. I'm fairly
confident with i
I've been reviewing the hash index build patch submitted here:
http://archives.postgresql.org/pgsql-patches/2007-10/msg00154.php
Although it definitely helps on large indexes, it's actually
counterproductive on not-so-large ones. The test case I'm using
is random integers generated like this:
Cristian Gafton <[EMAIL PROTECTED]> writes:
> I have a weird query execution plan problem I am trying to debug on
> Postgresql 8.2.6. I have a query that joins against a temporary table that
> has very few rows.
Is it possible that the temp table ever has exactly zero rows?
> My questions are:
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> It's strange, so correlated subqueries is faster, but it has much higher cost:
In the nestloop plan, the estimated cost for the indexscan is discounted
based on the knowledge that it'll be executed repeatedly:
>-> Index Scan using fxx
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>>> The comments are stored at JS-Kit:
>>> http://js-kit.com/comments/
>>
>> It's stored in their server?
> Yes, that was the beauty of it --- I just add javascript with a tag and
> al
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> You want the message-id on the listing page? Sure, I was doing that
> before but I didn't know anyone wanted it and it looked a little
> cluttered. Let me know.
I agree it was too cluttered for normal use.
What I'm trying to do is get a page which
Gregory Stark wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> >> I'm curious where the comments are being stored, since it's not in the html
> >> source. The javascript must be pulling them from another url?
> >
> > The comments are stored at JS-Kit:
> >
> > http://js-kit.com/comment
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
>> I'm curious where the comments are being stored, since it's not in the html
>> source. The javascript must be pulling them from another url?
>
> The comments are stored at JS-Kit:
>
> http://js-kit.com/comments/
It's stored in their server?
>
Hello
I tested speed SELF JOIN and correlated subquery for couting of subtotals:
It's strange, so correlated subqueries is faster, but it has much higher cost:
postgres=# explain analyze select t1.id, t1.sale_date, t1.product,
t1.sale_price, sum(t2.sale_price) from
history t1 inner join history
28 matches
Mail list logo