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 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 common in
>
On 21 December 2012 08:56, Simon Riggs 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 is needed so that
On 21 December 2012 09:29, Dean Rasheed wrote:
> On 21 December 2012 08:56, Simon Riggs 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 pur
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 ke
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 Lane wrote:
Heikki Linnakangas 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 that won't start
up. Why not include the time
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 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 of th
On Thu, Dec 20, 2012 at 5:07 PM, Joshua Berkus 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 t
On Thu, Dec 20, 2012 at 4:50 PM, Kevin Grittner 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 t
On Fri, Dec 21, 2012 at 3:56 AM, Simon Riggs 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 this thread have been
On 20 December 2012 19:29, Bruce Momjian wrote:
> On Wed, Dec 19, 2012 at 10:34:14PM +, Simon Riggs wrote:
>> On 19 December 2012 22:19, Joshua Berkus wrote:
>> >
>> >> It stalled because the patch author decided not to implement the
>> >> request to detect recovery.conf in data directory, wh
On 20 December 2012 19:29, Bruce Momjian 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 for 9.3!
The m
On 21 December 2012 14:19, Robert Haas wrote:
> On Fri, Dec 21, 2012 at 3:56 AM, Simon Riggs 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
On Wed, Dec 12, 2012 at 4:47 PM, Dimitri Fontaine
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 that should applies c
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 desi
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 stri
Marko Tiikkaja 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 effectively
On 21 December 2012 14:48, Kevin Grittner 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 sam
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 STRI
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 th
Peter Eisentraut 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 currently
> stor
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 s
2012/12/21 Marko Tiikkaja :
> 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 UPDATEin
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 no
On Fri, Dec 21, 2012 at 10:39 AM, Tom Lane wrote:
>
> Marko Tiikkaja 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 thi
> -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
Marko Tiikkaja 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 too.
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 :
> Marko Tiikkaja 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
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 PL
On 12/21/12 5:22 PM, Tom Lane wrote:
Marko Tiikkaja 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
Hi,
Robert Haas 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 commands to go th
On Fri, Dec 21, 2012 at 10:25 AM, Charles Gomes 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:
>
> CREATE OR REPLACE
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 :
> Hello guys,
>
> I've been finding performance issues when us
On Fri, Dec 21, 2012 at 4:22 PM, Tom Lane 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:
http://www.postgresql.org/mailpre
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 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 where you
expect
On 12/21/2012 08:39 AM, Merlin Moncure wrote:
> On Fri, Dec 21, 2012 at 10:25 AM, Charles Gomes 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.
>>
On Fri, Dec 21, 2012 at 11:25 AM, Charles Gomes
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:
>
> CREATE OR REPLACE
2012/12/21 Tom Lane :
> Christopher Browne 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 ma
2012/12/21 Joe Conway :
> On 12/21/2012 08:39 AM, Merlin Moncure wrote:
>> On Fri, Dec 21, 2012 at 10:25 AM, Charles Gomes
>> 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
On Fri, Dec 21, 2012 at 9:21 AM, Simon Riggs 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 just implement
> 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
> mailto:charle...@
On 21 December 2012 17:12, Robert Haas wrote:
> On Fri, Dec 21, 2012 at 9:21 AM, Simon Riggs 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
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 fi
On 21 December 2012 14:09, Robert Haas wrote:
> On Thu, Dec 20, 2012 at 5:07 PM, Joshua Berkus 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 pr
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
On 8 December 2012 14:41, Andres Freund 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 patch has been re-adde
On 11 December 2012 03:01, Noah Misch 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 might get the
On 11 December 2012 13:01, Pavel Stehule 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 informations about trigge
On Wed, Dec 19, 2012 at 8:28 AM, Michael Paquier
wrote:
>
>
> On Wed, Dec 12, 2012 at 12:06 AM, Bruce Momjian 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
>> > wrote:
>> > >
>> > > Bruce mentionned that pg_isready
On Fri, Dec 21, 2012 at 4:53 PM, Tom Lane 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 add code to chec
On Fri, Dec 21, 2012 at 02:25:47PM +, Simon Riggs wrote:
> On 20 December 2012 19:29, Bruce Momjian 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 releases.
On 21 December 2012 18:13, Heikki Linnakangas wrote:
> 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
On 21 December 2012 19:21, Bruce Momjian wrote:
> On Fri, Dec 21, 2012 at 02:25:47PM +, Simon Riggs wrote:
>> On 20 December 2012 19:29, Bruce Momjian wrote:
>>
>> > At this point backward compatibility has paralyzed us from fixing a
>> > recovery.conf API that everyone agrees is non-optimal,
On Fri, Dec 21, 2012 at 07:32:48PM +, Simon Riggs wrote:
> On 21 December 2012 19:21, Bruce Momjian wrote:
> > On Fri, Dec 21, 2012 at 02:25:47PM +, Simon Riggs wrote:
> >> On 20 December 2012 19:29, Bruce Momjian wrote:
> >>
> >> > At this point backward compatibility has paralyzed us fr
On 21 December 2012 19:35, Bruce Momjian 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 will you as
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 hav
On Fri, Dec 21, 2012 at 07:43:29PM +, Simon Riggs wrote:
> On 21 December 2012 19:35, Bruce Momjian 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
On Fri, Dec 21, 2012 at 06:47:56PM +, Simon Riggs wrote:
> On 11 December 2012 03:01, Noah Misch 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 code, and it
On 21.12.2012 21:43, Simon Riggs wrote:
On 21 December 2012 19:35, Bruce Momjian 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
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 l
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 fork
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)
Hi,
On 2012-12-21 09:48:22 -0500, Robert Haas wrote:
> On Wed, Dec 12, 2012 at 4:47 PM, Dimitri Fontaine
> 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
2012/12/21 Kevin Grittner :
> 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
KaiGai, all,
* Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
> 2012/12/21 Kevin Grittner :
> > 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
On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch 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 postmaster calls
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
that
On 21 December 2012 20:10, Noah Misch 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.
The loss of
On 21 December 2012 19:46, Bruce Momjian 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 PITR and does n
On 21 December 2012 22:01, Stephen Frost 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 commands.
>
>
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 conta
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 ALTER
On Fri, Dec 21, 2012 at 6:42 PM, Tom Lane 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 by
> http://arc
On Sat, Dec 22, 2012 at 12:59:55AM +0200, Marko Kreen wrote:
> On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch 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 at 06:05:10
On Sat, Dec 22, 2012 at 12:42:43AM +, Simon Riggs wrote:
> On 21 December 2012 20:10, Noah Misch 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 on
Robert Haas 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 (x);
CREATE VIEW
regr
Noah Misch 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 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.
A slightl
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
> t
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 Lane wrote:
>> Heikki Linnakangas writes:
I'm not happy with the fact that we just ignore the problem in a backup
taken from a standby, silen
2012/12/21 Stephen Frost :
>> 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 design, sy
2012/12/22 Simon Riggs :
> On 21 December 2012 22:01, Stephen Frost 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
85 matches
Mail list logo
