Re: [PATCHES] [HACKERS] Proposal: new large object API

[Tom Lane]

Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> Here is the proposed patches. If there's no objection, I will
> commit(or Shall I wait for next "commit festa"?).

No need to wait IMHO.

regards, tom lane

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] Hash Index Build Patch v2

[Tom Raney]

Tom,

Thanks for your comments and for your work incorporating our patch into 
8.4.  This will help us provide even a better patch next time around :)


-Shreya Bhargava and Tom Raney


Tom Raney <[EMAIL PROTECTED]> writes:
  
This revised version of our patch uses the function estimate_rel_size() 
from plancat.c to estimate the number of tuples in the parent relation.  
This method is an alternative to scanning the parent relation to 
estimate the number of tuples, as we did in the first version of the patch.



Applied after significant editorialization.  You need to pay more
attention to conforming to the style of the surrounding code and to
updating comments that your work renders inaccurate.

regards, tom lane

  



--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] [HACKERS] Proposal: new large object API

[Tatsuo Ishii]

Here is the proposed patches. If there's no objection, I will
commit(or Shall I wait for next "commit festa"?).

Note that I decide to use lo_import_with_oid, but the signature is
changed(the second and the third arguments are swapped because it
seems more natural).
--
Tatsuo Ishii
SRA OSS, Inc. Japan

> I would like to propose new large object client side API for 8.4.
> 
> Currently we have:
> 
> Oid lo_import(PGconn *conn, const char *filename);
> 
> But we do not have an API which imports a large object specifying the
> object id. This is inconvenient and inconsistent since we already have
> lo_create() and lo_open() which allow to specify the large object id.
> 
> So I propose to add new API:
> 
> int lo_import_with_oid(PGconn *conn, Oid lobjId, const char 
> *filename);
> 
> Another idea is changing the signature of lo_import:
> 
> Oid lo_import(PGconn *conn, Oid lobjId, const char *filename);
> 
> which will be cleaner but break the backward compatibility.
> 
> Comments are welcome.
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> 
> -- 
> Sent via pgsql-hackers mailing list ([EMAIL PROTECTED])
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
? src/interfaces/libpq/exports.list
? src/interfaces/libpq/libpq.so.5.2
Index: doc/src/sgml/lobj.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/lobj.sgml,v
retrieving revision 1.46
diff -c -r1.46 lobj.sgml
*** doc/src/sgml/lobj.sgml  14 Mar 2007 00:15:26 -  1.46
--- doc/src/sgml/lobj.sgml  18 Mar 2008 01:02:10 -
***
*** 161,166 
--- 161,188 
   the server; so it must exist in the client file system and be readable
   by the client application.
  
+ 
+ 
+  The function
+ 
+ Oid lo_import_with_oid(PGconn *conn, const char *filename, Oid lobjId);
+ 
+  lo_import_with_oid
+  also imports a new large object.  The OID to be assigned can be
+  specified by lobjId;
+  if so, failure occurs if that OID is already in use for some large
+  object.  If lobjId
+  is InvalidOid (zero) then 
lo_import_with_oid assigns an unused
+  OID (this is the same behavior as lo_import).
+  The return value is the OID that was assigned to the new large object,
+  or InvalidOid (zero) on failure.
+ 
+ 
+ 
+  lo_import_with_oid is new as of 
PostgreSQL
+  8.4 and uses lo_create internally which is new in 
8.1; if this function is run against 8.0 or before, it will
+  fail and return InvalidOid.
+ 
 
  
 
Index: src/interfaces/libpq/exports.txt
===
RCS file: /cvsroot/pgsql/src/interfaces/libpq/exports.txt,v
retrieving revision 1.18
diff -c -r1.18 exports.txt
*** src/interfaces/libpq/exports.txt9 Dec 2007 19:01:40 -   1.18
--- src/interfaces/libpq/exports.txt18 Mar 2008 01:02:10 -
***
*** 140,142 
--- 140,143 
  PQconnectionUsedPassword  138
  pg_valid_server_encoding_id 139
  PQconnectionNeedsPassword 140
