Hello Doug,
With patch and ‘-I dtgvpf’ options:
pgrun pgbench -i -s 2000 -F 90 -q -I dtgvpf
dropping old tables...
creating tables...
generating data...
…
2 of 2 tuples (100%) done (elapsed 168.76 s, remaining 0.00 s)
vacuuming...
creating primary keys...
creating foreign keys..
On Tue, Jan 30, 2018 at 6:48 PM, Tatsuo Ishii wrote:
>>> You need to DROP VIEW lock_view4 and lock_view5 in the regression
>>> test as well.
>>
>> Thank you for reviewing the patch.
>>
>> I fixed this and attached a updated patch v6.
>
> Looks good to me. If there's no objection, especially from T
>> You need to DROP VIEW lock_view4 and lock_view5 in the regression
>> test as well.
>
> Thank you for reviewing the patch.
>
> I fixed this and attached a updated patch v6.
Looks good to me. If there's no objection, especially from Thomas
Munro, I will mark this as "ready for committer".
Best
From: Masahiko Sawada [mailto:sawada.m...@gmail.com]
> On Mon, Jan 29, 2018 at 3:33 PM, Tsunakawa, Takayuki
> wrote:
> > I can understand your concern. On the other hand, it's unfair that one
> database could monopolize all workers, because other databases might also
> be facing wraparound risk.
On Tue, 30 Jan 2018 13:58:30 +0900 (JST)
Tatsuo Ishii wrote:
> > Attached is the updated patch v5 including fixing SGML and rebase to HEAD.
>
> You need to DROP VIEW lock_view4 and lock_view5 in the regression
> test as well.
Thank you for reviewing the patch.
I fixed this and attached a updat
On Tue, Jan 30, 2018 at 03:10:12PM +1100, Haribabu Kommi wrote:
> Ok, understood. As the libpq gives preference to hostaddr connection
> parameter than host while connecting. How about going with one column
> "remote_host" that displays either hostaddr(if exists) or hostname. So that
> one column t
> Attached is the updated patch v5 including fixing SGML and rebase to HEAD.
You need to DROP VIEW lock_view4 and lock_view5 in the regression
test as well.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
On Mon, Jan 29, 2018 at 09:16:56PM -0500, Peter Eisentraut wrote:
> On 1/28/18 23:43, Michael Paquier wrote:
>> The comment at the top of PQinitSSL mentions OpenSSL, you may want to
>> get rid of it as well.
>
> I think that whole business is actually obsolete as of OpenSSL 1.1.0 and
> not applica
Hi,
On Mon, Jan 29, 2018 at 10:40 AM, Andres Freund wrote:
> Hi,
>
> On 2018-01-29 10:28:18 -0800, Jeff Davis wrote:
>> OK. How about this: are you open to changes that move us in the
>> direction of extensibility later? (By this I do *not* mean imposing a
>> bunch of requirements on you... eithe
On Mon, Jan 29, 2018 at 3:33 PM, Tsunakawa, Takayuki
wrote:
> From: Masahiko Sawada [mailto:sawada.m...@gmail.com]
>> What I thought is that a worker reports these two values after scanned
>> pg_class and after freezed a table. The launcher decides to launch a new
>> worker if the number of tables
On Mon, Jan 29, 2018 at 7:06 PM, Michael Paquier
wrote:
> On Tue, Jan 16, 2018 at 05:56:22PM +1100, Haribabu Kommi wrote:
> > Without PQhostaddr() function, for the connections where the host is not
> > specified, it will be difficult to find out to remote server.
>
> That's true as well, but hos
Hi,
On 2018-01-29 22:41:53 -0500, Tom Lane wrote:
> But I think a big part of the value here is to verify that we've
> cleaned up our internal APIs to the point where a different SSL/TLS
> implementation *could* be rolled underneath.
Yea, I completely agree with that.
> As part of that, we certa
Andres Freund writes:
> FWIW, I'm -0.5 on adding gnutls support. I've not seen any non-vague
> arguments for it, and having debugged gnutls using applications in the
> past, I'm not convinced we're not primarily increasing our workload by
> adding support. If gnutls would improve our windows or OS
On Mon, Jan 29, 2018 at 07:39:33PM -0500, Peter Eisentraut wrote:
> I think most users actually still think about the whole topic as "SSL",
> and the leading library is called "OpenSSL", so I think we're fine.
Yes, that's my impression on the matter as well. While renaming the
client-side paramet
On Mon, Jan 29, 2018 at 06:24:18PM -0800, Andres Freund wrote:
> FWIW, I'm -0.5 on adding gnutls support. I've not seen any non-vague
> arguments for it, and having debugged gnutls using applications in the
> past, I'm not convinced we're not primarily increasing our workload by
> adding support. I
On 2018-01-17 12:30:16 -0500, Peter Eisentraut wrote:
> On 1/2/18 10:35, Peter Eisentraut wrote:
> > On 11/26/17 20:05, Andreas Karlsson wrote:
> >> I have now implemented this in the attached patch (plus added support
> >> for channel binding and rebased it) but I ran into one issue which I
> >>
On 1/28/18 23:43, Michael Paquier wrote:
> The comment at the top of PQinitSSL mentions OpenSSL, you may want to
> get rid of it as well.
I think that whole business is actually obsolete as of OpenSSL 1.1.0 and
not applicable to GnuTLS, so we might just leave it to die with some
appropriate docume
On 29 January 2018 at 22:53, Andres Freund wrote:
> Hi,
>
> On 2018-01-23 23:20:38 -0800, Andres Freund wrote:
> > == Code ==
> >
> > As the patchset is large (500kb) and I'm still quickly evolving it, I do
> > not yet want to attach it. The git tree is at
> > https://git.postgresql.org/git/use
On 1/29/18 8:10 PM, Masahiko Sawada wrote:
> On Tue, Jan 30, 2018 at 5:45 AM, Adam Brightwell
> wrote:
>> On Mon, Jan 29, 2018 at 1:17 PM, David Steele wrote:
>>>
>>> Whoops, my bad. Temp relations are stored in the db directories with a
>>> "t" prefix. Looks like we can take care of those easi
On Mon, Jan 29, 2018 at 2:55 AM, David Rowley
wrote:
> On 28 January 2018 at 12:00, Tomas Vondra
> wrote:
> > On 01/27/2018 10:45 PM, Tom Lane wrote:
> >> David Rowley writes:
> >>> I'd offer to put it back to the order of the enum, but I want to
> >>> minimise the invasiveness of the patch. I'
On Tue, Jan 30, 2018 at 5:45 AM, Adam Brightwell
wrote:
> On Mon, Jan 29, 2018 at 1:17 PM, David Steele wrote:
>> On 1/29/18 9:13 AM, David Steele wrote:
>>> On 1/29/18 5:28 AM, Masahiko Sawada wrote:
But I
have a question; can we exclude temp tables as well? The pg_basebackup
incl
Hi Jesper.
On 2018/01/29 22:13, Jesper Pedersen wrote:
> Hi Amit,
>
> On 01/26/2018 04:17 AM, Amit Langote wrote:
>> I made a few of those myself in the updated patches.
>>
>> Thanks a lot again for your work on this.
>>
>
> This needs a rebase.
AFAICS, v22 cleanly applies to HEAD (c12693d8f3 [
On 1/27/18 19:49, Bruce Momjian wrote:
> To open another can of worms, are we ever going to rename "ssl"
> parameters to "tls"
I had been thinking about that, too, but it doesn't seem worth it.
While renaming server-side settings might be feasible with some
annoyance, this would also include renam
Another thing I'm a little confused by is the precise API for the in_range
support functions (the lack of any documentation for it doesn't help).
I wonder why you chose to provide two support functions per datatype
combination rather than one with an additional boolean argument.
In fact, it almost
On Mon, Jan 29, 2018 at 04:34:48PM +, Simon Riggs wrote:
> In terms of timing of commits, I have marked the patch Ready For
> Committer. To me that signifies that it is ready for review by a
> Committer prior to commit.
My understanding of this meaning is different than yours. It should not
b
On Sat, Jan 27, 2018 at 12:20 AM, Amit Kapila wrote:
> I have posted the patch for the above API and posted it on a new
> thread [1]. Do let me know either here or on that thread if the patch
> suffices your need?
I've responded to you over on that thread. Thanks again for helping me.
I already
On 1/22/18 16:04, Chapman Flack wrote:
>> PostgreSQL only allows a trigger action of "call this function", so in
>> the SQL standard context that would mean we'd need to check the EXECUTE
>> privilege of the owner of the trigger. The trick is figuring out who
>> the owner is. If it's the owner
Hi,
On 2018-01-30 00:16:46 +0100, Tomas Vondra wrote:
> FWIW I've installed llvm 5.0.1 from distribution package, and now
> everything builds fine (I don't even need the configure tweak).
>
> I think I had to build the other binaries because there was no 5.x llvm
> back then, but it's too far bac
On 01/29/2018 11:49 PM, Tomas Vondra wrote:
>
> ...
>
> and that indeed changes the failure to this:
>
> Writing postgres.bki
> Writing schemapg.h
> Writing postgres.description
> Writing postgres.shdescription
> llvmjit_error.cpp: In function ‘void llvm_enter_fatal_on_oom()’:
> llvmjit_error.c
Hi,
On 2018-01-29 23:49:14 +0100, Tomas Vondra wrote:
> On 01/29/2018 11:17 PM, Andres Freund wrote:
> > On 2018-01-29 23:01:14 +0100, Tomas Vondra wrote:
> >> $ llvm-config --version
> >> 5.0.0svn
> >
> > Is thta llvm-config the one in /usr/local/include/ referenced by the
> > error message above
On Monday, 29 January 2018, Tom Lane wrote:
> Oliver Ford writes:
> > On Monday, 29 January 2018, Tom Lane wrote:
> >> I've started to go through this in some detail, and I'm wondering why
> >> you invented a FRAMEOPTION_EXCLUDE_NO_OTHERS option bit rather than
> >> just representing that choic
Oliver Ford writes:
> On Monday, 29 January 2018, Tom Lane wrote:
>> I've started to go through this in some detail, and I'm wondering why
>> you invented a FRAMEOPTION_EXCLUDE_NO_OTHERS option bit rather than
>> just representing that choice as default (0).
> My guess is that it's a little like
On 01/29/2018 11:17 PM, Andres Freund wrote:
> On 2018-01-29 23:01:14 +0100, Tomas Vondra wrote:
>> On 01/29/2018 10:57 PM, Andres Freund wrote:
>>> Hi,
>>>
>>> On 2018-01-29 22:51:38 +0100, Tomas Vondra wrote:
Hi, I wanted to look at this, but my attempts to build the jit branch
fail w
On Mon, Jan 29, 2018 at 1:34 PM, Simon Riggs wrote:
>> The way that routines like ExecUpdate() interact with MERGE for WHEN
>> qual + EPQ handling seems kind of convoluted. I hope for something
>> cleaner in the next revision.
>
> Cleaner?
Yeah, cleaner. The fact that when quals kind of participa
On 2018-01-29 23:01:14 +0100, Tomas Vondra wrote:
> On 01/29/2018 10:57 PM, Andres Freund wrote:
> > Hi,
> >
> > On 2018-01-29 22:51:38 +0100, Tomas Vondra wrote:
> >> Hi, I wanted to look at this, but my attempts to build the jit branch
> >> fail with some compile-time warnings (uninitialized var
On Monday, 29 January 2018, Tom Lane wrote:
> Oliver Ford writes:
> > [ 0001-window-frame-v9.patch ]
>
> I've started to go through this in some detail, and I'm wondering why
> you invented a FRAMEOPTION_EXCLUDE_NO_OTHERS option bit rather than
> just representing that choice as default (0). As
On 01/29/2018 10:57 PM, Andres Freund wrote:
> Hi,
>
> On 2018-01-29 22:51:38 +0100, Tomas Vondra wrote:
>> Hi, I wanted to look at this, but my attempts to build the jit branch
>> fail with some compile-time warnings (uninitialized variables) and
>> errors (unknown types, incorrect number of argu
On Sun, Jan 28, 2018 at 10:13 PM, Amit Kapila wrote:
> If we want to get rid of Gather (Merge) checks in
> apply_projection_to_path(), then we need some way to add a projection
> path to the subpath of gather node even if that is capable of
> projection as we do now. I think changing the order of
Hi,
On 2018-01-29 22:51:38 +0100, Tomas Vondra wrote:
> Hi, I wanted to look at this, but my attempts to build the jit branch
> fail with some compile-time warnings (uninitialized variables) and
> errors (unknown types, incorrect number of arguments). See the file
> attached.
Which git hash are y
On 01/24/2018 08:20 AM, Andres Freund wrote:
> Hi,
>
> I've spent the last weeks working on my LLVM compilation patchset. In
> the course of that I *heavily* revised it. While still a good bit away
> from committable, it's IMO definitely not a prototype anymore.
>
> There's too many small chang
Hi,
In contrast to most other nodes, nodeValuescan.c does expression
initialization at "runtime" rather than in initialization:
/*
* Get rid of any prior cycle's leftovers. We use
ReScanExprContext
* not just ResetExprContext because we want any
On 29 January 2018 at 20:41, Peter Geoghegan wrote:
> On Mon, Jan 29, 2018 at 6:11 AM, Simon Riggs wrote:
>> New patch attached that correctly handles all known concurrency cases,
>> with expected test output.
>
> This revision, v13, seems much improved in this area.
>
>> This means MERGE will wo
On 1/19/18 4:43 PM, Peter Eisentraut wrote:
> On 1/19/18 14:07, David Steele wrote:
>> I have yet to add tests for pg_rewindwal and pg_upgrade. pg_rewindwal
>> doesn't *have* any tests as far as I can tell and pg_upgrade has tests
>> in a shell script -- it's not clear how I would extend it or reu
Oliver Ford writes:
> [ 0001-window-frame-v9.patch ]
I've started to go through this in some detail, and I'm wondering why
you invented a FRAMEOPTION_EXCLUDE_NO_OTHERS option bit rather than
just representing that choice as default (0). As you have it, a
window definition that explicitly specifi
Hi,
On 2017-10-04 11:36:56 +0200, Alvaro Herrera wrote:
> Andrew Dunstan wrote:
> > On 10/03/2017 04:43 PM, Tom Lane wrote:
> > > I like the new-header-file idea because it will result in minimal code
> > > churn and thus minimal back-patching hazards.
I'm not sure it's that little code churn, an
On Mon, Jan 29, 2018 at 1:17 PM, David Steele wrote:
> On 1/29/18 9:13 AM, David Steele wrote:
>> On 1/29/18 5:28 AM, Masahiko Sawada wrote:
>>> But I
>>> have a question; can we exclude temp tables as well? The pg_basebackup
>>> includes even temp tables. But I don't think that it's necessary for
On Mon, Jan 29, 2018 at 6:11 AM, Simon Riggs wrote:
> New patch attached that correctly handles all known concurrency cases,
> with expected test output.
This revision, v13, seems much improved in this area.
> This means MERGE will work just fine for "normal" UPDATEs, but it will
> often fail (d
On 1/23/18 17:10, Alvaro Herrera wrote:
> The main question is this: when running the trigger function, it is
> going to look as it is running in the context of the partition, not in
> the context of the parent partitioned table (TG_RELNAME etc). That
> seems mildly ugly: some users may be expecti
Bruce>Well, we could have the connection pooler disconnect those, right?
I agree. Do you think we could rely on all the applications being
configured in a sane way?
A fallback configuration at DB level could still be useful to ensure the DB
keeps running in case multiple applications access it. It
Hi,
On 2018-01-29 10:28:18 -0800, Jeff Davis wrote:
> OK. How about this: are you open to changes that move us in the
> direction of extensibility later? (By this I do *not* mean imposing a
> bunch of requirements on you... either small changes to your patches
> or something part of another commit
On Mon, Jan 29, 2018 at 1:36 AM, Andres Freund wrote:
> There's already a *lot* of integration points in the patchseries. Error
> handling needs to happen in parts of code we do not want to make
> extensible, the defintion of expression steps has to exactly match, the
> core code needs to emit the
On 1/29/18 9:13 AM, David Steele wrote:
> On 1/29/18 5:28 AM, Masahiko Sawada wrote:
>> But I
>> have a question; can we exclude temp tables as well? The pg_basebackup
>> includes even temp tables. But I don't think that it's necessary for
>> backups
> Thank you for having another look at the patch
On 29 January 2018 at 17:35, Peter Geoghegan wrote:
> On Mon, Jan 29, 2018 at 8:51 AM, Simon Riggs wrote:
>> On 29 January 2018 at 16:44, Bruce Momjian wrote:
>>
>>> I think the question is how does it handle cases it doesn't support?
>>> Does it give wrong answers? Does it give a helpful error
On Mon, Jan 29, 2018 at 8:51 AM, Simon Riggs wrote:
> On 29 January 2018 at 16:44, Bruce Momjian wrote:
>
>> I think the question is how does it handle cases it doesn't support?
>> Does it give wrong answers? Does it give a helpful error message? Can
>> you summarize that?
>
> I'm happy to repo
On Mon, Jan 29, 2018 at 8:44 AM, Bruce Momjian wrote:
> On Mon, Jan 29, 2018 at 04:34:48PM +, Simon Riggs wrote:
>> The only discussion would be about the word "unfinished". I'm not
>> clear why this patch, which has current caveats all clearly indicated
>> in the docs, differs substantially f
2018-01-29 18:08 GMT+01:00 Simon Riggs :
> On 29 January 2018 at 16:23, Chapman Flack wrote:
> > On 01/29/2018 11:13 AM, Simon Riggs wrote:
> >> On 29 January 2018 at 15:44, Bruce Momjian wrote:
> >>> Uh, if we know we are going to get question on this, the patch had
> >>> better have an explana
On 29 January 2018 at 16:23, Chapman Flack wrote:
> On 01/29/2018 11:13 AM, Simon Riggs wrote:
>> On 29 January 2018 at 15:44, Bruce Momjian wrote:
>>> Uh, if we know we are going to get question on this, the patch had
>>> better have an explanation of when to use it. Pushing the problem to
>>>
On 01/29/2018 03:17 PM, Simon Riggs wrote:
> On 29 January 2018 at 14:13, Tomas Vondra
> wrote:
>
>> 4) inspect the new row (which we still have in reorderbuffer)
>>
>> 5) Kabooom! The row has column "c" which we don't see in the catalog.
>
> We don't use caches? Why does a cache miss cause i
On 29 January 2018 at 16:50, Tom Lane wrote:
> Bruce Momjian writes:
>> On Mon, Jan 29, 2018 at 04:34:48PM +, Simon Riggs wrote:
>>> ... If unfinished means it has caveats
>>> that is different to unfinished meaning crappy, risky, contentious
>>> etc..
>
>> I think the question is how does it
Hi,
On 2018-01-29 15:45:56 +0300, Konstantin Knizhnik wrote:
> On 26.01.2018 22:38, Andres Freund wrote:
> > And without it perf is not able to unwind stack trace for generated
> > > code.
> > You can work around that by using --call-graph lbr with a sufficiently
> > new perf. That'll not know fun
On 29 January 2018 at 16:44, Bruce Momjian wrote:
> I think the question is how does it handle cases it doesn't support?
> Does it give wrong answers? Does it give a helpful error message? Can
> you summarize that?
I'm happy to report that it gives correct answers to every known MERGE
test, ex
Bruce Momjian writes:
> On Mon, Jan 29, 2018 at 04:34:48PM +, Simon Riggs wrote:
>> ... If unfinished means it has caveats
>> that is different to unfinished meaning crappy, risky, contentious
>> etc..
> I think the question is how does it handle cases it doesn't support?
> Does it give wron
On 29.01.2018 16:24, Konstantin Knizhnik wrote:
On 29.01.2018 07:34, Thomas Munro wrote:
On Sat, Jan 20, 2018 at 5:41 AM, Konstantin Knizhnik
wrote:
On 19.01.2018 16:14, Antonin Houska wrote:
you should test the operator B-tree strategy: BTLessStrategyNumber,
BTLessEqualStrategyNumber, etc.
On Mon, Jan 29, 2018 at 04:34:48PM +, Simon Riggs wrote:
> I agree with all of the above.
>
> In terms of timing of commits, I have marked the patch Ready For
> Committer. To me that signifies that it is ready for review by a
> Committer prior to commit.
>
> In case of doubt, I would not even
On 29 January 2018 at 16:06, Tom Lane wrote:
> Simon Riggs writes:
>> On 29 January 2018 at 15:07, Robert Haas wrote:
>>> An argument could be made that this patch is already too late for PG
>>> 11, because it's a major feature that was not submitted in relatively
>>> complete form before the be
On 01/29/2018 11:13 AM, Simon Riggs wrote:
> On 29 January 2018 at 15:44, Bruce Momjian wrote:
>> Uh, if we know we are going to get question on this, the patch had
>> better have an explanation of when to use it. Pushing the problem to
>> later doesn't seem helpful.
>
> What problem are you ref
On 29 January 2018 at 15:44, Bruce Momjian wrote:
> On Mon, Jan 29, 2018 at 03:12:23PM +, Simon Riggs wrote:
>> On 29 January 2018 at 14:55, Pavel Stehule wrote:
>>
>> > My note was not against MERGE or INSERT ON CONFLICT. If I understand to
>> > this
>> > topic, I agree so these commands sh
On Mon, Jan 29, 2018 at 04:02:22PM +, Vladimir Sitnikov wrote:
> Bruce>Yes, it would impact applications and you are right most applications
> could not handle that cleanly.
>
> I would disagree here.
> We are discussing applications that produce "lots of idle" connections, aren't
> we? That t
Simon Riggs writes:
> On 29 January 2018 at 15:07, Robert Haas wrote:
>> An argument could be made that this patch is already too late for PG
>> 11, because it's a major feature that was not submitted in relatively
>> complete form before the beginning of the penultimate CommitFest.
> Overall, I
On Mon, 29 Jan 2018 17:29:29 +0300
Ildar Musin wrote:
>
> Patch applies cleanly, builds without any warnings, documentation
> builds ok, all tests pass.
>
> A remark for the committers. The patch is quite big, so I really wish
> more reviewers looked into it for more comprehensive review. Also
Bruce>Yes, it would impact applications and you are right most applications
could not handle that cleanly.
I would disagree here.
We are discussing applications that produce "lots of idle" connections,
aren't we? That typically comes from an application-level connection pool.
Most of the connectio
On Mon, Jan 29, 2018 at 03:12:23PM +, Simon Riggs wrote:
> On 29 January 2018 at 14:55, Pavel Stehule wrote:
>
> > My note was not against MERGE or INSERT ON CONFLICT. If I understand to this
> > topic, I agree so these commands should be implemented separately. But if we
> > use two commands
Hannu Krosing writes:
> I started looking at the thread about "Generic type subscripting" and am
> wondering, why does it take the approach of modifying pg_type and
> modifying lots of internal functions, when instead it could be defined
> in a much lighter and less intrusive way as an operator, p
On Mon, Jan 29, 2018 at 11:57:36AM +0300, Konstantin Knizhnik wrote:
> Right now, if you hit max_connections, we start rejecting new
> connections. Would it make sense to allow an option to exit idle
> connections when this happens so new users can connect?
>
> It will require changes
On 29 January 2018 at 15:07, Robert Haas wrote:
> Moreover, the patch should have had meaningful review from people not
> involved in writing it, and that is a process that generally takes a
> few months or at least several weeks, not a few days.
The code is about 1200 lines and has extensive do
On 29 January 2018 at 14:55, Pavel Stehule wrote:
> My note was not against MERGE or INSERT ON CONFLICT. If I understand to this
> topic, I agree so these commands should be implemented separately. But if we
> use two commands with some intersection, there can be nice to have
> documentation abou
On Tue, Jan 23, 2018 at 8:51 AM, Simon Riggs wrote:
> This is complete and pretty clean now. 1200 lines of code, plus docs and
> tests.
>
> I'm expecting to commit this and then come back for the Partitioning &
> RLS later, but will wait a few days for comments and other reviews.
I agree with Pe
On Mon, Jan 29, 2018 at 02:51:53PM +, Ryan Murphy wrote:
> >
> > >What I propose is in fact a server command, >which at least three of
> > >the other popular RDBMSs already have.
> >
> Well to actually implement it, it would probably be a client command,
> because that's what \d* are.
Why shou
2018-01-29 15:40 GMT+01:00 Simon Riggs :
> On 29 January 2018 at 14:19, Pavel Stehule
> wrote:
>
> >> The concurrency rules are very simple:
> >> If a MATCHED row is concurrently updated/deleted
> >> 1. We run EvalPlanQual
> >> 2. If the updated row is gone EPQ returns NULL slot or EPQ returns a
On Sat, Jan 27, 2018 at 3:14 AM, Amit Kapila wrote:
> During the recent development of parallel operation (parallel create
> index)[1], a need has been arised for $SUBJECT. The idea is to allow
> leader backend to rely on number of workers that are successfully
> started. This API allows leader
>
> >What I propose is in fact a server command, >which at least three of
> >the other popular RDBMSs already have.
>
Well to actually implement it, it would probably be a client command,
because that's what \d* are. We would most likely want them implemented
the same, to avoid needless complexity
On Sat, Jan 27, 2018 at 10:45 PM, Andres Freund wrote:
> Hi Peter (and others who mucked around with related code),
>
> While testing another patch I found that cancelling a parallel query on
> master segfaults the leader in an interesting manner:
...
> It's clearly not OK to recurse back into the
On Mon, Jan 29, 2018 at 3:32 AM, Antonin Houska wrote:
> I think of a variant of this: implement an universal function that tests the
> binary values for equality (besides the actual arguments, caller would have to
> pass info like typlen, typalign, typbyval for each argument, and cache these
> fo
On 29 January 2018 at 14:19, Pavel Stehule wrote:
>> The concurrency rules are very simple:
>> If a MATCHED row is concurrently updated/deleted
>> 1. We run EvalPlanQual
>> 2. If the updated row is gone EPQ returns NULL slot or EPQ returns a
>> row with NULL values, then
>> {
>>if NOT MATCHED
On Mon, Jan 29, 2018 at 4:12 AM, Masahiko Sawada wrote:
> On Sat, Jul 29, 2017 at 9:42 AM, Claudio Freire
> wrote:
>> Introduce a tree pruning threshold to FreeSpaceMapVacuum that avoids
>> recursing into branches that already contain enough free space, to
>> avoid having to traverse the whole F
Hello Ildus,
On 29.01.2018 14:44, Ildus Kurbangaliev wrote:
Thanks! Attached new version of the patch.
Patch applies cleanly, builds without any warnings, documentation builds
ok, all tests pass.
A remark for the committers. The patch is quite big, so I really wish
more reviewers looked
Hi
2018-01-29 15:11 GMT+01:00 Simon Riggs :
> On 26 January 2018 at 11:25, Simon Riggs wrote:
> > On 24 January 2018 at 04:12, Simon Riggs wrote:
> >> On 24 January 2018 at 01:35, Peter Geoghegan wrote:
> >>>
> >> Please rebase, and post a new version.
> >>
> >> Will do, though I'm sure that's
On 29 January 2018 at 14:13, Tomas Vondra wrote:
> 4) inspect the new row (which we still have in reorderbuffer)
>
> 5) Kabooom! The row has column "c" which we don't see in the catalog.
We don't use caches? Why does a cache miss cause it to explode?
--
Simon Riggshttp://www.2n
On 1/29/18 5:28 AM, Masahiko Sawada wrote:
> On Fri, Jan 26, 2018 at 4:58 AM, David Steele wrote:
>>
>> Attached is a new patch that uses stat() to determine if the init fork
>> for a relation file exists. I decided not to build a hash table as it
>> could use considerable memory and I didn't thi
On 01/29/2018 02:49 PM, Simon Riggs wrote:
> On 29 January 2018 at 13:34, Tomas Vondra
> wrote:
>
>> The important detail is that we only really care
>> about aborts in transactions that modified catalogs in some way (e.g. by
>> doing DDL). But we can safely decode (and stream) changes up to t
On 01/29/18 03:32, Antonin Houska wrote:
> Robert Haas wrote:
>>> only take place if we had a special equality operator which distinguishes
>>> the
>>> *binary* values (I don't know yet how to store this operator the catalog ---
...
>> We don't have an operator that tests for binary equality, bu
On 29 January 2018 at 13:34, Tomas Vondra wrote:
> The important detail is that we only really care
> about aborts in transactions that modified catalogs in some way (e.g. by
> doing DDL). But we can safely decode (and stream) changes up to the
> point when the catalogs get modified, so we can do
Hi,
On Sun, Jan 28, 2018 at 06:26:56PM +0100, Dmitry Dolgov wrote:
>
> Here is a new version of the patch:
>
> * rebased to the latest master
>
> * fixed issues I mentioned above
>
> * updated an example from the tutorial part
I have a few comments.
0002-Base-implementation-of-subscripting-m
Hi,
On 01/29/2018 11:23 AM, Simon Riggs wrote:
> On 29 January 2018 at 07:15, Nikhil Sontakke wrote:
>
>>> Having this as responsibility of plugin sounds interesting. It
>>> certainly narrows the scope for which we need to solve the abort
>>> issue. For 2PC that may be okay as we need to somehow
On 29.01.2018 07:34, Thomas Munro wrote:
On Sat, Jan 20, 2018 at 5:41 AM, Konstantin Knizhnik
wrote:
On 19.01.2018 16:14, Antonin Houska wrote:
you should test the operator B-tree strategy: BTLessStrategyNumber,
BTLessEqualStrategyNumber, etc. The operator string alone does not tell
enough
abo
Hi Amit,
On 01/26/2018 04:17 AM, Amit Langote wrote:
I made a few of those myself in the updated patches.
Thanks a lot again for your work on this.
This needs a rebase.
Best regards,
Jesper
On Mon, Jan 29, 2018 at 07:28:22PM +0900, Masahiko Sawada wrote:
> Thank you for updating the patch! The patch looks good to me. But I
> have a question; can we exclude temp tables as well? The pg_basebackup
> includes even temp tables. But I don't think that it's necessary for
> backups.
They are
On 29.01.2018 15:03, Fabien COELHO wrote:
Patch applies, compiles, pgbench & global "make check" ok, doc built ok.
Ok for me, switched to "Ready".
Thank you for the thorough review!
--
Ildar Musin
i.mu...@postgrespro.ru
On Mon, Jan 29, 2018 at 09:45:15AM +0200, Hannu Krosing wrote:
> ...
> I see two possibilities
>
> 1) add a third "ARG" to the CREATE OPERATOR syntax, maybe VALUEARG
> 2) use composite types - so for
>
> jsonb1[int1] = jsonb2
>
> the operator would be defined by first defining a
>
> CREATE
On 26.01.2018 22:38, Andres Freund wrote:
And without it perf is not able to unwind stack trace for generated
code.
You can work around that by using --call-graph lbr with a sufficiently
new perf. That'll not know function names et al, but at least the parent
will be associated correctly.
W
1 - 100 of 124 matches
Mail list logo
