(2010/05/21 1:14), Robert Haas wrote:
In yesterday's development meeting, we talked about the possibility of
a basic SE-PostgreSQL implementation that checks permissions only for
DML. Greg Smith offered the opinion that this could provide much of
the benefit of SE-PostgreSQL for many users,
At Ottawa, I had a talk with Robert Haas about this reworks.
Because a part of ALTER TABLE options need information which can
be gathered at execution stage, not preparation stage, the patch
tried to move all the access control stuff into execution stage.
However, he pointed out it has a matter
On 5/23/2010 11:19 PM, Andrew Dunstan wrote:
Jan Wieck wrote:
ISTM we are in danger of confusing several different things. A user
that doesn't want data to be shared should not stash it in global
objects. But to me, trusting a language is not about making data
private, but about not
2010/5/24 KaiGai Kohei kai...@ak.jp.nec.com:
BTW, I guess the reason why permissions on attributes are not checked here is
that we missed it at v8.4 development.
That's a little worrying. Can you construct and post a test case
where this results in a user-visible failure in CVS HEAD?
The
Hi,
I'm now designing the synchronous replication feature based on
SR for 9.1, while discussing that at another thread.
http://archives.postgresql.org/pgsql-hackers/2010-04/msg01516.php
At the first design phase, I'd like to clarify which synch levels
should be supported 9.1 and how it should be
On Mon, May 24, 2010 at 1:27 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, May 19, 2010 at 2:47 PM, Fujii Masao masao.fu...@gmail.com wrote:
Oh, right. How about allowing the postmaster only in PM_STARTUP,
PM_RECOVERY, PM_HOT_STANDBY or PM_WAIT_READONLY state to invoke
walreceiver? We
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
In light of the proposed purging scheme, how would it be able to distinguish
between those two cases (nothing there yet vs. was there but purged)?
There is a difference between an empty result set and an exception.
No, I meant how will
On 22/05/10 16:35, Tom Lane wrote:
Josh Berkusj...@agliodbs.com writes:
From a discussion at dinner at pgcon, I wanted to send this to the list
for people to poke holes in it:
Somebody (I think Joe or Heikki) poked a big hole in this last night at
the Royal Oak.
Me.
Although the
On Mon, 2010-05-24 at 09:26 -0400, Robert Haas wrote:
On Mon, May 24, 2010 at 1:27 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, May 19, 2010 at 2:47 PM, Fujii Masao masao.fu...@gmail.com wrote:
Oh, right. How about allowing the postmaster only in PM_STARTUP,
PM_RECOVERY,
On Sun, May 23, 2010 at 9:44 PM, Jan Wieck janwi...@yahoo.com wrote:
I'm not sure the retention policies of the shared buffer cache, the WAL
buffers, CLOG buffers and every other thing we try to cache are that easy to
fold into one single set of logic. But I'm all ears.
I'm not sure either,
On Mon, May 24, 2010 at 9:28 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2010-05-24 at 09:26 -0400, Robert Haas wrote:
On Mon, May 24, 2010 at 1:27 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, May 19, 2010 at 2:47 PM, Fujii Masao masao.fu...@gmail.com wrote:
Oh, right. How
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
(As also discussed in the Royal Oak) I think we should simply not dirty
a page when a hint bit is updated. Reading a page from disk is
expensive, setting hint bits on the access is generally cheap compared
to that. But that is
Robert Haas robertmh...@gmail.com writes:
On Mon, May 24, 2010 at 9:28 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2010-05-24 at 09:26 -0400, Robert Haas wrote:
This looks pretty reasonable to me, but I guess I feel like it would
be better to drive the CancelBackup() decision off of
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Well, the best way to define what a trusted language can do is to
define a *whitelist* of what it can do, not a blacklist of what it
can't do. That's the only way to get a complete definition. It's then
up to the implementation step to
On Mon, May 24, 2010 at 10:26 PM, Robert Haas robertmh...@gmail.com wrote:
This looks pretty reasonable to me, but I guess I feel like it would
be better to drive the CancelBackup() decision off of whether we've
ever reached PM_RUN rather than consulting XLogCtl. It just feels
cleaner to me
On Mon, May 24, 2010 at 10:35 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, May 24, 2010 at 10:26 PM, Robert Haas robertmh...@gmail.com wrote:
This looks pretty reasonable to me, but I guess I feel like it would
be better to drive the CancelBackup() decision off of whether we've
ever
Fujii Masao masao.fu...@gmail.com writes:
Okay, how about the attached patch? It uses the postmaster-local flag
ReachedEndOfRecovery (better name?) instead of XLogCtl one.
ReachedNormalRunning, perhaps?
regards, tom lane
--
Sent via pgsql-hackers mailing list
Jan Wieck wrote:
In some systems (data warehousing, replication), the order of
commits is important, since that is the order in which changes
have become visible.
This issue intersects with the serializable work I've been doing.
While in database transactions using S2PL the above is true,
On Mon, May 24, 2010 at 11:24 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Jan Wieck wrote:
In some systems (data warehousing, replication), the order of
commits is important, since that is the order in which changes
have become visible.
This issue intersects with the serializable
On Sun, May 23, 2010 at 11:50:00AM -0400, Stephen Frost wrote:
If we need this we should do it properly with autoconf.
I absolutely agree and planed to do that *after* the release if it makes sense
for the rest of PG, but wouldn't want to mess with it in the current
situtation. On the other
On 24/05/10 16:20, Fujii Masao wrote:
The log-shipping replication has some synch levels as follows.
The transaction commit on the master
#1 doesn't wait for replication (already suppored in 9.0)
#2 waits for WAL to be received by the standby
#3 waits for WAL to be received and
On Sat, May 22, 2010 at 11:20:50PM -0400, Stephen Frost wrote:
git diff -p), I noted that c.h is already included by both extern.h
and ecpg.header through postgres_fe.h. Given this and that we're
already doing alot of similar #define's there (unlike in those other
files), I felt c.h
I have some libpq-using application code, in which fetching the data
follows this logic (after a statement has been prepared):
PQexecPrepared(pg_result, pg_conn, pg_statement_name, input_param_cnt,
param_values, param_lengths,
I'm not sure it's cheap. What you suggest would result in a substantial
increase in clog accesses, which means (1) more I/O and (2) more
contention. Certainly it's worth experimenting with, but it's no
guaranteed win.
It seems like there's a number of issues we could fix by making the CLOG
Robert Haas wrote:
I think you're confusing two subtly different things.
The only thing I'm confused about is what benefit anyone expects to
get from looking at data between commits in some way other than our
current snapshot mechanism. Can someone explain a use case where
what Jan is
On 24/05/10 19:51, Kevin Grittner wrote:
The only thing I'm confused about is what benefit anyone expects to
get from looking at data between commits in some way other than our
current snapshot mechanism. Can someone explain a use case where
what Jan is proposing is better than snapshot
Michael Meskes mes...@postgresql.org writes:
On Sat, May 22, 2010 at 11:20:50PM -0400, Stephen Frost wrote:
git diff -p), I noted that c.h is already included by both extern.h
and ecpg.header through postgres_fe.h. Given this and that we're
already doing alot of similar #define's there
Stefan Kaltenbrunner wrote:
On 05/19/2010 05:16 PM, Bruce Momjian wrote:
Andres Freund wrote:
On Wednesday 19 May 2010 22:39:32 Bruce Momjian wrote:
There are some limitations when migrating from 8.3 to 8.4, but not when
migrating from 8.3 to 9.0, because we added a feature to 9.0. Can
Pavel Stehule wrote:
Hello
it fixes bug
pg_upgrade(13359) malloc: *** error for object 0x801600:
non-page-aligned, non-allocated pointer being freed
*** set a breakpoint in malloc_error_break to debug
arget 03:31 /usr/local/src/postgresql/contrib/pg_upgrade git diff .
diff --git
On 05/24/2010 07:43 PM, Bruce Momjian wrote:
Stefan Kaltenbrunner wrote:
On 05/19/2010 05:16 PM, Bruce Momjian wrote:
Andres Freund wrote:
On Wednesday 19 May 2010 22:39:32 Bruce Momjian wrote:
There are some limitations when migrating from 8.3 to 8.4, but not when
migrating from 8.3 to 9.0,
On Mon, May 24, 2010 at 12:51 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Robert Haas wrote:
I think you're confusing two subtly different things.
The only thing I'm confused about is what benefit anyone expects to
get from looking at data between commits in some way other than our
Excerpts from Robert Haas's message of dom may 23 20:38:14 -0400 2010:
On Sun, May 23, 2010 at 4:21 PM, Jan Wieck janwi...@yahoo.com wrote:
The system will have postgresql.conf options for enabling/disabling the
whole shebang, how many shared buffers to allocate for managing access
to the
Stefan Kaltenbrunner wrote:
I have updated the paragraph to be:
Upgrading from PostgreSQL 8.3 has additional restrictions not present
when upgrading from later PostgreSQL releases. For example,
pg_upgrade will not work for a migration from 8.3 if a user column
is
On Mon, May 24, 2010 at 3:07 PM, Alvaro Herrera alvhe...@alvh.no-ip.org wrote:
It'd be nice to have as a side effect, but if not, IMHO this proposal
could simply use a fixed buffer pool like all other slru.c callers until
someone gets around to fixing that. Adding more GUC switches for this
On Sun, May 23, 2010 at 04:21:58PM -0400, Jan Wieck wrote:
In some systems (data warehousing, replication), the order of commits is
important, since that is the order in which changes have become visible.
This information could theoretically be extracted from the WAL, but
scanning the entire
On Mon, May 24, 2010 at 3:11 PM, Bruce Momjian br...@momjian.us wrote:
Stefan Kaltenbrunner wrote:
I have updated the paragraph to be:
Upgrading from PostgreSQL 8.3 has additional restrictions not present
when upgrading from later PostgreSQL releases. For example,
I think the current coding is extremely fragile (if it indeed works at
all) because of its assumption that limits.h has been included
Well, this is the case in the code so far.
already. In any case, we have configure tests that exist only for the
benefit of contrib modules, so it's hard to
* Michael Meskes (mes...@postgresql.org) wrote:
I think the current coding is extremely fragile (if it indeed works at
all) because of its assumption that limits.h has been included
Well, this is the case in the code so far.
Right, the existing code is after limits.h is included, my
Robert Haas wrote:
On Mon, May 24, 2010 at 3:11 PM, Bruce Momjian br...@momjian.us wrote:
Stefan Kaltenbrunner wrote:
I have updated the paragraph to be:
? ? Upgrading from PostgreSQL 8.3 has additional restrictions not present
? ? when upgrading from later PostgreSQL releases. ?For
Excerpts from Josh Berkus's message of vie may 21 17:57:35 -0400 2010:
Problem: currently, if your database has a large amount of cold data,
such as 350GB of 3-year-old sales transactions, in 8.4 vacuum no longer
needs to touch it thanks to the visibility map. However, every
freeze_age
Robert Haas wrote:
It's a tool for replication solutions to use.
I was thrown by the original post referencing data warehousing.
For replication I definitely see that it would be good to provide
some facility to grab a coherent snapshot out of the transaction
stream, but I'm still not clear
Excerpts from Robert Haas's message of vie may 21 10:20:38 -0400 2010:
Actually, there's another way we could do this. Instead of creating
pg_shared_class and pg_shared_attribute and moving all of the catalog
entries for the shared relations into those tables, we could consider
leaving the
On Mon, May 24, 2010 at 4:23 PM, Alvaro Herrera alvhe...@alvh.no-ip.org wrote:
Excerpts from Robert Haas's message of vie may 21 10:20:38 -0400 2010:
Actually, there's another way we could do this. Instead of creating
pg_shared_class and pg_shared_attribute and moving all of the catalog
On Mon, May 24, 2010 at 3:41 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, May 24, 2010 at 3:11 PM, Bruce Momjian br...@momjian.us wrote:
Stefan Kaltenbrunner wrote:
I have updated the paragraph to be:
? ? Upgrading from PostgreSQL 8.3 has additional
On Mon, May 24, 2010 at 4:03 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Robert Haas wrote:
It's a tool for replication solutions to use.
I was thrown by the original post referencing data warehousing.
For replication I definitely see that it would be good to provide
some
On 5/24/2010 12:51 PM, Kevin Grittner wrote:
Robert Haas wrote:
I think you're confusing two subtly different things.
The only thing I'm confused about is what benefit anyone expects to
get from looking at data between commits in some way other than our
current snapshot mechanism. Can
Excerpts from Robert Haas's message of lun may 24 17:18:21 -0400 2010:
On Mon, May 24, 2010 at 4:23 PM, Alvaro Herrera alvhe...@alvh.no-ip.org
wrote:
Excerpts from Robert Haas's message of vie may 21 10:20:38 -0400 2010:
Uh, how does this work when you change the entries for shared
On Mon, May 24, 2010 at 5:20 PM, Robert Haas robertmh...@gmail.com wrote:
It works OK for me. The link to /contrib/pg_upgrade within the nav
section at the top righthand corner of the page seems to work just
fine.
http://wiki.postgresql.org/wiki/Todo#.2Fcontrib.2Fpg_upgrade
The problem is
Robert Haas wrote:
On Mon, May 24, 2010 at 3:41 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, May 24, 2010 at 3:11 PM, Bruce Momjian br...@momjian.us wrote:
Stefan Kaltenbrunner wrote:
I have updated the paragraph to be:
? ? Upgrading from PostgreSQL 8.3
On 5/24/2010 3:10 PM, Dan Ports wrote:
I'm not clear on why the total rowcount is useful, but perhaps I'm
missing something obvious.
It is a glimpse into the future. Several years of pain doing replication
work has taught me that knowing approximately who much work the next
chunk will be
On Mon, May 24, 2010 at 5:38 PM, Dave Page dp...@pgadmin.org wrote:
On Mon, May 24, 2010 at 5:20 PM, Robert Haas robertmh...@gmail.com wrote:
It works OK for me. The link to /contrib/pg_upgrade within the nav
section at the top righthand corner of the page seems to work just
fine.
On Mon, May 24, 2010 at 10:24:07AM -0500, Kevin Grittner wrote:
Jan Wieck wrote:
In some systems (data warehousing, replication), the order of
commits is important, since that is the order in which changes
have become visible.
This issue intersects with the serializable work I've
(2010/05/24 22:18), Robert Haas wrote:
2010/5/24 KaiGai Koheikai...@ak.jp.nec.com:
BTW, I guess the reason why permissions on attributes are not checked here is
that we missed it at v8.4 development.
That's a little worrying. Can you construct and post a test case
where this results in a
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi wrote:
On 5/21/10 11:47 PM +0300, Jeff Davis wrote:
It also allows you to enforce the constraint that only one tuple exists
in a table by doing something like:
create table a
(
i int,
exclude using gist (i with),
On May 25, 2010, at 0:42 , Dan Ports wrote:
On Mon, May 24, 2010 at 10:24:07AM -0500, Kevin Grittner wrote:
Jan Wieck wrote:
In some systems (data warehousing, replication), the order of
commits is important, since that is the order in which changes
have become visible.
This issue
(2010/05/25 4:11), Stephen Frost wrote:
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
I'd like to point out two more points are necessary to be considered
for DML permission checks in addition to ExecCheckRTPerms().
* DoCopy()
Although DoCopy() is called from standard_ProcessUtility(), it
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
postgres=# ALTER TABLE pk_tbl OWNER TO ymj;
ALTER TABLE
postgres=# ALTER TABLE fk_tbl OWNER TO ymj;
ALTER TABLE
postgres=# REVOKE ALL ON pk_tbl, fk_tbl FROM ymj;
REVOKE
postgres=# GRANT REFERENCES ON pk_tbl, fk_tbl TO ymj;
Florian Pflug f...@phlo.org writes:
The subtle point here is whether you consider the view from the outside (in
the sense of what a read-only transaction started at an arbitrary time can or
cannot observe), or from the inside (what updating transactions can observe
and might base their
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
We have two options; If the checker function takes the list of RangeTblEntry,
it will be comfortable to ExecCheckRTPerms(), but not DoCopy(). Inversely,
if the checker function takes arguments in my patch, it will be comfortable
to DoCopy(), but
#4 is useful for some cases, but might often make the
transaction commit on the master get stuck since read-only
query can easily block recovery by the lock conflict. So
#4 seems not to be worth working on until that HS problem
has been addressed. Thought?
I agree that #4 should be done
We determined that $SUBJECT would be a good idea in this thread:
http://archives.postgresql.org/pgsql-bugs/2010-05/msg00159.php
I looked a bit at what it would take to make this happen. The
difficulty is that the input buffer is a local variable in MainLoop(),
and so are a bunch of other
On Tue, May 25, 2010 at 1:18 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I see a lot of value in #4; it makes it possible to distribute read-only
load to the standby using something like pgbouncer, completely transparently
to the application.
Agreed.
In the lesser
* Stephen Frost (sfr...@snowman.net) wrote:
Add regression testing for psql backslash commands
This patch adds rather extensive regression testing
of the psql backslash commands. Hopefully this will
minimize issues such as the one which cropped up
recently with \h
(2010/05/25 10:13), Stephen Frost wrote:
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
postgres=# ALTER TABLE pk_tbl OWNER TO ymj;
ALTER TABLE
postgres=# ALTER TABLE fk_tbl OWNER TO ymj;
ALTER TABLE
postgres=# REVOKE ALL ON pk_tbl, fk_tbl FROM ymj;
REVOKE
(2010/05/25 10:27), Stephen Frost wrote:
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
We have two options; If the checker function takes the list of RangeTblEntry,
it will be comfortable to ExecCheckRTPerms(), but not DoCopy(). Inversely,
if the checker function takes arguments in my patch, it
2010/5/24 KaiGai Kohei kai...@ak.jp.nec.com:
I think we need a new SPI_*() interface which allows to run the given query
without any permission checks, because these queries are purely internal
stuff,
so we can trust the query is harmless.
[...]
I'm afraid of that the
On Mon, May 24, 2010 at 9:27 PM, Stephen Frost sfr...@snowman.net wrote:
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
We have two options; If the checker function takes the list of RangeTblEntry,
it will be comfortable to ExecCheckRTPerms(), but not DoCopy(). Inversely,
if the checker function
On Mon, May 24, 2010 at 5:50 PM, Bruce Momjian br...@momjian.us wrote:
What is your point?
My point is that I think Stefan has a good point when he says this:
hmm that seems better thanks, however I just noticed that we don't have
a general limitations section. The way the docs are now
Stephen Frost sfr...@snowman.net writes:
... It makes me wonder if COPY shouldn't have been implemented using
the Executor instead, but that's, again, a completely separate topic.
It wasn't, but it wants to play like it operates in the same kind of way
as INSERT, so it needs to pick up the
On Sat, 2010-05-22 at 01:02 +0300, Marko Tiikkaja wrote:
On 5/21/10 11:47 PM +0300, Jeff Davis wrote:
It also allows you to enforce the constraint that only one tuple exists
in a table by doing something like:
create table a
(
i int,
exclude using gist (i with),
Robert Haas wrote:
On Mon, May 24, 2010 at 5:50 PM, Bruce Momjian br...@momjian.us wrote:
What is your point?
My point is that I think Stefan has a good point when he says this:
hmm that seems better thanks, however I just noticed that we don't
have
a general limitations
On Mon, May 24, 2010 at 10:51 PM, Stephen Frost sfr...@snowman.net wrote:
* Stephen Frost (sfr...@snowman.net) wrote:
Add regression testing for psql backslash commands
This patch adds rather extensive regression testing
of the psql backslash commands. Hopefully this will
On Mon, May 24, 2010 at 11:25 PM, Jeff Davis pg...@j-davis.com wrote:
I think the original case (same values only) is potentially useful
enough that we should support it.
+1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-hackers
On Tue, May 25, 2010 at 10:29 AM, Josh Berkus j...@agliodbs.com wrote:
I agree that #4 should be done last, but it will be needed, not in the
least by your employer ;-) . I don't see any obvious way to make #4
compatible with any significant query load on the slave, but in general
I'd think
On Mon, May 24, 2010 at 5:37 PM, Alvaro Herrera alvhe...@alvh.no-ip.org wrote:
Excerpts from Robert Haas's message of lun may 24 17:18:21 -0400 2010:
On Mon, May 24, 2010 at 4:23 PM, Alvaro Herrera alvhe...@alvh.no-ip.org
wrote:
Excerpts from Robert Haas's message of vie may 21 10:20:38
Robert Haas robertmh...@gmail.com writes:
On Mon, May 24, 2010 at 5:37 PM, Alvaro Herrera alvhe...@alvh.no-ip.org
wrote:
Excerpts from Robert Haas's message of lun may 24 17:18:21 -0400 2010:
Well, I might be missing something here, but pg_class already IS
database-specific. If you change
The note at the end of;
http://www.postgresql.org/docs/8.4/static/sql-savepoint.html
Lead us to believe that if you roll back to the same savepoint name
twice in a row, that you might start walking back through the
savepoints. I guess I missed the note on ROLLBACK TO SAVEPOINT that
that is not
On Mon, May 24, 2010 at 10:20 PM, Fujii Masao masao.fu...@gmail.com wrote:
At the first design phase, I'd like to clarify which synch levels
should be supported 9.1 and how it should be specified by users.
There is another question about synch level:
When should the master wait for
78 matches
Mail list logo
