Bruce Momjian wrote:
> 2) Do we want row-level permissions at the SQL level?
Now I'm working for it and will submit patches due to the end of Oct,
if it is really required to make progress reviewing of SE-PostgreSQL
on the v8.4 development cycle.
However, the scale of its demand is unclear fo
Attached is my WIP patch for parallel pg_restore. It's still very rough,
but seems to work.
Anyone who can test this with highend equipment would be helping some.
cheers
andrew
Index: pg_backup.h
===
RCS file: /cvsroot/pgsql/src
KaiGai Kohei wrote:
> > 1) When are we getting column-level permissions that you can
> >plug into?
>
> Please note that SE-PostgreSQL checks its column-level permission *after*
> VIEWs
> are expanded, because it focuses on "what" object is accessed, not "how".
> Thus, it walks on the
Bruce Momjian wrote:
The bulk of the patch is in sepostgresql-sepgsql-8.4devel-3-r1043.patch,
which modifies the backend. About 30% of it or 3k lines modify our
backend, and the rest are indepdendent support routines in their own C
files.
The 3k lines (which is named as PGACE security framework
Tom,
> > WithClause node may need a location field, and almost certainly has to
> > be handled somehow in exprLocation().
> >
> > The error reports in parse_cte.c *desperately* need error locations.
Included is a patch for this against your cte-0923.patch.gz. Most
errors now have error locations
KaiGai Kohei wrote:
> > Particularly interesting was the doc patch,
> > sepostgresql-docs-8.4devel-3-r1043.patch. It explains how SE-PostgreSQL
> > checks the permission level of the client process (getpeercon) and uses
> > that to determine what the user should see.
>
> Yes, this is a significan
Robert Haas wrote:
Yes, we need '--enable-selinux' to activate all of SE-PostgreSQL features.
In addition, these are invoked via security hooks which are declared
as inline functions. So, I think it does not give us additional loss of
performances when you don't add the compile time option expli
Bruce Momjian wrote:
KaiGai Kohei wrote:
I updated the series of patches for SE-PostgreSQL 8.4devel.
[1/5]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1043.patch
[2/5]
http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1043.patch
[3/5]
http://sepgsq
Bruce Momjian wrote:
> Simon Riggs wrote:
> > 2. Master ignores Standby's OldestXmin
> > Effects:
> > * Long running queries on standby...
> >Have no effect on primary
> >Can delay apply of WAL records on standby
> > * Queries on standby give consistent answers in all cases.
>
> Just for c
Simon Riggs wrote:
> 2. Master ignores Standby's OldestXmin
> Effects:
> * Long running queries on standby...
>Have no effect on primary
>Can delay apply of WAL records on standby
> * Queries on standby give consistent answers in all cases.
Just for clarification, if you set a max_slave_de
> Yes, we need '--enable-selinux' to activate all of SE-PostgreSQL features.
>
> In addition, these are invoked via security hooks which are declared
> as inline functions. So, I think it does not give us additional loss of
> performances when you don't add the compile time option explicitly.
That
Bruce Momjian wrote:
Robert Haas wrote:
The objection comes down to this: it's an extremely large, invasive,
and probably performance-losing patch, which apparently will be of use
to only a rather small set of people. It's not unreasonable to discuss
just how large that set might be while we de
Peter Eisentraut wrote:
I am not arguing for or against this patch now, but I would like to know
whether someone has an agenda for it. Without an agenda, future
maintenance will be difficult. Reference to standards or other public
documents would work best to define that agenda.
It is a bit
Hello,
I modified my previous patch supporting the --role option in pg_dump and
pg_dumpall.
The attached patch contains the following things:
- pg_dump and pg_dumpall accepts the --role=rolename parameter, and
sends a SET ROLE
command on their connections
- pg_dumpall passes this option to t
This topic really doesn't belong on -hackers, does it? Surely it belongs
either on the pgfoundry admins list, or the sysadmins list, or the -www
list or some such.
cheers
andrew
David E. Wheeler wrote:
On Sep 24, 2008, at 14:02, Joshua Drake wrote:
I think one problem we have right now,
On Wed, 2008-09-24 at 13:48 +0100, Simon Riggs wrote:
> On Tue, 2008-09-23 at 22:47 +0100, Simon Riggs wrote:
>
> > I've tested this some more and am much happier with it now.
>
> The concept is fine, but I've found a coding bug in further testing.
> Please wait now for new version before review
Tom,
> Does that mean that they have looked at this specific patch and
> concluded that it meets their requirements? Or just that SELinux
> is a checkbox item for them?
That it was a checkbox item for them, and it led to them evaluating
PostgreSQL when they otherwise wouldn't have. I don't kno
On Sep 24, 2008, at 14:02, Joshua Drake wrote:
I think one problem we have right now, is nobody knows what it is
going
to take. I would expect that our current version is sufficiently old
enough to cause some migration pain?
I know we have two members willing to help that are not Stefan and I
On Mon, 22 Sep 2008 19:08:16 +0200
Stefan Kaltenbrunner <[EMAIL PROTECTED]> wrote:
> > OK, cool. Stefan; what's your take on where we're at?
>
> yeah there is a box and a jail I set up a while ago but for various
> reasons the actual migration (planning and testing) never happened.
> I'm still p
Robert Haas wrote:
> > The objection comes down to this: it's an extremely large, invasive,
> > and probably performance-losing patch, which apparently will be of use
> > to only a rather small set of people. It's not unreasonable to discuss
> > just how large that set might be while we debate whe
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Hmm. The smgrtuncate WAL record is generated after the file is
> truncated, so there's still a small window there, where we can be left
> with a truncated main fork, but no smgrtruncate record for it, and thus
> the page of the FSM representing th
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Zdenek Kotala wrote:
What's about truncate FSM during WAL replay of main fork truncation record?
That would work, except that there's no WAL record for truncating the
main fork.
Whaddya mean there's no WAL record for that? smg
> The objection comes down to this: it's an extremely large, invasive,
> and probably performance-losing patch, which apparently will be of use
> to only a rather small set of people. It's not unreasonable to discuss
> just how large that set might be while we debate whether to accept the
> patch.
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Zdenek Kotala wrote:
>> What's about truncate FSM during WAL replay of main fork truncation record?
> That would work, except that there's no WAL record for truncating the
> main fork.
Whaddya mean there's no WAL record for that? smgrtruncate prod
Ron Mayer wrote:
> I think it's a bug that these 3 different ways of writing 0.7 seconds
> produce different results from each other on HEAD.
>
> head=# select interval '0:0:0.7', interval '@ 0.70 secs', interval '0.7
> seconds';
>interval |interval |interval
> -+---
Josh Berkus <[EMAIL PROTECTED]> writes:
> Peter,
>> Yeah, but do we even have the slightest bit of information about what
>> exactly would be required to achieve the required levels? And whether
>> this patch does it? And whether there would be alternative, more
>> desirable ways to achieve a
Chris Browne wrote:
Let me report a problem with this...
Running pg_dump encounters the following:
[EMAIL PROTECTED]:Slony-I/CMD/slony1-HEAD/tests> pg_dump -s slonyregress1
pg_dump: column number -1 is out of range 0..7
pg_dump: column number -1 is out of range 0..7
zsh: segmentation fault pg_
KaiGai Kohei wrote:
> I updated the series of patches for SE-PostgreSQL 8.4devel.
>
> [1/5]
> http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1043.patch
> [2/5]
> http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1043.patch
> [3/5]
> http://sepgsql.google
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 24 sept. 08 à 18:56, Andrew Dunstan a écrit :
The is purely a patch to pg_restore. No backend changes at all (and
if I did it would not use anything that isn't in core anyway).
Ok, good.
I'm eager to see what -core hackers will want to do with
[EMAIL PROTECTED] (Heikki Linnakangas) writes:
> Log Message:
> ---
> Make LC_COLLATE and LC_CTYPE database-level settings. Collation and
> ctype are now more like encoding, stored in new datcollate and datctype
> columns in pg_database.
>
> This is a stripped-down version of Radek Strnad'
Josh Berkus wrote:
> Peter,
>
> > Yeah, but do we even have the slightest bit of information about what
> > exactly would be required to achieve the required levels? And whether
> > this patch does it? And whether there would be alternative, more
> > desirable ways to achieve a similar level?
On Sep 24, 2008, at 2:38 PM, Josh Berkus wrote:
Peter,
Yeah, but do we even have the slightest bit of information about
what exactly would be required to achieve the required levels? And
whether this patch does it? And whether there would be
alternative, more desirable ways to achieve
On Wed, 24 Sep 2008 11:38:36 -0700
Josh Berkus <[EMAIL PROTECTED]> wrote:
> Peter,
>
> > Yeah, but do we even have the slightest bit of information about
> > what exactly would be required to achieve the required levels? And
> > whether this patch does it? And whether there would be
> > alterna
Peter,
Yeah, but do we even have the slightest bit of information about what
exactly would be required to achieve the required levels? And whether
this patch does it? And whether there would be alternative, more
desirable ways to achieve a similar level?
Actually, I have some direct commun
Zdenek Kotala wrote:
> Heikki Linnakangas napsal(a):
>
>> It would be
>> simple to update the FSM at every heap insert and update record, but
>> that then might be an unacceptable amount of overhead at recovery. Also,
>> the index FSM is not yet updated during recovery.
>
> I expect locking pr
Zdenek Kotala wrote:
> Heikki Linnakangas napsal(a):
>> There's one known bug left. If we crash after truncating a relation, and
>> the truncation of the FSM doesn't hit the disk but the truncation of the
>> main fork does, we can end up with an FSM that shows that there's free
>> space on pages
Joshua Drake wrote:
I know of no one that really uses SELinux because it is a nightmare. On
the other hand, this type of security is required to get into certain
scary tin foil hat producing institutions.
Yeah, but do we even have the slightest bit of information about what
exactly would be re
Bruce Momjian wrote:
Peter, I am confused how the above statement relates to a posting you
made a week ago:
http://archives.postgresql.org/pgsql-hackers/2008-09/msg01067.php
Now these items are arguably useful and welcome features in their own
right. Unfortunately, this
Dimitri Fontaine wrote:
Le mercredi 24 septembre 2008, Andrew Dunstan a écrit :
No. The proposal will perform exactly the same set of steps as
single-threaded pg_restore, but in parallel. The individual steps won't
be broken up.
Ok, good for a solid trustworthy parallelism restore. W
On Wed, 2008-09-24 at 12:35 -0400, Robert Treat wrote:
> On Wednesday 24 September 2008 03:27:44 Simon Riggs wrote:
> > On Wed, 2008-09-24 at 00:30 -0400, Robert Treat wrote:
> > > * "However, some WAL redo actions will be for DDL actions. These DDL
> > > actions are repeating actions that have al
On Wednesday 24 September 2008 03:27:44 Simon Riggs wrote:
> On Wed, 2008-09-24 at 00:30 -0400, Robert Treat wrote:
> > here are some scattered thoughts i had while reading it :
>
> Thanks for your comments.
>
> It is very detailed, so further feedback is going to be very beneficial
> in making thi
Joshua Drake wrote:
> On Wed, 24 Sep 2008 11:58:58 -0400
> Tom Lane <[EMAIL PROTECTED]> wrote:
>
> > The objection comes down to this: it's an extremely large, invasive,
> > and probably performance-losing patch, which apparently will be of use
> > to only a rather small set of people. It's not u
On Wed, 24 Sep 2008 11:58:58 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> The objection comes down to this: it's an extremely large, invasive,
> and probably performance-losing patch, which apparently will be of use
> to only a rather small set of people. It's not unreasonable to
> discuss just ho
Le mercredi 24 septembre 2008, Andrew Dunstan a écrit :
> No. The proposal will perform exactly the same set of steps as
> single-threaded pg_restore, but in parallel. The individual steps won't
> be broken up.
Ok, good for a solid trustworthy parallelism restore. Which is exactly what we
want. J
On Wed, 24 Sep 2008 07:52:52 +0100
Simon Riggs <[EMAIL PROTECTED]> wrote:
> > Just as an FYI, by far the number one bottle neck on the multiple
> > work restores I was doing was CPU. RAM and IO were never the
> > problem.
>
> It would be useful to see a full breakdown of those results.
Its in th
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Aidan Van Dyk wrote:
>> Actually, I'ld go one stroke farther, and ask:
>> Does it make sense to introduce a bunch of features that are only
>> usable to people *able to write proper SELinux policy sets* (or whatever
>> they are called).
> I consider t
Dimitri Fontaine wrote:
Hi,
Le mardi 23 septembre 2008, Andrew Dunstan a écrit :
In any case, my agenda goes something like this:
* get it working with a basic selection algorithm on Unix (nearly
done - keep your eyes open for a patch soon)
* start testing
* get it worki
Peter Eisentraut wrote:
> Aidan Van Dyk wrote:
> > * Robert Haas <[EMAIL PROTECTED]> [080924 00:15]:
> >
> >> But I do think
> >> it's worthwhile to ask whether it makes sense to introduce a bunch of
> >> features that are only usable to peopl
PostgreSQL makes all identifiers to be lower-case except when putting an
identifier between double-quotes.
I have an special case where I would like to preserve the case-sensitivity
without putting every column/table name inside double-quotes (The
application is too big to change).
Is this functi
Aidan Van Dyk wrote:
* Robert Haas <[EMAIL PROTECTED]> [080924 00:15]:
But I do think
it's worthwhile to ask whether it makes sense to introduce a bunch of
features that are only usable to people running SELinux.
Actually, I'ld go one str
On Wed, 2008-09-24 at 17:42 +0300, Heikki Linnakangas wrote:
> Yeah. Nevertheless I like the way effective_spindle_count works, as
> opposed to an unintuitive "number of blocks to prefetch" (assuming the
> formula we use to turn the former into latter works). Perhaps we should
> keep the meani
Heikki Linnakangas napsal(a):
> It would be
> simple to update the FSM at every heap insert and update record, but
> that then might be an unacceptable amount of overhead at recovery. Also,
> the index FSM is not yet updated during recovery.
I expect locking problems specially on small tables
KaiGai Kohei wrote:
> Tom Lane wrote:
> > Josh Berkus <[EMAIL PROTECTED]> writes:
> >> Multilevel frameworks have concepts of data hiding and data substitution
> >> based on labels. That is, if a user doesn't have permissions on data,
> >> he's not merely supposed to be denied access to it, he's
I started a little campaign to get the default SHMMAX on Linux raised
from its current nostalgic 32 MB, to lessen the burden on our users:
http://bugzilla.kernel.org/show_bug.cgi?id=11381
The kernel developers aren't exactly convinced yet, so maybe others can
add their arguments there.
--
Se
Bruce Momjian wrote:
Ron Mayer wrote:
Even more often on systems I see these days, "spindles"
is an implementation detail that the DBA has no way to know
what the correct value is.
For example, on our sites hosted with Amazon's compute cloud (a great
place to host web sites), I know nothing abo
Gregory Stark wrote:
>
> Ron Mayer <[EMAIL PROTECTED]> writes:
>
> > For example, on our sites hosted with Amazon's compute cloud (a great
> > place to host web sites), I know nothing about spindles, but know
> > about Amazon Elastic Block Store[2]'s and Instance Store's[1]. I
> > have some spe
Ron Mayer wrote:
> Even more often on systems I see these days, "spindles"
> is an implementation detail that the DBA has no way to know
> what the correct value is.
>
> For example, on our sites hosted with Amazon's compute cloud (a great
> place to host web sites), I know nothing about spindles,
KaiGai Kohei wrote:
> The following proposal is idea which I have been considered for several days.
>
> A design of PostgreSQL fine-grained security
>
>
> * Target
>
> This feature provide a row-level access control feature based on
> database acl. An
KaiGai Kohei wrote:
> Aidan Van Dyk wrote:
>> * Robert Haas <[EMAIL PROTECTED]> [080924 00:15]:
>>
>>> But I do think
>>> it's worthwhile to ask whether it makes sense to introduce a bunch of
>>> features that are only usable to people running
Aidan Van Dyk wrote:
> * Robert Haas <[EMAIL PROTECTED]> [080924 00:15]:
>
>> But I do think
>> it's worthwhile to ask whether it makes sense to introduce a bunch of
>> features that are only usable to people running SELinux.
>
> Actually, I'
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>>> The point being that the config files are opened with AllocateFile(),
>>> which in turn calls fopen(). It doesn't use open(). The proposal was
>>> only to make all *open()* calls do it binary. I was under the impression
>>> that on Unix, that's what
* Robert Haas <[EMAIL PROTECTED]> [080924 00:15]:
> But I do think
> it's worthwhile to ask whether it makes sense to introduce a bunch of
> features that are only usable to people running SELinux.
Actually, I'ld go one stroke farther, and as
Tom Lane wrote:
The point being that the config files are opened with AllocateFile(),
which in turn calls fopen(). It doesn't use open(). The proposal was
only to make all *open()* calls do it binary. I was under the impression
that on Unix, that's what open() did, so we should behave the same?
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>> Tom Lane wrote:
>>> If you need a positive reason why this might be a bad idea, consider the
>>> idea that someone is examining postgresql.conf with a text editor that
>>> stops reading at control-Z. He might not be able to see
On Tue, 2008-09-23 at 22:47 +0100, Simon Riggs wrote:
> I've tested this some more and am much happier with it now.
The concept is fine, but I've found a coding bug in further testing.
Please wait now for new version before review.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Trai
Magnus Hagander wrote:
> Andrew Dunstan wrote:
>>
>> Tom Lane wrote:
>>> Bruce Momjian <[EMAIL PROTECTED]> writes:
>>>
Tom Lane wrote:
> Well, why is that a bug? If the platform is so silly as to define text
> files that way, who are we to argue?
>
>>>
The
Simon Riggs wrote:
On Mon, 2008-09-22 at 20:43 +0300, Heikki Linnakangas wrote:
Attached is a revamped version of the FSM rewrite. WAL-logging is now
gone. Any inconsistencies between levels of the FSM is fixed during
vacuum, and by searchers when they run into a dead end because of a
discrep
Hi,
Le mardi 23 septembre 2008, Andrew Dunstan a écrit :
> In any case, my agenda goes something like this:
>
> * get it working with a basic selection algorithm on Unix (nearly
> done - keep your eyes open for a patch soon)
> * start testing
> * get it working on Windows
> *
On Wed, 2008-09-24 at 08:28 +0100, Dave Page wrote:
> On Wed, Sep 24, 2008 at 5:30 AM, Robert Treat
> <[EMAIL PROTECTED]> wrote:
>
> > I presume this means the backend kill function would work? Also, can you go
> > into why pgAgent would not work? (I presume it's because you can't update
> > inf
On Wed, Sep 24, 2008 at 5:30 AM, Robert Treat
<[EMAIL PROTECTED]> wrote:
> I presume this means the backend kill function would work? Also, can you go
> into why pgAgent would not work? (I presume it's because you can't update
> information that needs to be changed when jobs run, if thats the cas
On Wed, 2008-09-24 at 00:30 -0400, Robert Treat wrote:
> here are some scattered thoughts i had while reading it :
Thanks for your comments.
It is very detailed, so further feedback is going to be very beneficial
in making this all work in the way we hope and expect.
> * "However, some WAL red
71 matches
Mail list logo