> On Thu, Dec 1, 2016 at 9:40 PM, Robert Haas wrote:
>>
>> OK, then my vote is to do it that way for now.
Thanks for your opinion. That's fine with me.
> Am 02.12.2016 um 07:22 schrieb Amit Kapila :
> Done that way in attached patch.
Did a quick review: The patch applies cleanly against curre
On Thu, Dec 1, 2016 at 6:25 PM, Robert Haas wrote:
> There's a couple of possible designs here, but there is the
> possibility for extra hops in some cases. But there are things we can
> do to mitigate that.
>
> 1. If each tuple has a definitely-all-visible bit, you can check that
> first; if it
Hello,
Sorry for the changing the status of the patch against to the current
status. While going through the recent mails, I thought that there is
some disagreement from committer.
If so, I'm willing to explain again why these operators are useful for
writing some benchmarks, for instance,
On Fri, Dec 2, 2016 at 2:02 AM Michael Paquier
wrote:
> On Fri, Dec 2, 2016 at 3:21 AM, Robert Haas wrote:
> > On Thu, Dec 1, 2016 at 10:29 AM, Vladimir Rusinov
> wrote:
> >> I've found myself wondering "where is my xlog" after running
> >> pg_switch_xlog() in 10.0.
> >>
> >> Renaming pg_xlog t
On Fri, Dec 2, 2016 at 12:08 PM, Karl O. Pinc wrote:
> On Sun, 27 Nov 2016 21:54:46 +0100
> Gilles Darold wrote:
>
> > I've attached the v15 of the patch
>
> > I've not applied patch patch_pg_current_logfile-v14.diff.backoff to
> > prevent constant call of logfile_writename() on a busy system (e
On Fri, Dec 2, 2016 at 1:32 PM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 11/23/16 5:04 PM, Tom Lane wrote:
> > I looked at this briefly. I agree that 0001-0003 are simple cleanup of
> > the grammar and could be pushed without further ado.
>
> Done.
>
> > However, starting
On Tue, Nov 22, 2016 at 2:42 PM, Tomas Vondra
wrote:
> On 11/21/2016 11:10 PM, Robert Haas wrote:
>
>> [ reviving an old multivariate statistics thread ]
>>
>> On Thu, Nov 13, 2014 at 6:31 AM, Simon Riggs
>> wrote:
>>
>>> On 12 October 2014 23:00, Tomas Vondra wrote:
>>>
>>> It however seems to
On Thu, Dec 1, 2016 at 10:33 PM, Thomas Munro wrote:
>
> Please find attached dsa-v8.patch, and also a small test module for
> running random allocate/free exercises and dumping the internal
> allocator state.
Moved to next CF with "needs review" status.
Regards,
Hari Babu
Fujitsu Australia
On Tue, Nov 22, 2016 at 10:17 PM, Haribabu Kommi
wrote:
>
> Hi Abhijit,
>
> This is a gentle reminder.
>
> you assigned as reviewer to the current patch in the 11-2016 commitfest.
> But you haven't shared your review yet. Please share your review about
> the patch. This will help us in smoother o
On Wed, Nov 23, 2016 at 11:17 PM, Daniel Verite
wrote:
>I wrote:
>
> > So I went through the psql commands which don't fail on parse errors
> > for booleans
> > [...]
>
> Here's a v5 patch implementing the suggestions mentioned upthread:
> all meta-commands calling ParseVariableBool() now fai
On Tue, Oct 11, 2016 at 1:36 PM, Tsunakawa, Takayuki <
tsunakawa.ta...@jp.fujitsu.com> wrote:
>
>
Moved to next CF with "needs review" status.
Regards,
Hari Babu
Fujitsu Australia
On Tue, Nov 29, 2016 at 4:26 PM, Mithun Cy
wrote:
> Sorry I took some time on this please find latest patch with addressed
> review comments. Apart from fixes for comments I have introduced a new GUC
> variable for the pg_autoprewarm "buff_dump_interval". So now we dump the
> buffer pool metadata
On Fri, Dec 2, 2016 at 8:41 AM, Andres Freund wrote:
> On 2016-11-30 16:11:23 +0530, Dilip Kumar wrote:
> > On Tue, Nov 29, 2016 at 11:21 PM, Robert Haas
> wrote:
> > > On Mon, Nov 28, 2016 at 11:17 PM, Dilip Kumar
> wrote:
> > >> Actually we want to call slot_getattr instead heap_getattr, beca
On Tue, Nov 1, 2016 at 1:33 AM, Kouhei Kaigai wrote:
> Hello,
>
> The attached patch implements the suggestion by Amit before.
>
> What I'm motivated is to collect extra run-time statistics specific
> to a particular ForeignScan/CustomScan, not only the standard
> Instrumentation; like DMA transf
On Tue, Nov 1, 2016 at 2:25 PM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> Here is a patch for the background sessions C API and PL/Python support.
> This was previously submitted as "autonomous transactions", which
> proved controversial, and there have been several suggestion
On Thu, Nov 3, 2016 at 4:19 PM, Thomas Munro
wrote:
> Obviously I'm actively working on developing and stabilising all this.
> Some of the things I'm working on are: work_mem accounting, batch
> increases, rescans and figuring out if the resource management for
> those BufFiles is going to work.
On 02/12/16 02:55, Thomas Munro wrote:
> On Fri, Dec 2, 2016 at 2:32 PM, Peter Eisentraut
> wrote:
>> On 11/30/16 8:06 PM, Petr Jelinek wrote:
>>> On 30/11/16 22:37, Peter Eisentraut wrote:
I have taken the libpqwalreceiver refactoring patch and split it into
two: one for the latch chang
On Thu, Dec 1, 2016 at 10:07 PM, Haribabu Kommi
wrote:
> From the recent mails, it is not clear to me what is the status of this
> patch.
> moved to next CF with "needs review" state. Please feel free to update
> the status.
I have committed this patch. And updated the status, too!
--
Robert H
On Wed, Nov 2, 2016 at 1:21 PM, David Rowley
wrote:
> On 31 October 2016 at 18:37, David Rowley
> wrote:
> > I've rebased the changes I made to address this back in April to current
> master.
>
> Please note that I went ahead and marked this as "Ready for
> committer". It was previously marked a
Petr Jelinek wrote:
> On 02/12/16 02:55, Thomas Munro wrote:
> > Commit 597a87ccc9a6fa8af7f3cf280b1e24e41807d555 left some comments
> > behind that referred to the select() that it removed. Maybe rewrite
> > like in the attached?
>
> Agreed.
Thanks, pushed.
--
Álvaro Herrerah
On Thu, Dec 1, 2016 at 9:54 PM, xu jian wrote:
> Thanks every for your help. I am not familiar with the internal of the
> vacuum freeze, just curious if there is no row change on the table(in other
> words, all pages are frozen), why could index page have dead tuple?
It can't. If the *entire* t
On Thu, Dec 1, 2016 at 6:51 PM, Amit Kapila wrote:
>> Thanks. I am thinking that it might make sense to try to get the
>> "microvacuum support for hash index" and "cache hash index meta page"
>> patches committed before this one, because I'm guessing they are much
>> simpler than this one, and I
On Tue, Nov 29, 2016 at 11:50 AM, Christian Convey
wrote:
> I think I can satisfy (3) with a PG extension which provides a function that
> approximately implements JSONPath. My short-term plans are to submit such a
> patch.
FWIW, I think that's a fine plan. I don't really know whether
JSONPath
On Fri, Dec 2, 2016 at 8:28 PM, Vladimir Rusinov wrote:
> I guess it would make sense to do all of it in 10.0.
> I'm new here, so not very sure about process. How many commit fests could I
> expect before 10.0 is out (I'm a bit busy at the moment)?
There are two remaining: 2017-01 and 2017-03: ht
On Wed, Nov 30, 2016 at 8:45 PM, Ian Barwick
wrote:
> Small doc patch to clarify how much of the query text is show in
> pg_stat_statements
> and a link to the relevant GUC.
This patch improves the pg_stat_activity documentation, not the
pg_stat_statements documentation, but it looks correct, so
On Fri, Dec 2, 2016 at 1:59 PM Michael Paquier
wrote:
> On Fri, Dec 2, 2016 at 8:28 PM, Vladimir Rusinov
> wrote:
> > I guess it would make sense to do all of it in 10.0.
> > I'm new here, so not very sure about process. How many commit fests
> could I
> > expect before 10.0 is out (I'm a bit bu
On Wed, Nov 30, 2016 at 2:56 AM, Michael Paquier
wrote:
> On Tue, Nov 29, 2016 at 08:45:13PM +0100, Christian Ullrich wrote:
>> * Michael Paquier wrote:
>>
>> > On Wed, Nov 16, 2016 at 12:45 PM, Christian Ullrich
>> > wrote:
>> >> I also did a debug build with 1+2+4 that came in at 84 μs/iteratio
I applied and tested the patch on latest master branch.
Kindly consider following comments,
ParseVariableBool(const char *value, const char *name)
+ParseVariableBool(const char *value, const char *name, bool *valid)
{
size_t len;
+ if (valid)
+ *valid = true;
psql_e
On Wed, Nov 30, 2016 at 11:38 AM, Andrew Borodin wrote:
> This scan acquires cleanup lock on root of scan (not necessarily root
> of posting tree). Cleanup lock ensures no inserts are inside subtree.
> Scan traverses subtree DF taking exclusive locks from left to right.
> For any page being delete
On Thu, Dec 1, 2016 at 5:00 AM, Mithun Cy wrote:
> On Wed, Nov 30, 2016 at 7:14 AM, Mithun Cy
> wrote:
>> Thanks, send query resets the errorMessage. Will fix same.
>> PQsendQuery()->PQsendQueryStart()->resetPQExpBuffer(&conn->errorMessage);
>
> Please find the patch which fixes this bug. conn->e
On Fri, Dec 2, 2016 at 5:01 AM, Alexander Korotkov
wrote:
> Idea of storing just one visibility bit in index tuple is a subject of
> serious doubts for me.
>
> 1. When definitely-all-visible isn't set then we have to recheck during
> scanning heap, right?
> But our current recheck (i.e. rechecking
>
>
> The other problem with not thinking about that general case is that
> people will keep on proposing little bitty features that nibble at
> the problem but may or may not be compatible with a general solution.
> To the extent that such patches get accepted, we'll be forced into
> either backwa
Hm, you omitted tableexpr.h from the v15 patch ...
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
htt
Corey Huinker writes:
> In order for me to understand how high the bar has been set, can you
> (Robert/Tom mostly, but I welcome any responses) explain what you mean by
> "full-blown expression language"? What constructs must it include, etc?
My guess is that something comparable to where pgbench
On Fri, Dec 2, 2016 at 11:12 AM, Corey Huinker wrote:
> In order for me to understand how high the bar has been set, can you
> (Robert/Tom mostly, but I welcome any responses) explain what you mean by
> "full-blown expression language"? What constructs must it include, etc?
I mostly mean it shoul
On 11/20/16 1:02 PM, Petr Jelinek wrote:
> 0001:
> This is the reworked approach to temporary slots that I sent earlier.
Andres, you had expressed an interest in this. Will you be able to
review it soon?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 S
On Thu, Dec 1, 2016 at 6:33 AM, Thomas Munro
wrote:
> Please find attached dsa-v8.patch, and also a small test module for
> running random allocate/free exercises and dumping the internal
> allocator state.
OK, I've committed the main patch. As far as test-dsa.patch, can we
tie that into make ch
On Fri, Dec 2, 2016 at 1:54 AM, Amit Kapila wrote:
>> I want to split when the average bucket
>> contains 10 pages worth of tuples.
>
> oh, I think what you mean to say is hack the code to bump fill factor
> and then test it. I was confused that how can user can do that from
> SQL command.
Yes,
On Fri, Dec 2, 2016 at 1:21 PM, Robert Haas wrote:
> On Thu, Dec 1, 2016 at 6:33 AM, Thomas Munro
> wrote:
>> Please find attached dsa-v8.patch, and also a small test module for
>> running random allocate/free exercises and dumping the internal
>> allocator state.
>
> OK, I've committed the main
On 01-12-2016 23:02, Michael Paquier wrote:
>>> Should we also:
>>>
>>> - rename pg_switch_xlog and friends to pg_switch_wal?
>>> - rename pg_recievexlog to pg_revievewal (and others in bin/)?
>>> - rename pg_xlogdump to pg_waldump?
>>
>> I think yes to all.
>
+1.
> I was hesitant to propose that
On Fri, Dec 2, 2016 at 2:56 PM, Robert Haas wrote:
> On Fri, Dec 2, 2016 at 1:21 PM, Robert Haas wrote:
>> On Thu, Dec 1, 2016 at 6:33 AM, Thomas Munro
>> wrote:
>>> Please find attached dsa-v8.patch, and also a small test module for
>>> running random allocate/free exercises and dumping the int
I wrote:
> Jim Nasby writes:
>> On 12/1/16 1:09 PM, Tom Lane wrote:
>>> I think that the patch I wrote is good cleanup, so I'm still inclined
>>> to apply it in HEAD, but I no longer think it's fixing any case that's
>>> significant in the field. I wonder if you have a counterexample?
>> No; I'm
On 11/09/2016 10:38 AM, Kyotaro HORIGUCHI wrote:
Thanks. The attached patch contains the patch by perlcritic.
0001,2,3 are Heikki's patch that are not modified since it is
first proposed. It's a bit too big so I don't attach them to this
mail (again).
https://www.postgresql.org/message-id/08e78
Heikki Linnakangas wrote:
> On 11/09/2016 10:38 AM, Kyotaro HORIGUCHI wrote:
> > Thanks. The attached patch contains the patch by perlcritic.
> >
> > 0001,2,3 are Heikki's patch that are not modified since it is
> > first proposed. It's a bit too big so I don't attach them to this
> > mail (again)
Current HaveNFreeProcs() iterates through the entire freeProcs list
(while holding ProcStructLock) just to determine if there's a small
number (superuser_reserved_connections) of free slots available. For the
common case, presumably it'd be faster to put the n<=0 test inside the
loop and return
Hi,
the new hash index code on 11003eb failed an assertion yesterday:
TRAP: FailedAssertion("!(bucket == obucket)", File: "hashpage.c", Line:
1037)
Statement was
update public.hash_i4_heap set seqno = public.hash_i4_heap.random;
It can be reproduced with the data directory (Debian str
On Sat, Dec 3, 2016 at 9:02 AM, Robert Haas wrote:
> On Fri, Dec 2, 2016 at 2:56 PM, Robert Haas wrote:
>> On Fri, Dec 2, 2016 at 1:21 PM, Robert Haas wrote:
>>> On Thu, Dec 1, 2016 at 6:33 AM, Thomas Munro
>>> wrote:
Please find attached dsa-v8.patch, and also a small test module for
On 12/02/2016 10:18 PM, Alvaro Herrera wrote:
Heikki Linnakangas wrote:
On 11/09/2016 10:38 AM, Kyotaro HORIGUCHI wrote:
Thanks. The attached patch contains the patch by perlcritic.
0001,2,3 are Heikki's patch that are not modified since it is
first proposed. It's a bit too big so I don't atta
Jim Nasby writes:
> Current HaveNFreeProcs() iterates through the entire freeProcs list
> (while holding ProcStructLock) just to determine if there's a small
> number (superuser_reserved_connections) of free slots available.
I think you misread it. Note the "n > 0" part of the while condition.
Robert Haas writes:
> Add max_parallel_workers GUC.
> Increase the default value of the existing max_worker_processes GUC
> from 8 to 16, and add a new max_parallel_workers GUC with a maximum
> of 8.
This broke buildfarm members coypu and sidewinder. It appears the reason
is that those machines
On Dec 2, 2016, at 7:47 AM, Haribabu Kommi wrote:
>> On Wed, Nov 2, 2016 at 1:21 PM, David Rowley
>> wrote:
>> On 31 October 2016 at 18:37, David Rowley
>> wrote:
>> > I've rebased the changes I made to address this back in April to current
>> > master.
>>
>> Please note that I went ahead an
Robert Haas writes:
> On Dec 2, 2016, at 7:47 AM, Haribabu Kommi wrote:
>> Patch still applies fine to HEAD.
>> Moved to next CF with "ready for committer" status.
> Tom, are you picking this up?
Yeah, I apologize for not having gotten to it in this commitfest, but
it's definitely something I w
On Fri, Dec 02, 2016 at 08:53:33AM -0500, Robert Haas wrote:
> On Tue, Nov 29, 2016 at 11:50 AM, Christian Convey
> wrote:
> > I think I can satisfy (3) with a PG extension which provides a function that
> > approximately implements JSONPath. My short-term plans are to submit such a
> > patch.
>
On 12/2/16 12:52 PM, Tom Lane wrote:
I think you misread it. Note the "n > 0" part of the while condition.
*facepalm*
Sorry for the noise...
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble
On Dec 2, 2016, at 4:07 PM, Tom Lane wrote:
> Robert Haas writes:
>> Add max_parallel_workers GUC.
>> Increase the default value of the existing max_worker_processes GUC
>> from 8 to 16, and add a new max_parallel_workers GUC with a maximum
>> of 8.
>
> This broke buildfarm members coypu and sid
On 12/2/16 2:34 PM, Robert Haas wrote:
Signs point to "no". It seemed like a good idea to leave some daylight between
max_parallel_workers and max_worker_processes, but evidently this wasn't the way to get
there. Or else we should just give up on that thought.
Could the defaults be scaled ba
Jim Nasby writes:
> On 12/2/16 2:34 PM, Robert Haas wrote:
>> Signs point to "no". It seemed like a good idea to leave some daylight
>> between max_parallel_workers and max_worker_processes, but evidently this
>> wasn't the way to get there. Or else we should just give up on that thought.
> Co
On 12/2/16 9:24 AM, Robert Haas wrote:
On Fri, Dec 2, 2016 at 11:12 AM, Corey Huinker wrote:
In order for me to understand how high the bar has been set, can you
(Robert/Tom mostly, but I welcome any responses) explain what you mean by
"full-blown expression language"? What constructs must it i
On Sat, Dec 3, 2016 at 2:06 AM, Andreas Seltenreich wrote:
> Hi,
>
> the new hash index code on 11003eb failed an assertion yesterday:
>
> TRAP: FailedAssertion("!(bucket == obucket)", File: "hashpage.c", Line:
> 1037)
>
This can happen if we start new split before completing the previous
sp
On Fri, Dec 2, 2016 at 1:32 PM, Nico Williams wrote:
...
On Fri, Dec 02, 2016 at 08:53:33AM -0500, Robert Haas wrote:
> > On Tue, Nov 29, 2016 at 11:50 AM, Christian Convey
> > wrote:
> > > I think I can satisfy (3) with a PG extension which provides a
> function that
> > > approximately impleme
On Dec 2, 2016, at 5:45 PM, Tom Lane wrote:
> Jim Nasby writes:
>>> On 12/2/16 2:34 PM, Robert Haas wrote:
>>> Signs point to "no". It seemed like a good idea to leave some daylight
>>> between max_parallel_workers and max_worker_processes, but evidently this
>>> wasn't the way to get there. O
On Sat, Dec 3, 2016 at 6:58 AM, Amit Kapila wrote:
> On Sat, Dec 3, 2016 at 2:06 AM, Andreas Seltenreich
> wrote:
>> Hi,
>>
>> the new hash index code on 11003eb failed an assertion yesterday:
>>
>> TRAP: FailedAssertion("!(bucket == obucket)", File: "hashpage.c", Line:
>> 1037)
>
> _hash_e
On Fri, Dec 2, 2016 at 3:31 PM, Tobias Bussmann wrote:
>
>> On Thu, Dec 1, 2016 at 9:40 PM, Robert Haas wrote:
>>>
>>> OK, then my vote is to do it that way for now.
>
> Thanks for your opinion. That's fine with me.
>
>> Am 02.12.2016 um 07:22 schrieb Amit Kapila :
>> Done that way in attached pa
On Sat, Dec 3, 2016 at 12:13 AM, Robert Haas wrote:
> On Fri, Dec 2, 2016 at 1:54 AM, Amit Kapila wrote:
>>> I want to split when the average bucket
>>> contains 10 pages worth of tuples.
>>
>> oh, I think what you mean to say is hack the code to bump fill factor
>> and then test it. I was conf
Hello,
My guess is that something comparable to where pgbench is would be a
reasonable target --- not least because I think we should strive to
reduce unnecessary differences between psql and pgbench metalanguages.
I'm not sure that I'm ready to propose that they should share the same
expressi
Hi
2016-12-02 23:25 GMT+01:00 Alvaro Herrera :
> Here's version 17. I have made significant changes here.
>
> 1. Restructure the execQual code. Instead of a PG_TRY wrapper, I have
> split this code in three pieces; there's the main code with the PG_TRY
> wrappers and is mainly in charge of the
66 matches
Mail list logo