Re: [HACKERS] WAL replay bugs

On Thu, Jul 3, 2014 at 3:38 PM, Tom Lane wrote: > Michael Paquier writes: >> On Wed, Jul 2, 2014 at 5:32 PM, Kyotaro HORIGUCHI >> wrote: >>> Pehaps this is showing that no tidy or generalized way to tell >>> what a page is used for. Many of the modules which have their >>> own page format has a

Re: [HACKERS] WAL replay bugs

Michael Paquier writes: > On Wed, Jul 2, 2014 at 5:32 PM, Kyotaro HORIGUCHI > wrote: >> Pehaps this is showing that no tidy or generalized way to tell >> what a page is used for. Many of the modules which have their >> own page format has a magic value and the values seem to be >> selected carefu

Re: [HACKERS] Autonomous Transaction (WIP)

On 01 July 2014 12:00, Amit Kapila Wrote: >On Tue, Jul 1, 2014 at 11:46 AM, Rajeev rastogi >mailto:rajeev.rast...@huawei.com>> wrote: >> On 30 June 2014 22:50, Pavel Stehule Wrote: >> >I didn't find a related message. >> >? >> >> I think there have been some confusion, the design idea were never

Re: [HACKERS] TODO : Allow parallel cores to be used by vacuumdb [ WIP ]

On Wed, Jul 2, 2014 at 11:45 PM, Alvaro Herrera wrote: > > Jeff Janes wrote: > > > I would only envision using the parallel feature for vacuumdb after a > > pg_upgrade or some other major maintenance window (that is the only > > time I ever envision using vacuumdb at all). I don't think autovacuu

Re: [HACKERS] [PATCH] introduce XLogLockBlockRangeForCleanup()

At 2014-07-03 11:15:53 +0530, amit.khande...@enterprisedb.com wrote: > > In GetBufferWithoutRelcache(), I was wondering, rather than calling > PinBuffer(), if we do this : > LockBufHdr(buf); > PinBuffer_Locked(buf); > valid = ((buf->flags & BM_VALID) != 0); > then we can avoid having the new buffer

Re: [HACKERS] WAL replay bugs

TODO On Wed, Jul 2, 2014 at 5:32 PM, Kyotaro HORIGUCHI wrote: > bufcapt.c: 326 memcpy(&tail, &page[BLCKSZ - 2], 2); > > This seems duzzling.. Isn't "*(uint16*)(&page[BLCKSZ - 2])" applicable? Well yes it is. > Pehaps this is showing that no tidy or generalized way to tell > what a page is

Re: [HACKERS] [PATCH] introduce XLogLockBlockRangeForCleanup()

On 13 June 2014 14:10, Abhijit Menon-Sen wrote: > nbtxlog.c:btree_xlog_vacuum() contains the following comment: > > * XXX we don't actually need to read the block, we just need to > * confirm it is unpinned. If we had a special call into the > * buffer manager we could optimise thi

Re: [HACKERS] better atomics - v0.5

On Tue, Jul 1, 2014 at 4:10 PM, Andres Freund wrote: > On 2014-07-01 10:44:19 +0530, Amit Kapila wrote: > > > I think defining barrier support for some atomic ops and not for others > > will lead to inconsistency with specs and we need to additionally > > define rules for such atomic ops usage. >

Re: [HACKERS] RLS Design

Robert, all, * Robert Haas (robertmh...@gmail.com) wrote: > I think we're converging, but it might be a good idea to summarize a > specific proposal before you start implementing. Alright, apologies for it being a bit later than intended, but here's what I've come up with thus far. -- policies d

Re: [HACKERS] alter user set local_preload_libraries.

o <20408.1404329...@sss.pgh.pa.us> User-Agent: Mew version 6.5 on Emacs 22.2 / Mule 5.0 =?iso-2022-jp?B?KBskQjpnGyhCKQ==?= / Meadow-3.01-dev (TSUBO-SUMIRE) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I'm getting confused.. The

Re: [HACKERS] Proposing pg_hibernate

On Wed, Jul 2, 2014 at 5:48 AM, Gurjeet Singh wrote: > > Granted, you have demonstrated that the blocks restored by > pg_hibernator can cause eviction of loaded-by-recovery blocks. But, > one can argue that pg_hibernator brought the shared-buffer contents to > to a state that is much closer to the

Re: [HACKERS] Stating the significance of Lehman & Yao in the nbtree README