+ lo_import_with_oid  141
Index: src/interfaces/libpq/fe-lobj.c
===
RCS file: /cvsroot/pgsql/src/interfaces/libpq/fe-lobj.c,v
retrieving revision 1.64
diff -c -r1.64 fe-lobj.c
*** src/interfaces/libpq/fe-lobj.c  1 Jan 2008 19:46:00 -   1.64
--- src/interfaces/libpq/fe-lobj.c  18 Mar 2008 01:02:11 -
***
*** 41,46 
--- 41,48 
  
  static intlo_initialize(PGconn *conn);
  
+ static Oid
+ lo_import_internal(PGconn *conn, const char *filename, const Oid oid);
  
  /*
   * lo_open
***
*** 484,489 
--- 486,512 
  Oid
  lo_import(PGconn *conn, const char *filename)
  {
+   return lo_import_internal(conn, filename, InvalidOid);
+ }
+ 
+ /*
+  * lo_import_with_oid -
+  *  imports a file as an (inversion) large object.
+  *  large object id can be specified.
+  *
+  * returns the oid of that object upon success,
+  * returns InvalidOid upon failure
+  */
+ 
+ Oid
+ lo_import_with_oid(PGconn *conn, const char *filename, Oid lobjId)
+ {
+   return lo_import_internal(conn, filename, lobjId);
+ }
+ 
+ static Oid
+ lo_import_internal(PGconn *conn, const char *filename, Oid oid)
+ {
int fd;
int nbytes,
tmp;
***
*** 507,516 
/*
 * create an inversion object
 */
!   lobjOid = lo_creat(conn, INV_READ | INV_WRITE);
if (lobjOid == InvalidOid)
{
!   /* we assume lo_creat() already set a suitable error message */
(void) close(fd);
return InvalidOid;
}
--- 530,543 
/*
 * create an inversion object
 */
!   if (oid == InvalidOid)
!   lobjOid = lo_creat(conn, INV_READ | INV_W

Re: [PATCHES] UPDATE using sub selects

[Tom Lane]

I wrote:
> ... eg backend/nodes/, optimizer/util/clauses.c, ruleutils.c...)

Actually, on further thought ruleutils.c represents one of the biggest
stumbling blocks here.  We have to be able to reverse-compile the parse
tree into something that's at least semantically equivalent to the
original query.  The existing kluge for UPDATE SET (columns) = ... can
ignore this because it rearranges the query into a sematically
equivalent update with independent SET targets, but the whole problem
with sub-select updates is that there *is* no semantically equivalent
command with a flat targetlist.  So one way or another there will have
to be more information in the parse tree than there is now.

If we use Params that can be traced back to specific SubLink list
entries, it might be okay to finesse this by having ruleutils.c check
for successive targetlist entries that reference outputs of the same
SubLink.  That's pretty ugly but it might be better than changing the
representation of targetlists, which is something that's understood
by one heck of a lot of code.

regards, tom lane

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] UPDATE using sub selects

[Tom Lane]

NikhilS <[EMAIL PROTECTED]> writes:
> As per discussion on -hackers, a patch which allows updates to use
> subselects is attached with this mail.

I looked over this patch briefly, and I'm afraid it still needs a lot of
work.

The way you altered transformUpdateStmt is a mess; it's duplicating
logic and also using inapplicable tests.  (In particular, invoking
checkInsertTargets on a subset of the complete target list is just not
sensible --- it's supposed to be catching conflicts.  I think you really
don't need it at all anyway, because the needed tests are done
downstream in the rewriter.)  I think the right way is to expand out the
row-assignment portions of the SET target list and then process the
whole SET list the same as before.

The real problem though is that the patch creates a new storage method
and processing path for ROWEXPR_SUBLINK sublinks that's got nothing to
do with the other kinds of sublinks.  This is going to be a mess and a
fertile source of bugs.  (You already have quite a few stemming from
having overlooked all the places that have to be touched to add a field
to Query, eg backend/nodes/, optimizer/util/clauses.c, ruleutils.c...)

The basic idea is not bad, but I think if we're going to make a list of
subqueries to attach to Query, we should try to do all the forms of
SubLink that way, not just one.  From a logical point of view all the
single-result-row forms of SubLink are about the same, and we should
strive to unify them not make them even more different.  Also there are
a lot of kluges that could be got rid of if subqueries were pulled out
of expression trees leaving only Param references behind.  We'd need
something a bit more general than Param, perhaps, depending on how we
wanted to distinguish output values from different subqueries.  Right
now we don't have to worry about that at parse time, but can leave it to
the planner to assign globally unique Param IDs; but that work would
have to be pushed further upstream.  (BTW, I'm fairly certain your patch
won't work for multiple subselects in one UPDATE, because it fails to
deal with this point.  The test cases in the patch do NOT exercise the
case because you don't have multiple multiple-output subselects in any
of them.)

