On Thu, May 5, 2016 at 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:
Thanks for assembling the notes.
This item:
"Avoid some spurious waits for AccessExclusiveLocks in hot-standby queries"
Should be something like
Avoid
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 data
> > is removed. Currently, we attemp
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 cla
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
> > tried to isolate the non-backwards-compa
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 pg_con
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 ordered-set-aggregate item. Let me know if th
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 a worker and leader
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 don't really think o
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 wal_writer_flush_aft
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
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
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 abbreviated keys feature as fol
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 subscription:
http://ww
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 hoping that the OpenSSL bugfix patch
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 that should provide
>
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, 10.
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 the 9.5.3
> release
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 new feature in 9.6.0. It will
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 his name in the notes, non
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 has second version.
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.
regards, tom
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 independent performance improvement (sadly
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. I've not gotten around to that
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 option for distinguishing
>>> tsvector from tsquery, should
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 pointer addresses. If you're just
> >>> printing offsets relative to
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 this with him.
Ok, so I spoke t
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 issues; so there's *some*
> 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 tsquery, should you need to do tha
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 OP had, it's hard
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 the motivation for using ts_ as the
prefix?
Th
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 would have
> increase the
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 counting since the la
* 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 th
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 enabl
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 23b09e15..c1543a8 fix
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 l
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 the amount of fuzzing
>
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 lik
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 () from /lib/libc.so.7
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 quickdie (postgres_signal_ar
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
> +
> +
> +Use atomic operati
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 should have happened a do
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 at a time (Dilip Kumar
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 0x00080142e085 in sbrk () from /l
> 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 fixe
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.
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 in sbrk () from /lib/l
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 ts_ as the
>> prefix?
> There is already severa
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
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" cal
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 (expec
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 added.
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 bit of discussion of th
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;
┌───┬───┬──
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 inclu
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
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 that should provide
>
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)
+
"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?
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=c311f
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 min() do in SQL. They're actually more
>> like
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.
* Bru
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 wit
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 0x
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 this briefly, and he's asked me t
* 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 and the comments up-thread from
> > >> Tom, I'
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: di
* 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
* 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 any
> >> of the function in pg_catalo
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 18:22:27 -0400, Robert Haas wrote:
> How would the semantic
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
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 special-case
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
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 keywords. It's only delete() and filter() that scare me.
Okay, so chan
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, and also add something
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 (postgres
> 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() and filter() that scare me.
>
>> Okay, so changed functions to ts
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?
> > >
> > > Right now the time for computi
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
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
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 going via OS buffer cache for control file?
> >
> > Wouldn't that fail outrig
80 matches
Mail list logo