On Wed, Jul 2, 2014 at 8:14 PM, Abhijit Menon-Sen wrote: > Well, to be fair, the original patch was posted to the list more than a > month ago, and it should have been in this CF. But… it wasn't. And now > after more than two weeks into this CF, I don't think it should be. Is that how the rule is

Re: [HACKERS] Stating the significance of Lehman & Yao in the nbtree README

At 2014-07-03 11:59:21 +0900, michael.paqu...@gmail.com wrote: > > +1. Even if it is just a doc patch, it has been submitted after 6/15, > which was the CF1 deadline. Well, to be fair, the original patch was posted to the list more than a month ago, and it should have been in this CF. But… it wasn

Re: [HACKERS] Stating the significance of Lehman & Yao in the nbtree README

On Thu, Jul 3, 2014 at 11:40 AM, Abhijit Menon-Sen wrote: > At 2014-07-02 17:24:06 -0700, p...@heroku.com wrote: >> >> I've added this to the ongoing commitfest. > > I don't actually understand why you were able to do that (seeing as this > CF is no longer open for new patches). Trivial or not, I

Re: [HACKERS] Stating the significance of Lehman & Yao in the nbtree README

At 2014-07-02 17:24:06 -0700, p...@heroku.com wrote: > > I've added this to the ongoing commitfest. I don't actually understand why you were able to do that (seeing as this CF is no longer open for new patches). Trivial or not, I think at this point it should go into the next one. Or it should be

Re: [HACKERS] "RETURNING PRIMARY KEY" syntax extension

On 01/07/14 21:00, Rushabh Lathia wrote: I spent some more time on the patch and here are my review comments. .) Patch gets applied through patch -p1 (git apply fails) .) trailing whitespace in the patch at various places Not sure where you see this, unless it's in the tests, where it's requ

Re: [HACKERS] "RETURNING PRIMARY KEY" syntax extension

On 02/07/14 15:16, Ian Barwick wrote: On 14/07/01 23:13, Robert Haas wrote: On Tue, Jul 1, 2014 at 8:00 AM, Rushabh Lathia wrote: .) In map_primary_key_to_list() patch using INDEX_ATTR_BITMAP_IDENTITY_KEY bitmap to get the keycols. In IndexAttrBitmapKind there is also INDEX_ATTR_BITMAP_KEY, so

Re: [HACKERS] Stating the significance of Lehman & Yao in the nbtree README

On Mon, May 26, 2014 at 1:22 PM, Peter Geoghegan wrote: > I think that this isn't enough. Attached patch proposes to add a small > paragraph at the top of the nbtree README, to clarify the advantages > of L&Y from a high level. I've added this to the ongoing commitfest. -- Peter Geoghegan --

Re: [HACKERS] Ancient bug in formatting.c/to_char()

Where are we on this? -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Doing better at HINTing an appropriate column within errorMissingColumn()

On Sun, Jun 29, 2014 at 7:30 AM, Tom Lane wrote: > Although printing all candidates seems to be what's preferred by > existing systems with similar facilities, I can see the point that > constructing the message in a translatable fashion might be difficult. > So personally I'd be willing to abando

Re: [HACKERS] Can simplify 'limit 1' with slow function?

Martijn van Oosterhout writes: > On Wed, Jul 02, 2014 at 04:17:13PM -0400, Tom Lane wrote: >> It's not so much the limit as that the sort has to happen before the >> limit, and yes, evaluation of the targetlist happens before the sort. > I guess I assumed the column c was indexable, and it that c

Re: [HACKERS] New functions in sslinfo module

On 07/02/2014 02:17 PM, Воронин Дмитрий wrote: I apologize, that I am writing this message today. Thank you for testing my patch! You are welcome! I will modify functions ssl_extensions(), that it returns a set (key, value). Could you get me an example of code those function? You can look a

Re: [HACKERS] Can simplify 'limit 1' with slow function?

On Wed, Jul 02, 2014 at 04:17:13PM -0400, Tom Lane wrote: > David G Johnston writes: > > Martijn van Oosterhout wrote > >> I'm probably dense, but I'm not sure I understand. Or it is that the > >> slowfunction() is called prior to the sort? That seems insane. > > > The basic reality is that limit

Re: [HACKERS] Audit of logout

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/02/2014 02:15 PM, Abhijit Menon-Sen wrote: > At 2014-07-02 16:47:16 -0400, alvhe...@2ndquadrant.com wrote: >> >> If we expect that the author is going to update the patch, the >> right state to use is "Waiting on author". > > Quite so. That's h

Re: [HACKERS] Audit of logout