I thought about trying to fix this stuff but soon concluded that it
was more work than I could justify spending on one patch during
commit fest.  It has to be bounced back for now.

regards, tom lane

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] DTrace probe patch for OS X Leopard

[Peter Eisentraut]

Am Donnerstag, 6. März 2008 schrieb Robert Lor:
> Attached is the updated patch which addressed all the concerns from
> Peter and Tom.
>
> * The header file containing the probe macros is now included only in
> the .c files that need it.
> * All probe macro names now start with TRACE_ (eg:
> TRACE_POSTGRESQL_TRANSACTION_START).

Patch applied.  I also added a small sed script that generates the dummy 
probes.h file automatically, so it doesn't need to be manually maintained.

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] Patch Status

[Simon Riggs]

On Mon, 2008-03-17 at 12:54 -0400, Bruce Momjian wrote:

> Well, this all seemed like work-in-progress stuff so it wasn't being
> tracked.  If you have things that need to be reviewed/applied, I suggest
> you resubmit and mark them as ready.

OK thanks, will do.

> As far as the doc patch, I see that as applied by Tom:
> 
>   revision 2.113
>   date: 2008/01/23 20:21:37;  author: tgl;  state: Exp;  lines: +10 -4
>   branches:  2.113.2;
>   Provide a concrete example of parameter expansion in archive_command.
>   Per discussion of bug #3877.  Simon Riggs, some fixes by moi.

Yep, see it now. My mistake. 

-- 
  Simon Riggs
  2ndQuadrant  http://www.2ndQuadrant.com 

  PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk


-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] [HACKERS] [0/4] Proposal of SE-PostgreSQL patches

[Josh Berkus]

KaiGai,

> The series of patches are the proposal of Security-Enhanced PostgreSQL
> (SE-PostgreSQL) for the upstreamed PostgreSQL 8.4 development cycle.

Since I'm (Finally!) expecting the TrustedSolaris folks to put some work into 
PostgreSQL as well this year, I'm going to ask them to look over PGACE to see 
if this implementation is (still) generic enough to support TS as well.  If 
it is, then it's probably generic enough to be a general building block.

-- 
Josh Berkus
PostgreSQL @ Sun
San Francisco

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] Minimum selectivity estimate for LIKE 'prefix%'

[Tom Lane]

Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Donnerstag, 6. März 2008 schrieb Tom Lane:
>> I attach a proposed patch against HEAD for this.  It's a bit long
>> but most of the bulk is refactoring eqsel() to make it easy to use from
>> prefix_selectivity().  The intellectual content is just in the last
>> diff hunk.

> Looking at the patch as committed here
> ,
> I am confused by one hunk:

Ack, that's a bug --- I was looking at the use of opproc by
ineq_histogram_selectivity and failed to notice make_greater_string
using it too.  Will fix.

regards, tom lane

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] Patch Status

[Bruce Momjian]

Well, this all seemed like work-in-progress stuff so it wasn't being
tracked.  If you have things that need to be reviewed/applied, I suggest
you resubmit and mark them as ready.

As far as the doc patch, I see that as applied by Tom:

revision 2.113
date: 2008/01/23 20:21:37;  author: tgl;  state: Exp;  lines: +10 -4
branches:  2.113.2;
Provide a concrete example of parameter expansion in archive_command.
Per discussion of bug #3877.  Simon Riggs, some fixes by moi.

---

