On 21.12.2012 08:18, Amit Kapila wrote:
On Thursday, December 20, 2012 11:15 PM Heikki Linnakangas wrote:
On 20.12.2012 18:19, Fujii Masao wrote:
InstallXLogFileSegment() also uses ThisTimeLineID. But your recent
commit
doesn't take care of it and prevents the standby from recycling the
WAL
On 20 December 2012 19:42, Stephen Frost sfr...@snowman.net wrote:
Kevin, all,
* Kevin Grittner (kgri...@mail.com) wrote:
The more secure behavior is to allow entry of data which will not
be visible by the person doing the entry.
wrt this- I'm inclined to agree with Kevin. It's certainly
On 21 December 2012 08:56, Simon Riggs si...@2ndquadrant.com wrote:
It's unreasonable for people to demand a feature yet provide no
guidance to the person trying (hard) to provide that feature in a
sensible way. If people genuinely believe case (2) is worth pursuing,
additional work and input
On 21 December 2012 09:29, Dean Rasheed dean.a.rash...@gmail.com wrote:
On 21 December 2012 08:56, Simon Riggs si...@2ndquadrant.com wrote:
It's unreasonable for people to demand a feature yet provide no
guidance to the person trying (hard) to provide that feature in a
sensible way. If people
In order to implement the PARAMETER_DEFAULT column in the information
schema I need a way to get the expressions out of the proargdefaults
column. pg_get_expr(proargdefaults, 0) gives me all expressions
comma-separated, but I need them individually. I think a function like
pg_get_list_nth (to
On 2012-12-21 07:20:00 -0500, Peter Eisentraut wrote:
In order to implement the PARAMETER_DEFAULT column in the information
schema I need a way to get the expressions out of the proargdefaults
column. pg_get_expr(proargdefaults, 0) gives me all expressions
comma-separated, but I need them
On 17.12.2012 18:58, Magnus Hagander wrote:
On Mon, Dec 17, 2012 at 5:19 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Heikki Linnakangashlinnakan...@vmware.com writes:
I'm not happy with the fact that we just ignore the problem in a backup
taken from a standby, silently giving the user a backup
On 12/21/12 7:26 AM, Andres Freund wrote:
On 2012-12-21 07:20:00 -0500, Peter Eisentraut wrote:
In order to implement the PARAMETER_DEFAULT column in the information
schema I need a way to get the expressions out of the proargdefaults
column. pg_get_expr(proargdefaults, 0) gives me all
On Thu, Dec 20, 2012 at 5:28 PM, Joshua Berkus j...@agliodbs.com wrote:
What would such a test look like? It's not obvious to me that
there's any rapid way for a user to detect this situation, without
checking each server individually.
Change something on the master and observe that none
On Thu, Dec 20, 2012 at 5:07 PM, Joshua Berkus j...@agliodbs.com wrote:
As ever, we spent much energy on debating backwards compatibility
rather than just solving the problem it posed, which is fairly easy
to
solve.
Well, IIRC, the debate was primarily of *your* making. Almost everyone else
On Thu, Dec 20, 2012 at 4:50 PM, Kevin Grittner kgri...@mail.com wrote:
I don't think I like ALTER TABLE as a syntax for row level
security. How about using existing GRANT syntax but allowing a
WHERE clause? That seems more natural to me, and it would make it
easy to apply the same conditions
On Fri, Dec 21, 2012 at 3:56 AM, Simon Riggs si...@2ndquadrant.com wrote:
It's unreasonable for people to demand a feature yet provide no
guidance to the person trying (hard) to provide that feature in a
sensible way.
You've got it backwards. All the issues that are being discussed now
on
On 20 December 2012 19:29, Bruce Momjian br...@momjian.us wrote:
On Wed, Dec 19, 2012 at 10:34:14PM +, Simon Riggs wrote:
On 19 December 2012 22:19, Joshua Berkus j...@agliodbs.com wrote:
It stalled because the patch author decided not to implement the
request to detect recovery.conf
On 20 December 2012 19:29, Bruce Momjian br...@momjian.us wrote:
At this point backward compatibility has paralized us from fixing a
recovery.conf API that everyone agrees is non-optimal, and this has
gone on for multiple major releases. I don't care what we have to do,
just clean this up
On 21 December 2012 14:19, Robert Haas robertmh...@gmail.com wrote:
On Fri, Dec 21, 2012 at 3:56 AM, Simon Riggs si...@2ndquadrant.com wrote:
It's unreasonable for people to demand a feature yet provide no
guidance to the person trying (hard) to provide that feature in a
sensible way.
You've
On Wed, Dec 12, 2012 at 4:47 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
The previously attached patch already needs a rebase since Tom fixed the
single user mode where you're not supposed to access potentially
corrupted system indexes. Please find attached a new version of the
patch
Kohei KaiGai wrote:
I don't think I like ALTER TABLE as a syntax for row level
security. How about using existing GRANT syntax but allowing a
WHERE clause? That seems more natural to me, and it would make
it easy to apply the same conditions to multiple types of
operations when desired, but
Hi,
Courtesy of me, Christmas comes a bit early this year. I wrote a patch
which allows you to add STRICT into PERFORM and INSERT/UPDATE/DELETE
without specifying an INTO clause. Observe:
=# create table foo(a int);
CREATE TABLE
=# create function foof() returns void as $$ begin update
Marko Tiikkaja pgm...@joh.to writes:
Courtesy of me, Christmas comes a bit early this year. I wrote a patch
which allows you to add STRICT into PERFORM and INSERT/UPDATE/DELETE
without specifying an INTO clause.
What is the use-case for this? Won't this result in the word STRICT
becoming
On 21 December 2012 14:48, Kevin Grittner kgri...@mail.com wrote:
Kohei KaiGai wrote:
I don't think I like ALTER TABLE as a syntax for row level
security. How about using existing GRANT syntax but allowing a
WHERE clause? That seems more natural to me, and it would make
it easy to apply the
On 12/21/12 4:39 PM, Tom Lane wrote:
What is the use-case for this?
Currently, the way to do this would be something like:
DECLARE
_ok bool;
BEGIN
UPDATE foo .. RETURNING TRUE INTO STRICT _ok;
We have a lot of code like this, and I bet others do as well.
Won't this result in the word
On 12/21/12 4:49 PM, I wrote:
On 12/21/12 4:39 PM, Tom Lane wrote:
What is the use-case for this?
Currently, the way to do this would be something like:
I realize I didn't really answer the question.
The use case is when you're UPDATEing or DELETEing a row and you want to
quickly assert
Peter Eisentraut pete...@gmx.net writes:
On 12/21/12 7:26 AM, Andres Freund wrote:
Hm. Wouldn't it be better to create a pg_node_tree[] and use that in
pg_attribute? Its already in the variable length part of pg_proc
anyway...
That sounds like a good idea. I don't know why they are
On 12/21/12 4:49 PM, I wrote:
Won't this result in the word STRICT
becoming effectively reserved in contexts where it currently is not?
It will, which probably is not ideal if it can be avoided. I also
considered syntax like INTO STRICT NULL, but that felt a bit ugly. It
would be great if
2012/12/21 Marko Tiikkaja pgm...@joh.to:
On 12/21/12 4:49 PM, I wrote:
On 12/21/12 4:39 PM, Tom Lane wrote:
What is the use-case for this?
Currently, the way to do this would be something like:
I realize I didn't really answer the question.
The use case is when you're UPDATEing or
When there is 'ssl=on' then postmaster calls SSL_CTX_new(),
which asks for random number, thus requiring initialization
of randomness pool (RAND_poll). After that all forked backends
think pool is already initialized. Thus they proceed with same
fixed state they got from postmaster.
Output is
On Fri, Dec 21, 2012 at 10:39 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Tiikkaja pgm...@joh.to writes:
Courtesy of me, Christmas comes a bit early this year. I wrote a patch
which allows you to add STRICT into PERFORM and INSERT/UPDATE/DELETE
without specifying an INTO clause.
What
-Original Message-
From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
ow...@postgresql.org] On Behalf Of Marko Tiikkaja
Sent: Friday, December 21, 2012 10:53 AM
To: Tom Lane
Cc: PostgreSQL-development
Subject: Re: [HACKERS] PL/PgSQL STRICT
On 12/21/12 4:49 PM, I
Marko Tiikkaja pgm...@joh.to writes:
Another idea would be to force the STRICT to be immediately after
INSERT, UPDATE or DELETE.
What about before it, ie
STRICT UPDATE ...
This should dodge the problem of possible conflict with table names,
and it seems to me to read more naturally
Hello guys,
I've been finding performance issues when using a trigger to modify inserts on
a partitioned table.
If using the trigger the total time goes from 1 Hour to 4 hours.
The trigger is pretty simple:
CREATE OR REPLACE FUNCTION quotes_insert_trigger()
RETURNS trigger AS $$
BEGIN
EXECUTE
2012/12/21 Tom Lane t...@sss.pgh.pa.us:
Marko Tiikkaja pgm...@joh.to writes:
Another idea would be to force the STRICT to be immediately after
INSERT, UPDATE or DELETE.
What about before it, ie
STRICT UPDATE ...
This should dodge the problem of possible conflict with table names,
On 12/21/12 5:09 PM, Christopher Browne wrote:
I could use GET DIAGNOSTICS to determine if nothing got altered, and
it seems likely to me that expressly doing this via IF/ELSE/END IF would
be easier to read in function code than a somewhat magic STRICT
side-effect.
STRICT is used in INTO, so
On 12/21/12 5:22 PM, Tom Lane wrote:
Marko Tiikkaja pgm...@joh.to writes:
Another idea would be to force the STRICT to be immediately after
INSERT, UPDATE or DELETE.
What about before it, ie
STRICT UPDATE ...
This should dodge the problem of possible conflict with table names,
and
Hi,
Robert Haas robertmh...@gmail.com writes:
Sorry for the delay - I'm looking at this now.
Thanks very much!
My first observation (a.k.a. gripe) is this patch touches an awful lot
of code all over the backend. We just did a big old refactoring to
try to get all the rename and alter owner
On Fri, Dec 21, 2012 at 10:25 AM, Charles Gomes charle...@outlook.com wrote:
Hello guys,
I've been finding performance issues when using a trigger to modify inserts
on a partitioned table.
If using the trigger the total time goes from 1 Hour to 4 hours.
The trigger is pretty simple:
Hello
you can find lot of examples in PostgreSQL source code - see
postgresql/contrib/spi directory
and documentation http://www.postgresql.org/docs/9.0/static/trigger-example.html
Regards
Pavel Stehule
2012/12/21 Charles Gomes charle...@outlook.com:
Hello guys,
I've been finding
On Fri, Dec 21, 2012 at 4:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
What about before it, ie
STRICT UPDATE ...
+1 from me too.
This feature would be awesome.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Simon Riggs wrote:
Each table has a single security clause. The clause doesn't enforce
that it must contain something that depends on role, but that is the
most easily understood usage of it. We do that to ensure that you can
embed the intelligence into a function, say hasRowLevelAccess(),
Christopher Browne cbbro...@gmail.com writes:
This is adding specific syntax for what seems like an unusual case to me,
which seems like an unworthwhile complication.
That was my first reaction too, but Marko's followon examples seem to
make a reasonable case for it. There are many situations
On 12/21/2012 08:39 AM, Merlin Moncure wrote:
On Fri, Dec 21, 2012 at 10:25 AM, Charles Gomes charle...@outlook.com wrote:
Hello guys,
I've been finding performance issues when using a trigger to modify inserts
on a partitioned table.
If using the trigger the total time goes from 1 Hour to
On Fri, Dec 21, 2012 at 11:25 AM, Charles Gomes charle...@outlook.com
wrote:
Hello guys,
I've been finding performance issues when using a trigger to modify
inserts on a partitioned table.
If using the trigger the total time goes from 1 Hour to 4 hours.
The trigger is pretty simple:
2012/12/21 Tom Lane t...@sss.pgh.pa.us:
Christopher Browne cbbro...@gmail.com writes:
This is adding specific syntax for what seems like an unusual case to me,
which seems like an unworthwhile complication.
That was my first reaction too, but Marko's followon examples seem to
make a
2012/12/21 Joe Conway m...@joeconway.com:
On 12/21/2012 08:39 AM, Merlin Moncure wrote:
On Fri, Dec 21, 2012 at 10:25 AM, Charles Gomes charle...@outlook.com
wrote:
Hello guys,
I've been finding performance issues when using a trigger to modify inserts
on a partitioned table.
If using
On Fri, Dec 21, 2012 at 9:21 AM, Simon Riggs si...@2ndquadrant.com wrote:
No, lets not.
The only stall happening is because of a refusal to listen to another
person's reasonable request during patch review. That requirement is
not a blocker to the idea, it just needs to be programmed.
Lets
Date: Fri, 21 Dec 2012 11:56:25 -0500
Subject: Re: [HACKERS] Writing Trigger Functions in C
From: cbbro...@gmail.com
To: charle...@outlook.com
CC: pgsql-hackers@postgresql.org
On Fri, Dec 21, 2012 at 11:25 AM, Charles Gomes
On 21 December 2012 17:12, Robert Haas robertmh...@gmail.com wrote:
On Fri, Dec 21, 2012 at 9:21 AM, Simon Riggs si...@2ndquadrant.com wrote:
No, lets not.
The only stall happening is because of a refusal to listen to another
person's reasonable request during patch review. That requirement
The PL/Python build on OS X is currently hardcoded to use the system
Python install. If you try to override this when running configure, you
get a mysterious mix-and-match build. If you want to build against your
own Python build, or MacPorts or Homebrew, you can't.
This is straightforward to
On 21 December 2012 14:09, Robert Haas robertmh...@gmail.com wrote:
On Thu, Dec 20, 2012 at 5:07 PM, Joshua Berkus j...@agliodbs.com wrote:
As ever, we spent much energy on debating backwards compatibility
rather than just solving the problem it posed, which is fairly easy
to
solve.
Well,
On 21.12.2012 01:50, Thom Brown wrote:
Now I'm getting this on all standbys after promoting the first standby in a
chain.
...
TRAP: FailedAssertion(!(((sentPtr)= (SendRqstPtr))), File:
walsender.c, Line: 1425)
Sigh. I'm sounding like a broken record, but I just committed another
fix for
On 8 December 2012 14:41, Andres Freund and...@2ndquadrant.com wrote:
Is anybody planning to work on this? There hasn't been any activity
since the beginning of the CF and it doesn't look like there is much
work left?
I took another look at this.
The growmemtuples bool from Jeff's original
On 11 December 2012 03:01, Noah Misch n...@leadboat.com wrote:
On Mon, Dec 10, 2012 at 08:04:55PM -0500, Robert Haas wrote:
I think the current behavior, where we treat FREEZE as a hint, is just
awful. Regardless of whether the behavior is automatic or manually
requested, the idea that you
On 11 December 2012 13:01, Pavel Stehule pavel.steh...@gmail.com wrote:
There are two basic aspects of design
* usability - we would to remove necessity of parsing error messages
for getting interesting data, it decrease dependency on current error
messages - then I am thinking so some
On Wed, Dec 19, 2012 at 8:28 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Wed, Dec 12, 2012 at 12:06 AM, Bruce Momjian br...@momjian.us wrote:
On Sat, Dec 8, 2012 at 08:59:00AM -0500, Phil Sorber wrote:
On Sat, Dec 8, 2012 at 7:50 AM, Michael Paquier
michael.paqu...@gmail.com
On Fri, Dec 21, 2012 at 4:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
That was my first reaction too, but Marko's followon examples seem to
make a reasonable case for it. There are many situations where you
expect an UPDATE or DELETE to hit exactly one row. Often, programmers
won't bother to
On Fri, Dec 21, 2012 at 02:25:47PM +, Simon Riggs wrote:
On 20 December 2012 19:29, Bruce Momjian br...@momjian.us wrote:
At this point backward compatibility has paralyzed us from fixing a
recovery.conf API that everyone agrees is non-optimal, and this has
gone on for multiple major
On 21 December 2012 18:13, Heikki Linnakangas hlinnakan...@vmware.comwrote:
On 21.12.2012 01:50, Thom Brown wrote:
Now I'm getting this on all standbys after promoting the first standby in
a
chain.
...
TRAP: FailedAssertion(!(((sentPtr)**= (SendRqstPtr))), File:
walsender.c, Line:
On 21 December 2012 19:21, Bruce Momjian br...@momjian.us wrote:
On Fri, Dec 21, 2012 at 02:25:47PM +, Simon Riggs wrote:
On 20 December 2012 19:29, Bruce Momjian br...@momjian.us wrote:
At this point backward compatibility has paralyzed us from fixing a
recovery.conf API that everyone
On Fri, Dec 21, 2012 at 07:32:48PM +, Simon Riggs wrote:
On 21 December 2012 19:21, Bruce Momjian br...@momjian.us wrote:
On Fri, Dec 21, 2012 at 02:25:47PM +, Simon Riggs wrote:
On 20 December 2012 19:29, Bruce Momjian br...@momjian.us wrote:
At this point backward compatibility
On 21 December 2012 19:35, Bruce Momjian br...@momjian.us wrote:
It's not too complex. You just want that to be true. The original
developer has actually literally gone away, but not because of this.
Well, Robert and I remember it differently.
Anyway, I will ask for a vote now.
And what
There has been discussion in the past of removing or significantly
changing the way streaming replication/point-in-time-recovery (PITR) is
setup in Postgres. Currently the file recovery.conf is used, but that
was designed for PITR and does not serve streaming replication well.
This all should
On Fri, Dec 21, 2012 at 07:43:29PM +, Simon Riggs wrote:
On 21 December 2012 19:35, Bruce Momjian br...@momjian.us wrote:
It's not too complex. You just want that to be true. The original
developer has actually literally gone away, but not because of this.
Well, Robert and I
On Fri, Dec 21, 2012 at 06:47:56PM +, Simon Riggs wrote:
On 11 December 2012 03:01, Noah Misch n...@leadboat.com wrote:
Until these threads, I did not know that a relcache invalidation could trip
up
the WAL avoidance optimization, and now this. I poked at the relevant
relcache.c
On 21.12.2012 21:43, Simon Riggs wrote:
On 21 December 2012 19:35, Bruce Momjianbr...@momjian.us wrote:
It's not too complex. You just want that to be true. The original
developer has actually literally gone away, but not because of this.
Well, Robert and I remember it differently.
Anyway,
On 12/21/2012 11:56 AM, Bruce Momjian wrote:
That is where we are now. Overhauling recovery.conf can't be a
super-complex job, and we already have a patch we can base it of off.
Why is this not done yet! I don't know, but I have seen lots of
discussion about it, and no clear conclusions, at
This should have gone to secur...@postgresql.org, instead.
On Fri, Dec 21, 2012 at 06:05:10PM +0200, Marko Kreen wrote:
When there is 'ssl=on' then postmaster calls SSL_CTX_new(),
which asks for random number, thus requiring initialization
of randomness pool (RAND_poll). After that all forked
On 2012-10-30 21:16:07 +0100, Christian Kruse wrote:
+static long
+InternalGetHugepageSize()
+{
+ DIR *dir = opendir(HUGE_PAGE_INFO_DIR);
+ long smallest_size = -1, size;
+ char *ptr;
...
+ while((ent = readdir(dir)) != NULL)
+ {
This should be (Allocate|Read)Dir btw.
Hi,
On 2012-12-21 09:48:22 -0500, Robert Haas wrote:
On Wed, Dec 12, 2012 at 4:47 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
The previously attached patch already needs a rebase since Tom fixed the
single user mode where you're not supposed to access potentially
corrupted system
2012/12/21 Kevin Grittner kgri...@mail.com:
Simon Riggs wrote:
Each table has a single security clause. The clause doesn't enforce
that it must contain something that depends on role, but that is the
most easily understood usage of it. We do that to ensure that you can
embed the intelligence
KaiGai, all,
* Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
2012/12/21 Kevin Grittner kgri...@mail.com:
Simon Riggs wrote:
Each table has a single security clause. The clause doesn't enforce
that it must contain something that depends on role, but that is the
most easily understood usage
On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch n...@leadboat.com wrote:
This should have gone to secur...@postgresql.org, instead.
It went and this could have been patched in 9.2.2 but they did not care.
On Fri, Dec 21, 2012 at 06:05:10PM +0200, Marko Kreen wrote:
When there is 'ssl=on' then
In commit 11e131854f8231a21613f834c40fe9d046926387 we rearranged
ruleutils.c's handling of relation aliases to ensure that views can
always be dumped and reloaded even in the face of confusing table
renamings. I was reminded by
http://archives.postgresql.org/pgsql-general/2012-12/msg00654.php
On 21 December 2012 20:10, Noah Misch n...@leadboat.com wrote:
I thought of one case where we do currently forget rd_newRelfilenodeSubid:
BEGIN;
TRUNCATE t;
SAVEPOINT save;
TRUNCATE t;
ROLLBACK TO save;
That's a weird one. Aborting a subtransacton that sets it, when it was
already set.
On 21 December 2012 19:46, Bruce Momjian br...@momjian.us wrote:
There has been discussion in the past of removing or significantly
changing the way streaming replication/point-in-time-recovery (PITR) is
setup in Postgres. Currently the file recovery.conf is used, but that
was designed for
On 21 December 2012 22:01, Stephen Frost sfr...@snowman.net wrote:
On the other hand, we are standing next to the consensus about
reader-side; a unique row-security policy (so, first version does not
support per-command policy) shall be checked on table scanning
on select, update or delete
Simon,
* Simon Riggs (si...@2ndquadrant.com) wrote:
Would anybody like to discuss this on a conference call on say 28th
Dec, to see if we can agree a way forwards? I feel certain that we can
work through any difficulties and agree a minimal subset for change.
All comers welcome, just contact
S1:
rhaas=# create table foo (a int);
CREATE TABLE
rhaas=# begin;
BEGIN
rhaas=# lock foo;
LOCK TABLE
S2:
rhaas=# grant all on foo to public;
GRANT
rhaas=# revoke all on foo from public;
REVOKE
This seems quite obviously silly, given the amount of time and energy
we've spent worrying about
On Fri, Dec 21, 2012 at 6:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In commit 11e131854f8231a21613f834c40fe9d046926387 we rearranged
ruleutils.c's handling of relation aliases to ensure that views can
always be dumped and reloaded even in the face of confusing table
renamings. I was reminded
On Sat, Dec 22, 2012 at 12:59:55AM +0200, Marko Kreen wrote:
On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch n...@leadboat.com wrote:
This should have gone to secur...@postgresql.org, instead.
It went and this could have been patched in 9.2.2 but they did not care.
Ah.
On Fri, Dec 21, 2012
On Sat, Dec 22, 2012 at 12:42:43AM +, Simon Riggs wrote:
On 21 December 2012 20:10, Noah Misch n...@leadboat.com wrote:
I thought of one case where we do currently forget rd_newRelfilenodeSubid:
BEGIN;
TRUNCATE t;
SAVEPOINT save;
TRUNCATE t;
ROLLBACK TO save;
That's a weird
Robert Haas robertmh...@gmail.com writes:
I'm having a hard time following this. Can you provide a concrete example?
regression=# create table t1 (x int, y int);
CREATE TABLE
regression=# create table t2 (x int, z int);
CREATE TABLE
regression=# create view v1 as select * from t1 join t2 using
Noah Misch n...@leadboat.com writes:
On Sat, Dec 22, 2012 at 12:59:55AM +0200, Marko Kreen wrote:
On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch n...@leadboat.com wrote:
This should have gone to secur...@postgresql.org, instead.
It went and this could have been patched in 9.2.2 but they did
On Fri, Dec 21, 2012 at 10:05:30PM -0500, Tom Lane wrote:
This new patch looks pretty reasonable from here,
modulo the question of whether it adds enough entropy.
More brains reviewing that question will be good.
I'm not entirely sold on whether it does. ISTM that any attack based on
this
On Friday, December 21, 2012 6:24 PM Heikki Linnakangas wrote:
On 17.12.2012 18:58, Magnus Hagander wrote:
On Mon, Dec 17, 2012 at 5:19 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Heikki Linnakangashlinnakan...@vmware.com writes:
I'm not happy with the fact that we just ignore the problem in a
2012/12/21 Stephen Frost sfr...@snowman.net:
It seems to me we need some more discussion about design and
implementation on row-security checks of writer-side, to reach our
consensus.
Again, I agree with Kevin on this- there should be a wiki or similar
which actually outlines the high-level
2012/12/22 Simon Riggs si...@2ndquadrant.com:
On 21 December 2012 22:01, Stephen Frost sfr...@snowman.net wrote:
On the other hand, we are standing next to the consensus about
reader-side; a unique row-security policy (so, first version does not
support per-command policy) shall be checked on
85 matches
Mail list logo
