On 2015/12/09 13:26, Kouhei Kaigai wrote:
On Tue, Dec 8, 2015 at 10:00 PM, Etsuro Fujita
wrote:
I think the actual regression test outputs are fine, and that your
desire to suppress part of the plan tree from showing up in the
EXPLAIN output is misguided. I like it just the way it is. To
prev
On Tue, Dec 8, 2015 at 6:00 PM, Amit Kapila wrote:
> On Tue, Dec 8, 2015 at 3:56 PM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
>>
>> Agree. This patch need to be carefully verified. Current experiments
>> just show that it is promising direction for improvement. I'll come with
>>
On Wed, Dec 9, 2015 at 5:31 PM, Amit Kapila wrote:
>
> Another bigger issue I see in the above part of code is that it doesn't
> seem to be safe to call load_hba() at that place in PostgresMain() as
> currently load_hba() is using a context created from PostmasterContext
> to perform the parsing a
>On Wednesday, 9 December 2015 12:55 PM, Amit Langote
> wrote:
>Thoughts?
Wondering, have you notice failed regression tests?
I have tried with new transformCheckConstraints() function & there will be
small fix in gram.y.
Have look into attached patch & please share your thoughts and/or su
On 03.12.2015 10:27, Vladimir Sitnikov wrote:
I've recently noticed W-TinyLfu cache admission policy (see [1]) being
used for caffeine "high performance caching library for Java 8".
It demonstrates high cache hit ratios (see [2]) and enables to build
high-throughput caches (see caffeine in [3])
On Wed, Dec 9, 2015 at 4:41 PM, Andres Freund wrote:
> On 2015-12-09 16:30:47 +0900, Michael Paquier wrote:
>> > I'm kinda wondering if it wouldn't have been better to go through shared
>> > buffers in ResetUnloggedRelationsInDbspaceDir() instead of using
>> > copy_file().
>>
>> For deployment wit
On 2015-12-09 19:36:11 +0900, Michael Paquier wrote:
> On Wed, Dec 9, 2015 at 4:41 PM, Andres Freund wrote:
> > On 2015-12-09 16:30:47 +0900, Michael Paquier wrote:
> >> > I'm kinda wondering if it wouldn't have been better to go through shared
> >> > buffers in ResetUnloggedRelationsInDbspaceDir(
On Mon, Dec 7, 2015 at 8:41 PM, Michael Paquier
wrote:
> On Tue, Nov 17, 2015 at 12:19 AM, Alvaro Herrera
> wrote:
>> Thomas Munro wrote:
>>> New version attached, merging recent changes.
>>
>> I wonder about the TailMatches and Matches macros --- wouldn't it be
>> better to have a single one, re
On Wednesday, 9 December 2015, amul sul wrote:
> >On Wednesday, 9 December 2015 12:55 PM, Amit Langote <
> langote_amit...@lab.ntt.co.jp > wrote:
>
> >Thoughts?
>
> Wondering, have you notice failed regression tests?
I did, I couldn't send an updated patch today before leaving for the day.
>
On Wed, Dec 9, 2015 at 8:17 PM, Thomas Munro
wrote:
> On Mon, Dec 7, 2015 at 8:41 PM, Michael Paquier
> wrote:
>> On Tue, Nov 17, 2015 at 12:19 AM, Alvaro Herrera
>> wrote:
>>> Thomas Munro wrote:
New version attached, merging recent changes.
>>>
>>> I wonder about the TailMatches and Match
On Tue, Dec 8, 2015 at 8:51 PM, Michael Paquier
wrote:
> On Tue, Dec 8, 2015 at 7:18 PM, Kyotaro HORIGUCHI
> wrote:
>> At Sat, 5 Dec 2015 21:05:29 +0900, Michael Paquier
>> wrote in
>>
>> > Regarding the patch, I
>> > would tend to think that we should just reject it and try to cruft
>> > som
On Wed, Dec 9, 2015 at 8:04 PM, Andres Freund wrote:
> On 2015-12-09 19:36:11 +0900, Michael Paquier wrote:
>> On Wed, Dec 9, 2015 at 4:41 PM, Andres Freund wrote:
>> > On 2015-12-09 16:30:47 +0900, Michael Paquier wrote:
>> >> > I'm kinda wondering if it wouldn't have been better to go through s
On 2015-12-09 21:03:47 +0900, Michael Paquier wrote:
> Oh, OK. I didn't read though your lines correctly. So you basically
> mean that we would look at the init files that are on disk, and check
> if they are empty. If they are, we simply use XLogReadBufferExtended
> to fetch the INIT_FORKNUM conte
On Thu, Sep 17, 2015 at 7:12 AM, Andres Freund wrote:
> On 2015-08-20 09:59:25 -0400, Andrew Dunstan wrote:
>> Is there any significant interest in either of these?
>>
>> Josh Berkus tells me that he would like pg_controldata information, and I
>> was a bit interested in pg_config information, for
On Wed, Dec 9, 2015 at 11:31 AM, Konstantin Knizhnik
wrote:
> I expect synchronization issues with implementation of this algorithm. It
> seems to be hard to avoid some global critical section which can cause
> significant performance degradation at MPP systems (see topic "Move
> PinBuffer and Unp
Hello, Robert
Thanks for your review. I believe I fixed items 1, 2 and 3 (see
attachment). Also I would like to clarify item 4.
> 4. It mixes together multiple ideas in a single patch, not only
> introducing a hashing concept but also striping a brand-new layer of
> abstraction across the resourc
On Wed, Dec 09, 2015 at 08:49:22PM +0900, Michael Paquier wrote:
> On Wed, Dec 9, 2015 at 8:17 PM, Thomas Munro
> wrote:
> > On Mon, Dec 7, 2015 at 8:41 PM, Michael Paquier
> > wrote:
> >> On Tue, Nov 17, 2015 at 12:19 AM, Alvaro Herrera
> >> wrote:
> >>> Thomas Munro wrote:
> New version a
On Tue, Dec 08, 2015 at 01:05:03PM -0500, Robert Haas wrote:
> On Tue, Dec 8, 2015 at 6:43 AM, Andres Freund wrote:
> > On 2015-12-04 21:55:29 -0500, Noah Misch wrote:
> >> On Thu, Dec 03, 2015 at 07:03:21PM +0100, Andres Freund wrote:
> >> > Sorry, but I really just want to see these changes as i
On Tue, Dec 08, 2015 at 12:13:41PM -0500, Tom Lane wrote:
> Andreas Seltenreich writes:
> >> I no longer see "failed to build any n-way joins" after pulling,
> >> but there are still instances of "could not devise a query plan".
> >> Samples below.
>
> > sorry, I spoke too soon: nine of the forme
On Wed, Nov 18, 2015 at 2:06 PM, Masahiko Sawada wrote:
> On Tue, Nov 17, 2015 at 7:52 PM, Kyotaro HORIGUCHI
> wrote:
>> Oops.
>>
>> At Tue, 17 Nov 2015 19:40:10 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
>> wrote in
>> <20151117.194010.17198448.horiguchi.kyot...@lab.ntt.co.jp>
>>> Hello,
On Wed, Dec 9, 2015 at 2:54 AM, Tom Lane wrote:
> Robert Haas writes:
>> With respect to this particular thing, it's hard for me to imagine
>> that anything will go wrong on ppcle that we wouldn't consider a
>> back-patchable fix, so there might be no harm in adjusting
>> config.guess and config.
On 2015-12-09 09:43:19 -0500, Noah Misch wrote:
> Aware of that, I have avoided[1] saying that I was shocked to see that
> commit's defects. Despite a committer-author and _two_ committer
> reviewers, the patch was rife with wrong new comments, omitted updates
> to comments it caused to become wro
On Wed, Dec 9, 2015 at 2:27 PM, David Fetter wrote:
> Agreed that the "whole new language" aspect seems like way too big a
> hammer, given what it actually does.
Which would be easier to update when things change?
Which would be possible to automatically generate from gram.y?
--
greg
--
Sent
On Wed, Dec 9, 2015 at 9:43 AM, Noah Misch wrote:
> Andres writing the patch that became commit 4f627f8 and you reviewing it were
> gifts to Alvaro and to the community. Aware of that, I have avoided[1] saying
> that I was shocked to see that commit's defects. Despite a committer-author
> and _t
On Wed, Dec 9, 2015 at 10:41 AM, Andres Freund wrote:
>> (I am glad you talked the author out of back-patching; otherwise,
>> 9.4.5 and 9.3.10 would have introduced a data loss bug.)
>
> Isn't that a bug in a, as far as we know, impossible scenario? Unless I
> miss something there's no known case
On 2015-12-09 11:18:39 -0500, Robert Haas wrote:
> If I correctly understand the scenario that you are describing, that
> does happen - not for the same MXID, but for different ones. At least
> the last time I checked, and I'm not sure if we've fixed this, it
> could happen because the SLRU page t
On Wed, Dec 9, 2015 at 3:22 AM, Etsuro Fujita
wrote:
> Sorry, my explanation might be not enough, but I'm not saying to hide the
> subplan. I think it would be better to show the subplan somewhere in the
> EXPLAIN outout, but I'm not sure that it's a good idea to show that in the
> current form.
On Fri, Dec 4, 2015 at 10:23 AM, Tom Lane wrote:
> Ashutosh Bapat writes:
>> I am seeing different results with two queries which AFAIU have same
>> semantics and hence are expected to give same results.
>
>> postgres=# select * from t1, (select distinct val, val2 from t2) t2ss where
>> t1.val =
On 09/12/15 00:02, Jeff Janes wrote:
> The second one consumes that giant tape run along with 232 small tape
> runs.
In terms of number of comparisons, binary merge works best when the
inputs are of similar length. I'd assume the same goes for n-ary
merge, but I don't know if comparison count is
On Fri, Dec 4, 2015 at 3:07 AM, Amit Kapila wrote:
> Do you think it will be useful to display in a similar way if worker
> is not able to execute plan (like before it starts execution, the other
> workers have already finished the work)?
Maybe, but it would clutter the output a good deal. I thi
On Mon, Nov 30, 2015 at 12:58 PM, Bruce Momjian wrote:
> On Mon, Nov 30, 2015 at 10:48:04PM +0530, Masahiko Sawada wrote:
>> On Sun, Nov 29, 2015 at 2:21 AM, Jeff Janes wrote:
>> > On Tue, Nov 24, 2015 at 3:13 PM, Masahiko Sawada
>> > wrote:
>> >>
>> >> Yeah, we need to consider to compute chec
On Wed, Dec 09, 2015 at 03:49:20PM +, Greg Stark wrote:
> On Wed, Dec 9, 2015 at 2:27 PM, David Fetter wrote:
> > Agreed that the "whole new language" aspect seems like way too big a
> > hammer, given what it actually does.
>
> Which would be easier to update when things change?
This questio
On Sun, Dec 6, 2015 at 4:45 PM, Thomas Munro
wrote:
> Since the ICU patch from the BSD ports trees has been discussed on
> this list a few times I thought people might be interested in this
> news:
>
> https://lists.freebsd.org/pipermail/freebsd-current/2015-October/057781.html
> https://www.drago
Hello.
While working with cluster stuff (DTM, tsDTM) we noted that postgres 2pc
transactions is approximately two times slower than an ordinary commit on
workload with fast transactions — few single-row updates and COMMIT or
PREPARE/COMMIT. Perf top showed that a lot of time is spent in kernel
Haribabu Kommi wrote:
> Reverting the context release patch is already provided in the first
> mail of this
> thread [1]. Forgot to mention about the same in further mails.
>
> Here I attached the same patch. This patch needs to be applied first before
> pg_hba_lookup patch. I tested it in window
On Sun, Dec 6, 2015 at 9:36 PM, Peter Geoghegan wrote:
> There is a redundant second appearance of more or less the same
> sentence at one point in the new INSERT documentation -- I missed this
> during the recent overhaul of the 9.5+ INSERT documentation.
>
> Attached is a trivial patch that fixe
On Sun, Dec 6, 2015 at 10:24 PM, Craig Ringer wrote:
> * An API to enumerate currently registered bgworkers
> * A way to securely make a libpq connection from a bgworker without messing
> with passwords etc. Generate one-time cookies, sometihng like that.
> * (unimportant but nice API fix): BGW_NO
On 2015-12-03 09:54:23 +0300, konstantin knizhnik wrote:
> But right now performance of Multimaster is not limited by logical
> replication protocol - if I remove DTM and use asynchronous replication
> (lightweight version of BDR:)
> then I get 38k TPS instead of 12k.
My guess is that that's to
On Sat, Oct 10, 2015 at 9:03 PM, Peter Geoghegan wrote:
> On Fri, Sep 25, 2015 at 2:39 PM, Jeff Janes wrote:
>> This needs a rebase, there are several conflicts in
>> src/backend/executor/nodeAgg.c
>
> I attached a revised version of the second patch in the series, fixing
> this bitrot.
>
> I al
On Mon, Dec 7, 2015 at 2:41 AM, Amit Langote
wrote:
> On 2015/12/03 19:05, Kyotaro HORIGUCHI wrote:
>> At Thu, 3 Dec 2015 16:24:32 +0900, Amit Langote
>> wrote
>>> By the way, there are some non-st_progress_* fields that I was talking
>>> about in my previous message. For example, st_activity_fl
On Mon, Dec 7, 2015 at 8:33 AM, Fujii Masao wrote:
> On Sat, Dec 5, 2015 at 12:56 AM, Alvaro Herrera
> wrote:
>> Fujii Masao wrote:
>>
>>> Sorry for not reviewing the patch before you push it...
>>>
>>> In HEAD, I ran very simple test case:
>>>
>>> 1. enable track_commit_timestamp
>>> 2. start th
On Wed, Dec 2, 2015 at 3:01 PM, Merlin Moncure wrote:
> On Tue, Dec 1, 2015 at 8:46 AM, YUriy Zhuravlev
> wrote:
>> On Tuesday 01 December 2015 08:38:21 you wrote:
>>> it (zero
>>> based indexing support) doesn't meet the standard of necessity for
>>> adding to the core API and as stated it's muc
Robert Haas wrote:
> On Mon, Dec 7, 2015 at 8:33 AM, Fujii Masao wrote:
> > So firstly you will push those "latest" changes soon?
>
> It seems like these changes haven't been pushed yet, and unfortunately
> that's probably a beta blocker.
I'm on this.
--
Álvaro Herrerahttp://w
On Wed, Dec 9, 2015 at 12:44 PM, Stas Kelvich wrote:
> Now 2PC in postgres does following:
> * on prepare 2pc data (subxacts, commitrels, abortrels, invalmsgs) saved to
> xlog and to file, but file not is not fsynced
> * on commit backend reads data from file
> * if checkpoint occurs before comm
I've been giving RecoveryTest.pm a look. I wonder if we really need that
as a separate package. My first thought was that we could have another
class that inherits from PostgresNode (say RecoveryNode). But later it
occured to me that we could have the new functions just be part of
PostgresNode it
This is per a report by an EnterpriseDB customer and a bunch of
off-list analysis by Kevin Grittner and Rahila Syed.
Suppose you have a large relation with OID 123456. There are segment
files 123456, 123456.1, and 123456.2. Due to some kind of operating
system malfeasance, 123456.1 disappears; y
On Wed, Dec 9, 2015 at 11:13 AM, Robert Haas wrote:
> I don't know nearly as much about ON CONFLICT DO UPDATE as Andres, but
> even I can spot a redundancy when somebody shoves the evidence right
> under my nose. So, committed and back-patched to 9.5.
Thanks.
--
Peter Geoghegan
--
Sent via
Robert Haas writes:
> The comment in mdnblocks.c says this:
> * Because we pass O_CREAT, we will create the
> next segment (with
> * zero length) immediately, if the last
> segment is of length
> * RELSEG_SIZE. While perh
Thanks, Kevin.
> I assume that last one should have been *Patched master with 2PC”?
Yes, this list should look like this:
Current master without 2PC: ~42 ktps
Current master with 2PC: ~22 ktps
Patched master with 2PC: ~36 ktps
And created CommitFest entry for this patch.
--
Stas Kelvich
Postgr
On Wed, Dec 9, 2015 at 11:31 AM, Robert Haas wrote:
> I find the references to a "void" representation in this patch to be
> completely opaque. I see that there are some such references in
> tuplesort.c already, and most likely they were put there by commits
> that I did, so I guess I have nobody
David Fetter writes:
> On Tue, Dec 08, 2015 at 12:13:41PM -0500, Tom Lane wrote:
>> Hm. At least in the first of these cases, the problem is that the
>> code I committed yesterday doesn't account for indirect lateral
>> dependencies. That is, if S1 depends on S2 which depends on the
>> inner sid
On Wed, Dec 9, 2015 at 2:15 PM, Peter Geoghegan wrote:
> I think that you're missing that patch 0001 formally forbids
> abbreviated keys that are pass-by-value
Sorry. I do of course mean it forbids abbreviated keys that are *not*
pass-by-value (that are pass-by-reference).
--
Peter Geoghegan
I'm doing some extension development (in C) and have a situation where I
need to examine the target list of a view, but all I have is the view's oid.
An approach that works is (pseudocode):
SPI_connect();
"SELECT ev_action FROM pg_catalog.pg_rewrite WHERE rulename = '_RETURN'
and ev_class=?o
On Thu, Dec 10, 2015 at 12:49 AM, Greg Stark wrote:
> On Wed, Dec 9, 2015 at 2:27 PM, David Fetter wrote:
>> Agreed that the "whole new language" aspect seems like way too big a
>> hammer, given what it actually does.
>
> Which would be easier to update when things change?
Regarding that both pa
Eric Ridge writes:
> I'm doing some extension development (in C) and have a situation where I
> need to examine the target list of a view, but all I have is the view's oid.
Open the relation and use get_view_query(), perhaps.
regards, tom lane
--
Sent via pgsql-hackers
On Wed, Dec 9, 2015 at 4:18 PM, Tom Lane wrote:
> David Fetter writes:
>> On Tue, Dec 08, 2015 at 12:13:41PM -0500, Tom Lane wrote:
>>> Hm. At least in the first of these cases, the problem is that the
>>> code I committed yesterday doesn't account for indirect lateral
>>> dependencies. That is
On Thu, Dec 10, 2015 at 3:44 AM, Stas Kelvich wrote:
> Most of that ideas was already mentioned in 2009 thread by Michael Paquier
> http://www.postgresql.org/message-id/c64c5f8b0908062031k3ff48428j824a9a46f2818...@mail.gmail.com
> where he suggested to store 2pc data in shared memory.
> At that
On Wed, Dec 9, 2015 at 4:04 PM Tom Lane wrote:
> Eric Ridge writes:
> > I'm doing some extension development (in C) and have a situation where I
> > need to examine the target list of a view, but all I have is the view's
> oid.
>
> Open the relation and use get_view_query(), perhaps.
I figured
Merlin Moncure writes:
> Aside from the functional issues, could your changes result in
> performance regressions? (if so, I'd argue not to backpatch unless
> there were cases that returned bad data as opposed to spurious
> errors).
I can't say that I think planner failures on valid queries is so
Eric Ridge writes:
> On Wed, Dec 9, 2015 at 4:04 PM Tom Lane wrote:
>> Open the relation and use get_view_query(), perhaps.
> I figured there was something simple, but I couldn't find it. Thanks!
> Sadly, it's static.
FWIW, it's exposed in 9.4 and up. But in older branches you could
probably
On Wed, Dec 9, 2015 at 5:07 PM Tom Lane wrote:
>
> FWIW, it's exposed in 9.4 and up. But in older branches you could
> probably just copy it, it's not that big.
>
That's good to know, thanks. I did copy it and it's almost 3x faster than
going through SPI. Thanks again for the pointer.
eric
On Tue, Nov 17, 2015 at 7:33 PM, Corey Huinker wrote:
> I'm willing, but I'm too new to the codebase to be an effective reviewer
> (without guidance). The one thing I can offer in the mean time is this: my
> company/client nearly always has a few spare AWS machines on the largish
> side where I ca
On Thu, Dec 10, 2015 at 4:22 AM, Alvaro Herrera
wrote:
> Haribabu Kommi wrote:
>
>> Reverting the context release patch is already provided in the first
>> mail of this
>> thread [1]. Forgot to mention about the same in further mails.
>>
>> Here I attached the same patch. This patch needs to be ap
On Wed, Dec 09, 2015 at 11:08:32AM -0500, Robert Haas wrote:
> On Wed, Dec 9, 2015 at 9:43 AM, Noah Misch wrote:
> > I hope those who have not already read commit 4f627f8 will not waste time
> > reading it. They should instead ignore multixact changes from commit
> > 4f627f8
> > through its reve
On 2015/12/09 18:07, amul sul wrote:
>> On Wednesday, 9 December 2015 12:55 PM, Amit Langote
>> wrote:
>
>> Thoughts?
>
> Wondering, have you notice failed regression tests?
Here is the updated patch.
> I have tried with new transformCheckConstraints() function & there will be
> small fix in
On Mon, Dec 07, 2015 at 02:34:39PM +0900, Michael Paquier wrote:
> On Mon, Dec 7, 2015 at 12:06 PM, Noah Misch wrote:
> > On Wed, Dec 02, 2015 at 06:59:09PM -0300, Alvaro Herrera wrote:
> >> +sub DESTROY
> >> +{
> >> + my $self = shift;
> >> + return if not defined $self->{_pid};
> >> +
On Wed, Dec 9, 2015 at 8:50 PM, Michael Paquier
wrote:
> On Tue, Dec 8, 2015 at 8:51 PM, Michael Paquier
> wrote:
>> On Tue, Dec 8, 2015 at 7:18 PM, Kyotaro HORIGUCHI
>> wrote:
>>> At Sat, 5 Dec 2015 21:05:29 +0900, Michael Paquier
>>> wrote in
>>>
>>> > Regarding the patch, I
>>> > would te
On Thu, Dec 10, 2015 at 6:46 AM, Haribabu Kommi
wrote:
>
> On Thu, Dec 10, 2015 at 4:22 AM, Alvaro Herrera
> wrote:
> > Haribabu Kommi wrote:
> >
> >> Reverting the context release patch is already provided in the first
> >> mail of this
> >> thread [1]. Forgot to mention about the same in furthe
On Wed, Dec 9, 2015 at 2:35 PM, Haribabu Kommi
wrote:
>
>
> Reverting the context release patch is already provided in the first
> mail of this
> thread [1]. Forgot to mention about the same in further mails.
>
Thanks, that is helpful. However I think it is better if you can
always keep the link
On Wed, Dec 9, 2015 at 9:07 PM, Andres Freund wrote:
> On 2015-12-09 21:03:47 +0900, Michael Paquier wrote:
>> Oh, OK. I didn't read though your lines correctly. So you basically
>> mean that we would look at the init files that are on disk, and check
>> if they are empty. If they are, we simply u
>On Thursday, 10 December 2015 8:22 AM, Amit Langote
> wrote:
>You forgot to put braces around the if block.
Does this really required?
Regards,
Amul Sul
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/m
On Thu, Dec 10, 2015 at 2:29 PM, Amit Kapila wrote:
> On Thu, Dec 10, 2015 at 6:46 AM, Haribabu Kommi
> wrote:
>>
>> On Thu, Dec 10, 2015 at 4:22 AM, Alvaro Herrera
>> wrote:
>> > Haribabu Kommi wrote:
>> >
>> >> Reverting the context release patch is already provided in the first
>> >> mail of
On 2015/12/10 13:12, amul sul wrote:
>> On Thursday, 10 December 2015 8:22 AM, Amit Langote
>> wrote:
>
>
>> You forgot to put braces around the if block.
>
>
> Does this really required?
If nothing else, for consistency with surrounding code.
Take a look at a similar code block in transfor
On 2015/12/10 13:38, Amit Langote wrote:
>
> Take a look at a similar code block in transformFKConstraints
> (parse_utilcmd.c: line 1935), or transformIndexConstraint
> (parse_utilcmd.c: line 1761).
Oops, forget the second one.
Thanks,
Amit
--
Sent via pgsql-hackers mailing list (pgsql-hack
On Mon, 07 Dec 2015 15:26:33 -0500
Korry Douglas wrote:
> The problem seems to be in PQconnectPoll() in the case for
> CONNECTION_AUTH_OK, specifically this code:
>
>/* We can release the address list now. */
>pg_freeaddrinfo_all(conn->addrlist_family, conn->addrlist);
>conn->addrl
>On Thursday, 10 December 2015 10:13 AM, Amit Langote
> wrote:
>On 2015/12/10 13:38, Amit Langote wrote:
>>
>> Take a look at a similar code block in transformFKConstraints
>> (parse_utilcmd.c: line 1935), or transformIndexConstraint
>> (parse_utilcmd.c: line 1761).
>Oops, forget the second one
On Wed, Dec 9, 2015 at 11:51 PM, Robert Haas wrote:
>
> On Fri, Dec 4, 2015 at 3:07 AM, Amit Kapila
wrote:
>
> > I think the problem is at Gather node, the number of buffers (read +
hit)
> > are greater than the number of pages in relation. The reason why it
> > is doing so is that in Workers (P
On Thu, Dec 10, 2015 at 9:51 AM, Haribabu Kommi
wrote:
>
> On Thu, Dec 10, 2015 at 2:29 PM, Amit Kapila
wrote:
> > How about creating "hba parser context" and "ident parser context"
> > at the beginning of their respective functions and don't change
> > anything in tokenize_file()?
>
> The token
On Thu, Dec 10, 2015 at 6:46 AM, Alvaro Herrera
wrote:
> I've been giving RecoveryTest.pm a look. I wonder if we really need that
> as a separate package. My first thought was that we could have another
> class that inherits from PostgresNode (say RecoveryNode). But later it
> occured to me that
On 2015/12/10 4:40, Robert Haas wrote:
> It's going to be *really* important that this facility provides a
> lightweight way of updating progress, so I think this whole API is
> badly designed. VACUUM, for example, is going to want a way to update
> the individual counter for the number of pages i
On Thu, Dec 10, 2015 at 4:33 PM, Amit Kapila wrote:
> On Thu, Dec 10, 2015 at 9:51 AM, Haribabu Kommi
> wrote:
>>
>> On Thu, Dec 10, 2015 at 2:29 PM, Amit Kapila
>> wrote:
>
>> > How about creating "hba parser context" and "ident parser context"
>> > at the beginning of their respective function
On Wed, Dec 9, 2015 at 2:17 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Tue, Dec 8, 2015 at 6:00 PM, Amit Kapila
> wrote:
>
>> On Tue, Dec 8, 2015 at 3:56 PM, Alexander Korotkov <
>> a.korot...@postgrespro.ru> wrote:
>>>
>>> Agree. This patch need to be carefully verified. Cu
On Thu, Dec 10, 2015 at 4:40 AM, Robert Haas wrote:
> On Mon, Dec 7, 2015 at 2:41 AM, Amit Langote
> wrote:
>> Hm, I guess progress messages would not change that much over the course
>> of a long-running command. How about we pass only the array(s) that we
>> change and NULL for others:
>>
>> W
On Wed, Dec 9, 2015 at 10:44 AM, Stas Kelvich wrote:
> Hello.
>
> While working with cluster stuff (DTM, tsDTM) we noted that postgres 2pc
> transactions is approximately two times slower than an ordinary commit on
> workload with fast transactions — few single-row updates and COMMIT or
> PREPA
Hello,
At Thu, 10 Dec 2015 15:28:14 +0900, Michael Paquier
wrote in
> On Thu, Dec 10, 2015 at 4:40 AM, Robert Haas wrote:
> > On Mon, Dec 7, 2015 at 2:41 AM, Amit Langote
> > wrote:
> >> Hm, I guess progress messages would not change that much over the course
> >> of a long-running command.
On December 10, 2015 5:02:27 AM GMT+01:00, Michael Paquier
wrote:
>On Wed, Dec 9, 2015 at 9:07 PM, Andres Freund
>wrote:
>> On 2015-12-09 21:03:47 +0900, Michael Paquier wrote:
>>> Oh, OK. I didn't read though your lines correctly. So you basically
>>> mean that we would look at the init files t
86 matches
Mail list logo