Simon Riggs wrote:
> I've submitted 5 patches in Jan/Feb, none of which appear on the patch
> status page for the CommitFest, or any other status page I'm aware of.
> There *is* a comment on that page about "Minor Recovery..." which was a
> patch from me that was committed to 8.3 on 26 Sep 2007, so that item can
> be removed from the list.
> 
> My understanding of status on them is this:
> 
> * Bulk Insert tuning - 26 Feb
> Reviewed and changes agreed. With me to complete patch.
> 
> * TransactionIdIsInProgress cache
> Committed on 11 Mar
> 
> * Truncate Triggers - 30 Jan
> Not reviewed yet.
> This is a fully tested and production ready patch, apart from a few
> sections of #ifdef'd code that were intended as stubs to show how we
> might implement a brief suggestion of Tom's as an extension to the
> concept of Truncate Triggers. I think we can ignore that and look to
> apply the patch, minus the #ifdef'd sections now. Happy to produce a
> clean patch with no #ifdef'd sections if that assists review.
> 
> * sinval contention reduction - 25 Jan
> A discussion patch prior to some performance testing which subsequently
> never took place. FWIW I have an updated patch which I haven't yet
> published but haven't yet had access to a test machine to try this at
> high volumes.
> 
> * Doc patch for bug 3877 - 17 Jan
> Ready to be applied.
> 
> My understanding is that all prior patches of mine have been dealt with.
> 
> -- 
>   Simon Riggs
>   2ndQuadrant  http://www.2ndQuadrant.com 
> 
>   PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk
> 
> 
> -- 
> Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-patches

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>http://momjian.us
  EnterpriseDB http://postgres.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] [HACKERS] CIC and deadlocks

[Tom Lane]

"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> [ patch to reduce probability of deadlock of CREATE INDEX CONCURRENTLY
>   with other things ]

This patch no longer applies because of the VirtualXid changes.
Looking at it again, I'm fairly dissatisfied with it anyway;
I really don't like moving the GetTransactionSnapshot calls around
like that, because it opens a risk that GetTransactionSnapshot won't
get called at all.

Since the autovacuum case is already dealt with separately, I'm
thinking there is no problem here that we actually need to solve.
C.I.C. can never be guaranteed free of deadlock risk, so I don't
see a lot of value in making it free of deadlock risk against
just CLUSTER and VACUUM FULL.

regards, tom lane

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] Minimum selectivity estimate for LIKE 'prefix%'

[Peter Eisentraut]

Am Donnerstag, 6. März 2008 schrieb Tom Lane:
> I attach a proposed patch against HEAD for this.  It's a bit long
> but most of the bulk is refactoring eqsel() to make it easy to use from
> prefix_selectivity().  The intellectual content is just in the last
> diff hunk.

Looking at the patch as committed here
,
I am confused by one hunk:

*** prefix_selectivity(VariableStatData *var
*** 4452,4468 
 *  "x < greaterstr".
 *---
 */
-   cmpopr = get_opfamily_member(opfamily, vartype, vartype,
-
BTLessStrategyNumber);
-   if (cmpopr == InvalidOid)
-   elog(ERROR, "no < operator for opfamily %u", opfamily);
-   fmgr_info(get_opcode(cmpopr), &opproc);
- 
greaterstrcon = make_greater_string(prefixcon, &opproc);
if (greaterstrcon)
{
Selectivity topsel;
  
topsel = ineq_histogram_selectivity(vardata, &opproc, false,

greaterstrcon->constvalue,

greaterstrcon->consttype);
--- 4503,4519 
 *  "x < greaterstr".
 *---
 */
greaterstrcon = make_greater_string(prefixcon, &opproc);
if (greaterstrcon)
{
Selectivity topsel;
  
+   cmpopr = get_opfamily_member(opfamily, vartype, vartype,
+
BTLessStrategyNumber);
+   if (cmpopr == InvalidOid)
+   elog(ERROR, "no < operator for opfamily %u", opfamily);
+   fmgr_info(get_opcode(cmpopr), &opproc);
+ 
topsel = ineq_histogram_selectivity(vardata, &opproc, false,

greaterstrcon->constvalue,

greaterstrcon->consttype);

make_greater_string() is documented as

 * The caller must provide the appropriate "less than" comparison function
 * for testing the strings.

but using the new code flow it appears that opproc would still refer to
the >= operator looked up earlier.

The 8.1 code calls this variable ltproc because it didn't need the >= operator.
Perhaps using two variables would also be clearer here.

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] [HACKERS] [0/4] Proposal of SE-PostgreSQL patches

[KaiGai Kohei]

Alvaro Herrera wrote:

KaiGai Kohei wrote:

Alvaro Herrera wrote:



Before we go any further, is this work derived from SELinux?  If so, is
it covered under the GPL?  If so, can it be licensed under BSD terms?

All of SE-PostgreSQL works are licensed unser BSD terms.
We are considering to push SE-PostgreSQL into upstreamed PostgreSQL from
the beginning, and we understand to choose GPL makes it impossible.


Right.  The question is: since this is derived from SE-Linux, is it
affected by SE-Linux license?


No, SE-PostgreSQL does not derivered from SELinux.

I guess you worry about SE-PostgreSQL contains a part of SELinux licensed
as GPL, but it is incorrect.
SE-PostgreSQL communicate with SELinux to make its decision in access control,
via an official interface provided by libselinux, because it does not have
information to make its decision.
The libselinux is linked with SE-PostgreSQL, but it is licensed as public
domain software by NSA.

Therefore, we have no issues related to imcompatible licenses.

Thanks,
--
KaiGai Kohei <[EMAIL PROTECTED]>

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] [HACKERS] [0/4] Proposal of SE-PostgreSQL patches

[Alvaro Herrera]

KaiGai Kohei wrote:
> Alvaro Herrera wrote:

>> Before we go any further, is this work derived from SELinux?  If so, is
>> it covered under the GPL?  If so, can it be licensed under BSD terms?
>
> All of SE-PostgreSQL works are licensed unser BSD terms.
> We are considering to push SE-PostgreSQL into upstreamed PostgreSQL from
> the beginning, and we understand to choose GPL makes it impossible.

Right.  The question is: since this is derived from SE-Linux, is it
affected by SE-Linux license?

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] [HACKERS] [0/4] Proposal of SE-PostgreSQL patches

