On Fri, Sep 30, 2016 at 2:05 PM, Kyotaro HORIGUCHI
wrote:
> At Fri, 30 Sep 2016 14:00:15 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
> wrote in
> <20160930.140015.150178454.horiguchi.kyot...@lab.ntt.co.jp>
>> I don't see no
At Thu, 29 Sep 2016 16:16:00 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20160929.161600.224338668.horiguchi.kyot...@lab.ntt.co.jp>
> That looks better. I'll change the API as the following.
>
> COMPLETE_WITH_QUERY(query);
>
On Fri, Sep 30, 2016 at 1:26 PM, Kyotaro HORIGUCHI
wrote:
> Hello,
>
> At Fri, 30 Sep 2016 13:11:21 +0900, Masahiko Sawada
> wrote in
Sorry, it wrote wrong thing.
At Fri, 30 Sep 2016 14:00:15 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20160930.140015.150178454.horiguchi.kyot...@lab.ntt.co.jp>
> Sorry, I might have torn off this thread somehow..
>
> At Thu, 29 Sep 2016 11:26:29
Sorry, I might have torn off this thread somehow..
At Thu, 29 Sep 2016 11:26:29 -0400, David Steele wrote in
<30095aea-3910-dbb7-1790-a579fb93f...@pgmasters.net>
> On 9/28/16 10:32 PM, Michael Paquier wrote:
> > On Thu, Sep 29, 2016 at 7:45 AM, David Steele
On Fri, Sep 30, 2016 at 1:48 AM, Robert Haas wrote:
> It seems to me that you haven't tested this patch very carefully,
> because as far as I can see it breaks wait event reporting for both
> heavyweight locks and buffer pins - or in other words two out of the
> three
On Thu, Sep 29, 2016 at 9:17 PM, Michael Paquier
wrote:
> On Tue, Aug 30, 2016 at 11:04 AM, Michael Paquier
> wrote:
>> On Mon, Aug 29, 2016 at 9:39 PM, Craig Ringer
>> wrote:
>>> Cool. I'll mark as waiting on
On Thu, Sep 29, 2016 at 8:05 PM, Robert Haas wrote:
> OK, another theory: Dilip is, I believe, reinitializing for each run,
> and you are not.
Yes, I am reinitializing for each run.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
--
Sent via
Hello,
At Fri, 30 Sep 2016 13:11:21 +0900, Masahiko Sawada
wrote in
On Fri, Sep 30, 2016 at 7:08 AM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Tom Lane wrote:
>>> I wouldn't even put a lot of faith in the errno being meaningful,
>>> considering that it does close() calls before capturing the errno.
>
>> So we do
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:tested, passed
Appreciate your support.
I've tested v6 patch again, looks good
On Thu, Sep 29, 2016 at 6:19 PM, David Fetter wrote:
> On Thu, Sep 29, 2016 at 11:12:11AM +1300, Thomas Munro wrote:
>> On Mon, Sep 26, 2016 at 5:11 PM, Thomas Munro
>> wrote:
>> > On Mon, Sep 26, 2016 at 1:18 PM, Thomas Munro
>> >
On Fri, Sep 30, 2016 at 3:00 AM, Jeff Janes wrote:
> On Wed, Sep 28, 2016 at 11:57 PM, Haribabu Kommi > wrote:
>>
>>
>> Providing the details of lock wait to the client is good. I fell this
>> message
>> is useful for the cases where
On Thu, Sep 29, 2016 at 8:53 PM, Peter Geoghegan wrote:
> On Fri, Sep 30, 2016 at 1:14 AM, Robert Haas wrote:
>>> I, for one, agree with this position.
>>
>> Well, I, for one, find it frustrating. It seems pretty unhelpful to
>> bring this up only after
On 30 September 2016 at 04:15, Emrul wrote:
> Hi,
>
> I'm working on an idea to implement a graph database in Postgres. At the
> moment its just a learning exercise.
>
> What I'd like to do is store a reference to all the links from one record
> using an array type that stores
On Thu, Sep 29, 2016 at 8:29 PM, Andres Freund wrote:
> On September 29, 2016 5:28:00 PM PDT, Robert Haas
> wrote:
>>On Thu, Sep 29, 2016 at 8:16 PM, Andres Freund
>>wrote:
Well, I, for one, find it frustrating. It seems
On Fri, Sep 30, 2016 at 1:14 AM, Robert Haas wrote:
>> I, for one, agree with this position.
>
> Well, I, for one, find it frustrating. It seems pretty unhelpful to
> bring this up only after the code has already been written. The first
> post on this thread was on May
On Fri, Sep 30, 2016 at 1:29 AM, Andres Freund wrote:
>>To whom? In what context?
>
> Amit, over dinner.
In case it matters, I also talked to Amit about this privately.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On September 29, 2016 5:28:00 PM PDT, Robert Haas wrote:
>On Thu, Sep 29, 2016 at 8:16 PM, Andres Freund
>wrote:
>>> Well, I, for one, find it frustrating. It seems pretty unhelpful to
>>> bring this up only after the code has already been written.
On Thu, Sep 29, 2016 at 8:16 PM, Andres Freund wrote:
>> Well, I, for one, find it frustrating. It seems pretty unhelpful to
>> bring this up only after the code has already been written.
>
> I brought this up in person at pgcon too.
To whom? In what context?
--
Robert
On 2016-09-29 20:14:40 -0400, Robert Haas wrote:
> On Thu, Sep 29, 2016 at 8:07 PM, Peter Geoghegan wrote:
> > On Wed, Sep 28, 2016 at 8:06 PM, Andres Freund wrote:
> >> On 2016-09-28 15:04:30 -0400, Robert Haas wrote:
> >>> Andres already
> >>> stated that
On Thu, Sep 29, 2016 at 8:07 PM, Peter Geoghegan wrote:
> On Wed, Sep 28, 2016 at 8:06 PM, Andres Freund wrote:
>> On 2016-09-28 15:04:30 -0400, Robert Haas wrote:
>>> Andres already
>>> stated that he things working on btree-over-hash would be more
>>>
On Thu, Sep 29, 2016 at 8:09 AM, Amit Langote
wrote:
> I removed DEPENDENCY_IGNORE. Does the following look good or am I still
> missing something?
You missed your commit message, but otherwise looks fine.
>> Also, I think this should be rephrased a bit to be
On Wed, Sep 28, 2016 at 8:06 PM, Andres Freund wrote:
> On 2016-09-28 15:04:30 -0400, Robert Haas wrote:
>> Andres already
>> stated that he things working on btree-over-hash would be more
>> beneficial than fixing hash, but at this point it seems like he's the
>> only one who
Alvaro Herrera writes:
> Tom Lane wrote:
>> I wouldn't even put a lot of faith in the errno being meaningful,
>> considering that it does close() calls before capturing the errno.
> So we do close() in a bunch of places while closing shop, which calls
> _close() on
Michael Paquier writes:
> Oops. Are you using gcc to see that? I compiled with clang and on
> Windows without noticing it.
Peter already noted that you'd only see it on platforms that define
PG_FLUSH_DATA_WORKS.
regards, tom lane
--
Sent via
Alvaro Herrera writes:
> Moreover I think getErrorText() as a whole is misconceived and should be
> removed altogether (why pstrdup the string?).
Indeed. I think bouncing the error back to the caller is misguided
to start with, seeing that the caller is just going to
I wrote:
> But what gets my attention in this connection is that it doesn't
> seem to be taking the trouble to open the files in binary mode.
> Could that lead to the reported failure? Not sure, but it seems
> like at the least it could result in corrupted VM files.
On further thought, it
On Fri, Sep 30, 2016 at 1:31 AM, Jeff Janes wrote:
> On Thu, Sep 29, 2016 at 8:33 AM, Peter Eisentraut
> wrote:
>>
>> On 9/26/16 10:34 PM, Michael Paquier wrote:
>> > I thought that as long as the error string is shown to the user, it
>> >
Tom Lane wrote:
> Thomas Kellerer writes:
> > for some reason pg_upgrade failed on Windows 10 for me, with an error
> > message that one specifc _vm file couldn't be copied.
>
> Hmm ... a _vm file would go through rewriteVisibilityMap(), which is new
> code for 9.6 and
Thomas Kellerer writes:
> for some reason pg_upgrade failed on Windows 10 for me, with an error message
> that one specifc _vm file couldn't be copied.
Hmm ... a _vm file would go through rewriteVisibilityMap(), which is new
code for 9.6 and hasn't really gotten that much
Hackers,
I wanted to congratulate everyone involved (and it's a long list of
people) in having our first on-schedule major release since 9.3.
Especially the RMT, which did a lot to make that happen.
Getting the release train to run on time is a major accomplishment, and
will help both
On 2016-09-29 15:46:00 -0400, Tom Lane wrote:
> I noticed that buildfarm member culicidae, which is running an
> EXEC_BACKEND build on Linux, occasionally falls over like this:
>
> FATAL: could not reattach to shared memory (key=6280001,
> addr=0x7fa9df845000): Invalid argument
>
> That's
Greg Stark writes:
> On Thu, Sep 29, 2016 at 8:46 PM, Tom Lane wrote:
>> We could probably refactor things enough so that we do pq_init()
>> before PGSharedMemoryReAttach(). It would be a little bit ugly,
>> and it would fractionally increase the chance of a
Hi,
I'm working on an idea to implement a graph database in Postgres. At the
moment its just a learning exercise.
What I'd like to do is store a reference to all the links from one record
using an array type that stores links to all related tables.
At first, I've succeeded in doing this using
On 9/29/16 12:31 PM, Jeff Janes wrote:
> With that in mind, I have committed the v3 series now.
>
>
> I'm getting compiler warnings:
Fixed.
>
> file_utils.c: In function 'fsync_pgdata':
> file_utils.c:86: warning: passing argument 2 of 'walkdir' from
> incompatible pointer type
>
On Thu, Sep 29, 2016 at 8:46 PM, Tom Lane wrote:
> We could probably refactor things enough so that we do pq_init()
> before PGSharedMemoryReAttach(). It would be a little bit ugly,
> and it would fractionally increase the chance of a reattach failure
> because pq_init()
On 9/29/16 4:00 PM, Peter Eisentraut wrote:
> Since the commit fest is drawing to a close, I'll set this patch as
> returned with feedback.
Actually, the CF app informs me that moving to the next CF is more
appropriate, so I have done that.
--
Peter Eisentraut
I think we should look into handling the different page types better.
The hash_page_stats function was copied from btree, which only has one
type. It's not clear whether all the values apply to each page type.
At least they should be null if they don't apply. BRIN has a separate
function for
I noticed that buildfarm member culicidae, which is running an
EXEC_BACKEND build on Linux, occasionally falls over like this:
FATAL: could not reattach to shared memory (key=6280001, addr=0x7fa9df845000):
Invalid argument
That's probably because Andres failed to disable ASLR on that machine,
I wrote some tests for pageinspect, attached here (hash stuff in a
separate patch). I think all the output numbers ought to be
deterministic (I excluded everything that might contain xids). Please test.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
On 09/23/2016 10:27 PM, Jim Nasby wrote:
On 9/23/16 2:42 AM, Heikki Linnakangas wrote:
How do we handle single-dimensional arrays of composite types at the
moment? At a quick glance, it seems that the composite types are just
treated like strings, when they're in an array. That's probably OK,
This patch do not apply on latest code. it fails as follows
libpq-failover-9.patch:176: trailing whitespace.
thread.o pgsleep.o
libpq-failover-9.patch:184: trailing whitespace.
check:
libpq-failover-9.patch:185: trailing whitespace.
$(prove_check)
libpq-failover-9.patch:186: trailing whitespace.
Corey Huinker writes:
> [ file_fdw_program_v3.diff ]
Pushed with cosmetic adjustments, mostly more work on the comments and
documentation.
I did not push the proposed test case; it's unportable. The upthread
suggestion to add a TAP test would have been all right,
On Wed, Sep 28, 2016 at 11:57 PM, Haribabu Kommi
wrote:
>
>
> On Sat, Aug 6, 2016 at 3:00 AM, Jeff Janes wrote:
>
>> One time too many, I ran some minor change using psql on a production
>> server and was wondering why it was taking so much longer
On Thu, Sep 29, 2016 at 11:38 AM, Peter Geoghegan wrote:
> On Thu, Sep 29, 2016 at 2:59 PM, Robert Haas wrote:
>>> Maybe that was the wrong choice of words. What I mean is that it seems
>>> somewhat unprincipled to give over an equal share of memory to
On Wed, Sep 28, 2016 at 9:40 PM, Michael Paquier
wrote:
> On Wed, Sep 28, 2016 at 9:45 PM, Robert Haas wrote:
>> On Wed, Sep 28, 2016 at 8:38 AM, Michael Paquier
>> wrote:
>>> So should I change back the patch to have
On Thu, Sep 29, 2016 at 8:33 AM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 9/26/16 10:34 PM, Michael Paquier wrote:
> > I thought that as long as the error string is shown to the user, it
> > does not matter much if errno is still saved or not. All the callers
> > of
On 09/29/2016 11:58 AM, Peter Eisentraut wrote:
On 9/27/16 10:10 AM, Jesper Pedersen wrote:
contrib/pageinspect/pageinspect--1.5--1.6.sql | 59
contrib/pageinspect/pageinspect--1.5.sql | 279 --
contrib/pageinspect/pageinspect--1.6.sql | 346
>
>> The attached patch adds the
>> dependencies from create_foreignscan_plan() which is called for any
>> foreign access. I have also added testcases to test the functionality.
>> Let me know your comments on the patch.
>
>
> Hmm. I'm not sure that that's a good idea.
>
> I was thinking the
On 9/27/16 10:10 AM, Jesper Pedersen wrote:
> contrib/pageinspect/pageinspect--1.5--1.6.sql | 59
> contrib/pageinspect/pageinspect--1.5.sql | 279 --
> contrib/pageinspect/pageinspect--1.6.sql | 346 ++
I think there is still a misunderstanding
Tom Lane wrote:
> Robert Haas writes:
> > As long as we get %t and %p in there we're going to be way ahead, really.
>
> Could we get consensus on just changing the default to
>
> log_line_prefix = '%t [%p] '
>
> and leaving the rest out of it?
+1 from me.
--
On Thu, Sep 29, 2016 at 2:59 PM, Robert Haas wrote:
>> Maybe that was the wrong choice of words. What I mean is that it seems
>> somewhat unprincipled to give over an equal share of memory to each
>> active-at-least-once tape, ...
>
> I don't get it. If the memory is being
On 9/26/16 10:34 PM, Michael Paquier wrote:
> I thought that as long as the error string is shown to the user, it
> does not matter much if errno is still saved or not. All the callers
> of durable_rename() on frontends don't check for strerrno(errno)
> afterwards. Do you think it matters?
Robert Haas writes:
> On Thu, Sep 29, 2016 at 4:04 AM, Haribabu Kommi
> wrote:
>> I am also not sure whether pg_dumpall -g and then individual pg_dump
>> is the more widely used approach or not?
> That's the approach I normally recommend.
The
On 9/28/16 10:32 PM, Michael Paquier wrote:
On Thu, Sep 29, 2016 at 7:45 AM, David Steele wrote:
In general I agree with the other comments that this could end up being
a problem. On the other hand, since the additional locks are only taken
at checkpoint or
On 09/29/2016 05:41 PM, Heikki Linnakangas wrote:
Here's a new patch version, addressing the points you made. Please have
a look!
Bah, I fumbled the initSlabAllocator() function, attached is a fixed
version.
- Heikki
>From bd74cb9c32b3073637d6932f3b4552598fcdc92a Mon Sep 17 00:00:00 2001
On 27 September 2016 at 14:58, Heikki Linnakangas wrote:
> On 09/27/2016 02:04 PM, Dave Cramer wrote:
>
>> On 26 September 2016 at 14:52, Dave Cramer wrote:
>>
>>> This crashes with arrays with non-default lower bounds:
postgres=# SELECT * FROM
On Thu, Sep 29, 2016 at 6:04 AM, Robert Haas wrote:
> On Wed, Sep 28, 2016 at 3:04 PM, Robert Haas wrote:
>> I'll write another email with my thoughts about the rest of the patch.
>
> I think that the README changes for this patch need a fairly large
On Thu, Sep 29, 2016 at 4:04 AM, Haribabu Kommi
wrote:
> I am also not sure whether pg_dumpall -g and then individual pg_dump
> is the more widely used approach or not?
That's the approach I normally recommend.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
On 09/29/2016 01:52 PM, Peter Geoghegan wrote:
* Variables like maxTapes have a meaning that is directly traceable
back to Knuth's description of polyphase merge. I don't think that you
should do anything to them, on general principle.
Ok. I still think that changing maxTapes would make sense,
Robert Haas writes:
> On Thu, Sep 29, 2016 at 4:54 AM, amul sul wrote:
>> Commitfest status left untouched, I am not sure how to deal with
>> "Returned With Feedback" patch. Is there any chance that, this can be
>> considered again for committer review?
Christoph Berg writes:
> Re: Tom Lane 2016-09-29 <16946.1475157...@sss.pgh.pa.us>
>> Personally I'm also on board with using this for regression testing:
>> log_line_prefix = '%t [%p] %q%a '
>> but I doubt it can be sold as a general-purpose default.
> I don't think it makes
On Thu, Sep 29, 2016 at 10:14 AM, Tomas Vondra
wrote:
>> It's not impossible that the longer runs could matter - performance
>> isn't necessarily stable across time during a pgbench test, and the
>> longer the run the more CLOG pages it will fill.
>
> Sure, but I'm
On Thu, Sep 29, 2016 at 4:54 AM, amul sul wrote:
> On Thu, Sep 29, 2016 at 2:48 AM, Tom Lane wrote:
>> Artur Zakirov writes:
>>> - now DCH_cache_getnew() is called after parse_format(). Because now
>>> parse_format() can raise an
Re: Tom Lane 2016-09-29 <16946.1475157...@sss.pgh.pa.us>
> Robert Haas writes:
> > As long as we get %t and %p in there we're going to be way ahead, really.
>
> Could we get consensus on just changing the default to
>
> log_line_prefix = '%t [%p] '
>
> and leaving
On 09/29/2016 03:47 PM, Robert Haas wrote:
On Wed, Sep 28, 2016 at 9:10 PM, Tomas Vondra
wrote:
I feel like we must be missing something here. If Dilip is seeing
huge speedups and you're seeing nothing, something is different, and
we don't know what it is. Even
Re: Peter Eisentraut 2016-09-29
<21d2719f-36ff-06d2-5856-25ed48b96...@2ndquadrant.com>
> > Christoph/Debian:
> > log_line_prefix = '%t [%p-%l] %q%u@%d '
> > Peter:
> > log_line_prefix = '%t [%p]: [%l] %qapp=%a '
>
> I'm aware of two existing guidelines on log line formats: syslog and
>
Robert Haas writes:
> As long as we get %t and %p in there we're going to be way ahead, really.
Could we get consensus on just changing the default to
log_line_prefix = '%t [%p] '
and leaving the rest out of it? I think pretty much everybody agrees
that those
On Thu, Sep 29, 2016 at 6:52 AM, Peter Geoghegan wrote:
>> How is it awkward?
>
> Maybe that was the wrong choice of words. What I mean is that it seems
> somewhat unprincipled to give over an equal share of memory to each
> active-at-least-once tape, ...
I don't get it. If the
On Wed, Sep 28, 2016 at 10:30 PM, Peter Eisentraut
wrote:
> On 9/28/16 6:13 PM, Robert Haas wrote:
>> Christoph/Debian:
>> log_line_prefix = '%t [%p-%l] %q%u@%d '
>> Peter:
>> log_line_prefix = '%t [%p]: [%l] %qapp=%a '
>
> I'm aware of two existing
On Wed, Sep 28, 2016 at 9:10 PM, Tomas Vondra
wrote:
>> I feel like we must be missing something here. If Dilip is seeing
>> huge speedups and you're seeing nothing, something is different, and
>> we don't know what it is. Even if the test case is artificial, it
>>
=?GB2312?B?ufkg08I=?= writes:
> I have a postgresql infinite problem.
> when inserting data, a postgresql process involve to infinite loop and cpu
> usage is 100%. perf top show that LWacquirelock is most costful.
> Callstack is below.
Given that stack trace, I'd have
I have a postgresql infinite problem.
when inserting data, a postgresql process involve to infinite loop and cpu
usage is 100%. perf top show that LWacquirelock is most costful.
Callstack is below.
Other processes are normal and can process insert operation.
But after some minutes, one
Hello,
At Thu, 29 Sep 2016 16:59:55 +0900, Michael Paquier
wrote in
> On Mon, Sep 26, 2016 at 5:03 PM, Kyotaro HORIGUCHI
> wrote:
> > Hello, I return to this before
On 2016/09/29 20:03, Ashutosh Bapat wrote:
On Tue, Apr 5, 2016 at 10:54 AM, Amit Langote
wrote:
How about the attached that teaches
extract_query_dependencies() to add a foreign table and associated foreign
data wrapper and foreign server to invalItems. Also, it
On 2016/09/29 20:06, Ashutosh Bapat wrote:
On Wed, Aug 24, 2016 at 1:55 PM, Etsuro Fujita
wrote:
On 2016/04/04 23:24, Tom Lane wrote:
A related issue, now that I've seen this example, is that altering
FDW-level or server-level options won't cause a replan either.
On 2016/09/28 18:35, Etsuro Fujita wrote:
Attached is an updated version of the patch.
I found a minor bug in that patch; the relation_index added to
PgFdwRelationInfo was defined as Index, but I used the modifier %d to
print that. So, I changed the data type to int. Also, I added a bit
On Wed, Aug 24, 2016 at 1:55 PM, Etsuro Fujita
wrote:
> On 2016/04/04 23:24, Tom Lane wrote:
>>
>> Amit Langote writes:
>>>
>>> On 2016/04/04 15:17, Rajkumar Raghuwanshi wrote:
* .Observation: *Prepare statement execution plan
On Tue, Apr 5, 2016 at 10:54 AM, Amit Langote
wrote:
> On 2016/04/05 0:23, Tom Lane wrote:
>> Amit Langote writes:
>>> On Mon, Apr 4, 2016 at 11:24 PM, Tom Lane wrote:
A related issue, now that I've seen this
On 9/28/16 9:55 PM, Peter Eisentraut wrote:
> On 9/28/16 2:45 AM, Michael Paquier wrote:
>> After all that fixed, I have moved the patch to "Ready for Committer".
>> Please use the updated patch though.
>
> Committed after some cosmetic changes.
Thank you, Peter!
--
-David
da...@pgmasters.net
On Thu, Sep 29, 2016 at 10:49 AM, Heikki Linnakangas wrote:
>> Do I have that right? If so, this seems rather awkward. Hmm.
>
>
> How is it awkward?
Maybe that was the wrong choice of words. What I mean is that it seems
somewhat unprincipled to give over an equal share of memory
On Mon, Sep 5, 2016 at 10:01 AM, Michael Paquier
wrote:
> On Sat, Sep 3, 2016 at 10:35 PM, Magnus Hagander
> wrote:
> > Ugh. That would be nice to have, but I think that's outside the scope of
> > this patch.
>
> A test for this patch that could
Hi Stephen,
> 4. It will be good if we have an example for this in section
> > "5.7. Row Security Policies"
>
> I haven't added one yet, but will plan to do so.
>
> I think you are going to add this in this patch itself, right?
I have reviewed your latest patch and it fixes almost all my review
On 09/29/2016 02:45 AM, Ivan Kartyshov wrote:
> Secondly, I see this bit added to the loop over buffers:
>
> if (bufHdr->tag.forkNum == -1)
> {
> fctx->record[i].blocknum = InvalidBlockNumber;
> continue;
> }
>
> and I have no idea why this is needed (when it
2016-09-29 13:54 GMT+05:00 amul sul :
>
> On Thu, Sep 29, 2016 at 2:48 AM, Tom Lane wrote:
> >
> > I started looking at your 0001-to-timestamp-format-checking-v4.patch
> > and this point immediately jumped out at me. Currently the code relies
> > ...
On 09/28/2016 07:20 PM, Peter Geoghegan wrote:
On Wed, Sep 28, 2016 at 5:11 PM, Peter Geoghegan wrote:
This is why I never pursued batch memory for non-final merges. Isn't
that what you're doing here? You're pretty much always setting
"state->batchUsed = true".
Wait. I guess
Hello,
At Tue, 13 Sep 2016 10:00:32 -0300, Alvaro Herrera
wrote in <20160913130032.GA391646@alvherre.pgsql>
> Michael Paquier wrote:
> > On Tue, Sep 13, 2016 at 10:42 AM, Kyotaro HORIGUCHI
> > wrote:
> > > If we take a policy to try to
On Thu, Sep 29, 2016 at 2:48 AM, Tom Lane wrote:
> Artur Zakirov writes:
>> - now DCH_cache_getnew() is called after parse_format(). Because now
>> parse_format() can raise an error and in the next attempt
>> DCH_cache_search() could return broken
Hello, thank you for the comment.
At Fri, 23 Sep 2016 18:15:40 +0530, Amit Khandekar
wrote in
> Well, those two results are not contradictory -- notice that you
> switched the order of the values in the comparison. I don't think
> you've really found the explanation yet.
I am sorry I copy-pasted the wrong example:
"select_views" test runs:
> SELECT name, #thepath FROM iexit ORDER BY 1,
On Tue, Aug 30, 2016 at 11:04 AM, Michael Paquier
wrote:
> On Mon, Aug 29, 2016 at 9:39 PM, Craig Ringer
> wrote:
>> Cool. I'll mark as waiting on author pending that.
>>
>> It'll be good to get this footgun put away.
>
> OK, so done. I
Hello,
At Tue, 20 Sep 2016 16:50:29 +0900, Michael Paquier
wrote in
> On Mon, Sep 19, 2016 at 6:11 PM, Pavel Stehule
> wrote:
> > I am thinking so commit's description
On Mon, Sep 26, 2016 at 2:29 PM, Rafia Sabih
wrote:
> On Tue, Jul 5, 2016 at 06:39 AM, Haribabu Kommi
> kommi(dot)haribabu(at)gmail(dot)com wrote:
>
> Still i feel the GRANT statements should be present, as the create
> database statement
> is generated only with -C
On Mon, Sep 26, 2016 at 5:03 PM, Kyotaro HORIGUCHI
wrote:
> Hello, I return to this before my things:)
>
> Though I haven't played with the patch yet..
Be sure to run the test cases in the patch or base your tests on them then!
> Though I don't know how it
On Thu, Sep 29, 2016 at 12:56 PM, Dilip Kumar wrote:
> On Thu, Sep 29, 2016 at 6:40 AM, Tomas Vondra
> wrote:
>> Yes, definitely - we're missing something important, I think. One difference
>> is that Dilip is using longer runs, but I don't
On Thu, Sep 29, 2016 at 6:40 AM, Tomas Vondra
wrote:
> Yes, definitely - we're missing something important, I think. One difference
> is that Dilip is using longer runs, but I don't think that's a problem (as I
> demonstrated how stable the results are).
>
> I wonder
Thank you for reviewing!
At Mon, 19 Sep 2016 11:11:03 +0200, Pavel Stehule
wrote in
On 29 September 2016 at 12:53, Petr Jelinek wrote:
> On 29/09/16 05:33, Michael Paquier wrote:
>> On Wed, Sep 28, 2016 at 11:25 PM, Konstantin Knizhnik
>> wrote:
>>> But if table was just altered and some attribute was removed from the table,
>>>
On Sat, Aug 6, 2016 at 3:00 AM, Jeff Janes wrote:
> One time too many, I ran some minor change using psql on a production
> server and was wondering why it was taking so much longer than it did
> on the test server. Only to discover, after messing around with
> opening new
1 - 100 of 103 matches
Mail list logo