On 02/06/17 17:11, Erik Rijkers wrote:
On 2017-06-02 00:46, Mark Kirkwood wrote:
On 31/05/17 21:16, Petr Jelinek wrote:
I'm seeing a new failure with the patch applied - this time the
history table has missing rows. Petr, I'll put back your access :-)
Is this error during 1-minute runs?
I'm
On Wed, May 31, 2017 at 12:10 PM, Peter Eisentraut
wrote:
> Here is a proposed solution that splits bgw_name into bgw_type and
> bgw_name_extra. bgw_type shows up in pg_stat_activity.backend_type.
> Uses of application_name are removed, because they are no longer
> necessary to identity the proce
On Fri, May 26, 2017 at 05:50:45PM +0530, Amit Kapila wrote:
> On Fri, May 26, 2017 at 5:30 AM, Tsunakawa, Takayuki
> wrote:
> > I guessed that the reason Noah suggested 1 - 5 seconds of retry is based
> > on the expectation that the address space might be freed by the anti-virus
> > software.
On Fri, Jun 2, 2017 at 2:21 PM, Noah Misch wrote:
> On Tue, May 30, 2017 at 11:13:37AM -0700, Michael Paquier wrote:
>> On Tue, May 30, 2017 at 11:09 AM, Peter Eisentraut
>> wrote:
>> > I don't think this is my item. Most of the behavior is old, and
>> > pg_stat_get_wal_receiver() is from commit
On Mon, May 29, 2017 at 01:43:26PM -0700, Michael Paquier wrote:
> On Mon, May 29, 2017 at 1:38 PM, Daniele Varrazzo
> wrote:
> > Patch attached
>
> Right. I am adding that to the list of open items, and Heikki in CC
> will likely take care of it.
[Action required within three days. This is a g
On Thu, Jun 01, 2017 at 12:00:33AM -0400, Peter Eisentraut wrote:
> On 5/31/17 02:51, Noah Misch wrote:
> > On Tue, May 30, 2017 at 01:30:35AM +, Noah Misch wrote:
> >> On Thu, May 18, 2017 at 10:27:51PM -0400, Peter Eisentraut wrote:
> >>> On 5/18/17 11:11, Noah Misch wrote:
> IMMEDIATE A
Hi,
While reading predicate lock source code, I found a comment typo in
predicate.c file.
Attached patch fixes it.
s/scrach/scratch/
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
fix_typo_in_predicate_c.patch
Description: Binary data
-
On Thu, Jun 1, 2017 at 11:25 AM, Andres Freund wrote:
> Secondly, I think that's to a significant degree caused by
> the fact that in practice people way more often partition on types like
> int4/int8/date/timestamp/uuid rather than text - there's rarely good
> reasons to do the latter.
Once we s
On Thu, Jun 1, 2017 at 10:59 AM, Robert Haas wrote:
> 1. Are the new problems worse than the old ones?
>
> 2. What could we do about it?
Exactly the right questions.
1. For range partitioning, I think it's "yes, a little". As you point
out, there are already some weird edge cases -- the main way
On Sun, May 21, 2017 at 08:19:34AM +0200, Erik Rijkers wrote:
> On 2017-05-21 06:37, Erik Rijkers wrote:
> >With this patch on current master my logical replication tests
> >(pgbench-over-logical-replication) run without errors for the first
> >time in many days (even weeks).
>
> Unfortunately, ju
On 2017-06-02 00:46, Mark Kirkwood wrote:
On 31/05/17 21:16, Petr Jelinek wrote:
I'm seeing a new failure with the patch applied - this time the
history table has missing rows. Petr, I'll put back your access :-)
Is this error during 1-minute runs?
I'm asking because I've moved back to longer
On 2017/06/02 10:36, Robert Haas wrote:
> On Thu, Jun 1, 2017 at 6:05 PM, Tom Lane wrote:
>> Without having checked the code, I imagine the reason for this is
>> that BEFORE triggers are fired after tuple routing occurs.
>
> Yep.
>
>> Re-ordering that seems problematic, because what if you have
On 2017-06-01 22:17:57 -0400, Peter Eisentraut wrote:
> On 6/1/17 00:06, Andres Freund wrote:
> > On 2017-05-31 23:51:08 -0400, Peter Eisentraut wrote:
> >> I think the easiest and safest thing to do now is to just prevent
> >> parallel plans in the walsender. See attached patch. This prevents th
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > On Tue, May 30, 2017 at 8:55 PM, David G. Johnston
> > wrote:
> >>> Having --no-comments seems generally useful to me, in any case.
>
> >> It smacks of being excessive to me.
>
> > It sounds perfectly sensible to me. It's n
On 6/1/17 00:06, Andres Freund wrote:
> On 2017-05-31 23:51:08 -0400, Peter Eisentraut wrote:
>> I think the easiest and safest thing to do now is to just prevent
>> parallel plans in the walsender. See attached patch. This prevents the
>> hang in the select_parallel tests run under your new test
Robert Haas writes:
> On Tue, May 30, 2017 at 8:55 PM, David G. Johnston
> wrote:
>>> Having --no-comments seems generally useful to me, in any case.
>> It smacks of being excessive to me.
> It sounds perfectly sensible to me. It's not exactly an elegant
> solution to the original problem, but
On 2017-06-01 21:42:41 -0400, Peter Eisentraut wrote:
> We should look at what the underlying problem is before we prohibit
> anything at a high level.
I'm not sure there's any underlying issue here, except being in single
user mode.
> When I try it, I get a
>
> TRAP: FailedAssertion("!(event->
On Tue, May 30, 2017 at 8:55 PM, David G. Johnston
wrote:
>> Having --no-comments seems generally useful to me, in any case.
>
> It smacks of being excessive to me.
It sounds perfectly sensible to me. It's not exactly an elegant
solution to the original problem, but it's a reasonable switch on i
On 6/1/17 04:49, Dilip Kumar wrote:
> On Thu, Jun 1, 2017 at 1:02 PM, Michael Paquier
> wrote:
>> Thanks, this looks correct to me at quick glance.
>>
>> +if (!IsUnderPostmaster)
>> +ereport(FATAL,
>> +(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
>> +errmsg("sub
On Thu, Jun 1, 2017 at 2:28 PM, Andres Freund wrote:
> On 2017-06-01 14:17:44 +0200, Petr Jelinek wrote:
>> Thinking more about this, I am not convinced it's a good idea to change
>> exports this late in the cycle. I still think it's best to do the xid
>> assignment only when the snapshot is actua
On Thu, Jun 1, 2017 at 6:05 PM, Tom Lane wrote:
> Without having checked the code, I imagine the reason for this is
> that BEFORE triggers are fired after tuple routing occurs.
Yep.
> Re-ordering that seems problematic, because what if you have different
> triggers on different partitions? We'd
On Thu, Jun 1, 2017 at 6:05 PM, Andres Freund wrote:
> I'm a unhappy how this is reusing SIGINT for WalSndLastCycleHandler.
> Normally INT is used cancel interrupts, and since walsender is now also
> working as a normal backend, this overlap is bad.
Yep, that's bad.
--
Robert Haas
EnterpriseDB:
On Thu, Jun 1, 2017 at 9:13 PM, Michael Paquier
wrote:
> On Fri, Jun 2, 2017 at 10:08 AM, Stephen Frost wrote:
>> What I find somewhat objectionable is the notion that if we don't have 5
>> different TLS/SSL implementations supported in PG and that we've tested
>> that channel binding works corre
On 5/31/17 21:26, Peter Eisentraut wrote:
> On 5/31/17 02:17, Kuntal Ghosh wrote:
>> On Wed, May 31, 2017 at 12:58 AM, Masahiko Sawada
>> wrote:
>>>
>>> I'd say we can fix this issue by just changing the query. Attached
>>> patch changes the query so that it can handle publication name
>>> correc
On 2017-06-02 10:05:21 +0900, Michael Paquier wrote:
> On Fri, Jun 2, 2017 at 9:29 AM, Andres Freund wrote:
> > On 2017-06-02 08:38:51 +0900, Michael Paquier wrote:
> >> On Fri, Jun 2, 2017 at 7:05 AM, Andres Freund wrote:
> >> > I'm a unhappy how this is reusing SIGINT for WalSndLastCycleHandler
On Fri, Jun 2, 2017 at 10:08 AM, Stephen Frost wrote:
> What I find somewhat objectionable is the notion that if we don't have 5
> different TLS/SSL implementations supported in PG and that we've tested
> that channel binding works correctly among all combinations of all of
> them, then we can't a
David Rowley writes:
> On 1 June 2017 at 04:16, Teodor Sigaev wrote:
>> I found an example where v10 chooses extremely non-optimal plan:
>> ...
> This is all caused by get_variable_numdistinct() deciding that all
> values are distinct because ntuples < DEFAULT_NUM_DISTINCT.
Uh, no. I traced th
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Jun 1, 2017 at 11:50 AM, Stephen Frost wrote:
> > I certainly wouldn't object to someone working on this, but I feel like
> > it's a good deal more work than perhaps you're realizing (and I tend to
> > think trying to use the Windows
On Fri, Jun 2, 2017 at 9:29 AM, Andres Freund wrote:
> On 2017-06-02 08:38:51 +0900, Michael Paquier wrote:
>> On Fri, Jun 2, 2017 at 7:05 AM, Andres Freund wrote:
>> > I'm a unhappy how this is reusing SIGINT for WalSndLastCycleHandler.
>> > Normally INT is used cancel interrupts, and since wals
On 2017-06-02 08:38:51 +0900, Michael Paquier wrote:
> On Fri, Jun 2, 2017 at 7:05 AM, Andres Freund wrote:
> > I'm a unhappy how this is reusing SIGINT for WalSndLastCycleHandler.
> > Normally INT is used cancel interrupts, and since walsender is now also
> > working as a normal backend, this ove
On 2 June 2017 at 03:46, Teodor Sigaev wrote:
> I miss here why could the presence of index influence on that? removing
> index causes a good plan although it isn't used in both plans .
Unique indexes are used as proofs when deciding if a join to the
relation is "inner_unique". A nested loop uniq
On Fri, Jun 2, 2017 at 7:05 AM, Andres Freund wrote:
> I'm a unhappy how this is reusing SIGINT for WalSndLastCycleHandler.
> Normally INT is used cancel interrupts, and since walsender is now also
> working as a normal backend, this overlap is bad. Even for plain
> walsender backend this seems b
On 31/05/17 21:16, Petr Jelinek wrote:
On 29/05/17 23:06, Mark Kirkwood wrote:
On 29/05/17 23:14, Petr Jelinek wrote:
On 29/05/17 03:33, Jeff Janes wrote:
What would you want to look at? Would saving the WAL from the master be
helpful?
Useful info is, logs from provider (mainly the logic
Chapman Flack writes:
> It might be fun to see how big a chunk of the 4106 would vanish just
> with the first tweak to one of the causes that's mentioned in a lot of
> them. (Unless your figures were already after culling to distinct causes,
> which would sound like a more-than-casual effort.)
No
On 06/01/17 17:41, Tom Lane wrote:
> 12169 warnings generated by -Wconversion
> 4106 warnings generated by -Wconversion -Wno-sign-conversion
> ...
> So it's better with -Wno-sign-conversion, but I'd say we're still not
> going there anytime soon.
On an optimistic note, there might not turn out to
Robert Haas writes:
> I just discovered that a BEFORE trigger can allow data into a
> partition that violates the relevant partition constraint. This is
> bad.
Without having checked the code, I imagine the reason for this is
that BEFORE triggers are fired after tuple routing occurs.
Re-orderin
On 2017-05-05 10:50:11 -0400, Peter Eisentraut wrote:
> On 5/5/17 01:26, Michael Paquier wrote:
> > The only code path doing HOT-pruning and generating WAL is
> > heap_page_prune(). Do you think that we need to worry about FPWs as
> > well?
> >
> > Attached is an updated patch, which also forbids
On Fri, Jun 2, 2017 at 9:27 AM, Peter Geoghegan wrote:
> On Thu, Jun 1, 2017 at 2:24 PM, Thomas Munro
> wrote:
>> Why should ICU be any different than the system provider in this
>> respect? In both cases, we have a two-level comparison: first we use
>> the collation-aware comparison, and then a
Peter Geoghegan writes:
> On Thu, Jun 1, 2017 at 2:24 PM, Thomas Munro
> wrote:
>> Why should ICU be any different than the system provider in this
>> respect? In both cases, we have a two-level comparison: first we use
>> the collation-aware comparison, and then as a tie breaker, we use a
>> bi
On 06/01/2017 11:25 AM, Andres Freund wrote:
> On 2017-06-01 13:59:42 -0400, Robert Haas wrote:
>> My personal guess is that most people will prefer the fast
>> hash functions over the ones that solve their potential future
>> migration problems, but, hey, options are good.
>
> I'm pretty sure tha
Chapman Flack writes:
> On 05/31/2017 11:36 AM, Tom Lane wrote:
>> However, I grant your point that some extensions may have outside
>> constraints that mandate using -Wconversion, so to the extent that
>> we can keep key headers like postgres.h from triggering those warnings,
>> it's probably wor
On Thu, Jun 1, 2017 at 2:24 PM, Thomas Munro
wrote:
> Why should ICU be any different than the system provider in this
> respect? In both cases, we have a two-level comparison: first we use
> the collation-aware comparison, and then as a tie breaker, we use a
> binary comparison. If we didn't do
On Fri, Jun 2, 2017 at 6:58 AM, Amit Khandekar wrote:
> While comparing two text strings using varstr_cmp(), if *strcoll*()
> call returns 0, we do strcmp() tie-breaker to do binary comparison,
> because strcoll() can return 0 for non-identical strings :
>
> varstr_cmp()
> {
> ...
> /*
> * In some
On 2017-06-01 19:08:33 +0200, Petr Jelinek wrote:
> On 01/06/17 16:51, Robert Haas wrote:
> > On Wed, May 31, 2017 at 8:07 PM, Andres Freund wrote:
> >> Here's a patch doing what I suggested above. The second patch addresses
> >> an independent oversight where the post alter hook was invoked befo
I tried to debug this, and I see that while the target partition index is
correctly
found in ExecInsert(), somehow the resultRelInfo->ri_PartitionCheck is NIL,
this
is extracted from array mstate->mt_partitions.
This prevents execution of constraints in following code snippet in
ExecInsert():
/*
On 2017-06-01 15:56:35 -0400, Robert Haas wrote:
> > I personally think we should fix this in 9.6 and 10, but I've to admit
> > I'm not entirely impartial, because Citus hit this...
>
> I guess it's a matter of judgement whether you want to call this a bug
> or a missing feature. I wasn't really
On Wed, May 31, 2017 at 7:19 PM, Andres Freund wrote:
> To me that appears to be an oversight rather than intentional. A
> somewhat annoying one at that, because it's not uncommong to use COPY to
> execute reports to a CSV file and such.
>
> Robert, am I missing a complication?
No, I think that
I just discovered that a BEFORE trigger can allow data into a
partition that violates the relevant partition constraint. This is
bad.
Here is an example:
rhaas=# create or replace function t() returns trigger as $$begin
new.a := 2; return new; end$$ language plpgsql;
CREATE FUNCTION
rhaas=# crea
On Thu, Jun 1, 2017 at 7:41 AM, Amit Khandekar wrote:
>> Regarding the trigger issue, I can't claim to have a terribly strong
>> opinion on this. I think that practically anything we do here might
>> upset somebody, but probably any halfway-reasonable thing we choose to
>> do will be OK for most
Hi,
I have addressed Ashutosh's and Amit's comments in the attached patch.
Please let me know if I have missed anything and any further comments.
PFA.
Regards,
Jeevan Ladhe
On Wed, May 31, 2017 at 9:50 AM, Beena Emerson
wrote:
> On Wed, May 31, 2017 at 8:13 AM, Amit Langote
> wrote:
> > On
While comparing two text strings using varstr_cmp(), if *strcoll*()
call returns 0, we do strcmp() tie-breaker to do binary comparison,
because strcoll() can return 0 for non-identical strings :
varstr_cmp()
{
...
/*
* In some locales strcoll() can claim that nonidentical strings are
* equal. Bel
On 2017-06-01 14:17:44 +0200, Petr Jelinek wrote:
> Thinking more about this, I am not convinced it's a good idea to change
> exports this late in the cycle. I still think it's best to do the xid
> assignment only when the snapshot is actually exported but don't assign
> xid when the export is only
On 2017-06-01 13:59:42 -0400, Robert Haas wrote:
> I'm not actually aware of an instance where this has bitten anyone,
> even though it seems like it certainly could have and maybe should've
> gotten somebody at some point. Has anyone else?
Two comments: First, citus has been doing hash-partition
On 2017-06-01 18:41:20 +0530, Rafia Sabih wrote:
> As per my understanding it looks like this increase in tuple queue
> size is helping only gather-merge. Particularly, in the case where it
> is enough stalling by master in gather-merge because it is maintaining
> the sort-order. Like in q12 the in
On Fri, May 12, 2017 at 1:35 PM, Joe Conway wrote:
>> That's a good point, but the flip side is that, if we don't have
>> such a rule, a pg_dump of a hash-partitioned table on one
>> architecture might fail to restore on another architecture. Today, I
>> believe that, while the actual database cl
On 01/06/17 17:32, Masahiko Sawada wrote:
> On Thu, May 25, 2017 at 5:29 PM, tushar wrote:
>> On 05/25/2017 12:44 AM, Petr Jelinek wrote:
>>>
>>> There is still outstanding issue that sync worker will keep running
>>> inside the long COPY because the invalidation messages are also not
>>> processe
On 01/06/17 16:51, Robert Haas wrote:
> On Wed, May 31, 2017 at 8:07 PM, Andres Freund wrote:
>> Here's a patch doing what I suggested above. The second patch addresses
>> an independent oversight where the post alter hook was invoked before
>> doing the catalog update.
>
> 0002 is a slam-dunk.
On 01/06/17 15:25, Tom Lane wrote:
> Robert Haas writes:
>> So, are you going to, perhaps, commit this? Or who is picking this up?
>
>> /me knows precious little about Windows.
>
> I'm not going to be the one to commit this either, but seems like someone
> should.
>
The new code does not use
On 01/06/17 17:50, Stephen Frost wrote:
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
On Wed, May 31, 2017 at 7:59 PM, Stephen Frost wrote:
If your comments regarding the requirement that we have interoperability
testing of this feature before accepting it were intended to mean that
On 2017-06-01 21:37:56 +0530, Amit Kapila wrote:
> On Thu, Jun 1, 2017 at 9:34 PM, Andres Freund wrote:
> > On 2017-06-01 21:23:04 +0530, Amit Kapila wrote:
> >> On a related note, I think it might be better to have an
> >> IsInParallelMode() check in this case as we have at other places.
> >> Thi
On 01/06/17 18:11, Bruce Momjian wrote:
On Wed, May 31, 2017 at 09:37:02AM -0400, Robert Haas wrote:
On Tue, May 30, 2017 at 11:49 PM, Stephen Frost wrote:
... and I don't believe that we should be asking the
implementors of channel binding to also implement support for multiple
TLS librarie
On Thu, Jun 1, 2017 at 11:50 AM, Stephen Frost wrote:
> I certainly wouldn't object to someone working on this, but I feel like
> it's a good deal more work than perhaps you're realizing (and I tend to
> think trying to use the Windows SSL implementation would increase the
> level of effort, not m
Dilip Kumar writes:
> Actually, I was not proposing this patch instead I wanted to discuss
> the approach. I was claiming that for
> non-equal JOIN_SEMI selectivity estimation instead of calculating
> selectivity in an existing way i.e
> = 1- (selectivity of equal JOIN_SEMI) the better way would
On Wed, May 31, 2017 at 09:37:02AM -0400, Robert Haas wrote:
> On Tue, May 30, 2017 at 11:49 PM, Stephen Frost wrote:
> > ... and I don't believe that we should be asking the
> > implementors of channel binding to also implement support for multiple
> > TLS libraries in PostgreSQL in order to test
On Thu, Jun 1, 2017 at 9:34 PM, Andres Freund wrote:
> On 2017-06-01 21:23:04 +0530, Amit Kapila wrote:
>> On a related note, I think it might be better to have an
>> IsInParallelMode() check in this case as we have at other places.
>> This is to ensure that if this command is invoked via plpgsql
On 2017-06-01 21:23:04 +0530, Amit Kapila wrote:
> On a related note, I think it might be better to have an
> IsInParallelMode() check in this case as we have at other places.
> This is to ensure that if this command is invoked via plpgsql function
> and that function runs is the parallel mode, it
On Thu, Jun 1, 2017 at 4:49 AM, Andres Freund wrote:
> Hi,
>
> At the moment $subject doesn't allow parallelism, because copy.c's
> pg_plan_query() invocation doesn't set the CURSOR_OPT_PARALLEL_OK
> flag.
>
> To me that appears to be an oversight rather than intentional.
>
I also don't see any p
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, May 31, 2017 at 7:59 PM, Stephen Frost wrote:
> > If your comments regarding the requirement that we have interoperability
> > testing of this feature before accepting it were intended to mean that
> > we need to make sure that the JD
Thank you for the answer!
This is all caused by get_variable_numdistinct() deciding that all
values are distinct because ntuples < DEFAULT_NUM_DISTINCT. I see that
if the example is increased to use 300 tuples instead of 32, then
that's enough for the planner to estimate 2 rows instead of clamp
On Thu, Jun 1, 2017 at 8:24 PM, Robert Haas wrote:
> On Wed, May 31, 2017 at 1:18 PM, Dilip Kumar wrote:
>> + if (jointype = JOIN_SEMI)
>> + {
>> + sjinfo->jointype = JOIN_INNER;
>> + }
>
> That is pretty obviously half-baked and completely untested.
Actually, I w
Tomas Vondra writes:
> Which brings me to the slightly suspicious bit. On 9.5, there's no
> difference between GROUP and GROUP+LIKE cases - the estimates are
> exactly the same in both cases. This is true too, but only without the
> foreign key between "partsupp" and "part", i.e. the two non-gr
On Thu, Jun 1, 2017 at 3:26 AM, Robert Haas wrote:
> On Tue, May 30, 2017 at 7:43 PM, Masahiko Sawada
> wrote:
>> There is an incomplete sentence at top of subtrans.c file. I think the
>> commit 88e66d19 removed the whole line mistakenly.
>
> Thanks for the patch. Sorry for the mistake that mad
On Thu, May 25, 2017 at 5:29 PM, tushar wrote:
> On 05/25/2017 12:44 AM, Petr Jelinek wrote:
>>
>> There is still outstanding issue that sync worker will keep running
>> inside the long COPY because the invalidation messages are also not
>> processed until it finishes but all the original issues r
On Wed, May 31, 2017 at 7:59 PM, Stephen Frost wrote:
> If your comments regarding the requirement that we have interoperability
> testing of this feature before accepting it were intended to mean that
> we need to make sure that the JDBC driver is able to work with the
> chosen solution (or, perh
On Wed, May 31, 2017 at 1:18 PM, Dilip Kumar wrote:
> + if (jointype = JOIN_SEMI)
> + {
> + sjinfo->jointype = JOIN_INNER;
> + }
That is pretty obviously half-baked and completely untested.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise P
On Wed, May 31, 2017 at 8:07 PM, Andres Freund wrote:
> Here's a patch doing what I suggested above. The second patch addresses
> an independent oversight where the post alter hook was invoked before
> doing the catalog update.
0002 is a slam-dunk. I don't object to 0001 but haven't reviewed it
Hi, Kevin sir!
On 1 June 2017 at 02:20, Kevin Grittner wrote:
> On Wed, May 31, 2017 at 3:02 PM, Shubham Barai
> wrote:
>
> > I have been accepted as GSoC student for the project "Explicitly support
> > predicate locks in index access methods besides b-tree". I want to share
> my
> > approach f
Moin,
On Wed, May 31, 2017 10:18 pm, Craig Ringer wrote:
> On 31 May 2017 at 08:43, Craig Ringer wrote:
>> Hi all
>>
>> More and more I'm finding it useful to extend PostgresNode for project
>> specific helper classes. But PostgresNode::get_new_node is a factory
>> that doesn't provide any mechan
I noticed that the `check` Makefile rule imported by PGXS is giving
a success exit code even when it is unsupported.
The attached patch fixes that.
--strk;
() Free GIS & Flash consultant/developer
/\ https://strk.kbt.io/services.html
>From 43fa28f141871a6efdd3e5d0c9ec8cc537585ff5 Mon Sep
> On Jun 1, 2017, at 6:31 AM, Tom Lane wrote:
>
> Mark Dilger writes:
>> When you guys commit changes that impact partitioning, I notice, and change
>> my code to match. But in this case, it seemed to me the change that got
>> committed was not thought through, and it might benefit the communi
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?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Mark Dilger writes:
> When you guys commit changes that impact partitioning, I notice, and change
> my code to match. But in this case, it seemed to me the change that got
> committed was not thought through, and it might benefit the community for
> me to point it out, rather than quietly make my
Robert Haas writes:
> So, are you going to, perhaps, commit this? Or who is picking this up?
> /me knows precious little about Windows.
I'm not going to be the one to commit this either, but seems like someone
should.
regards, tom lane
--
Sent via pgsql-hackers maili
On Tue, May 30, 2017 at 4:57 PM, Robert Haas wrote:
> I did a little bit of brief experimentation on this same topic a long
> time ago and didn't see an improvement from boosting the queue size
> beyond 64k but Rafia is testing Gather rather than Gather Merge and,
> as I say, my test was very bri
On Wed, May 31, 2017 at 7:18 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Wed, May 31, 2017 at 6:53 PM, Tom Lane wrote:
>
>> Alexander Korotkov writes:
>> > I've discovered that PostgreSQL is able to run following kind of
>> queries in
>> > order to change statistic-gathering
On 01/06/17 04:44, Peter Eisentraut wrote:
> On 5/31/17 09:40, Robert Haas wrote:
>> On Tue, May 30, 2017 at 3:01 PM, Peter Eisentraut
>> wrote:
>>> On 5/25/17 17:26, Peter Eisentraut wrote:
Another way to fix this particular issue is to not verify the
replication slot name before doing
On 31/05/17 11:21, Petr Jelinek wrote:
> On 31/05/17 09:24, Andres Freund wrote:
>> On 2017-05-29 23:49:33 +0200, Petr Jelinek wrote:
>>> I am not quite sure I understand (both the vxid suggestion and for the
>>> session dying badly). Maybe we can discuss bit more when you get to
>>> computer so it
On 01/06/17 06:06, Andres Freund wrote:
> On 2017-05-31 23:51:08 -0400, Peter Eisentraut wrote:
>> I think the easiest and safest thing to do now is to just prevent
>> parallel plans in the walsender. See attached patch. This prevents the
>> hang in the select_parallel tests run under your new te
On 05/25/2017 06:36 PM, Michael Paquier wrote:
On Thu, May 25, 2017 at 10:52 AM, Michael Paquier
wrote:
Actually, I don't think that we are completely done here. Using the
patch of upthread to enforce a failure on SASLInitialResponse, I see
that connecting without SSL causes the following error
On 1 June 2017 at 03:25, Robert Haas 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 else we wan
On Thu, Jun 1, 2017 at 1:02 PM, Michael Paquier
wrote:
> Thanks, this looks correct to me at quick glance.
>
> +if (!IsUnderPostmaster)
> +ereport(FATAL,
> +(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
> +errmsg("subscription commands are not supported by
> sing
On Thu, Jun 1, 2017 at 6:56 AM, Peter Eisentraut
wrote:
> On 5/31/17 02:17, Kuntal Ghosh wrote:
>> On Wed, May 31, 2017 at 12:58 AM, Masahiko Sawada
>> wrote:
>>>
>>> I'd say we can fix this issue by just changing the query. Attached
>>> patch changes the query so that it can handle publication
On Wed, May 31, 2017 at 7:18 PM, Craig Ringer wrote:
> Note that you can achieve the same effect w/o patching
> PostgresNode.pm, albeit in a somewhat ugly manner, by re-blessing the
> returned object.
>
> sub get_new_mywhatever_node {
> my $self = PostgresNode::get_new_node($name);
>
On Wed, May 31, 2017 at 10:49 PM, Dilip Kumar wrote:
> On Wed, May 31, 2017 at 2:20 PM, Michael Paquier
> wrote:
>> Yeah, see 0e0f43d6 for example. A simple fix is to look at
>> IsUnderPostmaster when creating, altering or dropping a subscription
>> in subscriptioncmds.c.
>
> Yeah, below patch fi
94 matches
Mail list logo
