On Wed, Jun 7, 2017 at 2:08 AM, Jeevan Ladhe
wrote:
>>
>> This also means that we have to test PREPARED statements involving
>> default partition. Any addition/deletion/attach/detach of other partition
>> should invalidate those cached statements.
>
>
> Will add this in next version of patch.
My
On Wed, Jun 7, 2017 at 12:19 PM, Peter Geoghegan wrote:
> On Tue, Jun 6, 2017 at 5:01 PM, Peter Geoghegan wrote:
>> Also, ISTM that the code within ENRMetadataGetTupDesc() probably
>> requires more explanation, resource management wise.
>
> Also, it's not clear why it should be okay that the new
On Wed, Jun 7, 2017 at 10:30 AM, Jeevan Ladhe
wrote:
>
>
>> IIUC, default partition constraints is simply NOT IN (> other sibling partitions>).
>> If constraint on the default partition refutes the new partition's
>> constraints that means we have overlapping partition, and perhaps
>> error.
>
>
>
On Thu, Jun 1, 2017 at 10:48 PM, Tom Lane wrote:
> Andres Freund writes:
>> when using
>> $ cat ~/.proverc
>> -j9
>> some tests fail for me in 9.4 and 9.5.
>
> Weren't there fixes specifically intended to make that safe, awhile ago?
60f826c has not been back-patched. While this would fix paralle
On Wed, May 31, 2017 at 8:45 PM, Craig Ringer wrote:
> On 1 June 2017 at 08:15, Andres Freund wrote:
>> Hi,
>>
>> when using
>> $ cat ~/.proverc
>> -j9
>>
>> some tests fail for me in 9.4 and 9.5. E.g. src/bin/script's tests
>> yields a lot of fun like:
>> $ (cd ~/build/postgres/9.5-assert/vpath
On Wed, Jun 7, 2017 at 9:42 AM, Robert Haas wrote:
> I think I'd like to walk back my earlier statements about reverting
> this patch just a little bit. Although putting the tuplestore at the
> wrong level does seem like a fairly significant design mistake, Thomas
> more or less convinced me yest
On 2017-06-07 14:29:04 +0900, Michael Paquier wrote:
> On Wed, Jun 7, 2017 at 2:01 PM, Josh Berkus wrote:
> > Q1. Why does wal_level default to "replica" and not "logical"?
>
> The difference of WAL generated is way higher between
> archive->hot_standby than hot_standby->logical. And unlike repli
On Wed, Jun 7, 2017 at 2:01 PM, Josh Berkus wrote:
> Q1. Why does wal_level default to "replica" and not "logical"?
The difference of WAL generated is way higher between
archive->hot_standby than hot_standby->logical. And unlike replica,
logical decoding is not something that is widely spread in
On 2017/06/07 11:57, Amit Langote wrote:
> How about we export ExecPartitionCheck() out of execMain.c and call it
> just before ExecFindPartition() using the root table's ResultRelInfo?
Turns out there wasn't a need to export ExecPartitionCheck after all.
Instead of calling it from execModifyTable
On Mon, May 15, 2017 at 12:45 PM, Bruce Momjian wrote:
> On Thu, May 11, 2017 at 11:50:03PM -0400, Tom Lane wrote:
> > Michael Paquier writes:
> > > Bruce, the release notes do not mention yet that support for cleartext
> > > passwords is removed. This has been done recently by Heikki in
> > > e
Folks,
I've put together some demos on PostgreSQL 10beta1. Here's a few
feedback notes based on my experience with it.
Things I tested
* Logical replication pub/sub with replicating only two tables out of a
12-table FK heirarchy, including custom data types
* Partitioning a lo
IIUC, default partition constraints is simply NOT IN ( other sibling partitions>).
> If constraint on the default partition refutes the new partition's
> constraints that means we have overlapping partition, and perhaps
> error.
>
You are correct Amul, but this error will be thrown before we try t
On Wed, Jun 7, 2017 at 2:08 AM, Jeevan Ladhe
wrote:
[...]
>>
>> The code in check_default_allows_bound() to check whether the default
>> partition
>> has any rows that would fit new partition looks quite similar to the code
>> in
>> ATExecAttachPartition() checking whether all rows in the table be
On 2017-06-07 00:03:15 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2017-06-06 23:32:53 -0400, Peter Eisentraut wrote:
> >> I'm not sure how you would parallelize these, since in most uses you
> >> want to have a deterministic output order.
>
> > Unless you specify ORDER BY you don't rea
Andres Freund writes:
> On 2017-06-06 23:32:53 -0400, Peter Eisentraut wrote:
>> I'm not sure how you would parallelize these, since in most uses you
>> want to have a deterministic output order.
> Unless you specify ORDER BY you don't really have that anyway, consider
> hash-aggregation. If you
On Wed, Jun 7, 2017 at 12:41 PM, Peter Eisentraut
wrote:
> On 6/6/17 04:17, Masahiko Sawada wrote:
>> With this patch, ALTER SUBSCRIPTION SET PUBLICATION [TAB]
>> completes with "REFRESH" and "SKIP REFRESH".
>> Specifying either REFRESH or SKIP REFRESH is mandatory after ALTER
>> SUBSCRIPTION SE
> On 6/6/17 13:52, Regina Obe wrote:
>> It seems CREATE AGGREGATE was expanded in 9.6 to support
>> parallelization of aggregate functions using transitions, with the
>> addition of serialfunc and deserialfunc to the aggregate definitions.
>>
>> https://www.postgresql.org/docs/10/static/sql-cre
On 2017-06-06 23:32:53 -0400, Peter Eisentraut wrote:
> On 6/6/17 13:52, Regina Obe wrote:
> > It seems CREATE AGGREGATE was expanded in 9.6 to support parallelization of
> > aggregate functions using transitions, with the addition of serialfunc and
> > deserialfunc to the aggregate definitions.
>
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Meskes
> I'm pretty sure it is indeed thread-aware, although I didn't provide the
> code for this feature myself.
>
> > So the doc seems to need fix. The patch is attached.
>
> Thanks, app
On 6/6/17 04:17, Masahiko Sawada wrote:
> With this patch, ALTER SUBSCRIPTION SET PUBLICATION [TAB]
> completes with "REFRESH" and "SKIP REFRESH".
> Specifying either REFRESH or SKIP REFRESH is mandatory after ALTER
> SUBSCRIPTION SET PUBLICATION, so i think it's good to add this.
That syntax do
On 6/6/17 13:52, Regina Obe wrote:
> It seems CREATE AGGREGATE was expanded in 9.6 to support parallelization of
> aggregate functions using transitions, with the addition of serialfunc and
> deserialfunc to the aggregate definitions.
>
> https://www.postgresql.org/docs/10/static/sql-createaggreg
On 2017/06/07 1:19, Robert Haas wrote:
> On Mon, Jun 5, 2017 at 1:02 AM, Amit Langote
> wrote:
>> On 2017/06/03 1:56, Robert Haas wrote:
>>> On Fri, Jun 2, 2017 at 12:51 AM, Amit Langote
>>> wrote:
Attached patch makes InitResultRelInfo() *always* initialize the
partition's constraint,
On 6/6/17 15:58, Robert Haas wrote:
> The problem with the status quo (after Peter's commit) is that there's
> now nothing at all to identify the logical replication launcher, apart
> from the wait_event field, which is likely to be LogicalLauncherMain
> fairly often if you've got the launcher. I
On 6/6/17 13:24, Petr Jelinek wrote:
> On 06/06/17 15:07, Peter Eisentraut wrote:
>> On 6/6/17 06:51, Petr Jelinek wrote:
>>> On 06/06/17 04:19, Peter Eisentraut wrote:
The logical replication code is supposed to use the subscription name as
the fallback_application_name, but in some case
On Wed, Jun 7, 2017 at 9:52 AM, Joe Conway wrote:
> On 06/06/2017 02:44 PM, Mike Palmiotto wrote:
>> On Tue, Jun 6, 2017 at 4:07 PM, Joe Conway wrote:
>>> On 06/06/2017 11:57 AM, Mike Palmiotto wrote:
On Mon, Jun 5, 2017 at 10:36 AM, Robert Haas wrote:
> On Mon, Jun 5, 2017 at 10:20 AM,
On 2017-06-06 19:36:13 +0200, Petr Jelinek wrote:
> So the fact that we moved workers to standard interrupt handling broke
> launcher in subtle ways because it still uses it's own SIGTERM handling
> but some function it calls are using CHECK_FOR_INTERRUPTS (they are used
> by worker as well). I thi
>
> I'll give it a few days for objections before reverting.
>>
>
> I can only say that the lack of this feature comes up on a weekly basis on
> IRC, and a lot of people would be disappointed to see it reverted.
>
Not that my opinion matters, but I was very much looking forward to this
feature in
On 06/06/2017 02:44 PM, Mike Palmiotto wrote:
> On Tue, Jun 6, 2017 at 4:07 PM, Joe Conway wrote:
>> On 06/06/2017 11:57 AM, Mike Palmiotto wrote:
>>> On Mon, Jun 5, 2017 at 10:36 AM, Robert Haas wrote:
On Mon, Jun 5, 2017 at 10:20 AM, Joe Conway wrote:
> Unless Robert objects, I'll wor
On 2017/06/07 0:19, Robert Haas wrote:
> On Sun, Jun 4, 2017 at 10:18 PM, Amit Langote
> wrote:
>> I think we can call it a bug of StorePartitionKey(). I looked at the
>> similar code in index_create() (which actually I had originally looked at
>> for reference when writing the partitioning code
On 2017/06/07 1:08, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Jun 4, 2017 at 10:18 PM, Amit Langote
>> wrote:
>>> BTW, the places which check whether the collation to store a dependency
>>> for is the database default collation don't need to do that. I mean the
>>> following code block in
Hi all,
The coverage of pg_basebackup is reaching 50%, which is not bad:
https://coverage.postgresql.org/src/bin/pg_basebackup/index.html
In this set pg_receivewal.c is the bad student with less than 20%.
There are a couple of causes behind that, with no tests like:
- option interactions like --c
On Tue, Jun 6, 2017 at 5:01 PM, Peter Geoghegan wrote:
> Also, ISTM that the code within ENRMetadataGetTupDesc() probably
> requires more explanation, resource management wise.
Also, it's not clear why it should be okay that the new type of
ephemeral RTEs introduced don't have permissions checks.
On Thu, Jun 1, 2017 at 12:49 AM, Andrew Borodin wrote:
> First, I just do not know, can VACUUM erase page with predicate lock?
For handling in btree, see:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/access/nbtree/nbtpage.c;h=f815fd40b20e98a88cb2fb5c71005ea125a459c9;
On Tue, Jun 6, 2017 at 3:47 PM, Peter Geoghegan wrote:
> I suppose you'll need two tuplestores for the ON CONFLICT DO UPDATE
> case -- one for updated tuples, and the other for inserted tuples.
Also, ISTM that the code within ENRMetadataGetTupDesc() probably
requires more explanation, resource ma
On Mon, Jun 5, 2017 at 12:40 PM, Shubham Barai wrote:
> GSoC (week 1)
> 4. went through source code of gist index to understand its implementation
>
> 5. found appropriate places in gist index AM to insert calls to existing
> functions (PredicateLockPage(), CheckForSerializableConflictIn() ...e
On 2017-06-06 12:53:21 -0700, Andres Freund wrote:
> On 2017-06-06 15:48:42 -0400, Robert Haas wrote:
> > On Fri, Jun 2, 2017 at 3:24 PM, Andres Freund wrote:
> > > Latches work in single user mode, it's just that the new code for some
> > > reason uses uninitialized memory as the latch. As I poi
Hi Sokolov --
I tried your patch. I only had time for doing a few points on power8.
pgbench rw on two sockets is awesome! Keeps getting more throughput as
threads are added -- in contrast to base and my prototype. I did not run
single socket pgbench.
Hammerdb, 1 socket was in the same ballpar
On Mon, Jun 5, 2017 at 6:40 PM, Thomas Munro
wrote:
> After sleeping on it, I don't think we need to make that decision here
> though. I think it's better to just move the tuplestores into
> ModifyTableState so that each embedded DML statement has its own, and
> have ModifyTable pass them to the
On 06/06/17 23:42, Andres Freund wrote:
> On 2017-06-06 23:24:50 +0200, Petr Jelinek wrote:
>> On 06/06/17 23:17, Andres Freund wrote:
>>> Right. I found a couple more instance of similarly iffy, although not
>>> quite as broken, patterns in launcher.c. It's easy to get this wrong,
>>> but it's a
On Tue, Jun 6, 2017 at 4:07 PM, Joe Conway wrote:
> On 06/06/2017 11:57 AM, Mike Palmiotto wrote:
>> On Mon, Jun 5, 2017 at 10:36 AM, Robert Haas wrote:
>>> On Mon, Jun 5, 2017 at 10:20 AM, Joe Conway wrote:
Unless Robert objects, I'll work with Mike to get a fix posted and
committed i
On 2017-06-06 23:24:50 +0200, Petr Jelinek wrote:
> On 06/06/17 23:17, Andres Freund wrote:
> > Right. I found a couple more instance of similarly iffy, although not
> > quite as broken, patterns in launcher.c. It's easy to get this wrong,
> > but it's a lot easy if you do it differently everywhe
On Tue, Jun 6, 2017 at 4:25 PM, Kevin Grittner wrote:
> Nice as it would be to add a SQL standard feature and advance the
> effort to get to incremental maintenance of materialized views, and
> much as I really appreciate the efforts Thomas has put into trying
> to solve these problems, I agree th
On 06/06/17 23:17, Andres Freund wrote:
> On 2017-06-06 17:14:59 -0400, Tom Lane wrote:
>> Andres Freund writes:
>>> The function in $subject does:
>>
>>> ResetLatch(&MyProc->procLatch);
>>> rc = WaitLatchOrSocket(&MyProc->procLatch,
>>>
On 06/06/17 21:09, Robert Haas wrote:
> On Tue, Jun 6, 2017 at 3:01 PM, Erik Rijkers wrote:
>> Belated apologies all round for the somewhat provocative $subject; but I
>> felt at that moment that this item needed some extra attention.
>
> FWIW, it seemed like a pretty fair subject line to me give
On 2017-06-06 17:14:59 -0400, Tom Lane wrote:
> Andres Freund writes:
> > The function in $subject does:
>
> > ResetLatch(&MyProc->procLatch);
> > rc = WaitLatchOrSocket(&MyProc->procLatch,
> >WL_POSTMASTER_DEATH | WL_SOCKET_READABLE
>
Andres Freund writes:
> The function in $subject does:
> ResetLatch(&MyProc->procLatch);
> rc = WaitLatchOrSocket(&MyProc->procLatch,
>WL_POSTMASTER_DEATH | WL_SOCKET_READABLE |
>WL_LATCH_SET,
>
Hi,
The function in $subject does:
while (PQisBusy(streamConn))
{
int rc;
/*
* We don't need to break down the sleep into smaller increments,
* since we'll get interrupted by signals and can either handle
* in
On Tue, Jun 6, 2017 at 3:41 PM, Marko Tiikkaja wrote:
> On Tue, Jun 6, 2017 at 10:25 PM, Kevin Grittner wrote:
>> It took years to get an in-depth review, then I was asked
>> not to commit it because others were working on patches that would
>> conflict. That just doesn't leave enough time to a
On Mon, Jun 5, 2017 at 2:37 PM, Jeff Janes wrote:
> In the documentation for fdw_startup_cost, it says "This represents the
> additional overhead of establishing a connection, parsing and planning the
> query on the remote side, etc.". I think that "establishing a connection"
> should be stricken
On Tue, Jun 6, 2017 at 10:25 PM, Kevin Grittner wrote:
> Nice as it would be to add a SQL standard feature and advance the
> effort to get to incremental maintenance of materialized views, and
> much as I really appreciate the efforts Thomas has put into trying
> to solve these problems, I agree
Hi Ashutosh,
Thanks for the detailed review.
Also, please find my feedback on your comments in-lined, I also addressed
the comments given by Robert in attached patch:
On Sat, Jun 3, 2017 at 5:13 PM, Ashutosh Bapat wrote:
> Here's some detailed review of the code.
>
> @@ -1883,6 +1883,15 @@ hea
Dmitriy Sarafannikov writes:
> Starting and stopping master after running pg_upgrade but before rsync to
> collect statistics
> was a bad idea.
But, starting and stopping master after running pg_upgrade is *required*
by documentation:
https://www.postgresql.org/docs/9.6/static/pgupgrade.html
>
On Tue, Jun 6, 2017 at 4:25 PM, Tom Lane wrote:
> (I'm tempted to add something like this permanently, at DEBUG1 or DEBUG2
> or so.)
I don't mind adding it permanently, but I think that's too high.
Somebody running a lot of parallel queries could easily get enough
messages to drown out the stuff
Robert Haas writes:
> On Tue, Jun 6, 2017 at 2:21 PM, Tom Lane wrote:
>> Hmm. With some generous assumptions it'd be possible to think that
>> aa1351f1eec4adae39be59ce9a21410f9dd42118 triggered this. That commit was
>> present in 20 successful lorikeet runs before the first of these failures,
>
Nice as it would be to add a SQL standard feature and advance the
effort to get to incremental maintenance of materialized views, and
much as I really appreciate the efforts Thomas has put into trying
to solve these problems, I agree that it is best to revert the
feature. It took years to get an i
On 06/06/2017 11:57 AM, Mike Palmiotto wrote:
> On Mon, Jun 5, 2017 at 10:36 AM, Robert Haas wrote:
>> On Mon, Jun 5, 2017 at 10:20 AM, Joe Conway wrote:
>>> Unless Robert objects, I'll work with Mike to get a fix posted and
>>> committed in the next day or two.
>>
>> That would be great. Thanks
On Sat, Jun 3, 2017 at 3:33 AM, Kuntal Ghosh wrote:
>> Agreed with this.
>>
>> However, I am not sure about the bgw_name_extra. I think I would have
>> preferred keeping full bgw_name field which would be used where full
>> name is needed and bgw_type where only the worker type is used. The
>> con
On 2017-06-06 15:48:42 -0400, Robert Haas wrote:
> On Fri, Jun 2, 2017 at 3:24 PM, Andres Freund wrote:
> > Latches work in single user mode, it's just that the new code for some
> > reason uses uninitialized memory as the latch. As I pointed out above,
> > the new code really should just use MyL
On Fri, Jun 2, 2017 at 3:24 PM, Andres Freund wrote:
> Latches work in single user mode, it's just that the new code for some
> reason uses uninitialized memory as the latch. As I pointed out above,
> the new code really should just use MyLatch instead of
> MyProc->procLatch.
We seem to have acc
On Mon, Jun 5, 2017 at 9:22 AM, Sokolov Yura
wrote:
> Good day, everyone.
>
> This patch improves performance of contended LWLock.
> It was tested on 4 socket 72 core x86 server (144 HT) Centos 7.1
> gcc 4.8.5
>
> Patch makes lock acquiring in single CAS loop:
> 1. LWLock->state is read, and abili
On 2017-06-06 12:23:49 -0700, David Fetter wrote:
> On Tue, Jun 06, 2017 at 01:52:45PM -0400, Regina Obe wrote:
> > It seems CREATE AGGREGATE was expanded in 9.6 to support parallelization of
> > aggregate functions using transitions, with the addition of serialfunc and
> > deserialfunc to the agg
On Tue, Jun 06, 2017 at 01:52:45PM -0400, Regina Obe wrote:
> It seems CREATE AGGREGATE was expanded in 9.6 to support parallelization of
> aggregate functions using transitions, with the addition of serialfunc and
> deserialfunc to the aggregate definitions.
>
> https://www.postgresql.org/docs/1
On 6/3/17 01:04, Noah Misch wrote:
> On Wed, May 31, 2017 at 10:15:50PM -0400, Peter Eisentraut wrote:
>> On 5/30/17 13:25, Masahiko Sawada wrote:
>>> I think this cause is that the relation status entry could be deleted
>>> by ALTER SUBSCRIPTION REFRESH before corresponding table sync worker
>>> s
On 2017-06-06 14:45:37 -0400, Tom Lane wrote:
> Andres Freund writes:
> > A reasonable rule would actually be to only use [u]int32 and
> > sig_atomic_t, never bool.
>
> Yes, I'd agree with that.
Cool. I propose we change, once branched, the existing code using
booleans, and codify that practice
On Tue, Jun 6, 2017 at 3:01 PM, Erik Rijkers wrote:
> Belated apologies all round for the somewhat provocative $subject; but I
> felt at that moment that this item needed some extra attention.
FWIW, it seemed like a pretty fair subject line to me given your test
results. I think it's in everyone
On Tue, Jun 6, 2017 at 2:21 PM, Tom Lane wrote:
>> One thought is that the only places where shm_mq_set_sender() should
>> be getting invoked during the main regression tests are
>> ParallelWorkerMain() and ExecParallelGetReceiver, and both of those
>> places using ParallelWorkerNumber to figure o
On 2017-06-06 20:53, Peter Eisentraut wrote:
On 6/4/17 22:38, Petr Jelinek wrote:
Committed that, with some further updates of comments to reflect the
Belated apologies all round for the somewhat provocative $subject; but I
felt at that moment that this item needed some extra attention.
I d
On Mon, Jun 5, 2017 at 10:36 AM, Robert Haas wrote:
> On Mon, Jun 5, 2017 at 10:20 AM, Joe Conway wrote:
>> Unless Robert objects, I'll work with Mike to get a fix posted and
>> committed in the next day or two.
>
> That would be great. Thanks.
I have the updated patch with rowsecurity regressi
On 6/4/17 22:38, Petr Jelinek wrote:
> On 03/06/17 16:12, Jeff Janes wrote:
>>
>> On Fri, Jun 2, 2017 at 4:10 PM, Petr Jelinek
>> mailto:petr.jeli...@2ndquadrant.com>> wrote:
>>
>>
>> While I was testing something for different thread I noticed that I
>> manage transactions incorrectly in t
Andres Freund writes:
> A reasonable rule would actually be to only use [u]int32 and
> sig_atomic_t, never bool.
Yes, I'd agree with that.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
Robert Haas writes:
> On Tue, Jun 6, 2017 at 1:33 PM, Tom Lane wrote:
>> That's an argument from false premises. The question here is what types
>> are safe for an interrupt handler to *change*, not what can it read.
> OK, but we certainly have code in signal handlers that does:
> int save_err
On Tue, Jun 6, 2017 at 2:24 PM, Andres Freund wrote:
> Don't think it's actually clear that errno is an integer - might very
> well be just a sig_atomic_t, which can contain values up to like 127 or
> so. I think the bigger point Tom was making is that we actually know
> an int4 is safe - otherw
On 2017-06-06 14:13:29 -0400, Robert Haas wrote:
> On Tue, Jun 6, 2017 at 1:33 PM, Tom Lane wrote:
> >> I think that's a pretty good argument, really. If there exists a
> >> platform where only sig_atomic_t is safe to read from a signal
> >> handler, then we already don't work on that platform.
On Mon, Jun 5, 2017 at 2:51 AM, Amit Kapila wrote:
>> Greg/Amit's idea of using the CTID field rather than an infomask bit
>> seems like a possibly promising approach. Not everything that needs
>> bit-space can use the CTID field, so using it is a little less likely
>> to conflict with something
Robert Haas writes:
> On Mon, Jun 5, 2017 at 10:40 AM, Andrew Dunstan
> wrote:
>> Buildfarm member lorikeet is failing occasionally with a failed
>> assertion during the select_parallel regression tests like this:
> I don't *think* we've made any relevant code changes lately. The only
> thing t
On Fri, Jun 2, 2017 at 7:07 AM, Amit Khandekar wrote:
> So, according to that, below would be the logic :
>
> Run partition constraint check on the original NEW row.
> If it succeeds :
> {
> Fire BR UPDATE trigger on the original partition.
> Run partition constraint check again with the m
On Tue, Jun 6, 2017 at 1:33 PM, Tom Lane wrote:
>> I think that's a pretty good argument, really. If there exists a
>> platform where only sig_atomic_t is safe to read from a signal
>> handler, then we already don't work on that platform. Even saving and
>> restoring errno isn't safe in that cas
On Tue, Jun 6, 2017 at 1:27 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jun 6, 2017 at 12:44 PM, Tom Lane wrote:
>>> By definition, the address range we're trying to reuse worked successfully
>>> in the postmaster process. I don't see how forcing a specific address
>>> could do anythin
It seems CREATE AGGREGATE was expanded in 9.6 to support parallelization of
aggregate functions using transitions, with the addition of serialfunc and
deserialfunc to the aggregate definitions.
https://www.postgresql.org/docs/10/static/sql-createaggregate.html
I was looking at the PostgreSQL 10
On 03/06/17 18:53, Peter Eisentraut wrote:
> On 6/2/17 14:52, Peter Eisentraut wrote:
>> On 5/24/17 15:14, Petr Jelinek wrote:
>>> All the locking works just fine the way it is in master. The issue with
>>> deadlock with apply comes from the wrong handling of the SIGTERM in the
>>> apply (we didn't
Robert Haas writes:
> On Sun, Jun 4, 2017 at 7:21 PM, Andres Freund wrote:
>> Well, we already have some variables that aren't actually booleans,
>> although I think all of them are only read not manipulated in signal
>> handlers (InterruptHoldoffCount etc). So one could argue that there's
>> no
On 2017-06-06 13:07:57 -0400, Robert Haas wrote:
> > We also already rely on int32 stores being atomic in other
> > parts of the code, although that's between processes not between signal
> > / normal path of execution.
>
> I don't think the issues are much different. Presumably no CPU
> delivers
Robert Haas writes:
> On Tue, Jun 6, 2017 at 12:44 PM, Tom Lane wrote:
>> By definition, the address range we're trying to reuse worked successfully
>> in the postmaster process. I don't see how forcing a specific address
>> could do anything but create an additional risk of postmaster startup
>
On 06/06/17 15:07, Peter Eisentraut wrote:
> On 6/6/17 06:51, Petr Jelinek wrote:
>> On 06/06/17 04:19, Peter Eisentraut wrote:
>>> The logical replication code is supposed to use the subscription name as
>>> the fallback_application_name, but in some cases it uses the slot name,
>>> which could be
On Tue, Jun 6, 2017 at 11:37 AM, Kevin Hale Boyes wrote:
> On 6 June 2017 at 09:19, Robert Haas wrote:
>> Thanks. Committed.
>
> The changes to catalogs.sgml has introduced a double "the" in this part of
> the sentence "this contains the OID of the the collation".
> The other section already had
On Sun, Jun 4, 2017 at 7:21 PM, Andres Freund wrote:
> Well, we already have some variables that aren't actually booleans,
> although I think all of them are only read not manipulated in signal
> handlers (InterruptHoldoffCount etc). So one could argue that there's
> no safety benefit in sig_atom
On Tue, Jun 6, 2017 at 12:44 PM, Tom Lane wrote:
> By definition, the address range we're trying to reuse worked successfully
> in the postmaster process. I don't see how forcing a specific address
> could do anything but create an additional risk of postmaster startup
> failure.
If the postmast
On Mon, Jun 5, 2017 at 10:40 AM, Andrew Dunstan
wrote:
> Buildfarm member lorikeet is failing occasionally with a failed
> assertion during the select_parallel regression tests like this:
>
>
> 2017-06-03 05:12:37.382 EDT [59327d84.1160:38] LOG: statement: select
> count(*) from tenk1, tenk2
Robert Haas writes:
> I think the idea of retrying process creation (and I definitely agree
> with Tom and Magnus that we have to retry process creation, not just
> individual mappings) is a good place to start. Now if we find that we
> are having to retry frequently, then I think we might need t
On Sun, Jun 4, 2017 at 6:10 AM, Tom Lane wrote:
> Masahiko Sawada writes:
>> Attached patch tweaks tab completion for some backslash commands.
>
> Pushed, thanks!
>
Thank you!
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via
On Mon, Jun 5, 2017 at 10:10 PM, Amit Kapila wrote:
> Agreed. By the way, while browsing about this problem, I found that
> one other open source (nginx) has used a solution similar to what
> Andres was proposing upthread to solve this problem. Refer:
> https://github.com/nginx/nginx/commit/2ec8
On Tue, Jun 6, 2017 at 12:15:13PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > There seems to be a problem. I can't see a patch dated 2017-06-07 on
> > the commitfest page:
> > https://commitfest.postgresql.org/14/1161/
>
> It looks to me like the patch is buried inside a multipart/al
On Tue, Jun 6, 2017 at 11:37 AM, Kevin Hale Boyes wrote:
> On 6 June 2017 at 09:19, Robert Haas wrote:
>> Thanks. Committed.
>
> The changes to catalogs.sgml has introduced a double "the" in this part of
> the sentence "this contains the OID of the the collation".
> The other section already had
Robert Haas writes:
> I don't think it's true that we force the latest TLS version to be
> used. The comment says:
> /*
> * We use SSLv23_method() because it can negotiate use of the highest
> * mutually supported protocol version, while alternatives like
> * T
On Mon, Jun 5, 2017 at 1:02 AM, Amit Langote
wrote:
> On 2017/06/03 1:56, Robert Haas wrote:
>> On Fri, Jun 2, 2017 at 12:51 AM, Amit Langote
>> wrote:
>>> Attached patch makes InitResultRelInfo() *always* initialize the
>>> partition's constraint, that is, regardless of whether insert/copy is
>>
Hi, Kevin and Alvaro.
I think disk I/O is not the bottleneck in our experiment, but the global lock
is.
For disk I/O, there are two evidences:
1) The total throughput is not more than 10 Ktps. Only a half are update
transactions. An update transaction modifies 20 tuples; each tuple's size is
Bruce Momjian writes:
> There seems to be a problem. I can't see a patch dated 2017-06-07 on
> the commitfest page:
> https://commitfest.postgresql.org/14/1161/
It looks to me like the patch is buried inside a multipart/alternative
MIME section. That's evidently causing our mail archives
On Wed, Jun 7, 2017 at 01:06:22AM +0900, Man Trieu wrote:
> 2017-06-07 0:31 GMT+09:00 Bruce Momjian :
> I added the thread but there was no change. (I think the thread was
> already present.) It appears it is not seeing this patch as the latest
> patch.
>
> Does anyone know why
Robert Haas writes:
> On Sun, Jun 4, 2017 at 10:18 PM, Amit Langote
> wrote:
>> BTW, the places which check whether the collation to store a dependency
>> for is the database default collation don't need to do that. I mean the
>> following code block in all of these places:
>>
>> /* The default
2017-06-07 0:31 GMT+09:00 Bruce Momjian :
> On Wed, Jun 7, 2017 at 12:10:25AM +0900, Dang Minh Huong wrote:
> > > On Jun 4, 29 Heisei, at 00:48, Bruce Momjian wrote:
> > Shouldn't you use "or is_letter_with_marks()", instead of "or
> len(...)
> > > 1"? Your test might catch something t
1 - 100 of 129 matches
Mail list logo
