Re: [HACKERS] GIN pending list clean up exposure to SQL

On 20/01/2016 15:17, Fujii Masao wrote: > > When I compiled the PostgreSQL with the patch, I got the following error. > ISTM that the inclusion of pg_am.h header file is missing in ginfast.c. > > ginfast.c: In function 'gin_clean_pending_list': > ginfast.c:980: error: 'GIN_AM_OID' undeclared

Re: [HACKERS] Combining Aggregates

On Wed, Jan 20, 2016 at 11:06 AM, Robert Haas wrote: > On Wed, Jan 20, 2016 at 7:38 AM, David Rowley > wrote: >> Agreed. So I've attached a version of the patch which does not have any of >> the serialise/deserialise stuff in it. > > I

Re: [HACKERS] Releasing in September

On 22 January 2016 at 05:07, Noah Misch wrote: > On Wed, Jan 20, 2016 at 06:58:24PM +, Simon Riggs wrote: > > The main problem is the length of the integration phase, which is mostly > > where nothing happens. > > The open items wiki page saw steady change from 30 April to

Re: [HACKERS] Performance improvement for joins where outer side is unique

On 23 January 2016 at 05:36, Tomas Vondra wrote: > OK. I've looked at the patch again today, and it seems broken bv 45be99f8 as > the partial paths were not passing the unique_inner to the create_*_path() > functions. The attached patch should fix that. > Thanks for

Re: [HACKERS] Combining Aggregates

On 23 January 2016 at 09:17, Jeff Janes wrote: > On Wed, Jan 20, 2016 at 11:06 AM, Robert Haas wrote: >> On Wed, Jan 20, 2016 at 7:38 AM, David Rowley >> wrote: >>> Agreed. So I've attached a version of the patch which

Re: [HACKERS] Proposal: Trigonometric functions in degrees

Dean Rasheed writes: > I tried using feclearexcept + fetestexcept as recommended by > POSIX.1-2008, and that does indeed make the above examples compliant > on my linux box. Unfortunately it introduces new errors -- asin starts > generating FE_UNDERFLOW errors for

Re: [HACKERS] Declarative partitioning

> > > So for now, you create an empty partitioned table specifying all the > partition keys without being able to define any partitions in the same > statement. Partitions (and partitions thereof, if any) will be created > using CREATE PARTITION statements, one for each. > ...and I would assume

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Hi, Here's an updated patch improving on how the horizontal and vertical headers can be sorted. The discussion upthread went into how it was desirable to have independant sorts for these headers, possibly driven by another column, in addition to the query's ORDER BY. Thus the options now

Re: [HACKERS] Patch: Implement failover on libpq connect level.

You're editing the expected file for the libpq-regress thingy, but you haven't added any new lines to test the new capability. I think it'd be good to add some there. (I already said this earlier in the thread; is there any reason you ignored it the first time?) If the test program requires

Re: [HACKERS] Releasing in September

On Fri, Jan 22, 2016 at 7:19 PM, Andres Freund wrote: > On 2016-01-22 08:18:45 -0600, Jim Nasby wrote: > > Personally, I don't see why we have our scarcest resource doing what is > > essentially a project management task, especially when at least one > > commercial company

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On Tue, 19 Jan 2016 14:34:54 + Thom Brown wrote: > > The segfault issue I originally reported now appears to be resolved. > > But now I have another one: > > psql >

Re: [HACKERS] Releasing in September

On 1/20/16 4:29 PM, Bruce Momjian wrote: On Wed, Jan 20, 2016 at 09:12:07AM -0800, Joshua Drake wrote: I just don't buy the Ubuntu release model for our database. Ubuntu is trying to balance hot features vs stability, while we are really focused on stability, similar to Debian. I understand

Re: [HACKERS] Releasing in September

On 22 January 2016 at 16:34, Robert Haas wrote: > For my part, I am not sure the names in the release notes are actually > all that helpful. It has one important effect of current interest: establishing the truth that multiple people and multiple companies are involved

Re: [HACKERS] Releasing in September

On 2016-01-22 08:50:15 -0600, Jim Nasby wrote: > I think that's a great way to ensure we shrink the pool of reviewers when > someone works on a patch and then it goes nowhere. True, it really sucks. But what's your counter proposal? Commitfests dragging on forever, and people burning out on

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On 1/21/16 4:57 PM, Pavel Stehule wrote: It is not correct - outside PLPython you got a Error (PostgreSQL error has not any classes), and isn't important the raising class (Error or SPIError). Inside PL/Python you will got SPIError or successors (based on SQLcode). Right. The closest thing we

Re: [HACKERS] Releasing in September

On 1/21/16 2:29 AM, Amit Kapila wrote: I also think there should be some way to give credit to CFM, if it is difficult to do anything related to money, then we can enforce that if CFM submits any patches for next CF, then those should be prioritised. Personally, I don't see why we have our

Re: [HACKERS] Releasing in September

On 2016-01-22 08:40:28 -0600, Jim Nasby wrote: > Ideally reviewers shouldn't be doing any testing, because the tests > that are part of the patch should answer every question they would > have, but I don't see that happening until we have a separate > automation-only target that we don't care how

Re: [HACKERS] Releasing in September

On 2016-01-22 08:18:45 -0600, Jim Nasby wrote: > Personally, I don't see why we have our scarcest resource doing what is > essentially a project management task, especially when at least one > commercial company has offered to donate paid staff time. Because so far all CFs that weren't managed by

Re: [HACKERS] Releasing in September

On 1/20/16 11:40 AM, Tom Lane wrote: Yeah. It's certainly unfair if someone's patch doesn't get reviewed, but there are only 24 hours in a day, and we have a limited pool of reviewer and committer manpower. I think we just have to say that sometimes life is unfair. I think that's a great way

Re: [HACKERS] Releasing in September

On 1/20/16 11:49 PM, Tom Lane wrote: Michael Paquier writes: On Thu, Jan 21, 2016 at 2:30 PM, Peter Geoghegan wrote: What benefit does porting sqlsmith for inclusion in core have? I can only think of costs, including those that you mentioned. We

Re: [HACKERS] count_nulls(VARIADIC "any")

On 1/21/16 1:48 PM, Pavel Stehule wrote: the form of regress tests is not pretty significant issue. Jim's design is little bit transparent, Marko's is maybe little bit practical. Both has sense from my opinion, and any hasn't significant advantage against other. any possible

Re: [HACKERS] Extracting fields from 'infinity'::TIMESTAMP[TZ]

On 01/22/2016 04:28 AM, Tom Lane wrote: > Vik Fearing writes: >> I looked around for other places where this code should be used and >> didn't find any. I am marking this patch Ready for Committer. > > I pushed this with some adjustments, mainly to make sure that the >

Re: [HACKERS] Patch: fix lock contention for HASHHDR.mutex

Hi, > First of all, why not merge both patches into one? They aren't too > big anyway. Agree. > I think comments should be changed, to be more informative here. > Add a comment here too. > Maybe you should explain this magic number 7 in the comment above? Done. > Then, this thread became

Re: [HACKERS] Patch: fix lock contention for HASHHDR.mutex

This patch affects header files. By any chance didn't you forget to run `make clean` after applying it? As we discussed above, when you change .h files autotools doesn't rebuild dependent .c files:

Re: [HACKERS] pg_dump fails on domain constraint comments

Michael Paquier wrote: > On Tue, Jan 12, 2016 at 7:56 AM, Elvis Pranskevichus > wrote: > > It looks like pg_dump emits incorrect text for domain constraint comments: > > > > Assuming the following structure, > > Nice catch! qtypname already has fmtId applied to it, so quotes

Re: [HACKERS] Proposal: Generic WAL logical messages

Hi, here is updated version of this patch, calling the messages logical (decoding) messages consistently everywhere and removing any connection to standby messages. Moving this to it's own module gave me place to write some brief explanation about this so the code documentation has hopefully

Re: [HACKERS] silent data loss with ext4 / all current versions

Hi, On 01/22/2016 06:45 AM, Michael Paquier wrote: So, I have been playing with a Linux VM with VMware Fusion and on ext4 with data=ordered the renames are getting lost if the root folder is not fsync. By killing-9 the VM I am able to reproduce that really easily. Yep. Same experience here

Re: [HACKERS] silent data loss with ext4 / all current versions

On Fri, Jan 22, 2016 at 9:26 AM, Tomas Vondra wrote: > Hi, > > On 01/22/2016 06:45 AM, Michael Paquier wrote: > > So, I have been playing with a Linux VM with VMware Fusion and on >> ext4 with data=ordered the renames are getting lost if the root >> folder is not

Re: [HACKERS] Parallel Aggregate

On 22 January 2016 at 17:25, Haribabu Kommi wrote: > Along with these changes, I added a float8 combine function to see > how it works under parallel aggregate, it is working fine for float4, but > giving small data mismatch with float8 data type. > > postgres=# select

Re: [HACKERS] silent data loss with ext4 / all current versions

On Fri, Jan 22, 2016 at 8:26 AM, Tomas Vondra wrote: > On 01/22/2016 06:45 AM, Michael Paquier wrote: > >> So, I have been playing with a Linux VM with VMware Fusion and on >> ext4 with data=ordered the renames are getting lost if the root >> folder is not fsync. By

Re: [HACKERS] silent data loss with ext4 / all current versions

On 2016-01-22 21:32:29 +0900, Michael Paquier wrote: > Group shot with 3), 4) and 5). Well, there is no data loss here, > putting me in the direction of considering this addition of an fsync > as an optimization and not a bug. I think this is an extremely weak argument. The reasoning when exactly

Re: [HACKERS] silent data loss with ext4 / all current versions

On Fri, Jan 22, 2016 at 5:26 PM, Tomas Vondra wrote: > On 01/22/2016 06:45 AM, Michael Paquier wrote: >> Here are some comments about your patch after a look at the code. >> >> Regarding the additions in fsync_fname() in xlog.c: >> 1) In InstallXLogFileSegment,

Re: [HACKERS] Removing Functionally Dependent GROUP BY Columns

David Rowley writes: > [ prune_group_by_clause_59f15cf_2016-01-15.patch ] I spent some time looking through this but decided that it needs some work to be committable. The main thing I didn't like was that identify_key_vars seems to have a rather poorly chosen API:

Re: [HACKERS] Relation extension scalability

On Tue, Jan 12, 2016 at 2:41 PM, Dilip Kumar wrote: > On Thu, Jan 7, 2016 at 4:53 PM, Andres Freund wrote: > >> On 2016-01-07 16:48:53 +0530, Amit Kapila wrote: >> >> I think it's a worthwhile approach to pursue. But until it actually >> fixes the

Re: [HACKERS] Releasing in September

On Fri, Jan 22, 2016 at 11:46 PM, Simon Riggs wrote: > On 22 January 2016 at 16:34, Robert Haas wrote: > > >> For my part, I am not sure the names in the release notes are actually >> all that helpful. > > > It has one important effect of current

[HACKERS] insert/update performance

Hi All, Here is my test environment: postgresql 9.4.5, Ubuntu 14.04, 8 CPU core, 8GB ram, SCSI hard disk I have a table with 70 columns, and 6 indexes. The data flow is a special OLTP model: frequent inserts (2000 tps), and each inserted row would be updated very soon (i.e. the number of

Re: [HACKERS] insert/update performance

On Sat, Jan 23, 2016 at 12:13 PM, Jinhua Luo wrote: > > Hi All, > > Here is my test environment: > > postgresql 9.4.5, Ubuntu 14.04, 8 CPU core, 8GB ram, SCSI hard disk > > I have a table with 70 columns, and 6 indexes. The data flow is a > special OLTP model: frequent

Re: [HACKERS] insert/update performance

Hi, The vacuum doesn't recycle the rows obsoleted by update? I don't think so. In the above vacuum result, I do not delete any rows, but the vacuum still recycles a fraction of rows, obviously they're obsoleted by update. I know plain vacuum (without full option) do not reduce the size of the

Re: [HACKERS] proposal: function parse_ident

Hi Pavel, Sorry for the lack of review here. I didn't realize I was still the reviewer for this after it had been moved to another commitfest. That said, I think I've exhausted my usefulness here as a reviewer. Marking ready for committer. .m -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Fwd: Re: [DOCS] Document Upper Limit for NAMEDATELEN in pgsql 9.5+

Robert Haas writes: > Actually, though, varstr_levenshtein_less_equal() never gets called > from parse_relation.c with a distance bound of more than four, so it > can't actually go quadratic. There's another call in that file to > varstr_levenshtein(), which in retrospect

Re: [HACKERS] Declarative partitioning

Hi Amit, thanks for working on this. Seems the last version of the patch was submitted more than 2 months ago and I believe large parts of it will get reworked based on the extensive discussion on this list, so I haven't looked at the code at all. I'd like to comment on the one thing and

Re: [HACKERS] WIP: Failover Slots

On Fri, Jan 22, 2016 at 2:46 AM, Craig Ringer wrote: > It's also going to be necessary to handle what happens when a new failover > slot (physical or logical) is created on the master where it conflicts with > the name of a non-failover physical slot that was created on the

Re: [HACKERS] WIP: Failover Slots

On 2016-01-22 11:40:24 -0500, Robert Haas wrote: > It occurred to me to wonder if it might be better to > propagate logical slots partially or entirely outside the WAL stream, > because with this design you will end up with the logical slots on > every replica, including cascaded replicas, and I'm

Re: [HACKERS] Tsvector editing functions

On 12/30/2015 06:49 PM, Stas Kelvich wrote: Hi, Tomáš! Thanks for comprehensive review. On 15 Dec 2015, at 06:07, Tomas Vondra wrote: 1) It's a bit difficult to judge the usefulness of the API, as I've always been a mere user of full-text search, and I

Re: [HACKERS] Combining Aggregates

On Thu, Jan 21, 2016 at 4:08 PM, David Rowley wrote: > It's quite simple to test how much of a win it'll be in the serial > case today, and yes, it's not much, but it's a bit. > > create table t1 as select x from generate_series(1,100) x(x); > vacuum analyze t1;

Re: [HACKERS] Releasing in September

On Wed, Jan 20, 2016 at 11:46 PM, Peter Geoghegan wrote: > On Wed, Jan 20, 2016 at 8:32 PM, Michael Paquier > wrote: >> Perhaps some people are more interested in implementing new >> features than working on bugs and would just continue hacking and >>

Re: [HACKERS] Releasing in September

Bruce Momjian wrote: > FYI, the fact that feature authors appear in the release notes is an > artifact of how we track who wrote which stuff, and is not designed for > rewarding, though it has that effect. I think you can claim this all you want, but I'd be surprised if anyone actually believed

Re: [HACKERS] Releasing in September

On Fri, Jan 22, 2016 at 10:43 AM, Alvaro Herrera wrote: >> If we were to expand that to >> cover reviewers, we would then be overburdinging that system and we >> would probably end up removing all names from the release notes. > > To me, this reads just as a threat that

Re: [HACKERS] Performance improvement for joins where outer side is unique

Hi, On 12/17/2015 02:17 PM, David Rowley wrote: On 17 December 2015 at 19:11, Simon Riggs > wrote: On 17 December 2015 at 00:17, Tomas Vondra > wrote:

Re: [HACKERS] pglogical - logical replication contrib module

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:not tested This reply will covers a 10,000 foot level review of the feature (some of

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On 22 January 2016 at 19:30, Victor Wagner wrote: > On Tue, 19 Jan 2016 14:34:54 + > Thom Brown wrote: > >> >> The segfault issue I originally reported now appears to be resolved. >> >> But now I have another one: >> >> psql >>

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On 23 January 2016 at 03:32, Thom Brown wrote: > On 22 January 2016 at 19:30, Victor Wagner wrote: >> On Tue, 19 Jan 2016 14:34:54 + >> Thom Brown wrote: >> >>> >>> The segfault issue I originally reported now appears to be resolved. >>>

Re: [HACKERS] Parallel Aggregate

On Fri, Jan 22, 2016 at 10:13 PM, David Rowley wrote: > On 22 January 2016 at 17:25, Haribabu Kommi wrote: >> Along with these changes, I added a float8 combine function to see >> how it works under parallel aggregate, it is working fine

Re: [HACKERS] silent data loss with ext4 / all current versions

On 01/23/2016 02:35 AM, Michael Paquier wrote: On Fri, Jan 22, 2016 at 9:41 PM, Greg Stark wrote: On Fri, Jan 22, 2016 at 8:26 AM, Tomas Vondra wrote: On 01/22/2016 06:45 AM, Michael Paquier wrote: So, I have been playing with a Linux VM with

Re: [HACKERS] Combining Aggregates

On 23 January 2016 at 09:44, David Rowley wrote: > On 23 January 2016 at 09:17, Jeff Janes wrote: >> On Wed, Jan 20, 2016 at 11:06 AM, Robert Haas wrote: >>> On Wed, Jan 20, 2016 at 7:38 AM, David Rowley >>>

Re: [HACKERS] silent data loss with ext4 / all current versions

On Fri, Jan 22, 2016 at 9:41 PM, Greg Stark wrote: > On Fri, Jan 22, 2016 at 8:26 AM, Tomas Vondra > wrote: >> On 01/22/2016 06:45 AM, Michael Paquier wrote: >> >>> So, I have been playing with a Linux VM with VMware Fusion and on >>> ext4 with

Re: [HACKERS] Proposal: Trigonometric functions in degrees

I wrote: > Dean Rasheed writes: >> Attached are patches for this and the new functions in degrees, now >> with POSIX compatible Inf/NaN handling. > Pushed with minor, mostly cosmetic fixes. So the early returns from the buildfarm aren't very good: * tern/sungazer