Abhijit Menon-Sen wrote: > At 2014-07-02 16:47:16 -0400, alvhe...@2ndquadrant.com wrote: > > > > If we expect that the author is going to update the patch, the right > > state to use is "Waiting on author". > > Quite so. That's how I understand it, and what I've been doing. But what > if we reall

Re: [HACKERS] Patch to send transaction commit/rollback stats to the stats collector unconditionally.

Gurjeet Singh wrote: > On Wed, Jul 2, 2014 at 3:49 PM, Kevin Grittner wrote: >> Gurjeet Singh wrote: >>> Kevin Grittner wrote: I have reviewed this patch, and think we should do what the patch is trying to do, but I don't think the submitted patch would actually work. >>> >>> Jus

Re: [HACKERS] Audit of logout

At 2014-07-02 16:47:16 -0400, alvhe...@2ndquadrant.com wrote: > > If we expect that the author is going to update the patch, the right > state to use is "Waiting on author". Quite so. That's how I understand it, and what I've been doing. But what if we really *don't* expect the author to update t

[HACKERS] Re: Patch to send transaction commit/rollback stats to the stats collector unconditionally.

On Wed, Jul 2, 2014 at 3:49 PM, Kevin Grittner wrote: > In preparing to push the patch, I noticed I hadn't responded to this: > > Gurjeet Singh wrote: >> Kevin Grittner wrote: >>> I have reviewed this patch, and think we should do what the patch >>> is trying to do, but I don't think the submitt

Re: [HACKERS] Audit of logout

Abhijit Menon-Sen wrote: > At 2014-07-02 12:52:51 -0700, m...@joeconway.com wrote: > > > > Doesn't mean that to me but feel free to change it to Waiting on > > Author if you prefer :-) > > > > Is there any official explanation as to what those states mean > > documented anywhere? > > I don't know

Re: [HACKERS] Audit of logout

I wrote: > In short, maybe we ought to invent a new category PGC_SU_BACKEND (not > wedded to this spelling), which is to PGC_BACKEND as PGC_SUSET is to > PGC_USERSET, ie same when-it-can-be-changed behavior but only superusers > are allowed to change it. I don't have any objection to making these

Re: [HACKERS] Re: Patch to send transaction commit/rollback stats to the stats collector unconditionally.

Tom Lane wrote: > FWIW, master + 9.4 seems like a reasonable compromise to me too. Pushed to those branches.  Marked in CF. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make chan

Re: [HACKERS] Audit of logout

At 2014-07-02 12:52:51 -0700, m...@joeconway.com wrote: > > Doesn't mean that to me but feel free to change it to Waiting on > Author if you prefer :-) > > Is there any official explanation as to what those states mean > documented anywhere? I don't know if there's an official definition, but my

Re: [HACKERS] Can simplify 'limit 1' with slow function?

David G Johnston writes: > Martijn van Oosterhout wrote >> I'm probably dense, but I'm not sure I understand. Or it is that the >> slowfunction() is called prior to the sort? That seems insane. > The basic reality is that limit applies to the final set of rows that could > be output. It's not so

Re: [HACKERS] Aggregate function API versus grouping sets

> "Tom" == Tom Lane writes: >> Do we want a decision on the fn_extra matter first, or shall I do >> one patch for the econtext, and a following one for fn_extra? Tom> I think they're somewhat independent, and probably best patched Tom> separately. In any case orderedsetagg.c's use of fn

Re: [HACKERS] Aggregate function API versus grouping sets

Andrew Gierth writes: > "Tom" == Tom Lane writes: > Tom> If we're going to do that, I think it needs to be in 9.4. Are > Tom> you going to work up a patch? > Do we want a decision on the fn_extra matter first, or shall I do one > patch for the econtext, and a following one for fn_extra? I th

Re: [HACKERS] Audit of logout

Fujii Masao writes: > On Wed, Jul 2, 2014 at 11:39 PM, Joe Conway wrote: >> Returned with Feedback means, well exactly that ;-) -- the patch as >> linked to the CF page is wrong and cannot be applied the way it is >> currently. It is therefore returned to you to be fixed. It does not >> mean "Rej

Re: [HACKERS] gaussian distribution pgbench

On 02/07/14 21:05, Fabien COELHO wrote: Hello Mitsumasa-san, And I'm also interested in your "decile percents" output like under followings, decile percents: 39.6% 24.0% 14.6% 8.8% 5.4% 3.3% 2.0% 1.2% 0.7% 0.4% Sure, I'm really fine with that. I think that it is easier than before. Sum of d