[KaiGai Kohei]

I'll submit the proposal of SE-PostgreSQL patches again, because some of 
previous
messages are filtered due to attachment and I cannot provide whole of patches 
yet.
Please refer the pointed URL, as follows.

--
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
http://sepgsql.googlecode.com/files/sepostgresql-pgace-8.4devel-3-r704.patch

 [2/4] sepostgresql-sepgsql-8.4devel-3.patch
 provides SE-PostgreSQL feature, based on PGACE framework.

http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r704.patch

 [3/4] sepostgresql-pg_dump-8.4devel-3.patch
 enables pg_dump to dump database with security attribute.

http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r704.patch

 [4/4] sepostgresql-policy-8.4devel-3.patch
 provides the default security policy for SE-PostgreSQL.

http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r704.patch

We can provide a quick overview for SE-PostgreSQL at:
http://code.google.com/p/sepgsql/wiki/WhatIsSEPostgreSQL

ENVIRONMENT
---
Please confirm your environment.
The followings are requriements of SE-PostgreSQL.
 * Fedora 8 or later system
 * SELinux is enabled and working
 * kernel-2.6.24 or later
 * selinux-policy and selinux-policy-devel v3.0.8 or later
 * libselinux, policycoreutils

INSTALLATION

$ tar jxvf postgresql-snapshot.tar.bz2
$ cd postgresql-snapshot
$ patch -p1 < ../sepostgresql-pgace-8.4devel-3.patch
$ patch -p1 < ../sepostgresql-sepgsql-8.4devel-3.patch
$ patch -p1 < ../sepostgresql-pg_dump-8.4devel-3.patch
$ patch -p1 < ../sepostgresql-policy-8.4devel-3.patch

$ ./configure --enable-selinux
$ make
$ make -C contrib/sepgsql-policy
$ su
# make install

# /usr/sbin/semodule -i contrib/sepgsql-policy/sepostgresql.pp
  (NOTE: semodule is a utility to load/unload security policy modules.)

# /sbin/restorecon -R /usr/local/pgsql
  (NOTE: restorecon is a utilicy to initialize security context of files.)

SETUP
-
# mkdir -p /opt/sepgsql
# chown foo_user:var_group /opt/sepgsql
# chcon -t postgresql_db_t /opt/sepgsql
  (NOTE: chcon is a utility to set up security context of files.)
# exit

$ /usr/sbin/run_init /usr/local/pgsql/bin/initdb -D /opt/sepgsql
  (NOTE: run_init is a utility to start a program, as if it is branched from 
init script.)
$ /usr/local/pgsql/bin/pg_ctl -D /opt/sepgsql start


SUMMARYS FOR EVERY PATCHES
--
[1/4] - sepostgresql-pgace-8.4devel-3.patch

This patch provides PGACE (PostgreSQL Access Control Extension) framework.

