Hi,
While testing "Aggregate pushdown", i found the below error:
-- GROUP BY alias showing different behavior after adding patch.
-- Create table "t1", insert few records.
create table t1(c1 int);
insert into t1 values(10), (20);
-- Create foreign table:
create foreign table f_t1 (c1 int) server
On 12 September 2016 at 13:07, Pavel Stehule wrote:
>> Out of interest, should the syntax allow room for future expansion to
>> permit reading from file rather than just string literal / column
>> reference? It'd be ideal to avoid reading big documents wholly into
>> memory when using INSERT INTO
2016-09-12 8:14 GMT+02:00 Craig Ringer :
> On 12 September 2016 at 14:02, Pavel Stehule
> wrote:
> > Hi
> >
> > There is some opened questions - the standard (and some other databases)
> > requires entering XPath expression as string literal.
> >
> > I am thinking so it is too strong not necessar
On 12 September 2016 at 03:38, Tom Lane wrote:
> On reflection, maybe s/walsender/WAL sender/? It doesn't look like
> we really use the word "walsender" in user-facing docs.
There are already
* 3 user messages referring to walsender and 2 referring to walreceiver
* multiple references in the do
On 12 September 2016 at 14:02, Pavel Stehule wrote:
> Hi
>
> There is some opened questions - the standard (and some other databases)
> requires entering XPath expression as string literal.
>
> I am thinking so it is too strong not necessary limit - (it enforces dynamic
> query in more cases), so
On Fri, Sep 09, 2016 at 03:33:58PM +0200, Vik Fearing wrote:
> I often see mention of project policies for various things (the one
> triggering this email is in commit 967a7b0).
>
> Where can I find documentation for these policies?
In PostgreSQL community jargon, referring to something as "proje
Hi
There is some opened questions - the standard (and some other databases)
requires entering XPath expression as string literal.
I am thinking so it is too strong not necessary limit - (it enforces
dynamic query in more cases), so I allowed the expressions there.
Another questions is when these
On 12 September 2016 at 13:07, Pavel Stehule wrote:
>> Out of interest, should the syntax allow room for future expansion to
>> permit reading from file rather than just string literal / column
>> reference? It'd be ideal to avoid reading big documents wholly into
>> memory when using INSERT INTO
On 2016/09/11 8:04, Corey Huinker wrote:
> V2 of this patch:
>
> Changes:
> * rebased to most recent master
> * removed non-tap test that assumed the existence of Unix sed program
> * added non-tap test that assumes the existence of perl
> * switched from filename/program to filename/is_program to
On Sun, Sep 11, 2016 at 7:40 PM, Amit Kapila
wrote:
> On Mon, Sep 12, 2016 at 7:00 AM, Jeff Janes wrote:
> > On Thu, Sep 8, 2016 at 12:09 PM, Jeff Janes
> wrote:
> >
> >>
> >> I plan to do testing using my own testing harness after changing it to
> >> insert a lot of dummy tuples (ones with neg
2016-09-12 6:36 GMT+02:00 Craig Ringer :
> On 12 September 2016 at 12:28, Craig Ringer wrote:
> >> I'll take a closer read-through shortly.
>
> >DEFAULT
> > isn't a normal literal, it's an xpath expression evaluated at the same
> > time as the rowexpression.
>
> Sorry for the spam, but turns out
2016-09-12 6:28 GMT+02:00 Craig Ringer :
> > I'll take a closer read-through shortly.
>
>
> Missing file. You omitted executor/tableexpr.h from the patch, so I
> can't compile.
>
> I've expanded and copy-edited the docs. Some of it is guesswork based
> on the references you sent and a glance at th
2016-09-12 6:36 GMT+02:00 Craig Ringer :
> On 12 September 2016 at 12:28, Craig Ringer wrote:
> >> I'll take a closer read-through shortly.
>
> >DEFAULT
> > isn't a normal literal, it's an xpath expression evaluated at the same
> > time as the rowexpression.
>
> Sorry for the spam, but turns out
On 12 September 2016 at 12:28, Craig Ringer wrote:
>> I'll take a closer read-through shortly.
>DEFAULT
> isn't a normal literal, it's an xpath expression evaluated at the same
> time as the rowexpression.
Sorry for the spam, but turns out that's not the case as implemented
here. The docs you re
> I'll take a closer read-through shortly.
Missing file. You omitted executor/tableexpr.h from the patch, so I
can't compile.
I've expanded and copy-edited the docs. Some of it is guesswork based
on the references you sent and a glance at the code. Please check my
changes carefully. I found a fe
On 9/11/16, Tom Lane wrote:
> Vitaly Burovoy writes:
>> On 9/11/16, Kevin Grittner wrote:
>>> I was able to find cases during test which were not handled
>>> correctly with either version, so I tweaked the query a little.
>
>> Hmm. Which one? Attempt to "SET ROLE "?
>> Unfortunately, I after rea
On Sun, Sep 11, 2016 at 3:01 PM, Mark Kirkwood
wrote:
> On 11/09/16 19:16, Mark Kirkwood wrote:
>
>>
>>
>> On 11/09/16 17:01, Amit Kapila wrote:
>>>
>>> ...Do you think we can do some read-only
>>> workload benchmarking using this server? If yes, then probably you
>>> can use concurrent hash inde
On Mon, Sep 12, 2016 at 11:38 AM, Tom Lane wrote:
> Michael Paquier writes:
>> Indeed, and the query field does not have much more meaning for a WAL
>> sender. So I'd propose the attached for 9.6 and HEAD. I have thought
>> about reporting that to pgstat in StartReplication(), but as there is
>>
On Mon, Sep 12, 2016 at 7:00 AM, Jeff Janes wrote:
> On Thu, Sep 8, 2016 at 12:09 PM, Jeff Janes wrote:
>
>>
>> I plan to do testing using my own testing harness after changing it to
>> insert a lot of dummy tuples (ones with negative values in the pseudo-pk
>> column, which are never queried by
On Mon, Sep 12, 2016 at 10:01 AM, Noah Misch wrote:
> I discourage documenting LF/CR restrictions. For the epsilon of readers who
> would benefit from this knowledge, the error message suffices. For everyone
> else, it would just dilute the text. (One could argue against other parts of
> our do
Michael Paquier writes:
> Indeed, and the query field does not have much more meaning for a WAL
> sender. So I'd propose the attached for 9.6 and HEAD. I have thought
> about reporting that to pgstat in StartReplication(), but as there is
> some error handling there I'd think that WalSndLoop() is
On Mon, Sep 12, 2016 at 10:16 AM, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Michael Paquier writes:
>> > On Sun, Sep 11, 2016 at 5:21 AM, Tom Lane wrote:
>> >> The fact that the pg_stat_replication view does show walsender processes
>> >> seems like possibly a reasonable a
On 9 September 2016 at 21:44, Pavel Stehule wrote:
>
>
> 2016-09-09 10:35 GMT+02:00 Pavel Stehule :
>>
>> Hi,
>>
>> I am sending new version of this patch
>>
>> 1. now generic TableExpr is better separated from a real content
>> generation
>> 2. I removed cached typmod - using row type cache every
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Sep 8, 2016 at 5:21 PM, Tom Lane wrote:
> > Stephen Frost writes:
> >> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> >>> Can't you keep those words as Sconst or something (DefElems?) until the
> >>> execution phase, so that th
On Thu, Sep 8, 2016 at 5:21 PM, Tom Lane wrote:
> Stephen Frost writes:
>> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
>>> Can't you keep those words as Sconst or something (DefElems?) until the
>>> execution phase, so that they don't need to be keywords at all?
>
>> Seems like we could do
On Thu, Sep 8, 2016 at 12:09 PM, Jeff Janes wrote:
> I plan to do testing using my own testing harness after changing it to
> insert a lot of dummy tuples (ones with negative values in the pseudo-pk
> column, which are never queried by the core part of the harness) and
> deleting them at random
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Michael Paquier writes:
> > On Sun, Sep 11, 2016 at 5:21 AM, Tom Lane wrote:
> >> The fact that the pg_stat_replication view does show walsender processes
> >> seems like possibly a reasonable argument for not showing them in
> >> pg_stat_activity. But we
Michael Paquier writes:
> On Sun, Sep 11, 2016 at 5:21 AM, Tom Lane wrote:
>> The fact that the pg_stat_replication view does show walsender processes
>> seems like possibly a reasonable argument for not showing them in
>> pg_stat_activity. But we'd have to do some rejiggering of the view
>> def
Vitaly Burovoy writes:
> On 9/11/16, Kevin Grittner wrote:
>> I was able to find cases during test which were not handled
>> correctly with either version, so I tweaked the query a little.
> Hmm. Which one? Attempt to "SET ROLE "?
> Unfortunately, I after reading your letter I realized that I mi
On Thu, Sep 08, 2016 at 12:12:49PM -0400, Peter Eisentraut wrote:
> On 9/6/16 1:42 PM, Robert Haas wrote:
> > On Tue, Sep 6, 2016 at 9:43 PM, Peter Eisentraut
> > wrote:
> > > Everything that is using appendShellString() is now going to reject LF
> > > and CR characters, but there is no systemati
On Sun, Sep 11, 2016 at 5:21 AM, Tom Lane wrote:
> The fact that the pg_stat_replication view does show walsender processes
> seems like possibly a reasonable argument for not showing them in
> pg_stat_activity. But we'd have to do some rejiggering of the view
> definition to make that happen.
W
Hi all,
The current status summary is:
Needs review: 81
Waiting on author: 35
Ready for Commiter: 12
Commited: 78
Moved to next CF: 1
Rejected: 6
Returned with feedback: 6
TOTAL: 219
The current progress is ~39%. The things moving fast but 27 patches still
with no signed reviewer. So if you have
On 12/09/16 12:16, Gavin Flower wrote:
[...]
two blocks would be logically adjacent (which means they are likely
to be physically close together, but not guaranteed!).
[...]
Actual disk layouts are quite complicated, the above is an over
simplification, but the message is still valid.
The
On 12/09/16 10:13, Peter Geoghegan wrote:
On Sun, Sep 11, 2016 at 8:47 AM, Heikki Linnakangas wrote:
[...]
I don't know what the difference is between accessing 10 pages
randomly, and accessing a random set of 10 single pages sequentially,
in close succession. As Tom would say, that's above my
On Sun, Sep 11, 2016 at 3:13 PM, Peter Geoghegan wrote:
>> + for (tapenum = 0; tapenum < maxTapes; tapenum++)
>> + {
>> + LogicalTapeAssignReadBufferSize(state->tapeset, tapenum,
>> + (per_tape + (tapenum < cutoff ? 1 :
>> 0)) * BLCKSZ);
>> + }
S
On Sun, Sep 11, 2016 at 11:07 PM, Michael Malis wrote:
> On Sun, Sep 11, 2016 at 9:20 AM Tom Lane wrote:
>>
>> Michael Malis writes:
>> >> As I understand it, a merge join will currently read all tuples from
>> >> both
>> >> subqueries (besides early termination). I believe it should be possible
On 9/11/16, Kevin Grittner wrote:
> On Sat, Sep 10, 2016 at 12:26 AM, Vitaly Burovoy
>> Mark it as "Ready for committer".
>>
>> P.S.: While I was reviewing I simplified SQL query: improved version
>> only 2 seqscans instead of 3 seqscans with an inner loop in an
>> original one.
>> Please find a f
On Sun, Sep 11, 2016 at 3:13 PM, Peter Geoghegan wrote:
> * Doesn't this code need to call MemoryContextAllocHuge() rather than
> palloc()?:
>
>> @@ -709,18 +765,19 @@ LogicalTapeRewind(LogicalTapeSet *lts, int tapenum,
>> bool forWrite)
>> Assert(lt->frozen);
>> databloc
The IDENTIFICATION filename in src/backend/storage/ipc/dsm_impl.c is
incorrectly labelling the file dsm.c. Patch fixing the typo attached.
cheers ./daniel
typo-dsm_impl_identification.diff
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Sun, Sep 11, 2016 at 3:13 PM, Peter Geoghegan wrote:
> * Please make this use the ".., + 1023" natural rounding trick that is
> used in the similar traces that are removed:
>
>> +#ifdef TRACE_SORT
>> + if (trace_sort)
>> + elog(LOG, "using %d kB of memory for read buffers in %d tapes, %
On Mon, Sep 12, 2016 at 1:47 AM, Tom Lane wrote:
> Looks reasonable to me, we'll soon see what the buildfarm thinks.
Thanks for the commit. I am seeing green statuses on the buildfarm.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
On Sun, Sep 11, 2016 at 8:47 AM, Heikki Linnakangas wrote:
> Here's a new version of these patches, rebased over current master. I
> squashed the two patches into one, there's not much point to keep them
> separate.
I think I have my head fully around this now. For some reason, I
initially though
On Sun, Sep 11, 2016 at 9:20 AM Tom Lane wrote:
> Michael Malis writes:
> >> As I understand it, a merge join will currently read all tuples from
> both
> >> subqueries (besides early termination). I believe it should be possible
> to
> >> take advantages of the indexes on one or both of the tab
On Sat, Sep 10, 2016 at 12:26 AM, Vitaly Burovoy
wrote:
> Tested manually in versions 9.2 and 10devel, I hope it can be
> back-patched to all supported versions.
We don't normally back-patch tab completion work unless it is
fixing a crash or removing displayed entries which make no sense.
This i
Hello,
Based on the previous discussions, I've modified the existing patch.
>+ void(*rm_checkConsistency) (XLogReaderState *record);
>All your _checkConsistency functions share the same pattern, in short
>they all use a for loop for each block, call each time
>XLogReadBufferExtended, et
Kevin Grittner writes:
> test=# create role fred with createdb;
> CREATE ROLE
> test=# create user bob;
> CREATE ROLE
> test=# grant fred to bob;
> GRANT ROLE
> test=# alter database postgres owner to fred;
> ALTER DATABASE
> test=# set role fred;
> SET
> test=> create database db1 template postgr
Pushed with adjustments for the review points. Hopefully this will make
Stephen's life easier, along with others submitting contrib-module
updates. We should urge anyone who submits an old-style extension update
patch to consider whether they really want to bother with a new base
script.
At some
On Sun, Sep 11, 2016 at 6:28 AM, Heikki Linnakangas wrote:
> Pushed this "displace root" patch, with some changes:
Attached is rebased version of the entire patch series, which should
be applied on top of what you pushed to the master branch today.
This features a new scheme for managing workMem
On Sat, Sep 10, 2016 at 12:26 AM, Vitaly Burovoy
wrote:
> According to the documentation since 9.2 till devel a database can be
> used as a template if it has a "datistemplate" mark or by superusers
> or by their owners.
Hm. I wonder whether the following failure of "bob" to use the
specified t
Michael Paquier writes:
> On Sun, Sep 11, 2016 at 1:03 AM, Tom Lane wrote:
>> It might accidentally fail to fail as-is, but likely it would be better
>> not to be pushing garbage paths into extraincludes and extralibs when
>> some of those options aren't set.
> Right, we need to correct somethin
Some of your patches look useful, but unrelated to C++: 7, 8, 15, 16(?), 20.
I applied that subset to 9.6 and got a clean "make check".
Would it make sense to add them to the next commitfest, regardless of
the C++ effort?
On Wed, Aug 31, 2016 at 9:41 AM, Peter Eisentraut
wrote:
> [trimmed cc li
Michael Malis writes:
> As I understand it, a merge join will currently read all tuples from both
> subqueries (besides early termination). I believe it should be possible to
> take advantages of the indexes on one or both of the tables being read from
> to skip a large number of tuples that would
On Sun, Sep 11, 2016 at 9:01 AM, Tom Lane wrote:
> Peter Geoghegan writes:
>> I think that we *can* refine this guess, and should, because random
>> I/O is really quite unlikely to be a large cost these days (I/O in
>> general often isn't a large cost, actually). More fundamentally, I
>> think it
Peter Geoghegan writes:
> I think that we *can* refine this guess, and should, because random
> I/O is really quite unlikely to be a large cost these days (I/O in
> general often isn't a large cost, actually). More fundamentally, I
> think it's a problem that cost_sort() thinks that external sorts
On Sun, Sep 11, 2016 at 6:28 AM, Heikki Linnakangas wrote:
> * I renamed "tuplesort_heap_siftup()" to "tuplesort_delete_top()". I realize
> that this is controversial, per the discussion on the "Is
> tuplesort_heap_siftup() a misnomer?" thread. However, now that we have a new
> function, "tuplesor
Here's a new version of these patches, rebased over current master. I
squashed the two patches into one, there's not much point to keep them
separate.
- Heikki
>From 6e3813d876cf3efbe5f1b80c45f44ed5494304ab Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas
Date: Sun, 11 Sep 2016 18:41:44 +030
Paul Guo writes:
> I happened to read the pg_usleep() code recently. I'm wondering
> if we could implement it using the posix function nanosleep(),
> instead of by select().
That actually looks like a pretty good idea. Some research says that
nanosleep() is defined in SUSv2, our usual baseline f
Jim Nasby writes:
> On 9/8/16 4:55 AM, Emre Hasegeli wrote:
>> The main problem that has been discussed before was the indexes. One
>> way is to tackle with it is to reindex all the tables after the
>> operation. Currently we are doing it when the datatype of indexed
>> columns change. So it sh
> P.S. I'm asking because I was planning to review that patch. But I
>> can't tell if any more review by a non-committer is still required by
>> the commitfest workflow.
>
>
> I think this has gotten enough attention, for the commitfest workflow. The
> workflow is flexible, depending on the nature
On 09/11/2016 01:20 AM, Christian Convey wrote:
Hi Heikki,
Could I ask you a newbie-reviewer question about something I'm seeing
here? https://commitfest.postgresql.org/10/776/
From some reading I've done (e.g., Stephen Frost's PGCon 2011 slides),
I got the impression that a successful patch w
On 09/11/2016 01:20 AM, Christian Convey wrote:
Hi Heikki,
Could I ask you a newbie-reviewer question about something I'm seeing
here? https://commitfest.postgresql.org/10/776/
From some reading I've done (e.g., Stephen Frost's PGCon 2011 slides),
I got the impression that a successful patch w
On 09/10/2016 03:22 AM, Claudio Freire wrote:
Overall, however, I believe the patch is in good shape. Only minor
form issues need to be changed, the functionality seems both desirable
and ready.
Pushed this "displace root" patch, with some changes:
* I renamed "tuplesort_heap_siftup()" to "tup
On Sun, Sep 11, 2016 at 1:03 AM, Tom Lane wrote:
> It might accidentally fail to fail as-is, but likely it would be better
> not to be pushing garbage paths into extraincludes and extralibs when
> some of those options aren't set.
Right, we need to correct something here. But this block does not
On 11 Sep. 2016 11:31, "Jim Nasby" wrote:
> Actually, I wish this was a straight-up logging level feature, because I
need it all the time when debugging complicated user-level code.
Specifically, I wish there was a GUC that would alter
(client|log)_min_messages upon entering a specific function,
I happened to read the pg_usleep() code recently. I'm wondering
if we could implement it using the posix function nanosleep(),
instead of by select().
nanosleep() is designed with higher time resolution, besides it provide
remaining time if is interrupted by signal so that pg_usleep() could
be imp
On 11/09/16 19:16, Mark Kirkwood wrote:
On 11/09/16 17:01, Amit Kapila wrote:
...Do you think we can do some read-only
workload benchmarking using this server? If yes, then probably you
can use concurrent hash index patch [1] and cache the metapage patch
[2] (I think Mithun needs to rebase h
On 11/09/16 17:01, Amit Kapila wrote:
On Sun, Sep 11, 2016 at 4:10 AM, Mark Kirkwood
wrote:
performed several 10 hour runs on size 100 database using 32 and 64 clients.
For the last run I rebuilt with assertions enabled. No hangs or assertion
failures.
Thanks for verification. Do you thin
> Why not just disallow dropping a value that's still in use? That's certainly
> what I would prefer to happen by default...
Of course, we should disallow it. That problem is what to do next.
We cannot just remove the value, because it might still be referenced
from the inner nodes of the indexes
68 matches
Mail list logo