Re: [HACKERS] Can simplify 'limit 1' with slow function?

Martijn van Oosterhout wrote > On Tue, Jul 01, 2014 at 02:36:55PM -0500, Merlin Moncure wrote: >> On Tue, Jul 1, 2014 at 2:16 PM, Martijn van Oosterhout >> < > kleptog@ > > wrote: >> > On Sun, Jun 29, 2014 at 10:05:50PM +0800, gotoschool6g wrote: >> >> The simplified scene: >> >> select slowfunct

Re: [HACKERS] Audit of logout

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/02/2014 12:43 PM, Fujii Masao wrote: > I think that we should use "Waiting on Author" in that case. > > "Returned with Feedback" is not "Rejected". That's right. But it > basically means that the bugfixed or revised version of the patch > will N

Re: [HACKERS] Patch to send transaction commit/rollback stats to the stats collector unconditionally.

In preparing to push the patch, I noticed I hadn't responded to this: Gurjeet Singh wrote: > Kevin Grittner wrote: >> I have reviewed this patch, and think we should do what the patch >> is trying to do, but I don't think the submitted patch would >> actually work. > > Just curious, why do you t

Re: [HACKERS] log_error_verbosity and unexpected errors

Merlin Moncure writes: > Not trying to hijack your thread, just wondering out load if a > SQLSTATE driven verbosity decision, if you were to do that, > could/should also be hooked to client console logging and/or psql. Yeah, you could certainly argue that a similar facility on the client side wou

Re: [HACKERS] Aggregate function API versus grouping sets

> "Tom" == Tom Lane writes: Tom> Another approach would be to remove AggGetPerAggEContext as such Tom> from the API altogether, and instead offer an interface that Tom> says "register an aggregate cleanup callback", leaving it to the Tom> agg/window core code to figure out which context t

Re: [HACKERS] Audit of logout

On Wed, Jul 2, 2014 at 11:39 PM, Joe Conway wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/01/2014 11:55 PM, Fujii Masao wrote: >> Hmm... I found that you had marked this proposal as "Returned with >> Feedback". But I don't think that we reached the consensus to do >> that. I t

Re: [HACKERS] Can simplify 'limit 1' with slow function?

On Tue, Jul 01, 2014 at 02:36:55PM -0500, Merlin Moncure wrote: > On Tue, Jul 1, 2014 at 2:16 PM, Martijn van Oosterhout > wrote: > > On Sun, Jun 29, 2014 at 10:05:50PM +0800, gotoschool6g wrote: > >> The simplified scene: > >> select slowfunction(s) from a order by b limit 1; > >> is slow than >

Re: [HACKERS] alter user set local_preload_libraries.

Fujii Masao writes: > Agreed. I was also thinking we can set it per role, but got surprised > when I found that's impossible. Is this a problem of only > local_preload_libraries? I'm afraid that all PGC_BACKEND parameters > have the same problem. Well, there aren't that many PGC_BACKEND parameter

[HACKERS] docs: additional subsection for page-level locks in explicit-locking section

Hi, While reading through the Explicit Locking section of the manual today, I felt the last paragraph of section 13.3.2. (Row-level Locks) might merit its own subsection. It talks about page-level locks as distinct from table- and row-level locks. Then again, it is just one paragraph, so maybe t

Re: [HACKERS] log_error_verbosity and unexpected errors

On Wed, Jul 2, 2014 at 2:10 PM, Tom Lane wrote: > Greg Stark writes: >> I think log_error_verbosity is a strange variable. It's useless for >> expected user-facing errors but essential for unexpected errors that >> indicate bugs in the code -- and you can only have it on for >> everything or off

[HACKERS] Should extension--unpackaged-$ver.sql's \echo use FROM unpackaged;?

Hi, Fujii noticed that I'd used \echo Use "CREATE EXTENSION pg_buffercache" to load this file. \quit in an extension upgrade script. That's obviously wrong, because it should say ALTER EXTENSION. The reason it's that way is that I copied the line from the unpackaged--1.0.sql file. I noticed all un

Re: [HACKERS] alter user set local_preload_libraries.

On Thu, Jul 3, 2014 at 3:53 AM, Tom Lane wrote: > Fujii Masao writes: >> On Wed, Jul 2, 2014 at 11:15 PM, Tom Lane wrote: >>> Kyotaro HORIGUCHI writes: postgres=# alter user horiguti2 set local_preload_libraries='libname'; ERROR: parameter "local_preload_libraries" cannot be set afte

Re: [HACKERS] log_error_verbosity and unexpected errors

Greg Stark writes: > I think log_error_verbosity is a strange variable. It's useless for > expected user-facing errors but essential for unexpected errors that > indicate bugs in the code -- and you can only have it on for > everything or off for everything. > I'm finding I usually want it set to

Re: [HACKERS] alter user set local_preload_libraries.

Fujii Masao writes: > On Wed, Jul 2, 2014 at 11:15 PM, Tom Lane wrote: >> Kyotaro HORIGUCHI writes: >>> postgres=# alter user horiguti2 set local_preload_libraries='libname'; >>> ERROR: parameter "local_preload_libraries" cannot be set after connection >>> start >> Hm ... it's kind of annoyin

Re: [HACKERS] alter user set local_preload_libraries.

On Wed, Jul 2, 2014 at 11:15 PM, Tom Lane wrote: > Kyotaro HORIGUCHI writes: >> postgres=# alter user horiguti2 set local_preload_libraries='libname'; >> ERROR: parameter "local_preload_libraries" cannot be set after connection >> start > > Hm ... it's kind of annoying that that doesn't work; i

Re: [HACKERS] Aggregate function API versus grouping sets

Andrew Gierth writes: > "Tom" == Tom Lane writes: > Tom> Another approach would be to remove AggGetPerAggEContext as such > Tom> from the API altogether, and instead offer an interface that > Tom> says "register an aggregate cleanup callback", leaving it to the > Tom> agg/window core code to

[HACKERS] log_error_verbosity and unexpected errors

I think log_error_verbosity is a strange variable. It's useless for expected user-facing errors but essential for unexpected errors that indicate bugs in the code -- and you can only have it on for everything or off for everything. I'm finding I usually want it set to 'verbose' for anything that P

Re: [HACKERS] TODO : Allow parallel cores to be used by vacuumdb [ WIP ]

On Wed, Jul 2, 2014 at 2:27 PM, Dilip kumar wrote: > On 01 July 2014 22:17, Sawada Masahiko Wrote, > > >> I have executed latest patch. >> One question is that how to use --jobs option is correct? >> $ vacuumdb -d postgres --jobs=30 >> >> I got following error. >> vacuumdb: unrecognized option '

Re: [HACKERS] TODO : Allow parallel cores to be used by vacuumdb [ WIP ]

Jeff Janes wrote: > I would only envision using the parallel feature for vacuumdb after a > pg_upgrade or some other major maintenance window (that is the only > time I ever envision using vacuumdb at all). I don't think autovacuum > can be expected to handle such situations well, as it is design

Re: [HACKERS] 9.5 CF1

At 2014-07-02 11:19:10 -0400, sfr...@snowman.net wrote: > > I'd be fine leaving this open for now at least ('waiting on author' > perhaps) and then bumping it to August only if necessary. Since there's active discussion/development happening, I wasn't planning to change the status anyway. It looks

Re: [HACKERS] Aggregate function API versus grouping sets

> "Tom" == Tom Lane writes: >> Doing rollup via GroupAggregate by maintaining multiple transition >> values at a time (one per grouping set) means that the transfn is >> being called interleaved for transition values in different >> contexts. So the question becomes: is it wrong for the t

Re: [HACKERS] TODO : Allow parallel cores to be used by vacuumdb [ WIP ]

On Mon, Jun 30, 2014 at 3:17 PM, Alvaro Herrera wrote: > Jeff Janes wrote: > >> In particular, pgpipe is almost an exact duplicate between them, >> except the copy in vac_parallel.c has fallen behind changes made to >> parallel.c. (Those changes would have fixed the Windows warnings). I >> think

Re: [HACKERS] 9.5 CF1

Abhijit Menon-Sen wrote: > Minmax indexes > Álvaro will respond to the design questions Heikki raised. I'm currently reworking the patch so that things that need to be abstract per discussion are abstract, without enlarging the scope excessively. I'm working on an opclass implementation that

Re: [HACKERS] /proc/self/oom_adj is deprecated in newer Linux kernels

On Wed, Jul 2, 2014 at 9:08 AM, Jonathan Corbet wrote: > On Tue, 1 Jul 2014 15:57:25 -0400 > Robert Haas wrote: >> Of course, we have no guarantee that the Linux kernel guys won't >> change this again. Apparently "we don't break userspace" is a >> somewhat selectively-enforced principle. > > It'

Re: [HACKERS] Re: Patch to send transaction commit/rollback stats to the stats collector unconditionally.

Robert Haas writes: > On Wed, Jul 2, 2014 at 11:45 AM, Kevin Grittner wrote: >>> I'll vote for master-only. >> Well, it seems tame enough to me to apply to the release still in >> beta testing. > It didn't seem important enough to me to justify a beta-to-release > behavior change, but I won't c

Re: [HACKERS] RLS Design

* Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Jul 2, 2014 at 11:42 AM, Stephen Frost wrote: > >> > What if policies exist and they decide to > >> > 'turn off' RLS for the table- suddenly everyone can see all the rows? > >> > >> That'd be my vote. Sorta like disabling triggers. > > > > Hm

Re: [HACKERS] Keepalive-related socket options under FreeBSD 9, 10

> Since upgrading FreeBSD from 8 to 9, I've noticed the following messages > showing up in logs when a connection with pgAdmin3 is made: > > LOG: getsockopt(TCP_KEEPCNT) failed: Protocol not available > STATEMENT: SELECT setting FROM pg_settings WHERE name IN ('autovacuum', > 'track_counts') > L

Re: [HACKERS] slotname vs slot_name

On 2014-06-05 12:57:57 +0200, Andres Freund wrote: > > BTW, what about also renaming pg_llog directory? I'm afraid that > > a user can confuse pg_log with pg_llog. > > We have: > * pg_ldecoding (Heikki) > * pg_lcse or pg_lcset (Petr) > * pg_logical (Andres) > > I like, what a surprise, my own sug

Re: [HACKERS] Re: Patch to send transaction commit/rollback stats to the stats collector unconditionally.

On Wed, Jul 2, 2014 at 11:45 AM, Kevin Grittner wrote: >> I'll vote for master-only. > > Well, it seems tame enough to me to apply to the release still in > beta testing. It didn't seem important enough to me to justify a beta-to-release behavior change, but I won't complain too much if you feel

Re: [HACKERS] Re: Patch to send transaction commit/rollback stats to the stats collector unconditionally.

Robert Haas wrote: > On Tue, Jul 1, 2014 at 7:32 PM, Gurjeet Singh wrote: >> Considering this as a bug-fix, I'd vote for it to be applied to >> all supported releases. I initially considered that position, but balanced that against this: > I view this as a behavior change, and it isn't nice to

Re: [HACKERS] RLS Design

On Wed, Jul 2, 2014 at 11:42 AM, Stephen Frost wrote: >> > What if policies exist and they decide to >> > 'turn off' RLS for the table- suddenly everyone can see all the rows? >> >> That'd be my vote. Sorta like disabling triggers. > > Hmm. Ok- how would you feel about at least spitting out a WA

Re: [HACKERS] RLS Design

* Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Jul 2, 2014 at 9:47 AM, Stephen Frost wrote: > >> But you could do it other ways. For example: > >> > >> ALTER TABLE table_name [ NO ] ROW LEVEL SECURITY; > >> ALTER TABLE table_name GRANT ROW ACCESS TO role_name USING qual; > >> > >> If a ta

Re: [HACKERS] /proc/self/oom_adj is deprecated in newer Linux kernels

Christoph Berg writes: > Re: Tom Lane 2014-07-01 <20654.1404247...@sss.pgh.pa.us> >> Fair enough. I went for a minimum-change approach when hacking that >> script, but we could change it some more in the name of readability. >> Will do something about that. > Thanks, it's much nicer now. There's

Re: [HACKERS] 9.5 CF1

* Abhijit Menon-Sen (a...@2ndquadrant.com) wrote: > Row-security based on Updatable security barrier views > Lots of discussion that I haven't dared to look at properly yet. I > gather there's still plenty of design-level work needed, and this > is not in any imminent danger of being co

Re: [HACKERS] autovacuum: found orphan temp table

"Joshua D. Drake" writes: > While it is obvious what is happening in $SUBJECT as well as reasonably > obvious why it can happen. What isn't obvious is what to do about it. It > seems we log in as a super user and drop the temp tables. You don't need to do anything --- the table will go away the

Re: [HACKERS] autovacuum: found orphan temp table

Joshua D. Drake wrote: Hi, > While it is obvious what is happening in $SUBJECT as well as > reasonably obvious why it can happen. What isn't obvious is what to > do about it. It seems we log in as a super user and drop the temp > tables. > > However, I would think if we know that it is orphaned

[HACKERS] autovacuum: found orphan temp table

Hello, While it is obvious what is happening in $SUBJECT as well as reasonably obvious why it can happen. What isn't obvious is what to do about it. It seems we log in as a super user and drop the temp tables. However, I would think if we know that it is orphaned that autovacuum should just

Re: [HACKERS] 9.5 CF1

Abhijit Menon-Sen wrote: > Spread shared memory across NUMA memory nodes > Marked waiting on author, but status unclear. Any updates? The review was a little sparse: http://www.postgresql.org/message-id/CADyhKSXs+oUetngSbeiM0tVSRy=QeCaSNBQBDbM=sfqtdg+...@mail.gmail.com In particular, there

Re: [HACKERS] Re: Patch to send transaction commit/rollback stats to the stats collector unconditionally.

On Tue, Jul 1, 2014 at 7:32 PM, Gurjeet Singh wrote: > On Tue, Jul 1, 2014 at 10:05 AM, Kevin Grittner wrote: >> Tom Lane wrote: >> >>> If we're going to do it like this, then I think the force flag >>> should be considered to do nothing except override the clock >>> check, which probably means

Re: [HACKERS] RLS Design

On Wed, Jul 2, 2014 at 9:47 AM, Stephen Frost wrote: >> But you could do it other ways. For example: >> >> ALTER TABLE table_name [ NO ] ROW LEVEL SECURITY; >> ALTER TABLE table_name GRANT ROW ACCESS TO role_name USING qual; >> >> If a table is set to NO ROW LEVEL SECURITY then it behaves just li

Re: [HACKERS] Aggregate function API versus grouping sets

Andrew Gierth writes: > 1. Assumptions about the relationship between aggcontext and fn_extra > Tom's version of the ordered-set aggregate code makes the assumption > that it is safe to store the aggcontext returned by AggCheckCallContext > in a structure hung off flinfo->fn_extra. This implicitl

Re: [HACKERS] Audit of logout

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/01/2014 11:55 PM, Fujii Masao wrote: > Hmm... I found that you had marked this proposal as "Returned with > Feedback". But I don't think that we reached the consensus to do > that. I think that it's still worth discussing this topic in this > CF.

Re: [HACKERS] alter user set local_preload_libraries.

Kyotaro HORIGUCHI writes: > postgres=# alter user horiguti2 set local_preload_libraries='libname'; > ERROR: parameter "local_preload_libraries" cannot be set after connection > start Hm ... it's kind of annoying that that doesn't work; it's certainly not hard to imagine use-cases for per-user o

Re: [HACKERS] Spinlocks and compiler/memory barriers

On Wed, Jul 2, 2014 at 4:06 AM, Mark Cave-Ayland wrote: > The point I wanted to make was that there are certain applications for which > SPARCv8 is still certified for particular military/aerospace use. While I > don't use it myself, some people are still using it enough to want to > contribute QE

Re: [HACKERS] RLS Design

* Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Jul 1, 2014 at 3:20 PM, Dean Rasheed wrote: > > If RLS quals are instead regarded as constraints on access, and > > multiple policies apply, then it seems that the quals should now be > > combined with AND rather than OR, right? I do feel tha

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

Simon, * Simon Riggs (si...@2ndquadrant.com) wrote: > On 1 July 2014 18:32, Stephen Frost wrote: > > Having functions to control the auditing would work, but it's not > > exactly the ideal approach, imv, and > > What aspect is less than ideal? I certainly don't like passing table names to funct

Re: [HACKERS] better atomics - v0.5

On 2014-06-26 00:42:37 +0300, Heikki Linnakangas wrote: > On 06/25/2014 11:36 PM, Andres Freund wrote: > > > >>>- I completely loathe the file layout you've proposed in > >>>src/include/storage. If we're going to have separate #include files > >>>for each architecture (and I'd rather we didn't go

Re: [HACKERS] /proc/self/oom_adj is deprecated in newer Linux kernels

On Tue, 1 Jul 2014 15:57:25 -0400 Robert Haas wrote: > Of course, we have no guarantee that the Linux kernel guys won't > change this again. Apparently "we don't break userspace" is a > somewhat selectively-enforced principle. It's selectively enforced in that kernel developers don't (and can't

Re: [HACKERS] better atomics - v0.5

Hi, On 2014-06-30 20:28:52 +0200, Andres Freund wrote: > To quantify this, on my 2 socket xeon E5520 workstation - which is too > small to heavily show the contention problems in pgbench -S - the > numbers are: > > pgbench -M prepared -c 16 -j 16 -T 10 -S (best of 5, noticeably variability) > mast

Re: [HACKERS] 9.5 CF1