It has a similar idea of LSM (Linu Security Module).
It can provide a guest module several hooks at strategic points.
The guest module can make its decision whether required actions should be
allowed, or not.
In addition, PGACE also provides falicilites to manage security attribute
of database objects. Any tuple can have a its security attribute, and the
guest module can refer it to control accesses.

  A more conprehensive memo at:
http://code.google.com/p/sepgsql/wiki/WhatIsPGACE

[2/4] - sepostgresql-sepgsql-8.4devel-3.patch

This patch provides SE-PostgreSQL facilities based on PGACE.

Security-Enhanced PostgreSQL (SE-PostgreSQL) is a security extension
built in PostgreSQL, to provide system-wide consistency in access
controls. It enables to apply a single unigied security policy of
SELinux for both operating system and database management system.
In addition, it also provides fine-grained mandatory access which
includes column-/row- level non-bypassable access control even if
privileged database users.

  Quick overview at:
http://code.google.com/p/sepgsql/wiki/WhatIsSEPostgreSQL

[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
database. It it same when they tries to restore the database.

[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.

-- 
KaiGai Kohei <[EMAIL PROTECTED]>

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] [HACKERS] [0/4] Proposal of SE-PostgreSQL patches

[KaiGai Kohei]

Alvaro Herrera wrote:

Kohei KaiGai wrote:

The series of patches are the proposal of Security-Enhanced PostgreSQL
(SE-PostgreSQL) for the upstreamed PostgreSQL 8.4 development cycle.


Before we go any further, is this work derived from SELinux?  If so, is
it covered under the GPL?  If so, can it be licensed under BSD terms?

Obviously, if it's not BSD, we cannot include it in Postgres.


All of SE-PostgreSQL works are licensed unser BSD terms.
We are considering to push SE-PostgreSQL into upstreamed PostgreSQL from
the beginning, and we understand to choose GPL makes it impossible.

Thanks,
--
KaiGai Kohei <[EMAIL PROTECTED]>

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] [HACKERS] [0/4] Proposal of SE-PostgreSQL patches

[Alvaro Herrera]

Kohei KaiGai wrote:
> The series of patches are the proposal of Security-Enhanced PostgreSQL
> (SE-PostgreSQL) for the upstreamed PostgreSQL 8.4 development cycle.

Before we go any further, is this work derived from SELinux?  If so, is
it covered under the GPL?  If so, can it be licensed under BSD terms?

Obviously, if it's not BSD, we cannot include it in Postgres.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] updated hash functions for postgresql v1

[Kenneth Marshall]

On Sun, Mar 16, 2008 at 10:53:02PM -0400, Tom Lane wrote:
> Kenneth Marshall <[EMAIL PROTECTED]> writes:
> > Dear PostgreSQL Developers,
> > This patch is a "diff -c" against the hashfunc.c from postgresql-8.3beta1.
> 
> It's pretty obvious that this patch hasn't even been tested on a
> big-endian machine:
> 
> > + #ifndef WORS_BIGENDIAN
> 
> However, why do we need two code paths anyway?  I don't think there's
> any requirement for the hash values to come out the same on little-
> and big-endian machines.  In common cases the byte-array data being
> presented to the hash function would be different to start with, so
> you could hardly expect identical hash results even if you had separate
> code paths.
> 
> I don't find anything very compelling about 64-bit hashing, either.
> We couldn't move to that without breaking API for hash functions
> of user-defined types.  Given all the other problems with hash
> indexes, the issue of whether it's useful to have more than 2^32
> hash buckets seems very far off indeed.
> 
>   regards, tom lane
> 

Yes, there is that typo but it has, in fact, been tested on big and
little-endian machines. Since, it was a simple update to replace the
current hash function used by PostgreSQL with the new version from
Bob Jenkins. The test for the endian-ness of the system allows for
the code paths to be optimized for the particular CPU. The 64-bit
hashing was included for use during my work on on the hash index.
Part of that will entail testing the performance of various
permutations of previously submitted suggestions. 

Regards,
Ken Marshall

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

[PATCHES] Patch Status

[Simon Riggs]

I've submitted 5 patches in Jan/Feb, none of which appear on the patch
status page for the CommitFest, or any other status page I'm aware of.
There *is* a comment on that page about "Minor Recovery..." which was a
patch from me that was committed to 8.3 on 26 Sep 2007, so that item can
be removed from the list.

My understanding of status on them is this:

