On Tue, Feb 17, 2015 at 6:34 AM, Peter Eisentraut wrote:
>> This patch been reviewed by 4 people, resulting in 2 minor suggestions
>> for changes (adding an m modifier, and removing a bogus last).
>>
>> It has 2 clear upvotes and 0 downvotes.
>>
>> I think it should be revised along the lines sugg
On Wed, Feb 18, 2015 at 10:06 AM, Michael Paquier wrote:
> Yes, the existing assertion is right. My point is that it is strange
> that we do not check the values of freeze parameters for an ANALYZE
> query, which should be set to -1 all the time. If this is thought as
> not worth checking, I'll dro
At 2015-02-17 13:01:46 -0500, sfr...@snowman.net wrote:
>
> I have to admit that I'm confused by this. Patches don't stabilise
> through sitting in the archives, they stabilise when the comments are
> being addressed, the patch updated, and further comments are
> addressing less important issues.
On Wed, Feb 18, 2015 at 9:06 AM, James Sewell
wrote:
> I've just noticed something in the Commit fest post
> - Reducing lock strength of trigger and foreign key DDL
>
This reduces the lock taken for ADD FOREIGN KEY to ShareRowExclusiveLock,
authorizing SELECT and SELECT FOR [SHARE | UPDATE ... ]
On 18/02/15 02:59, Petr Jelinek wrote:
On 17/02/15 23:11, Robert Haas wrote:
On Sun, Feb 15, 2015 at 1:40 PM, Petr Jelinek
wrote:
sending new version that is updated along the lines of what we
discussed at
FOSDEM, which means:
- back to single bytea amdata column (no custom columns)
Well,
On 17/02/15 23:11, Robert Haas wrote:
On Sun, Feb 15, 2015 at 1:40 PM, Petr Jelinek wrote:
sending new version that is updated along the lines of what we discussed at
FOSDEM, which means:
- back to single bytea amdata column (no custom columns)
Well, the main argument is still future possi
Hi,
I looked at the patch and have several comments.
First let me say that modifying the individual paths of the json is the
feature I miss the most in the current implementation so I am happy that
this patch was submitted.
I would prefer slightly the patch split into two parts, one for the
On 1/20/15 6:32 PM, David G Johnston wrote:
> In fact, as far as
> the database knows, the values provided to this function do represent an
> entire population and such a correction would be unnecessary. I guess it
> boils down to whether "future" queries are considered part of the population
> or
On Wed, Feb 18, 2015 at 12:09 AM, Robert Haas wrote:
> On Thu, Feb 12, 2015 at 11:54 PM, Michael Paquier
> wrote:
>> Hi all,
>>
>> When calling vacuum(), there is the following assertion using VACOPT_FREEZE:
>> Assert((vacstmt->options & VACOPT_VACUUM) ||
>> !(vacstmt->options & (VACOPT_FULL
Michael Paquier wrote:
> On Wed, Feb 18, 2015 at 9:54 AM, Alvaro Herrera
> wrote:
> > Michael Paquier wrote:
> >> On Wed, Feb 18, 2015 at 5:55 AM, Corey Huinker
> >> wrote:
> >> > What is required to get the New Patch superpower? I'm also in need of it.
> >>
> >> CCing Magnus... I am not sure my
On Wed, Feb 18, 2015 at 9:54 AM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
>> On Wed, Feb 18, 2015 at 5:55 AM, Corey Huinker
>> wrote:
>> > What is required to get the New Patch superpower? I'm also in need of it.
>>
>> CCing Magnus... I am not sure myself, but I would imagine that the
>> c
Michael Paquier wrote:
> On Wed, Feb 18, 2015 at 5:55 AM, Corey Huinker
> wrote:
> > What is required to get the New Patch superpower? I'm also in need of it.
>
> CCing Magnus... I am not sure myself, but I would imagine that the
> commit fest needs to be "Open" and not "In Process" to be able t
* Jim Nasby (jim.na...@bluetreble.com) wrote:
> On 2/17/15 1:10 PM, Stephen Frost wrote:
> >>What I'd prefer to see is a way to decouple the OS account from any
> >>>DB account. Clearly that doesn't protect us from the OS user doing
> >>>something bad, but at least then there's no way for them to j
Oh,
I've just noticed something in the Commit fest post
- Reducing lock strength of trigger and foreign key DDL
Perhaps I just need to be more patient.
Cheers,
James Sewell,
Solutions Architect
__
Level 2, 50 Queen St, Melbourne VIC 3000
*P *(+61) 3 83
Hello all,
When I add a FK with a statement like this:
ALTER TABLE a ADD FOREIGN KEY (id) REFERENCES b(id);
I see a lock on table b:
select locktype,mode,granted from pg_locks, pg_stat_activity where
relation::regclass::text = 'b' AND pg_locks.pid = pg_stat_activity.pid;
locktype | relation
mo
On 2/17/15 4:39 PM, Oskari Saarenmaa wrote:
10.06.2013, 17:51, Dimitri Fontaine kirjoitti:
Andres Freund writes:
In any case, no packager is going to ship an insecure-by-default
configuration, which is what Dimitri seems to be fantasizing would
happen. It would have to be local option to rela
On 2/17/15 1:10 PM, Stephen Frost wrote:
What I'd prefer to see is a way to decouple the OS account from any
>DB account. Clearly that doesn't protect us from the OS user doing
>something bad, but at least then there's no way for them to just
>silently run SQL commands.
If the DB account isn't a
On Wed, Feb 18, 2015 at 5:55 AM, Corey Huinker wrote:
> What is required to get the New Patch superpower? I'm also in need of it.
CCing Magnus... I am not sure myself, but I would imagine that the
commit fest needs to be "Open" and not "In Process" to be able to add
patches.
--
Michael
--
Sen
Etsuro Fujita writes:
> On 2015/02/10 14:49, Etsuro Fujita wrote:
>> On 2015/02/07 1:09, Tom Lane wrote:
>>> I think your basic idea of preserving the original parent table's relid
>>> is correct; but instead of doing it like this patch does, I'd be inclined
>>> to make ModifyTable inherit from Sc
* Stephen Frost (sfr...@snowman.net) wrote:
> Thanks for the review and comments. I'll remove the extraneous #define,
> the comment change which was made to the other #define (as it's not
> relevant since the #define is only located in one place) and fix the
> regression test comments to match the
Etsuro,
* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
> On 2015/02/11 4:06, Stephen Frost wrote:
> >I had been trying to work out an FDW-specific way to address this, but I
> >think Dean's right that this should be addressed in
> >expand_security_qual(), which means it'll apply to all cases
10.06.2013, 17:51, Dimitri Fontaine kirjoitti:
> Andres Freund writes:
>>> In any case, no packager is going to ship an insecure-by-default
>>> configuration, which is what Dimitri seems to be fantasizing would
>>> happen. It would have to be local option to relax the permissions
>>> on the direc
On Sun, Feb 15, 2015 at 1:40 PM, Petr Jelinek wrote:
> sending new version that is updated along the lines of what we discussed at
> FOSDEM, which means:
>
> - back to single bytea amdata column (no custom columns)
Why?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Pos
On 02/17/2015 02:56 PM, Alexander Korotkov wrote:
Hi!
On Mon, Dec 22, 2014 at 1:07 PM, Heikki Linnakangas
wrote:
Ok, thanks for the review! I have committed this, with some cleanup and
more comments added.
ISTM that checks in pairingheap_GISTSearchItem_cmp is incorrect. This
function shoul
What is required to get the New Patch superpower? I'm also in need of it.
On Mon, Feb 16, 2015 at 6:59 PM, Kouhei Kaigai wrote:
> > On Tue, Feb 17, 2015 at 8:50 AM, Kouhei Kaigai
> wrote:
> > >> > I couldn't find operation to add new entry on the current CF.
> > >>
> > >> Go to the bottom of th
* Jim Nasby (jim.na...@bluetreble.com) wrote:
> On 2/17/15 12:50 PM, Stephen Frost wrote:
> >* Jim Nasby (jim.na...@bluetreble.com) wrote:
> >>We may need to bite the bullet and allow changing the user that the
> >>postgres process runs under so it doesn't match who owns the files.
> >>Maybe there'
On 2/17/15 12:50 PM, Stephen Frost wrote:
Jim,
* Jim Nasby (jim.na...@bluetreble.com) wrote:
We may need to bite the bullet and allow changing the user that the
postgres process runs under so it doesn't match who owns the files.
Maybe there's a way to allow that other than having the process
st
Jim,
* Jim Nasby (jim.na...@bluetreble.com) wrote:
> We may need to bite the bullet and allow changing the user that the
> postgres process runs under so it doesn't match who owns the files.
> Maybe there's a way to allow that other than having the process
> start as root.
That's an interesting t
On 2/17/15 10:23 AM, Simon Riggs wrote:
> I vote to include pgaudit in 9.5, albeit with any changes. In
> particular, David may have some changes to recommend, but I haven't
> seen a spec or a patch, just a new version of code (which isn't how we
> do things...).
I submitted the new patch in my na
On 2/17/15 12:23 PM, Stephen Frost wrote:
* Jim Nasby (jim.na...@bluetreble.com) wrote:
On 2/17/15 12:07 PM, Stephen Frost wrote:
I agree that it's not the auditing job to stop or control access to
data, but it's not so simple to audit the superuser completely. The
issue is that even if you ha
* Jim Nasby (jim.na...@bluetreble.com) wrote:
> On 2/17/15 12:07 PM, Stephen Frost wrote:
> >I agree that it's not the auditing job to stop or control access to
> >data, but it's not so simple to audit the superuser completely. The
> >issue is that even if you have a hard-coded bit in the binary w
On 2/17/15 12:07 PM, Stephen Frost wrote:
My views are from working with FDA validated environments, and I don’t really
understand the above. It is not db auditing’s job to stop or control the
access to data or to log what happens to data outside of PostgreSQL. To audit
a db superuser is ver
Andres Freund writes:
> On 2015-02-14 14:10:53 -0500, Tom Lane wrote:
>> Andres Freund writes:
>>> If you just gdb into the VACUUM process with 6647248e370884 checked out,
>>> and do a PGSemaphoreUnlock(&MyProc->sem) you'll hit it as well. I think
>>> we should simply move the buf->flags &= ~BM_P
Neil,
* Neil Tiffin (ne...@neiltiffin.com) wrote:
> > On Feb 17, 2015, at 3:40 AM, Yeb Havinga wrote:
> > Auditing superuser access means auditing beyond the running database.
> > The superuser can dump a table, and pipe this data everywhere outside of
> > the auditing domain. I cannot begin to i
* Simon Riggs (si...@2ndquadrant.com) wrote:
> David's work is potentially useful, but having two versions of a
> feature slows things down. Since he is new to development here, I have
> made those comments so he understands, not so you would pick up on
> that.
I have a bad tendency of replying to
On 2/16/15 9:43 PM, Kyotaro HORIGUCHI wrote:
Hello, I had a look on gram.y and found other syntaxes using WITH
option clause.
At Wed, 11 Feb 2015 14:34:17 -0600, Jim Nasby wrote
in<54dbbcc9.1020...@bluetreble.com>
>I suspect at least some of this stems from how command line programs
>tend to
> On Feb 17, 2015, at 3:40 AM, Yeb Havinga wrote:
>
> Hi list,
>
. . . . .
> Auditing superuser access means auditing beyond the running database.
> The superuser can dump a table, and pipe this data everywhere outside of
> the auditing domain. I cannot begin to imagine the kind of security
>
On 2015-02-14 14:10:53 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I don't think it's actually 675333 at fault here. I think it's a
> > long standing bug in LockBufferForCleanup() that can just much easier be
> > hit with the new interrupt code.
>
> > Imagine what happens in LockBufferForC
At 2015-02-17 10:52:55 -0500, sfr...@snowman.net wrote:
>
> From the old thread, David had offered to submit a pull request if
> there was interest and I didn't see any response...
For whatever it's worth, that's because I've been away from work, and
only just returned. I had it on my list to look
On 17 February 2015 at 15:52, Stephen Frost wrote:
> * Simon Riggs (si...@2ndquadrant.com) wrote:
>> I vote to include pgaudit in 9.5, albeit with any changes. In
>> particular, David may have some changes to recommend, but I haven't
>> seen a spec or a patch, just a new version of code (which isn
On 2015-02-11 15:49:17 -0500, Robert Haas wrote:
> On Tue, Feb 10, 2015 at 3:56 PM, Andres Freund wrote:
> >> On Tue, Feb 10, 2015 at 9:08 AM, Andres Freund
> >> wrote:
> >> > And good chunk sizes et al depend on higher layers,
> >> > selectivity estimates and such. And that's planner/executor w
On 2015-02-11 13:59:04 -0500, Robert Haas wrote:
> On Tue, Feb 10, 2015 at 8:45 PM, Andres Freund wrote:
> > The only reason I'd like it to be active is because that'd *prohibit*
> > doing the crazier stuff. There seems little reason to not da it under
> > the additional protection against crazy t
* Simon Riggs (si...@2ndquadrant.com) wrote:
> I vote to include pgaudit in 9.5, albeit with any changes. In
> particular, David may have some changes to recommend, but I haven't
> seen a spec or a patch, just a new version of code (which isn't how we
> do things...).
Hrm. I thought David's new p
On 17/02/15 16:12, Andres Freund wrote:
On 2015-02-17 15:50:39 +0100, Petr Jelinek wrote:
On 17/02/15 03:07, Petr Jelinek wrote:
On 17/02/15 03:03, Andrew Dunstan wrote:
On 02/16/2015 08:57 PM, Andrew Dunstan wrote:
Average of 3 runs of read-only pgbench on my system all with
pg_stat_statemen
On Sat, Feb 14, 2015 at 10:18 PM, Peter Eisentraut wrote:
> When managing configuration changes through automatic systems like Chef
> or Puppet, there is a problem: How do you manage changes requiring a
> restart?
>
> Generally, you'd set it up so that when a configuration file is changed,
> the s
David,
I've CC'd Abhijit, the original author of pgaudit, as it seems likely
he'd also be interested in this.
* David Steele (da...@pgmasters.net) wrote:
> I've posted a couple of messages over the last few weeks about the work
> I've been doing on the pg_audit extension. The lack of response co
On Thu, Feb 12, 2015 at 9:31 AM, Marco Nenciarini
wrote:
> Il 02/02/15 21:48, Robert Haas ha scritto:
>> On Sat, Jan 31, 2015 at 8:28 AM, Marco Nenciarini
>> wrote:
>>> Il 30/01/15 03:54, Michael Paquier ha scritto:
On Fri, Jan 30, 2015 at 2:49 AM, Tom Lane wrote:
> There is at least on
I'd like to remind "Be Early" advice for GSoC students.
http://www.postgresql.org/developer/summerofcodeadvice/
Students which starts discussion of their project early have much more
chances to show favourable sides of their proposals. As result they have
more chances to get proposals accepted.
--
On 17 February 2015 at 14:44, Stephen Frost wrote:
>> The patch as it is, is targeted at auditing user/application level
>> access to the database, and as such it matches the use case of auditing
>> user actions.
>
> Right, and that's a *very* worthwhile use-case.
Agreed.
So, we are still at th
On Thu, Feb 12, 2015 at 11:54 PM, Michael Paquier
wrote:
> Hi all,
>
> When calling vacuum(), there is the following assertion using VACOPT_FREEZE:
> Assert((vacstmt->options & VACOPT_VACUUM) ||
> !(vacstmt->options & (VACOPT_FULL | VACOPT_FREEZE)));
> I think that this should be changed with
On 2015-02-17 15:50:39 +0100, Petr Jelinek wrote:
> On 17/02/15 03:07, Petr Jelinek wrote:
> >On 17/02/15 03:03, Andrew Dunstan wrote:
> >>On 02/16/2015 08:57 PM, Andrew Dunstan wrote:
> Average of 3 runs of read-only pgbench on my system all with
> pg_stat_statement activated:
> HEAD:
On 2015-02-17 12:18:41 +0900, Fujii Masao wrote:
> On Fri, Feb 13, 2015 at 9:18 AM, Andres Freund wrote:
> > On 2015-02-12 11:44:05 -0800, Sergey Konoplev wrote:
> >> On Thu, Feb 12, 2015 at 11:40 AM, Andres Freund
> >> wrote:
> >> > This obviously should not be the case. I'll have a look in a c
On 17/02/15 03:07, Petr Jelinek wrote:
On 17/02/15 03:03, Andrew Dunstan wrote:
On 02/16/2015 08:57 PM, Andrew Dunstan wrote:
On 02/16/2015 08:48 PM, Petr Jelinek wrote:
On 17/02/15 01:57, Peter Geoghegan wrote:
On Mon, Feb 16, 2015 at 4:44 PM, Petr Jelinek
wrote:
We definitely want this
Yeb,
* Yeb Havinga (yebhavi...@gmail.com) wrote:
> On 20/01/15 23:03, Jim Nasby wrote:> On 1/20/15 2:20 PM, Robert Haas wrote:
> > +1. In particular I'm very concerned with the idea of doing this via
> > roles, because that would make it trivial for any superuser to disable
> > auditing.
>
> Reje
17.02.2015, 15:46, Andres Freund kirjoitti:
> On 2015-02-17 15:41:45 +0200, Oskari Saarenmaa wrote:
>> 15.01.2015, 21:58, Robert Haas kirjoitti:
>>> On Wed, Jan 14, 2015 at 5:54 PM, Andres Freund
>>> wrote:
I think I'd for now simply not define pg_attribute_aligned() on
platforms where
On 2/17/15 4:40 AM, Yeb Havinga wrote:
> On 20/01/15 23:03, Jim Nasby wrote:> On 1/20/15 2:20 PM, Robert Haas wrote:
>>> On Tue, Jan 20, 2015 at 1:05 AM, Abhijit
>>> Menon-Sen wrote:
> So when I'm trying to decide what to audit, I have to:
>
> (a) check if the current user is menti
On 2015-02-17 15:41:45 +0200, Oskari Saarenmaa wrote:
> 15.01.2015, 21:58, Robert Haas kirjoitti:
> > On Wed, Jan 14, 2015 at 5:54 PM, Andres Freund
> > wrote:
> >> I think I'd for now simply not define pg_attribute_aligned() on
> >> platforms where it's not supported, instead of defining it empt
On Tue, Jan 20, 2015 at 8:06 PM, Gilles Darold wrote:
> Le 19/01/2015 14:41, Robert Haas a écrit :
>> On Thu, Jan 15, 2015 at 6:26 AM, Gilles Darold
>> wrote:
>>> I attach a patch that solves the issue in pg_dump, let me know if it might
>>> be included in Commit Fest or if the three other solut
Slight typo on my local host example there. s/clone/local/
More like the below:
CREATE FOREIGN TABLE IF NOT EXISTS live.devices (
device_id bigint NOT NULL
);
CREATE MATERIALISED VIEW local.devices;
CREATE test_table (device_id bigint FOREIGN KEY (device_id) REFERENCES
*local*.devic
On Sun, Feb 15, 2015 at 2:08 PM, Alexander Korotkov
wrote:
> Following changes has been made in attached patch:
>
> * Get sort operators from pathkeys.
> * Recheck argument of distance function has been reverted.
>
Few comments were added and pairing heap comparison function was fixed in
attac
Hi all,
Not sure if this has been reported already, it seems to be a variation on
this thread:
http://www.postgresql.org/message-id/20130515151059.go4...@tamriel.snowman.net
One minor difference is, in my scenario - my source table field is defined
as BIGINT (not serial) - though it does have a
Hi!
On Mon, Dec 22, 2014 at 1:07 PM, Heikki Linnakangas wrote:
> Ok, thanks for the review! I have committed this, with some cleanup and
> more comments added.
>
ISTM that checks in pairingheap_GISTSearchItem_cmp is incorrect. This
function should perform inverse comparison. Thus, if item a sho
Hello, thank you for the comment.
The current patch lacks change in documentation and dependency
stuff. Current framework doesn't consider changing pg_shdepend
from column default expressions so the possible measures are the
followings, I think.
1. Make pg_shdepend to have refobjsubid and add som
Thank you for the comment. Three new patches are attached. I
forgot to give a revision number on the previous patch, but I
think this is the 2nd version.
1. walrcv_reply_fix_94_v2.patch
Walreceiver patch applyable on master/REL9_4_STBLE/REL9_3_STABLE
2. walrcv_reply_fix_92_v2.patch
Walrecei
>?6?9Jim Nasby writes:
> On 2/14/15 3:14 PM, Robert Haas wrote:
>> Although I like the idea, it's not clear to me how to implement it.
> Throw an error in AssignTransactionId/GetNewTransactionId?
>A whole lot depends on what you choose to mean by "read only". If it
>?6?9means the same thing as "
Hi list,
On 20/01/15 23:03, Jim Nasby wrote:> On 1/20/15 2:20 PM, Robert Haas wrote:
>> On Tue, Jan 20, 2015 at 1:05 AM, Abhijit
>> Menon-Sen wrote:
>>> >So when I'm trying to decide what to audit, I have to:
>>> >
>>> > (a) check if the current user is mentioned in .roles; if so,
>>> audit.
Hi, Michael
I found that definition of VERBOSE and log_autovacuum is not
pretty match. For example, "VERBOSE" can output logs of
scanning indices and scanning detail of analyze, but
log_autovacuum can't output them.
Please see following sequences.
1. execute these queries.
DROP TABLE t1;
C
Hi All,
Here are the steps and infrastructure for achieving atomic commits across
multiple foreign servers. I have tried to address most of the concerns
raised in this mail thread before. Let me know, if I have left something.
Attached is a WIP patch implementing the same for postgres_fdw. I have
On 2015-02-17 12:18:41 +0900, Fujii Masao wrote:
> On Fri, Feb 13, 2015 at 9:18 AM, Andres Freund wrote:
> > Somewhat uckily it's 9.2 only (9.3, 9.4 and master look correct, earlier
> > releases don't have pg_receivexlog)
>
> Are you planning to back-patch the fix to 9.2?
Yes, but I want to look
69 matches
Mail list logo
