Re: [HACKERS] Final Patch for GROUPING SETS

On Thu, May 14, 2015 at 08:38:07AM +0200, Andres Freund wrote: > On 2015-05-14 02:32:04 -0400, Noah Misch wrote: > > On Thu, May 14, 2015 at 07:50:31AM +0200, Andres Freund wrote: > > > Andrew, is that a structure you could live with, or not? > > > > > > Others, what do you think? > > > > Andrew

Re: [HACKERS] pgAdmin4 Bug fix or my Fault ?

Bruce, Thank you for "webpage" trick, I send subscrible mail to pgadmin-hackers-request. Actually I want to developer for pgadmin4. I talk with Dave, He say, "... You should use "git diff" to create patches and then submit them to pgadmin-hackers ..." So, If I want run pgadmin4 in Debian Jessie,

[HACKERS] CLUSTER on brin indexes

Hi Here's an idea for a small 9.6 feature that I don't see on the todo list already. I noticed that you can't currently CLUSTER on a brin index. As I understand it, brin indexes are most effective when blocks have non-overlapping value ranges, and less effective the more the ranges overlap, so i

Re: [HACKERS] Final Patch for GROUPING SETS

On 2015-05-14 02:32:04 -0400, Noah Misch wrote: > On Thu, May 14, 2015 at 07:50:31AM +0200, Andres Freund wrote: > > Andrew, is that a structure you could live with, or not? > > > > Others, what do you think? > > Andrew and I discussed that very structure upthread: > http://www.postgresql.org/me

Re: [HACKERS] proposal: contrib module - generic command scheduler

2015-05-14 8:01 GMT+02:00 Jim Nasby : > On 5/13/15 1:32 AM, Pavel Stehule wrote: > >> 5. When command waits to free worker, write to log >> 6. When command was not be executed due missing workers (and >> max_workers >> > 0), write to log >> >> >> Also unfortun

Re: [HACKERS] Final Patch for GROUPING SETS

On Thu, May 14, 2015 at 07:50:31AM +0200, Andres Freund wrote: > I still believe that the general approach of chaining vs. a union or CTE > is correct due to the efficiency arguments upthread. My problem is > that, unless I very much misunderstand something, the current > implementation can end up

Re: [HACKERS] proposal: contrib module - generic command scheduler

On 5/13/15 1:32 AM, Pavel Stehule wrote: 5. When command waits to free worker, write to log 6. When command was not be executed due missing workers (and max_workers > 0), write to log Also unfortunate. We already don't provide enough monitoring capabili

Re: [HACKERS] Final Patch for GROUPING SETS

On 2015-05-13 22:51:15 +0200, Andres Freund wrote: > I'm pretty sure by now that I dislike the introduction of GroupedVar, > and not just tentatively. While I can see why you found its > introduction to be nicer than fiddling with the result tuple, for me the > disadvantages seem to outweigh the a

Re: [HACKERS] Why does contain_leaked_vars believe MinMaxExpr is safe?

On Wed, May 13, 2015 at 09:34:53AM -0400, Robert Haas wrote: > On Tue, May 12, 2015 at 7:22 PM, Tom Lane wrote: > > MinMaxExpr is an implicit invocation of a btree comparison function. > > Are we supposing that all of those are necessarily leakproof? > > I suspect it's an oversight, because the c

[HACKERS] Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file

On Thu, May 14, 2015 at 2:10 AM, Andrew Dunstan wrote: > > How about if we simply abort if we find a non-symlink where we want the symlink to be, and only remove something that is actually a symlink (or a junction point, which is more or less the same thing)? > We can do that way and for that I t

Re: [HACKERS] upper planner path-ification