* Bulk Insert tuning - 26 Feb
Reviewed and changes agreed. With me to complete patch.

* TransactionIdIsInProgress cache
Committed on 11 Mar

* Truncate Triggers - 30 Jan
Not reviewed yet.
This is a fully tested and production ready patch, apart from a few
sections of #ifdef'd code that were intended as stubs to show how we
might implement a brief suggestion of Tom's as an extension to the
concept of Truncate Triggers. I think we can ignore that and look to
apply the patch, minus the #ifdef'd sections now. Happy to produce a
clean patch with no #ifdef'd sections if that assists review.

* sinval contention reduction - 25 Jan
A discussion patch prior to some performance testing which subsequently
never took place. FWIW I have an updated patch which I haven't yet
published but haven't yet had access to a test machine to try this at
high volumes.

* Doc patch for bug 3877 - 17 Jan
Ready to be applied.

My understanding is that all prior patches of mine have been dealt with.

-- 
  Simon Riggs
  2ndQuadrant  http://www.2ndQuadrant.com 

  PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk


-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

[PATCHES] [1/4] Proposal of SE-PostgreSQL patches

[Kohei KaiGai]

[1/4] - sepostgresql-pgace-8.4devel-3.patch.gz

This patch provides PGACE (PostgreSQL Access Control Extension) framework.

It has a similar idea of LSM (Linu Security Module).
It can provide a guest module several hooks at strategic points.
The guest module can make its decision whether required actions should be
allowed, or not.
In addition, PGACE also provides falicilites to manage security attribute
of database objects. Any tuple can have a its security attribute, and the
guest module can refer it to control accesses.

  A more conprehensive memo at:
http://code.google.com/p/sepgsql/wiki/WhatIsPGACE

(This patch is gzip'ed, bacause it overed the limitation of filesize.)

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <[EMAIL PROTECTED]>


sepostgresql-pgace-8.4devel-3.patch.gz
Description: application/gzip

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] [HACKERS] [0/4] Proposal of SE-PostgreSQL patches

[Zdenek Kotala]

Kohei KaiGai napsal(a):
> 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.

There is a file size limitation. If your patch is too big (I guess over
40kB), please gzip it or send only url for download.

Zdenek

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

[PATCHES] [2/4] Proposal of SE-PostgreSQL patches

[Kohei KaiGai]

[2/4] - sepostgresql-sepgsql-8.4devel-3.patch.gz

This patch provides SE-PostgreSQL facilities based on PGACE.

Security-Enhanced PostgreSQL (SE-PostgreSQL) is a security extension
built in PostgreSQL, to provide system-wide consistency in access
controls. It enables to apply a single unigied security policy of
SELinux for both operating system and database management system.
In addition, it also provides fine-grained mandatory access which
includes column-/row- level non-bypassable access control even if
privileged database users.

  Quick overview at:
http://code.google.com/p/sepgsql/wiki/WhatIsSEPostgreSQL

(This patch is gzip'ed, bacause it overed the limitation of filesize.)

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <[EMAIL PROTECTED]>


sepostgresql-sepgsql-8.4devel-3.patch.gz
Description: application/gzip

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] [HACKERS] [0/4] Proposal of SE-PostgreSQL patches

[Kohei KaiGai]

Zdenek Kotala wrote:
> Kohei KaiGai napsal(a):
>> 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.
> 
> There is a file size limitation. If your patch is too big (I guess over
> 40kB), please gzip it or send only url for download.
> 
>   Zdenek

Thanks for your information,

Your estimation is correct. Two of them are over the limitaion.
So, I'll send it again with gzip'ed attachment.

[EMAIL PROTECTED] a]$ ls -lh *-8.4devel-*.patch
-rw-r--r-- 1 kaigai users  17K 2008-03-17 13:01 
sepostgresql-pg_dump-8.4devel-3.patch
-rw-r--r-- 1 kaigai users 134K 2008-03-17 13:01 
sepostgresql-pgace-8.4devel-3.patch
-rw-r--r-- 1 kaigai users  17K 2008-03-17 13:01 
sepostgresql-policy-8.4devel-3.patch
-rw-r--r-- 1 kaigai users 138K 2008-03-17 13:01 
sepostgresql-sepgsql-8.4devel-3.patch

-- 
OSS Platform Development Division, NEC
KaiGai Kohei <[EMAIL PROTECTED]>

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches