Re: [HACKERS] pg9.6 segfault using simple query (related to use fk for join estimates)

On 6 May 2016 at 02:48, David Rowley wrote: > In the attached I've left the GUC remaining. The reason for the GUC is > for testing purposes and it should be removed before release. It > should likely be documented though, even if we're planning to remove > it later.

Re: [HACKERS] Is pg_control file crashsafe?

On 2016-05-05 00:32:29 -0400, Tom Lane wrote: > To repeat, I'm pretty hesitant to change this logic. While this is not > the first report we've ever heard of loss of pg_control, I believe I could > count those reports without running out of fingers on one hand --- and > that's counting since the

Re: [HACKERS] Initial release notes created for 9.6

Andres Freund writes: > On 2016-05-05 16:25:38 -0400, Robert Haas wrote: >> This was basically an attempt to cure a defect in 48354581a and could >> perhaps be lumped under that item. > It's also an independent performance improvement (sadly), and has the > potential for

Re: [HACKERS] Naming of new tsvector functions

Stas Kelvich writes: > On 06 May 2016, at 00:46, Gavin Flower wrote: >> On 06/05/16 07:44, Tom Lane wrote: >>> Yeah, I see we're already a bit inconsistent here. The problem with using >>> a ts_ prefix, to my mind, is that it offers no

Re: [HACKERS] [sqlsmith] Failed assertion in BecomeLockGroupLeader

> Amit Kapila writes: >> Sounds good. So can we assume that you will try to get us the new report >> with more information? I don't see these crashes anymore in c1543a8. By the amount of fuzzing done it should have happened a dozen times, so it's highly likely something in 23b09e15..c1543a8

Re: [HACKERS] Is pg_control file crashsafe?

On 5 May 2016 12:32 am, "Tom Lane" wrote: > > To repeat, I'm pretty hesitant to change this logic. While this is not > the first report we've ever heard of loss of pg_control, I believe I could > count those reports without running out of fingers on one hand --- and > that's

Re: [HACKERS] Is pg_control file crashsafe?

Greg Stark writes: > One thing we could do without much worry of being less reliable would be to > keep two copies of pg_control. Write one, fsync, then write to the other > and fsync that one. Hmm, interesting thought. Without knowing more about the filesystem problem that the

Re: [HACKERS] Naming of new tsvector functions

> On 06 May 2016, at 00:46, Gavin Flower wrote: > > On 06/05/16 07:44, Tom Lane wrote: >> >> Yeah, I see we're already a bit inconsistent here. The problem with using >> a ts_ prefix, to my mind, is that it offers no option for distinguishing >> tsvector from

Re: [HACKERS] pg_shmem_allocations view

On 2014-09-19 23:07:07 -0500, Michael Paquier wrote: > On Mon, Aug 18, 2014 at 1:12 PM, Robert Haas wrote: > > On Mon, Aug 18, 2014 at 1:27 PM, Tom Lane wrote: > >> Robert Haas writes: > >>> I thought you were printing actual

Re: [HACKERS] pg9.6 segfault using simple query (related to use fk for join estimates)

Hi, On 05/05/2016 04:48 PM, David Rowley wrote: On 5 May 2016 at 16:04, David Rowley wrote: I've started making some improvements to this, but need to talk to Tomas. It's currently in the middle of his night, but will try to catch him in his morning to discuss

Re: [HACKERS] New pgbench functions are misnamed

Robert Haas writes: > On Wed, May 4, 2016 at 5:41 PM, Tom Lane wrote: >> I noticed that commit 7e137f846 added functions named max() and min() >> to pgbench's expression syntax. Unfortunately, these functions have >> zilch to do with what max() and

Re: [HACKERS] Initial release notes created for 9.6

On Thu, May 5, 2016 at 1:32 PM, Tom Lane wrote: > I've pushed a first cut at release notes for 9.6. There's a good deal > of work to do yet: > > * The section about parallel query could probably stand to be fleshed out, > but I'm unsure what to say. Somebody who's worked on

Re: [HACKERS] Postgres 9.6 scariest patch tournament

Noah Misch wrote: > On Mon, Apr 18, 2016 at 03:37:21PM -0300, Alvaro Herrera wrote: > > The RMT will publish aggregate, unattributed results after the poll > > closes. Here are some more detailed results. We got 15 valid replies. One person voted twice, mentioning the same patches both times in

Re: [HACKERS] atomic pin/unpin causing errors

Hi Jeff, On 2016-04-29 10:38:55 -0700, Jeff Janes wrote: > I don't see the problem with an cassert-enabled, probably because it > is just too slow to ever reach the point where the problem occurs. Running the test with cassert enabled I actually get assertion failures, due to the FATAL you

Re: [HACKERS] Postgres 9.6 scariest patch tournament

This is raw, in case anyone wants to look more closely. alvherre=# select level, count(*), patch, subject from scary left join commits on patch = sha1 group by level, patch, subject order by level asc, count(*) desc;

Re: [HACKERS] atomic pin/unpin causing errors

Hm. And you're not seeing the asserts I reported in http://archives.postgresql.org/message-id/20160505185246.2i7qftadwhzewykj%40alap3.anarazel.de ? I see it a lot, but I think that is a result of ereport(FATAL) after FileWrite(BLCKSZ/3) added by Jeff. Teodor Sigaev

Re: [HACKERS] Reviewing freeze map code

Hi, On 2016-05-02 14:48:18 -0700, Andres Freund wrote: > 7087166 pg_upgrade: Convert old visibility map format to new format. +const char * +rewriteVisibilityMap(const char *fromfile, const char *tofile, bool force) ... + while ((bytesRead = read(src_fd, buffer, BLCKSZ)) == BLCKSZ) +

Re: [HACKERS] Initial release notes created for 9.6

"Joshua D. Drake" writes: > On 05/05/2016 10:32 AM, Tom Lane wrote: >> I've pushed a first cut at release notes for 9.6. There's a good deal >> of work to do yet: > Just for the cheap seats, I assume they are pushed to git?

Re: [HACKERS] Initial release notes created for 9.6

On 05/05/2016 10:32 AM, Tom Lane wrote: I've pushed a first cut at release notes for 9.6. There's a good deal of work to do yet: * The section about parallel query could probably stand to be fleshed out, but I'm unsure what to say. Somebody who's worked on that should provide some text. *

[HACKERS] Initial release notes created for 9.6

I've pushed a first cut at release notes for 9.6. There's a good deal of work to do yet: * The section about parallel query could probably stand to be fleshed out, but I'm unsure what to say. Somebody who's worked on that should provide some text. * Bruce usually likes to sprinkle the notes

Re: [HACKERS] atomic pin/unpin causing errors

On 2016-05-04 18:12:45 +0300, Teodor Sigaev wrote: > > > I get the errors: > > > > > > ERROR: attempted to delete invisible tuple > > > STATEMENT: update foo set count=count+1,text_array=$1 where text_array > > > @> $2 > > > > > > And also: > > > > > > ERROR: unexpected chunk number 1

[HACKERS] Poorly-thought-out handling of double variables in pgbench

While testing 7a622b273 I happened to notice this: \set x greatest(3, 2, 4.9) create table mytab (x numeric); insert into mytab values(:x); results in this table: x -- 4.900355 (1 row) The reason for that is that the result of a "double"

Re: [HACKERS] Postgres 9.6 scariest patch tournament

Alvaro Herrera wrote: > "Parallel Query" got many mentions; some of them were specific commits > (such as "parallel infrastructure", "parallel joins", "parallel > aggregates") and others were more generic. For the generic mentions I > just chose a few of the most salient patches, but didn't

Re: [HACKERS] Initial release notes created for 9.6

On Thu, May 5, 2016 at 1:32 PM, Tom Lane wrote: > * As is somewhat customary for early drafts of the notes, I've made no > attempt to call out which are the most significant changes. I've not > tried to isolate the non-backwards-compatible items, either. There was quite a

Re: [HACKERS] Naming of new tsvector functions

> On 04 May 2016, at 20:15, Tom Lane wrote: > > Stas Kelvich writes: >>> On 04 May 2016, at 16:58, Tom Lane wrote: >>> The other ones are not so problematic because they do not conflict with >>> SQL keywords. It's only delete()

Re: [HACKERS] atomic pin/unpin causing errors

Any chance you could package up that data directory for me to download? Sent by personal email to Alexander, Andres and Jeff In /var/log/message I found May 4 22:04:07 xor kernel: pid 14010 (postgres), uid 1001: exited on signal 6 (core dumped) May 4 22:04:25 xor kernel: pid 14032

Re: [HACKERS] what to revert

5. mai 2016 6:14 AM kirjutas kuupäeval "Andres Freund" : > > On 2016-05-05 06:08:39 +0300, Ants Aasma wrote: > > On 5 May 2016 1:28 a.m., "Andres Freund" wrote: > > > On 2016-05-04 18:22:27 -0400, Robert Haas wrote: > > > > How would the semantics change? >

Re: [HACKERS] New pgbench functions are misnamed

I noticed that commit 7e137f846 added functions named max() and min() to pgbench's expression syntax. Unfortunately, these functions have zilch to do with what max() and min() do in SQL. They're actually more like the greatest() and least() server-side functions. Yep. While I can't imagine

Re: [HACKERS] Is pg_control file crashsafe?

On Thu, May 5, 2016 at 4:32 PM, Tom Lane wrote: > Amit Kapila writes: >> How about using 512 bytes as a write size and perform direct writes rather >> than going via OS buffer cache for control file? > > Wouldn't that fail outright under a lot of

Re: [HACKERS] Segmentation fault when max_parallel degree is very High

On Wed, May 4, 2016 at 8:31 PM, Tom Lane wrote: > > Dilip Kumar writes: > > When parallel degree is set to very high say 7, there is a segmentation > > fault in parallel code, > > and that is because type casting is missing in the code.. > > I'd say

Re: [HACKERS] [BUGS] Breakage with VACUUM ANALYSE + partitions

Hello Tom, I understood the point and I do not see real disadvantages. The C standard really says that an enum is an int, and compilers just do that. No, it doesn't say that, and compilers don't just do that. A compiler is specifically allowed to store an enum in char or short if the enum's

Re: [HACKERS] Is pg_control file crashsafe?

On Thu, May 5, 2016 at 11:52 AM, Thomas Munro wrote: > > On Thu, May 5, 2016 at 4:32 PM, Tom Lane wrote: > > Amit Kapila writes: > >> How about using 512 bytes as a write size and perform direct writes rather > >> than

Re: [HACKERS] atomic pin/unpin causing errors

I'll try to get a coredump after SIGSEGV, but it could take a time. Got it! #0 0x0008014321d7 in sbrk () from /lib/libc.so.7 #1 0x000801431ddd in sbrk () from /lib/libc.so.7 #2 0x00080142e5bb in sbrk () from /lib/libc.so.7 #3 0x00080142e085 in sbrk () from /lib/libc.so.7 #4

Re: [HACKERS] Naming of new tsvector functions

On 05/05/16 21:20, Stas Kelvich wrote: On 04 May 2016, at 20:15, Tom Lane wrote: Stas Kelvich writes: On 04 May 2016, at 16:58, Tom Lane wrote: The other ones are not so problematic because they do not conflict with SQL

Re: [HACKERS] what to revert

On Thu, May 5, 2016 at 3:39 AM, Ants Aasma wrote: > 5. mai 2016 6:14 AM kirjutas kuupäeval "Andres Freund" : >> >> On 2016-05-05 06:08:39 +0300, Ants Aasma wrote: >>> On 5 May 2016 1:28 a.m., "Andres Freund" wrote: On 2016-05-04

Re: [HACKERS] pg_dump vs. TRANSFORMs

On 5/4/16 11:23 PM, Tom Lane wrote: Actually, I believe it will be dumped. selectDumpableCast believes it should dump casts with OID >= FirstNormalObjectId. That's a kluge no doubt, but reasonably effective; looks like we've been doing that since 9.0. pg_dump appears not to have a

Re: [HACKERS] More inaccurate results from numeric pow()

On 2 May 2016 at 18:38, Tom Lane wrote: > I don't much care for the hardwired magic number here, especially since > exp_var() does not have its limit expressed as "6000" but as > "NUMERIC_MAX_RESULT_SCALE * 3". I think you should rephrase the limit > to use that expression,

[HACKERS] Delete query on materialized view

Hi all I am trying to delete/insert a row on materialized view which has join from a UDF by using SPI_execute. Materialized views are not allowed to do any DML changes once created,so by bypassed that check by enabling MatViewIncrementalMaintenanceIsEnabled. so DML queries

Re: [HACKERS] Pg_stop_backup process does not run - Backup Intervals

Hi, Thanks for the feedback. Log: LOG: connection authorized: user=postgres database=template1 LOG: statement: select pg_start_backup('bkpfull',true); ERROR: a backup is already in progress HINT: Run pg_stop_backup() and try again. STATEMENT: select pg_start_backup('bkpfull',true); LOG:

Re: [HACKERS] SET ROLE and reserved roles

* Stephen Frost (sfr...@snowman.net) wrote: > * Robert Haas (robertmh...@gmail.com) wrote: > > On Tue, Apr 26, 2016 at 7:39 PM, Robert Haas wrote: > > > On Mon, Apr 25, 2016 at 6:55 PM, Stephen Frost wrote: > > >> Based on our discussion at PGConf.US

Re: [HACKERS] pg9.6 segfault using simple query (related to use fk for join estimates)

On 5 May 2016 at 16:04, David Rowley wrote: > I've started making some improvements to this, but need to talk to > Tomas. It's currently in the middle of his night, but will try to > catch him in his morning to discuss this with him. Ok, so I spoke to Tomas about

Re: [HACKERS] pg_dump vs. TRANSFORMs

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Peter Eisentraut writes: > > On 5/4/16 2:39 PM, Stephen Frost wrote: > >> These checks are looking for the functions used by the transform in the > >> list of functions that pg_dump has loaded, but in 9.5, we don't load

Re: [HACKERS] pg_dump vs. TRANSFORMs

* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 5/4/16 11:23 PM, Tom Lane wrote: > >Actually, I believe it will be dumped. selectDumpableCast believes it > >should dump casts with OID >= FirstNormalObjectId. That's a kluge no > >doubt, but reasonably effective; looks like we've

Re: [HACKERS] quickdie doing memory allocations (was atomic pin/unpin causing errors)

Hi Teodor, Thanks for analyzing this. On 2016-05-05 13:50:09 +0300, Teodor Sigaev wrote: > > I'll try to get a coredump after SIGSEGV, but it could take a time. > > Got it! > > #0 0x0008014321d7 in sbrk () from /lib/libc.so.7 > #1 0x000801431ddd in sbrk () from /lib/libc.so.7 > #2

[HACKERS] [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan)

Hi, when fuzz testing master as of c1543a8, parallel workers trigger the following assertion in ExecInitSubPlan every couple hours. TRAP: FailedAssertion("!(list != ((List *) ((void *)0)))", File: "list.c", Line: 390) Sample backtraces of a worker and leader below, plan of leader attached.

Re: [HACKERS] Initial release notes created for 9.6

On Thu, May 5, 2016 at 1:32 PM, Tom Lane wrote: > Please review and comment before Monday, if you can. Overall, I think this looks pretty great. Thanks for pulling it together so quickly. Various nitpicky comments below. + +Extend relations multiple blocks

Re: [HACKERS] [sqlsmith] Failed assertion in BecomeLockGroupLeader

Robert Haas wrote: > On Thu, May 5, 2016 at 4:11 PM, Andreas Seltenreich > wrote: > >> Amit Kapila writes: > >>> Sounds good. So can we assume that you will try to get us the new report > >>> with more information? > > > > I don't see these crashes anymore in c1543a8. By

Re: [HACKERS] Missing error handling for FATALs in checkpointer/bgwriter

On 2016-05-05 11:52:46 -0700, Andres Freund wrote: > Hi Jeff, > > On 2016-04-29 10:38:55 -0700, Jeff Janes wrote: > > I don't see the problem with an cassert-enabled, probably because it > > is just too slow to ever reach the point where the problem occurs. > > Running the test with cassert

Re: [HACKERS] Naming of new tsvector functions

On 06/05/16 07:44, Tom Lane wrote: Stas Kelvich writes: On 04 May 2016, at 20:15, Tom Lane wrote: Also, I'd supposed that we'd rename to tsvector_something, since the same patch also introduced tsvector_to_array() and array_to_tsvector(). What's

Re: [HACKERS] quickdie doing memory allocations (was atomic pin/unpin causing errors)

Hi, On 2016-05-05 15:56:45 -0400, Tom Lane wrote: > Andres Freund writes: > >> #0 0x0008014321d7 in sbrk () from /lib/libc.so.7 > >> #1 0x000801431ddd in sbrk () from /lib/libc.so.7 > >> #2 0x00080142e5bb in sbrk () from /lib/libc.so.7 > >> #3

Re: [HACKERS] quickdie doing memory allocations (was atomic pin/unpin causing errors)

On 2016-05-05 16:32:38 -0400, Robert Haas wrote: > On Thu, May 5, 2016 at 11:51 AM, Andres Freund wrote: > >> #7 0x00080149e3d6 in nsdispatch () from /lib/libc.so.7 > >> #8 0x0008014a41c6 in __cxa_finalize () from /lib/libc.so.7 > >> #9 0x00080144525c in exit ()

Re: [HACKERS] Poorly-thought-out handling of double variables in pgbench

Hello Tom, While testing 7a622b273 I happened to notice this: \set x greatest(3, 2, 4.9) create table mytab (x numeric); insert into mytab values(:x); x -- 4.900355 The reason for that is that the result of a "double" calculation is coerced to text

Re: [HACKERS] [sqlsmith] Failed assertion in BecomeLockGroupLeader

Alvaro Herrera writes: > Robert Haas wrote: >> On Thu, May 5, 2016 at 4:11 PM, Andreas Seltenreich >> wrote: >> > I don't see these crashes anymore in c1543a8. By the amount of fuzzing >> > done it should have happened a dozen times, so it's highly likely >> > something in

Re: [HACKERS] quickdie doing memory allocations (was atomic pin/unpin causing errors)

Andres Freund writes: >> #0 0x0008014321d7 in sbrk () from /lib/libc.so.7 >> #1 0x000801431ddd in sbrk () from /lib/libc.so.7 >> #2 0x00080142e5bb in sbrk () from /lib/libc.so.7 >> #3 0x00080142e085 in sbrk () from /lib/libc.so.7 >> #4 0x00080142de28

Re: [HACKERS] pg_dump dump catalog ACLs

* Stephen Frost (sfr...@snowman.net) wrote: > In any case, as I was saying, that's far closer to 9.5 run-time. I've > not measured the time added when things like TRANSFORMs were added, but > it wouldn't surprise me if adding a new query for every database to > pg_dump adds something similar to

Re: [HACKERS] Naming of new tsvector functions

Stas Kelvich writes: >> On 04 May 2016, at 20:15, Tom Lane wrote: >> Also, I'd supposed that we'd rename to tsvector_something, since >> the same patch also introduced tsvector_to_array() and >> array_to_tsvector(). What's the motivation for using

Re: [HACKERS] [sqlsmith] Failed assertion in BecomeLockGroupLeader

On Thu, May 5, 2016 at 4:11 PM, Andreas Seltenreich wrote: >> Amit Kapila writes: >>> Sounds good. So can we assume that you will try to get us the new report >>> with more information? > > I don't see these crashes anymore in c1543a8. By the amount of fuzzing > done it

Re: [HACKERS] Initial release notes created for 9.6

On 2016-05-05 16:25:38 -0400, Robert Haas wrote: > On Thu, May 5, 2016 at 1:32 PM, Tom Lane wrote: > > Please review and comment before Monday, if you can. > > Overall, I think this looks pretty great. Thanks for pulling it > together so quickly. +1 > + > + > +

Re: [HACKERS] quickdie doing memory allocations (was atomic pin/unpin causing errors)

On Thu, May 5, 2016 at 11:51 AM, Andres Freund wrote: >> #7 0x00080149e3d6 in nsdispatch () from /lib/libc.so.7 >> #8 0x0008014a41c6 in __cxa_finalize () from /lib/libc.so.7 >> #9 0x00080144525c in exit () from /lib/libc.so.7 >> #10 0x008e1bc2 in

Re: [HACKERS] Poorly-thought-out handling of double variables in pgbench

Fabien COELHO writes: >> A better answer, perhaps, would be to store double-valued variables in >> double format to begin with, coercing to text only when and if the value >> is interpolated into a string. > Yep, but that was yet more changes for a limited benefit and

Re: [HACKERS] Initial release notes created for 9.6

On Fri, May 6, 2016 at 7:53 AM, Tom Lane wrote: > Andres Freund writes: >> On 2016-05-05 16:25:38 -0400, Robert Haas wrote: >>> This was basically an attempt to cure a defect in 48354581a and could >>> perhaps be lumped under that item. > >> It's also an

Re: [HACKERS] Initial release notes created for 9.6

Andres Freund writes: > wal-writer-flush-after doesn't really fit into this section, it wasn't > affected by any of the above commits, and the change in 9.6 is to make > it *less* aggressive in flushing (as you listed in a separate entry). I hadn't focused on this before, but

Re: [HACKERS] Initial release notes created for 9.6

On 5/5/16, Tom Lane wrote: > Please review and comment before Monday, if you can. > > regards, tom lane 1. "YUriy Zhuravlev" should be "Yury Zhuravlev" Previously[1] he had the first version in his signature, but I guess it was misconfiguring, now[2] hi

Re: [HACKERS] Initial release notes created for 9.6

Masahiko Sawada writes: > Very minor comment but I'd like to unify my name to First Last (i.g., > Masahiko Sawada). Will fix, thanks. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Initial release notes created for 9.6

Hi, On 2016-05-05 13:32:55 -0400, Tom Lane wrote: > * Bruce usually likes to sprinkle the notes with a whole lot of links > to the main docs. I've only bothered with links for new GUCs and system > views. I guess it'd be worthwhile to add a links for new SQL functions as well. > Please review

Re: [HACKERS] Initial release notes created for 9.6

Vitaly Burovoy writes: > 1. "YUriy Zhuravlev" should be "Yury Zhuravlev" > Previously[1] he had the first version in his signature, but I guess > it was misconfiguring, now[2] hi has second version. Ah. Now that I look, I see we've got three different ASCII-izations of

Re: [HACKERS] Initial release notes created for 9.6

I wrote: > Michael Paquier writes: >> Are you not adding VS2015 support in those notes? > Hmm, I had decided that wasn't worth listing, but now I can't think > why :-(. Will add it. Oh, now I see why it's not here: it was back-patched into 9.5, so it will not be a

[HACKERS] Feature request: make cluster_name GUC useful for psql prompts

It's great that 9.5 has the new cluster_name variable as an available GUC. It would be even better to make that GUC available for use in psql prompting escape sequences. Prompting via sequences utilizing %M, %m and %> means the same cluster could be identified numerous ways (local, 127.0.0.1,

Re: [HACKERS] Initial release notes created for 9.6

On Fri, May 6, 2016 at 2:32 AM, Tom Lane wrote: > I've pushed a first cut at release notes for 9.6. There's a good deal > of work to do yet: > > * The section about parallel query could probably stand to be fleshed out, > but I'm unsure what to say. Somebody who's worked on

Re: [HACKERS] Initial release notes created for 9.6

Michael Paquier writes: > Are you not adding VS2015 support in those notes? Hmm, I had decided that wasn't worth listing, but now I can't think why :-(. Will add it. > Petr Jelinek is a > co-author btw, he's missing from the credits in 0fb54de. OK, thanks.

Re: [HACKERS] Initial release notes created for 9.6

Peter Geoghegan writes: > On Thu, May 5, 2016 at 5:54 PM, Tom Lane wrote: >> Oh, now I see why it's not here: it was back-patched into 9.5, so it >> will not be a new feature in 9.6.0. It will be listed in the 9.5.3 >> release notes, instead. > I was really

Re: [HACKERS] Initial release notes created for 9.6

On Thu, May 5, 2016 at 5:54 PM, Tom Lane wrote: >> Hmm, I had decided that wasn't worth listing, but now I can't think >> why :-(. Will add it. > > Oh, now I see why it's not here: it was back-patched into 9.5, so it > will not be a new feature in 9.6.0. It will be listed in

Re: [HACKERS] Initial release notes created for 9.6

On Thu, May 5, 2016 at 10:32 AM, Tom Lane wrote: > Please review and comment before Monday, if you can. I think that there could stand to be some consolidation among the items that I authored. Firstly, there's the abbreviated key stuff. The 9.5 notes described the

Re: [HACKERS] modifying WaitEventSets (was: Performance degradation in commit ac1d794)

On 2016-05-04 16:05:04 -0400, Robert Haas wrote: > I'm more than happy to rip it out, either now or after the tree opens > for 9.7 development. Let's rip the select support out in 9.7 then; given the relevant code was already written and tested there's no hurry. But if you'd rather do so earlier

Re: [HACKERS] Initial release notes created for 9.6

Peter Geoghegan writes: > I think that there could stand to be some consolidation among the > items that I authored. After thinking a bit, I merged all the abbreviated-keys stuff including the ordered-set-aggregate item. Let me know if that seems wrong. > Also, I personally

Re: [HACKERS] Initial release notes created for 9.6

Andres Freund wrote: > On 2016-05-05 13:32:55 -0400, Tom Lane wrote: > + > + > +Add pg_config > +system view to expose the same information available from > +the pg_config utility (Joe Conway) > + > + > > Hm. Rereading this I'm wondering whether

Re: [HACKERS] Initial release notes created for 9.6

On Fri, May 6, 2016 at 12:11 AM, Robert Haas wrote: > > On Thu, May 5, 2016 at 1:32 PM, Tom Lane wrote: > > * As is somewhat customary for early drafts of the notes, I've made no > > attempt to call out which are the most significant changes. I've not

Re: [HACKERS] [BUGS] Breakage with VACUUM ANALYSE + partitions

On 2016-05-05 09:32, Fabien COELHO wrote: I note that C99 specifically mentions this as something a compiler might warn about: [...] Indeed. Neither gcc nor clang emit such warnings... but they might some day, which would be a blow for my suggestion! For what it's worth, newer versions of

Re: [HACKERS] [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan)

Andreas Seltenreich writes: > when fuzz testing master as of c1543a8, parallel workers trigger the > following assertion in ExecInitSubPlan every couple hours. > TRAP: FailedAssertion("!(list != ((List *) ((void *)0)))", File: > "list.c", Line: 390) > Sample backtraces of

Re: [HACKERS] Initial release notes created for 9.6

On Thu, May 5, 2016 at 7:42 PM, Tom Lane wrote: > Peter Geoghegan writes: >> I think that there could stand to be some consolidation among the >> items that I authored. > > After thinking a bit, I merged all the abbreviated-keys stuff including > the

Re: [HACKERS] old_snapshot_threshold's interaction with hash index

On Wed, May 4, 2016 at 7:48 PM, Kevin Grittner wrote: > > On Tue, May 3, 2016 at 11:48 AM, Robert Haas wrote: > > > OK, I see now: the basic idea here is that we can't prune based on the > > newer XID unless the page LSN is guaranteed to advance whenever