On Wed, May 13, 2015 at 10:27 PM, Tom Lane wrote: > Both of those are problems all right, but there is more context here. Thanks for providing the context. >> I'm inclined to think that it would be useful to solve the first >> problem even if we didn't solve the second one right away (but that >

Re: [HACKERS] upper planner path-ification

Robert Haas writes: > I've been pulling over Tom's occasional remarks about redoing > grouping_planner - and maybe further layers of the planner - to work > with Paths instead of Plans. ... > I think there are two separate problems here. First, there's the > problem that grouping_planner() is com

[HACKERS] upper planner path-ification

Hi, I've been pulling over Tom's occasional remarks about redoing grouping_planner - and maybe further layers of the planner - to work with Paths instead of Plans. I've had difficulty locating all of the relevant threads. Here's everything I've found so far, which I'm pretty sure is not everythi

Re: [HACKERS] Manipulating complex types as non-contiguous structures in-memory

Andres Freund writes: > On 2015-05-13 21:01:43 -0400, Tom Lane wrote: >> It is, but why would it be a disaster? We could add StaticAsserts >> verifying that the sizes actually are different. I doubt that the pad >> space itself could amount to any issue performance-wise, since it would >> only e

Re: [HACKERS] Manipulating complex types as non-contiguous structures in-memory

On 2015-05-13 21:01:43 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2015-05-13 20:48:51 -0400, Tom Lane wrote: > >> I still think that going back to defining the second byte as the size > >> would be better. Fortunately, since this is only a matter of in-memory > >> representations, we a

Re: [HACKERS] Manipulating complex types as non-contiguous structures in-memory

Andres Freund writes: > On 2015-05-13 20:48:51 -0400, Tom Lane wrote: >> I still think that going back to defining the second byte as the size >> would be better. Fortunately, since this is only a matter of in-memory >> representations, we aren't committed to any particular answer. > Requiring s

Re: [HACKERS] Proposal : REINDEX xxx VERBOSE

On Wed, May 13, 2015 at 8:25 PM, Sawada Masahiko wrote: > The v15 patch emits a line for each table when reindexing multiple > tables, and emits a line for each index when reindexing single table. > But v14 patch emits a line for each index, regardless of reindex target. > Should I change back to

Re: [HACKERS] Manipulating complex types as non-contiguous structures in-memory

On 2015-05-13 20:48:51 -0400, Tom Lane wrote: > I still think that going back to defining the second byte as the size > would be better. Fortunately, since this is only a matter of in-memory > representations, we aren't committed to any particular answer. Requiring sizes to be different still str

Re: [HACKERS] Manipulating complex types as non-contiguous structures in-memory

Andres Freund writes: > On 2015-05-10 12:09:41 -0400, Tom Lane wrote: >> Andres Freund writes: >>> * The VARTAG_IS_EXPANDED(tag) trick in VARTAG_SIZE is unlikely to >>> beneficial, before the compiler could implement the whole thing as a >>> computed goto or lookup table, afterwards not. >> Well

Re: [HACKERS] Triaging the remaining open commitfest items

> > * ctidscan as an example of custom-scan > > > > This basically hasn't gotten any attention, which may mean nobody cares > > enough to justify putting it in the tree. We need to either push it to > > next CF or reject altogether. > > Agreed. I was fine with never committing this. I don't thi

Re: [HACKERS] Manipulating complex types as non-contiguous structures in-memory

On 2015-05-13 20:28:52 -0400, Tom Lane wrote: > Andres Freund writes: > > Similarly using inline funcs for AARR_NDIMS/HASNULL does not appear to > > hamper performance and gets rid of the multiple evaluation risk. > > I'm less excited about that part though. The original ARR_FOO macros > mostly

Re: [HACKERS] Manipulating complex types as non-contiguous structures in-memory

Andres Freund writes: > On 2015-05-10 12:09:41 -0400, Tom Lane wrote: >>> * I find the ARRAY_ITER_VARS/ARRAY_ITER_NEXT macros rather ugly. I don't >>> buy the argument that turning them into functions will be slower. I'd >>> bet the contrary on common platforms. >> Perhaps; do you want to do some

Re: [HACKERS] Proposal : REINDEX xxx VERBOSE

On Wed, May 13, 2015 at 2:49 PM, Sawada Masahiko wrote: > > On Thu, May 14, 2015 at 12:28 AM, Robert Haas wrote: > > On Thu, May 7, 2015 at 6:55 PM, Sawada Masahiko wrote: > >> Sorry, I forgot attach files. > > > > Review comments: > > > > - Customarily we use int, rather than uint8, for flags v

Re: [HACKERS] Proposal : REINDEX xxx VERBOSE

On Thu, May 14, 2015 at 4:53 AM, Robert Haas wrote: > On Wed, May 13, 2015 at 2:10 PM, Alvaro Herrera > wrote: >> Uh, are we really using INFO to log this? I thought that was a >> discouraged level to use anymore. Why not NOTICE? > > Well, as Masahiko-san points out, VACUUM uses INFO. I can't

Re: [HACKERS] pgAdmin4 Bug fix or my Fault ?

I think you want PGAdmin support: http://www.pgadmin.org/support/list.php Also, why isn't the non-subscribe email address listed on that webpage? --- On Thu, May 14, 2015 at 12:11:15AM +0300, Seçkin Alan wrote: > H

[HACKERS] pgAdmin4 Bug fix or my Fault ?

Hi, I am using Debian Jessie and install pgAdmin4 Required modules. after I clone pgAdmin4 from http://git.postgresql.org/gitweb/?p=pgadmin4.git;a=summary , First of, ıf I want run setup.py, I must fix bug . after I want run pgadmin4.py, I must fix gravatar import line. In this case, There are re

Re: [HACKERS] BRIN range operator class

Emre Hasegeli wrote: > > I pushed patches 04 and 07, as well as adopting some of the changes to > > the regression test in 06. I'm afraid I caused a bit of merge pain for > > you -- sorry about that. > > No problem. I rebased the remaining ones. Thanks! After some back-and-forth between Emre a

Re: [HACKERS] i feel like compelled !

Oh well... then, THANKS GUYS!!! I'm not the original poster, btw. I felt a bit 'abandoned' a while back, since I started using Interbase/Firebird since, like, ~2000. But since Firebird never really took off, I felt I had to look for better solutions. I worked with Oracle for a bit, and then

Re: [HACKERS] PATCH: pgbench allow '=' in \set

On Wed, May 13, 2015 at 3:54 PM, Fabien COELHO wrote: > Ok. I've marked this one as REJECTED. > > Otherwise, I was considering this kind of things: > > n := expr > n, m, p, q := SELECT ... > > Also, having ";" as a end of commands could also help by allowing multiline > commands, but that woul

Re: [HACKERS] Fix token exceeding NAMELEN

On 13 May 2015 at 17:55, Tom Lane wrote: > "Aaron W. Swenson" writes: > > Trying to build HEAD and ran into this issue building the docs: > > openjade:logicaldecoding.sgml:575:62:Q: length of name token must > > not exceed NAMELEN (44) > > openjade:replication-origins.sgml:87:67:Q: l

Re: [HACKERS] Fix token exceeding NAMELEN

"Aaron W. Swenson" writes: > Trying to build HEAD and ran into this issue building the docs: > openjade:logicaldecoding.sgml:575:62:Q: length of name token must > not exceed NAMELEN (44) > openjade:replication-origins.sgml:87:67:Q: length of name token must > not exceed NAMELEN (44

Re: [HACKERS] i feel like compelled !

On 14/05/15 09:35, essam Gndelee essam wrote: hi i don't want to make this post long. i just started to use PostgreSQL and it is absolutely awesome . just want to say thank you very much You're allowed to say more!!! :-) What particular features do you like best, and why? What O/S, hardware

[HACKERS] i feel like compelled !

hi i don't want to make this post long. i just started to use PostgreSQL and it is absolutely awesome . just want to say thank you very much

Re: [HACKERS] PATCH: adaptive ndistinct estimator v4

On Thu, Apr 30, 2015 at 6:20 PM, Tomas Vondra wrote: > Hi, > > On 04/30/15 22:57, Robert Haas wrote: > >> On Tue, Mar 31, 2015 at 3:02 PM, Tomas Vondra >> wrote: >> >>> attached is v4 of the patch implementing adaptive ndistinct estimator. >>> >> >> So, I took a look at this today. It's interest

Re: [HACKERS] Final Patch for GROUPING SETS

On 2015-05-12 05:36:19 +0200, Andres Freund wrote: > > Another controversial item was the introduction of GroupedVar. The need > > for this can be avoided by explicitly setting to NULL the relevant > > columns of the representative group tuple when evaluating result rows, > > but (a) I don't think

[HACKERS] Fix token exceeding NAMELEN

Trying to build HEAD and ran into this issue building the docs: openjade:logicaldecoding.sgml:575:62:Q: length of name token must not exceed NAMELEN (44) openjade:replication-origins.sgml:87:67:Q: length of name token must not exceed NAMELEN (44) I've tried playing with the flags

[HACKERS] Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file

[redirecting to -hackers] On 05/12/2015 01:30 PM, Amit Kapila wrote: On Tue, May 12, 2015 at 9:02 PM, Andrew Dunstan > wrote: On 05/12/2015 10:33 AM, Heikki Linnakangas wrote: On 05/12/2015 04:42 PM, Andrew Dunstan wrote: + +

Re: [HACKERS] Proposal : REINDEX xxx VERBOSE

Robert Haas wrote: > On Wed, May 13, 2015 at 2:10 PM, Alvaro Herrera > wrote: > > Uh, are we really using INFO to log this? I thought that was a > > discouraged level to use anymore. Why not NOTICE? > > Well, as Masahiko-san points out, VACUUM uses INFO. I can't see any > good reason to make t

Re: [HACKERS] PATCH: pgbench allow '=' in \set

I also don't like to restate what has already been said. \set at the beginning of the line tells you that you will be setting a variable. Adding = or := only restates the same thing. I agree it superficially looks a little nicer, but I'm not sure it's really going to add clarity, because it's

Re: [HACKERS] Proposal : REINDEX xxx VERBOSE

On Wed, May 13, 2015 at 2:10 PM, Alvaro Herrera wrote: > Uh, are we really using INFO to log this? I thought that was a > discouraged level to use anymore. Why not NOTICE? Well, as Masahiko-san points out, VACUUM uses INFO. I can't see any good reason to make this different. > Also, when mult

[HACKERS] Re: Abbreviated keys for Datum tuplesort (was: Re: B-Tree support function number 3 (strxfrm() optimization))

On Wed, May 13, 2015 at 2:44 PM, Peter Geoghegan wrote: > On Wed, May 13, 2015 at 11:40 AM, Robert Haas wrote: >> Committed. Thanks for the patch and your patience. > > This comment was not updated: > > /* > * The sortKeys variable is used by every case other than the datum and > * hash index

Re: [HACKERS] KNN-GiST with recheck

On Wed, May 13, 2015 at 10:16 PM, Heikki Linnakangas wrote: > On 04/17/2015 12:05 PM, Alexander Korotkov wrote: > >> On Wed, Feb 25, 2015 at 12:15 PM, Alexander Korotkov < >> aekorot...@gmail.com> >> wrote: >> >> Hi! >>> >>> On Tue, Feb 24, 2015 at 5:39 PM, Tomas Vondra < >>> tomas.von...@2ndqua

Re: [HACKERS] KNN-GiST with recheck

On 04/17/2015 12:05 PM, Alexander Korotkov wrote: On Wed, Feb 25, 2015 at 12:15 PM, Alexander Korotkov wrote: Hi! On Tue, Feb 24, 2015 at 5:39 PM, Tomas Vondra < tomas.von...@2ndquadrant.com> wrote: On 17.2.2015 14:21, Alexander Korotkov wrote: On Sun, Feb 15, 2015 at 2:08 PM, Alexander Ko

Re: [HACKERS] Proposal : REINDEX xxx VERBOSE

On Thu, May 14, 2015 at 3:10 AM, Alvaro Herrera wrote: > Uh, are we really using INFO to log this? I thought that was a > discouraged level to use anymore. Why not NOTICE? > I think it should be INFO level because it is a information of REINDEX command,such as progress of itself, CPU usage and

[HACKERS] Re: Abbreviated keys for Datum tuplesort (was: Re: B-Tree support function number 3 (strxfrm() optimization))

On Wed, May 13, 2015 at 11:40 AM, Robert Haas wrote: > Committed. Thanks for the patch and your patience. This comment was not updated: /* * The sortKeys variable is used by every case other than the datum and * hash index cases; it is set by tuplesort_begin_xxx. tupDesc is only * used by t

[HACKERS] Re: Abbreviated keys for Datum tuplesort (was: Re: B-Tree support function number 3 (strxfrm() optimization))

On Fri, Jan 23, 2015 at 4:13 PM, Andrew Gierth wrote: > [pruning the Cc: list and starting a new thread] > > Here's the cleaned-up version of the patch to allow abbreviated keys > when sorting a single Datum. This also removes comments that suggest > that the caller of tuplesort_begin_datum should

Re: [HACKERS] Proposal : REINDEX xxx VERBOSE

Uh, are we really using INFO to log this? I thought that was a discouraged level to use anymore. Why not NOTICE? Also, when multiple tables are reindexed, do we emit lines for each index, or only for each table? If we're going to emit a line for each index in the single-table mode, it seems mor

Re: [HACKERS] Proposal : REINDEX xxx VERBOSE

On Thu, May 14, 2015 at 12:28 AM, Robert Haas wrote: > On Thu, May 7, 2015 at 6:55 PM, Sawada Masahiko wrote: >> Sorry, I forgot attach files. > > Review comments: > > - Customarily we use int, rather than uint8, for flags variables. I > think we should do that here also. > > - reindex_index() e

Re: [HACKERS] Streaming replication and WAL archive interactions

On 05/13/2015 04:29 PM, Robert Haas wrote: On Wed, May 13, 2015 at 8:53 AM, Heikki Linnakangas wrote: Our manual says that archive_command should refuse to overwrite an existing file. But to work-around the double-archival problem, where the same file is archived twice, it would be even better

Re: [HACKERS] Triaging the remaining open commitfest items

On Wed, May 13, 2015 at 1:06 PM, Tom Lane wrote: > Andres Freund writes: >> On 2015-05-13 11:38:27 -0400, Tom Lane wrote: >>> * parallel mode/contexts >>> >>> Robert's patch, his to deal with (likewise for "assessing parallel-safety"). > >> Just as a note, a large part of this has been committed.

Re: [HACKERS] Triaging the remaining open commitfest items

Andres Freund writes: > On 2015-05-13 11:38:27 -0400, Tom Lane wrote: >> * parallel mode/contexts >> >> Robert's patch, his to deal with (likewise for "assessing parallel-safety"). > Just as a note, a large part of this has been committed. Right, and Robert commented that he isn't planning to d

Re: [HACKERS] EvalPlanQual behaves oddly for FDW queries involving system columns

Etsuro Fujita writes: > On 2015/05/13 6:22, Tom Lane wrote: >> Of course, if we don't do that then we still have your original gripe >> about ctid not being correct in EvalPlanQual results. I poked at this >> a bit and it seems like we could arrange to pass ctid through even in >> the ROW_MARK_CO

Re: [HACKERS] Triaging the remaining open commitfest items

On 2015-05-13 11:38:27 -0400, Tom Lane wrote: > * parallel mode/contexts > > Robert's patch, his to deal with (likewise for "assessing parallel-safety"). Just as a note, a large part of this has been committed. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make chang

Re: [HACKERS] subxcnt defined as signed integer in SnapshotData and SerializeSnapshotData

On Wed, May 13, 2015 at 12:17 PM, Michael Paquier wrote: > On Thu, May 14, 2015 at 1:03 AM, Michael Paquier wrote: >> On Thu, May 14, 2015 at 12:02 AM, Robert Haas wrote: >>> I'm just going to remove the useless assertion for now. What you're >>> proposing here may (or may not) be worth doing, bu

Re: [HACKERS] a few thoughts on the schedule

On 05/13/2015 09:27 AM, Tom Lane wrote: Andres Freund writes: On 2015-05-13 11:52:40 -0400, Tom Lane wrote: One thing that continues to bother me about the commitfest process is that it's created a default expectation that things get committed eventually. Agreed that this is a problem. I t

Re: [HACKERS] Triaging the remaining open commitfest items

On 13/05/15 17:38, Tom Lane wrote: * Sequence Access Method Heikki's marked as reviewer, so it's his call as to whether this is ready, but the impression I have is that there's not really consensus as to whether the API is good. If not, it's something I think we should push to 9.6. Heikki s

Re: [HACKERS] a few thoughts on the schedule

Andres Freund writes: > On 2015-05-13 11:52:40 -0400, Tom Lane wrote: >> One thing that continues to bother me about the commitfest process is that >> it's created a default expectation that things get committed eventually. > Agreed that this is a problem. I think we need to work on giving that >

Re: [HACKERS] Default Roles (was: Additional role attributes)

Robert Haas writes: > Now, if six people who are all well-known PostgreSQL contributors show > up and they all say "I looked at the latest version of this carefully > and I'm confident you've got it right", then go ahead: push it. But > don't make the mistake of thinking that because you're confi

Re: [HACKERS] Triaging the remaining open commitfest items

On 05/13/2015 11:38 AM, Tom Lane wrote: * Grouping Sets I had originally promised to be committer for this one, and still want to go look at it, but Robert's nearby message about not committing stuff in haste definitely seems to apply. That makes me sad. I wish you would still try. Sadly,

Re: [HACKERS] subxcnt defined as signed integer in SnapshotData and SerializeSnapshotData

On Thu, May 14, 2015 at 1:03 AM, Michael Paquier wrote: > On Thu, May 14, 2015 at 12:02 AM, Robert Haas wrote: >> I'm just going to remove the useless assertion for now. What you're >> proposing here may (or may not) be worth doing, but it carries a >> non-zero risk of breaking something somewhere

Re: [HACKERS] Triaging the remaining open commitfest items

* Robert Haas (robertmh...@gmail.com) wrote: > On Wed, May 13, 2015 at 11:38 AM, Tom Lane wrote: > > * Additional role attributes > > > > Is this ready to commit? Stephen's call. > > -1 for committing this, per discussion earlier today on a thread > that's probably not linked into the CF app. L

Re: [HACKERS] a few thoughts on the schedule

On 2015-05-13 11:52:40 -0400, Tom Lane wrote: > One thing that continues to bother me about the commitfest process is that > it's created a default expectation that things get committed eventually. > But many new ideas are just plain bad, and others are things that nobody > but the author cares abo

Re: [HACKERS] Triaging the remaining open commitfest items

Andres Freund writes: > On 2015-05-13 11:38:27 -0400, Tom Lane wrote: >> * Manipulating complex types as non-contiguous structures in-memory >> >> This one's mine of course. I've been hoping to get more independent >> performance testing than it's gotten, but time grows short. I'm inclined >> t

Re: [HACKERS] Triaging the remaining open commitfest items

Tom, all, * Tom Lane (t...@sss.pgh.pa.us) wrote: > * Optimization for updating foreign tables in Postgres FDW > > I concur with Stephen's assessment that this doesn't look well designed. > I think we should just mark it RWF for now. I had meant to do that already, sorry about that, done now. >

Re: [HACKERS] a few thoughts on the schedule

On 05/13/2015 08:09 AM, Tom Lane wrote: What I think we need to be doing this week is triage. Commit what's ready, punt what's not. I'll post a separate list about that. regards, tom lane +1 JD -- Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564

Re: [HACKERS] Default Roles (was: Additional role attributes)

On Wed, May 13, 2015 at 11:50 AM, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> Yes: let's punt this to 9.6. The decisions you're making here are way >> too significant to be making a couple of days before feature freeze, >> and this patch has changed massively since it w

Re: [HACKERS] a few thoughts on the schedule

On 2015-05-13 11:49:45 -0400, Robert Haas wrote: > On Wed, May 13, 2015 at 11:40 AM, Bruce Momjian wrote: > > Let me put a finer point on this --- whatever gets pushed to 9.6 > > unreasonably will be a feature we don't have in 9.5 and will discourage > > future development. I know we can't do mag

Re: [HACKERS] subxcnt defined as signed integer in SnapshotData and SerializeSnapshotData

On Thu, May 14, 2015 at 12:02 AM, Robert Haas wrote: > On Sat, May 9, 2015 at 8:48 AM, Michael Paquier > wrote: >> On Fri, May 8, 2015 at 10:27 PM, Simon Riggs wrote: >>> On 8 May 2015 at 13:02, Michael Paquier wrote: I think that we should redefine subxcnt as uint32 for consistency with >>>

Re: [HACKERS] Triaging the remaining open commitfest items

On 2015-05-13 11:38:27 -0400, Tom Lane wrote: > Looking at what remains open in the current commitfest: > > * fsync $PGDATA recursively at startup > > Andres is the reviewer of record on this one. He should either commit it > if he feels it's ready, or bounce it to next CF if not. The more impo

Re: [HACKERS] Triaging the remaining open commitfest items

On Wed, May 13, 2015 at 11:38 AM, Tom Lane wrote: > * fsync $PGDATA recursively at startup > > Andres is the reviewer of record on this one. He should either commit it > if he feels it's ready, or bounce it to next CF if not. I committed the first part of this as 2ce439f3379aed857517c8ce20748565

Re: [HACKERS] a few thoughts on the schedule

On Wed, May 13, 2015 at 11:52:40AM -0400, Tom Lane wrote: > Bruce Momjian writes: > > Let me put a finer point on this --- whatever gets pushed to 9.6 > > unreasonably will be a feature we don't have in 9.5 and will discourage > > future development. I know we can't do magic, but now is the time

Re: [HACKERS] a few thoughts on the schedule

Bruce Momjian writes: > Let me put a finer point on this --- whatever gets pushed to 9.6 > unreasonably will be a feature we don't have in 9.5 and will discourage > future development. I know we can't do magic, but now is the time to > try. The other side of that coin is that the stuff that ends

Re: [HACKERS] Default Roles (was: Additional role attributes)

* Robert Haas (robertmh...@gmail.com) wrote: > Yes: let's punt this to 9.6. The decisions you're making here are way > too significant to be making a couple of days before feature freeze, > and this patch has changed massively since it was first submitted. > There isn't time now for people who wan

Re: [HACKERS] a few thoughts on the schedule

On Wed, May 13, 2015 at 11:40 AM, Bruce Momjian wrote: >> We have three days left so I think we need committers to devote serious >> time, if possible, to helping us resolve as much as we can. If we start >> thinking about this on Friday, it is too late. > > Let me put a finer point on this --- w

Re: [HACKERS] a few thoughts on the schedule

* Bruce Momjian (br...@momjian.us) wrote: > On Wed, May 13, 2015 at 11:19:29AM -0400, Bruce Momjian wrote: > > On Wed, May 13, 2015 at 10:32:03AM -0400, Robert Haas wrote: > > > We also need to start thinking about what happens after feature > > > freeze. The CommitFest application currently lists

Re: [HACKERS] Triaging the remaining open commitfest items

I wrote: > * Cube extension kNN support > This is still marked as "needs review", I'm afraid we have to push to 9.6. > * compress method for spgist Sigh. There was a "Ditto" under this one, but somehow it disappeared in editing :-( regards, tom lane -- Sent via pgsql

Re: [HACKERS] a few thoughts on the schedule

On Wed, May 13, 2015 at 11:19:29AM -0400, Bruce Momjian wrote: > On Wed, May 13, 2015 at 10:32:03AM -0400, Robert Haas wrote: > > We also need to start thinking about what happens after feature > > freeze. The CommitFest application currently lists a 2015-06 > > CommitFest which, according to prev

[HACKERS] Triaging the remaining open commitfest items

Looking at what remains open in the current commitfest: * fsync $PGDATA recursively at startup Andres is the reviewer of record on this one. He should either commit it if he feels it's ready, or bounce it to next CF if not. * EvalPlanQual behaves oddly for FDW queries involving system columns

Re: [HACKERS] Proposal : REINDEX xxx VERBOSE

On Thu, May 7, 2015 at 6:55 PM, Sawada Masahiko wrote: > Sorry, I forgot attach files. Review comments: - Customarily we use int, rather than uint8, for flags variables. I think we should do that here also. - reindex_index() emits a log message either way, but at DEBUG2 level without VERBOSE a

Re: [HACKERS] a few thoughts on the schedule

On Wed, May 13, 2015 at 10:32:03AM -0400, Robert Haas wrote: > We also need to start thinking about what happens after feature > freeze. The CommitFest application currently lists a 2015-06 > CommitFest which, according to previous practice, would be expected to > start on the 15th of the month.

Re: [HACKERS] a few thoughts on the schedule

On Wed, May 13, 2015 at 11:09 AM, Tom Lane wrote: >> - Code review for foreign/custom join pushdown patch - Whacks around >> my earlier commit without agreement or adequate discussion, apparently >> on the theory that Tom always knows best. > > As far as that goes, obviously I've got strong opinio

Re: [HACKERS] PATCH: pgbench allow '=' in \set

On Thu, May 7, 2015 at 2:18 PM, Fabien COELHO wrote: > Since an expression syntax has been added to pgbench, I find that the > readability of expressions is not great. An extra '=' improves the situation > for me: > >\set id = 1 + abs((:id * 1021) % (10 * :scale)) > > seems slightly better

Re: [HACKERS] a few thoughts on the schedule

Robert Haas writes: > It's pretty clear that the impending feature freeze proposed by core > has spurred a lot of activity. This is both good and bad. On the > good side, we're getting a bunch of stuff done. On the bad side, > there is inevitably going to be a temptation to rush things in that

Re: [HACKERS] subxcnt defined as signed integer in SnapshotData and SerializeSnapshotData

On Sat, May 9, 2015 at 8:48 AM, Michael Paquier wrote: > On Fri, May 8, 2015 at 10:27 PM, Simon Riggs wrote: >> On 8 May 2015 at 13:02, Michael Paquier wrote: >>> I think that we should redefine subxcnt as uint32 for consistency with >>> xcnt, and remove the two assertions that 924bcf4 has introdu

[HACKERS] a few thoughts on the schedule

Hi, It's pretty clear that the impending feature freeze proposed by core has spurred a lot of activity. This is both good and bad. On the good side, we're getting a bunch of stuff done. On the bad side, there is inevitably going to be a temptation to rush things in that are really not quite ful

Re: [HACKERS] Default Roles (was: Additional role attributes)

On Wed, May 13, 2015 at 10:16:39AM -0400, Robert Haas wrote: > On Tue, May 12, 2015 at 11:07 PM, Stephen Frost wrote: > > Thoughts? Comments? Suggestions? > > Yes: let's punt this to 9.6. The decisions you're making here are way > too significant to be making a couple of days before feature fr

Re: [HACKERS] Default Roles (was: Additional role attributes)

On Tue, May 12, 2015 at 11:07 PM, Stephen Frost wrote: > Thoughts? Comments? Suggestions? Yes: let's punt this to 9.6. The decisions you're making here are way too significant to be making a couple of days before feature freeze, and this patch has changed massively since it was first submitted

Re: [HACKERS] Silent Data Manipulation - Time(stamp) w/o Time Zone Literals w/ TZ

On Tue, May 12, 2015 at 1:57 PM, David G. Johnston wrote: > "In a literal that has been determined to be timestamp without time zone, > PostgreSQL will silently ignore any time zone indication. That is, the > resulting value is derived from the date/time fields in the input value, and > is not adj

Re: [HACKERS] Sequence Access Method WIP

On 13/05/15 14:15, Heikki Linnakangas wrote: I don't see what calamity will occur if we commit this. If you don't want a sequence AM, don't ever use this. I'd like the API to be good for its purpose. Also, I did mention that the the current patch makes the situation slightly worse for people wh

Re: [HACKERS] Why does contain_leaked_vars believe MinMaxExpr is safe?

On Tue, May 12, 2015 at 7:22 PM, Tom Lane wrote: > MinMaxExpr is an implicit invocation of a btree comparison function. > Are we supposing that all of those are necessarily leakproof? I suspect it's an oversight, because the comment gives no hint that any such intention was present. It's been mo

Re: [HACKERS] Streaming replication and WAL archive interactions

On Wed, May 13, 2015 at 8:53 AM, Heikki Linnakangas wrote: > Our manual says that archive_command should refuse to overwrite an existing > file. But to work-around the double-archival problem, where the same file is > archived twice, it would be even better if it would simply return success if > t

Re: [HACKERS] Auditing extension for PostgreSQL (Take 2)

On Mon, May 11, 2015 at 9:07 PM, David Steele wrote: > On 5/1/15 5:58 AM, Sawada Masahiko wrote: >> For now, since pg_audit patch has a pg_audit_ddl_command_end() >> function which uses part of un-committed "deparsing utility commands" >> patch API, >> pg_audit patch is completely depend on that p

Re: [HACKERS] Streaming replication and WAL archive interactions

On 05/13/2015 03:36 PM, Robert Haas wrote: On Mon, May 11, 2015 at 12:00 PM, Heikki Linnakangas wrote: And here is a new version of the patch. I kept the approach of using pgstat, but it now only polls pgstat every 10 seconds, and doesn't block to wait for updated stats. It's not entirely a n

Re: [HACKERS] One question about security label command

2015-05-13 21:45 GMT+09:00 Robert Haas : > On Sun, May 10, 2015 at 3:15 AM, Kohei KaiGai wrote: >> 2015-05-01 9:52 GMT+09:00 Kohei KaiGai : >>> 2015-05-01 7:40 GMT+09:00 Alvaro Herrera : Kouhei Kaigai wrote: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > > The idea of making the regre

Re: [HACKERS] One question about security label command

On Sun, May 10, 2015 at 3:15 AM, Kohei KaiGai wrote: > 2015-05-01 9:52 GMT+09:00 Kohei KaiGai : >> 2015-05-01 7:40 GMT+09:00 Alvaro Herrera : >>> Kouhei Kaigai wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > The idea of making the regression test entirely independent of the > >

Re: [HACKERS] Streaming replication and WAL archive interactions

On Mon, May 11, 2015 at 12:00 PM, Heikki Linnakangas wrote: > And here is a new version of the patch. I kept the approach of using pgstat, > but it now only polls pgstat every 10 seconds, and doesn't block to wait for > updated stats. It's not entirely a new problem, but this error message has go

Re: [HACKERS] Default Roles

All, * Heikki Linnakangas (hlinn...@iki.fi) wrote: > On 05/13/2015 06:07 AM, Stephen Frost wrote: > >This does change the XLOG functions to require pg_monitor, as discussed > >on the other thread where it was pointed out by Heikki that the XLOG > >location information could be used to extract sens

Re: [HACKERS] Disabling trust/ident authentication configure option

On Wed, May 13, 2015 at 8:01 AM, Volker Aßmann wrote: > Even in this case it still means that any breach in any of the network > services running on your application server would immediately own your > database, or at least everything your application can access. This applies > even to totally unr

Re: [HACKERS] Sequence Access Method WIP

On 05/13/2015 02:12 PM, Simon Riggs wrote: This has had around 2 years of thought at this point. I don't agree it needs more thought. Noted. There is one clear use case for this and it is of benefit to many distributed architectures. Right. What's your point? I don't see what calamity wil

Re: [HACKERS] Disabling trust/ident authentication configure option

On Mon, May 11, 2015 at 10:00 PM, Robert Haas wrote: > On Thu, May 7, 2015 at 4:57 PM, Stephen Frost wrote: > > * Robert Haas (robertmh...@gmail.com) wrote: > >> On Thu, May 7, 2015 at 11:02 AM, Stephen Frost > wrote: > >> > I realize it's not going to be popular, but I'd love to have 'trust' >

  1   2   >