On Wed, Jul 2, 2014 at 10:08 AM, Abhijit Menon-Sen wrote: > KNN-GiST with recheck > Partial sort > Some earlier discussion, but no conclusions, and as far as I know > nobody is working on these patches at the moment. > I'm now working on next revision of KNN-GiST with recheck. Also, I th

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

On Wed, Jul 2, 2014 at 5:19 AM, Simon Riggs wrote: > On 1 July 2014 18:32, Stephen Frost wrote: >> Having functions to control the auditing would work, but it's not >> exactly the ideal approach, imv, and > > What aspect is less than ideal? > >> the only reason it's being >> discussed here is bec

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

* Abhijit Menon-Sen (a...@2ndquadrant.com) wrote: > I foresee lots of disappointment, then. I don't think even Stephen is > advocating NIST-compliance as the *baseline* for serious auditing in > core, just that we need a design that lets us get there sometime. Agreed. I'm not suggesting that we m

Re: [HACKERS] New functions in sslinfo module

On Wed, Jul 2, 2014 at 9:19 PM, Воронин Дмитрий wrote: > > Oh, how can I write a documentation for my functions? You will need to edit the sgml documentation and to include the diffs in your patch. Hence in your case simply list the new functions and a description of what they do in doc/src/sgml/

Re: [HACKERS] New functions in sslinfo module

Oh, how can I write a documentation for my functions? 02.07.2014, 16:17, "Воронин Дмитрий" : > 24.06.2014, 00:07, "Andreas Karlsson" : >>  On 04/21/2014 07:51 AM, Воронин Дмитрий wrote: >>>   I put patch generated on git diffs to this letter. I make an a thread in >>>   postgresql commit fest: >>>

Re: [HACKERS] New functions in sslinfo module

24.06.2014, 00:07, "Andreas Karlsson" : On 04/21/2014 07:51 AM, Воронин Дмитрий wrote:  I put patch generated on git diffs to this letter. I make an a thread in  postgresql commit fest:  https://commitfest.postgresql.org/action/patch_view?id=1438 Thanks for the patch, it seems li

Re: [HACKERS] gaussian distribution pgbench

I have just updated the wording so that it may be clearer: Oops, I have sent the wrong patch, without the wording fix. Here is the real updated version, which I tested. probability of fist/last percent of the range: 11.3% 0.0% -- Fabien.diff --git a/contrib/pgbench/pgbench.c b/contrib/p

Re: [HACKERS] Selectivity estimation for inet operators

On, 15 May 2014 14:04 Emre Hasegeli Wrote, > > * matching first MCV to second MCV > * searching first MCV in the second histogram > * searching second MCV in the first histogram > * searching boundaries of the first histogram in the second histogram > > Comparing the lists with each other slows

Re: [HACKERS] Allowing NOT IN to use ANTI joins

On Wed, Jul 2, 2014 at 9:25 PM, Jeevan Chalke < jeevan.cha...@enterprisedb.com> wrote: > > > Testing more on SQL level. > > I'm just looking into an issue I've found in the find_inner_rels() function, where it does not properly find the rel in the from list in certain cases, for example: explain

[HACKERS] Aggregate function API versus grouping sets

I've been assisting Atri with development of an implementation of GROUPING SETS, beginning with a one-pass implementation of ROLLUP. Two issues have arisen regarding the API for calling aggregate transition and final functions that I think need answering now, since they relate to changes in 9.4. 1

Re: [HACKERS] Allowing NOT IN to use ANTI joins

On Sun, Jun 29, 2014 at 4:18 PM, David Rowley wrote: > I think I'm finally ready for a review again, so I'll update the > commitfest app. > > I have reviewed this on code level. 1. Patch gets applied cleanly. 2. make/make install/make check all are fine No issues found till now. However some c

Re: [HACKERS] 9.5 CF1

(2014/07/02 18:19), Abhijit Menon-Sen wrote: Thanks for the update. I have marked the patch "returned with feedback" and moved it to the 2014-08 CF. OK I've changed the status from "returned with feedback" to "Waiting on Author". Thanks, Best regards, Etsuro Fujita -- Sent via pgsql-hack

Re: [HACKERS] 9.5 CF1

Thanks for the update. I have marked the patch "returned with feedback" and moved it to the 2014-08 CF. -- Abhijit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

On 1 July 2014 18:32, Stephen Frost wrote: > Having functions to control the auditing would work, but it's not > exactly the ideal approach, imv, and What aspect is less than ideal? > the only reason it's being > discussed here is because it might be a way to allow an extension to > provide the

  1   2   >