greg
On 24 Sep 2008, at 02:45, Tom Lane [EMAIL PROTECTED] wrote:
The next big
thing seems to be to figure out exactly how to do multiple references
to CTE outputs, so that we can de-bogotify the planner.
I've looked and don't seem to still have the source tree where I
worked on this. I
On Tue, 2008-09-23 at 22:17 -0700, Joshua D. Drake wrote:
Simon Riggs wrote:
On Tue, 2008-09-23 at 16:50 -0400, Andrew Dunstan wrote:
If we get all that done by November we'll have done well. And we know
that in some cases just this much can lead to reductions in restore
time
of
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 redo
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 case it
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
information
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
*
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
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 problem is that our pg_controldata might
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
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 items that
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
* 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 ask:
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 open() did,
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
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 SELinux.
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. Any tuple
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, but
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 specs and are
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
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.
--
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 not even
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
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 meaning
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
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
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 people running
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
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 this a valid
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 the
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.
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 how
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
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 this all
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 already
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.
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
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
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 that
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 problems
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
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
alternative, more
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
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?
[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's
-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
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]
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
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 similar
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
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 produces
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.
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?
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 the
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 whether to
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 prepared
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
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 know
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.
OK,
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,
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
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
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
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 is
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_delay
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 clarification,
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]
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
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 significant point
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, but
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
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 query tree
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:
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
73 matches
Mail list logo
