On Wed, Jul 26, 2017 at 11:06 AM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> On Wed, Jul 26, 2017 at 11:00 AM, Rafia Sabih
> wrote:
> >
> >
> > On Wed, Jul 26, 2017 at 10:58 AM, Ashutosh Bapat
> > wrote:
> >>
> >> On
On Wed, Jul 26, 2017 at 11:00 AM, Rafia Sabih
wrote:
>
>
> On Wed, Jul 26, 2017 at 10:58 AM, Ashutosh Bapat
> wrote:
>>
>> On Tue, Jul 25, 2017 at 11:01 AM, Rafia Sabih
>> wrote:
>>
>> > Query plans for
On Wed, Jul 26, 2017 at 10:58 AM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> On Tue, Jul 25, 2017 at 11:01 AM, Rafia Sabih
> wrote:
>
> > Query plans for the above mentioned queries is attached.
> >
>
> Can you please share plans for all the queries,
On Tue, Jul 25, 2017 at 11:01 AM, Rafia Sabih
wrote:
> Query plans for the above mentioned queries is attached.
>
Can you please share plans for all the queries, even if they haven't
chosen partition-wise join when run on partitioned tables with
Hi
I wrote a special pager for psql. Surely, this pager is not good for paging
of man pages. So is not good to set it as global pager. We can introduce
new env variable PSQL_PAGER for this purpose. It can work similar like
PSQL_EDITOR variable.
Notes, comments?
Regards
Pavel
On Tue, Jul 25, 2017 at 9:39 PM, Dilip Kumar wrote:
> On Tue, Jul 25, 2017 at 8:59 PM, Robert Haas wrote:
>> On Tue, Jul 25, 2017 at 1:31 AM, Rafia Sabih
>> wrote:
>>> - other queries show a good 20-30% improvement in
On Wed, Jul 26, 2017 at 4:04 PM, Thomas Munro
wrote:
> On Wed, Jul 26, 2017 at 6:35 AM, Robert Haas wrote:
>> That's pretty cool. Per long-standing precedent, anything we use in a
>> build needs to be in Perl, not Python, but I think it
On Wed, Jul 26, 2017 at 6:35 AM, Robert Haas wrote:
> That's pretty cool. Per long-standing precedent, anything we use in a
> build needs to be in Perl, not Python, but I think it would be great
> to fix all of these (or the script) and then add this to our standard
>
Robert Haas writes:
> Based on discussion downthread, it seems like what we actually need to
> do is update perl.m4 to extract CCFLAGS. Turns out somebody proposed
> a patch for that back in 2002:
>
On Tue, Jul 25, 2017 at 8:02 PM, Peter Geoghegan wrote:
> Setup:
>
> Initialize pgbench (any scale factor).
> create index on pgbench_accounts (aid);
That "create index" was meant to be on "abalance", to make the UPDATE
queries always HOT-unsafe. (You'll want to *also* create this
On Tue, Jul 25, 2017 at 10:23 AM, Robert Haas wrote:
> While I'm not sure of the details, I suspect that we need to use one
> of those methods to get the CCFLAGS used to build perl, and include
> those when SPI.o, Util.o, and plperl.o in src/pl/plperl. Or at least
> the -D
On Tue, Jul 25, 2017 at 3:02 PM, Peter Geoghegan wrote:
> I've been thinking about this a lot, because this really does look
> like a pathological case to me. I think that this workload is very
> sensitive to how effective kill_prior_tuples/LP_DEAD hinting is. Or at
> least, I can
On 2017/07/25 5:35, Robert Haas wrote:
On Fri, Jul 21, 2017 at 6:21 AM, Etsuro Fujita
wrote:
I mean constraints derived from WITH CHECK OPTIONs specified for parent
views. We use the words "WITH CHECK OPTION constraints" in comments in
nodeModifyTable.c, so the
I wrote:
> The main problem with Kevin's fix, after thinking about it more, is that
> it shoves matview refresh commands into the same final processing phase
> where ACLs are done, which means that in a parallel restore they will not
> be done in parallel. That seems like a pretty serious
Stephen Frost writes:
> On Tue, Jul 25, 2017 at 20:29 Thom Brown wrote:
>> I should point out that this commit was made during the 9.6 cycle, and
>> I get the same issue with 9.6.
> Interesting that Tom didn't. Still, that does make more sense to me.
Yeah,
At Fri, 21 Jul 2017 10:09:25 -0400, Hadi Moshayedi wrote
in
> Hello,
>
> The attached patch moves declarations of
> ExplainBeginGroup()/ExplainEndGroup() from explain.c to explain.h.
>
> This can be useful
Hi,
On 2017-07-24 13:27:58 -0400, Tom Lane wrote:
> Andres Freund writes:
> >> * I think the comments need more work. Am willing to make a pass over
> >> that if you want.
>
> > That'd be good, but let's wait till we have something more final.
>
> Agreed, I'll wait till
Hi hackers,
Some LDAP error codes are a bit vague. For example:
LDAP_CONNECT_ERROR Indicates a connection problem.
LDAP_PROTOCOL_ERROR A protocol violation was detected.
To learn more, you have to call
ldap_get_option(LDAP_OPT_DIAGNOSTIC_MESSAGE). Should we do that? For
(Re-added hackers to Cc as this doesn't seem private, just accidentally
didn't reply-all?)
On 24 July 2017 at 23:50, Mat Arye wrote:
>
>
>
>> Issue 1: Preloading the right shared library.
>> When preloading libraries (either via local_preload_libraries, or
>>
On 26 July 2017 at 07:12, Alvaro Herrera wrote:
> Chapman Flack wrote:
>
> > Any takers if I propose this amendment in the form of a patch?
> >
> > Relying on the perl idiom instead of a $node->isa() test shortens
> > the patch; does that ameliorate at all the concern
On 26 July 2017 at 00:16, Thom Brown wrote:
> On 8 April 2016 at 07:13, Craig Ringer wrote:
> > On 6 April 2016 at 22:17, Andres Freund wrote:
> >
> >>
> >> Quickly skimming 0001 in [4] there appear to be a number of issues:
> >> *
Thom,
On Tue, Jul 25, 2017 at 20:29 Thom Brown wrote:
> On 26 July 2017 at 00:52, Stephen Frost wrote:
> > Thom,
> >
> > * Thom Brown (t...@linux.com) wrote:
> >> This is the culprit:
> >>
> >> commit 23f34fa4ba358671adab16773e79c17c92cbc870
> >> Author:
On 26 July 2017 at 00:52, Stephen Frost wrote:
> Thom,
>
> * Thom Brown (t...@linux.com) wrote:
>> This is the culprit:
>>
>> commit 23f34fa4ba358671adab16773e79c17c92cbc870
>> Author: Stephen Frost
>> Date: Wed Apr 6 21:45:32 2016 -0400
>
> Thanks!
Thom,
* Thom Brown (t...@linux.com) wrote:
> This is the culprit:
>
> commit 23f34fa4ba358671adab16773e79c17c92cbc870
> Author: Stephen Frost
> Date: Wed Apr 6 21:45:32 2016 -0400
Thanks! I'll take a look tomorrow.
Stephen
signature.asc
Description: Digital signature
Chapman Flack wrote:
> Any takers if I propose this amendment in the form of a patch?
>
> Relying on the perl idiom instead of a $node->isa() test shortens
> the patch; does that ameliorate at all the concern about complicating
> core for the benefit of modules?
Yeah, I like this (I also got
On 25 July 2017 at 21:47, Stephen Frost wrote:
> Tom,
>
> On Tue, Jul 25, 2017 at 16:43 Tom Lane wrote:
>>
>> AFAICT, pg_dump has no notion that it needs to be careful about the order
>> in which permissions are granted. I did
>>
>> regression=# create
On Fri, Jul 14, 2017 at 5:06 PM, Peter Geoghegan wrote:
> I think that what this probably comes down to, more than anything
> else, is that you have leftmost hot/bloated leaf pages like this:
>
>
> idx | level | l_item | blkno | btpo_prev |
> btpo_next |
Kunshchikov Vladimir wrote:
> Errors should be like this:
> pg_restore: [compress_io] could not read from input file: d3/2811.dat.gz:
> invalid distance too far back
>
> Attached small fix for this issue.
After looking at this patch, I don't like it very much. In particular,
I don't like the
On Thu, Jul 13, 2017 at 1:09 PM, Amit Khandekar wrote:
> Attached is a WIP patch (make_resultrels_ordered.patch) that generates
> the result rels in canonical order. This patch is kept separate from
> the update-partition-key patch, and can be applied on master branch.
Victor Wagner writes:
> PostgreSQL 10 when build with --with-icu requires ICU 4.6 and above.
> (because it searches for libicu using pkgconfig, and pgkconfig support
> significantly changed in ICU version 4.6)
> However, there are some reasons to build PostgreSQL with older
Tom,
On Tue, Jul 25, 2017 at 16:43 Tom Lane wrote:
> AFAICT, pg_dump has no notion that it needs to be careful about the order
> in which permissions are granted. I did
>
> regression=# create user joe;
> CREATE ROLE
> regression=# create user bob;
> CREATE ROLE
>
AFAICT, pg_dump has no notion that it needs to be careful about the order
in which permissions are granted. I did
regression=# create user joe;
CREATE ROLE
regression=# create user bob;
CREATE ROLE
regression=# create user alice;
CREATE ROLE
regression=# \c - joe
You are now connected to
Hi,
Is there any particular reason why postgres_fdw forbids usage of
connection strings by passing expand_dbname = false to
PQconnectdbParams? Attached patch shows where this happens.
>From 6bf3741976b833379f5bb370aa41f73a51b99afd Mon Sep 17 00:00:00 2001
From: Arseny Sher
Collegues,
PostgreSQL 10 when build with --with-icu requires ICU 4.6 and above.
(because it searches for libicu using pkgconfig, and pgkconfig support
significantly changed in ICU version 4.6)
However, there are some reasons to build PostgreSQL with older versions
of ICU.
For instance such
On 07/25/2017 01:41 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 07/25/2017 11:25 AM, Tom Lane wrote:
>>> Oh. So when was the last time it worked? And why do the buildfarm
>>> archives contain apparently-successful log_stage entries for pg_ctl-check
>>>
On Thu, Jul 13, 2017 at 9:46 PM, Thomas Munro
wrote:
> I wrote a script to cross-check various node handling functions and it told
> me:
>
> T_NextValueExpr not handled in outfuncs.c
> T_ObjectWithArgs not handled in outfuncs.c
> T_AccessPriv not handled in
On Tue, Jul 25, 2017 at 5:47 AM, Petr Jelinek
wrote:
> As a side note, the ConditionVariablePrepareToSleep()'s comment could be
> improved because currently it says the only advantage is that we skip
> double-test in the beginning of ConditionVariableSleep(). But
On Tue, Jul 25, 2017 at 1:42 PM, Alvaro Herrera
wrote:
> As I see it, we need to backpatch at least parts of this patch. I've
> received reports that in earlier branches pglogical and BDR can
> sometimes leave slots behind when removing nodes, and I have a hunch
> that
On Tue, Jul 25, 2017 at 1:50 PM, Tom Lane wrote:
> Andres Freund writes:
>> I'm not sure what you're arguing for here.
>
> Robert wants perfection, of course ;-). As do we all. But there are
> only so many hours in the day, and rejiggering pg_dump's
"Joshua D. Drake" writes:
> Isn't the simplest solution just to actually document this?
Given that it's behaved this way since 8.1 (maybe earlier, I'm not sure),
and nobody has complained before, I'm not sure it's worth documenting.
There are lots of undocumented
Andres Freund writes:
> I'm not sure what you're arguing for here.
Robert wants perfection, of course ;-). As do we all. But there are
only so many hours in the day, and rejiggering pg_dump's rules about
how to dump PLs is just way down the to-do list. I'm going to go do
On 07/25/2017 10:24 AM, Andres Freund wrote:
On 2017-07-25 13:18:25 -0400, Robert Haas wrote:
On Tue, Jul 25, 2017 at 1:13 PM, Andres Freund wrote:
On 2017-07-25 13:10:11 -0400, Robert Haas wrote:
On Tue, Jul 25, 2017 at 1:06 PM, Tom Lane wrote:
Is
Petr Jelinek wrote:
> On 25/07/17 01:33, Alvaro Herrera wrote:
> > Alvaro Herrera wrote:
> >> I'm back at looking into this again, after a rather exhausting week. I
> >> think I have a better grasp of what is going on in this code now,
> >
> > Here's an updated patch, which I intend to push
Andrew Dunstan writes:
> On 07/25/2017 11:25 AM, Tom Lane wrote:
>> Oh. So when was the last time it worked? And why do the buildfarm
>> archives contain apparently-successful log_stage entries for pg_ctl-check
>> on jacana, up through yesterday when I looked?
>
On 2017-07-25 13:18:25 -0400, Robert Haas wrote:
> On Tue, Jul 25, 2017 at 1:13 PM, Andres Freund wrote:
> > On 2017-07-25 13:10:11 -0400, Robert Haas wrote:
> >> On Tue, Jul 25, 2017 at 1:06 PM, Tom Lane wrote:
> >> >> Is this assumption, like, documented
On Tue, Jul 25, 2017 at 1:13 PM, Andres Freund wrote:
> On 2017-07-25 13:10:11 -0400, Robert Haas wrote:
>> On Tue, Jul 25, 2017 at 1:06 PM, Tom Lane wrote:
>> >> Is this assumption, like, documented someplace?
>> >
>> > Uh, right there?
>>
>> I don't
On 2017-07-25 13:10:11 -0400, Robert Haas wrote:
> On Tue, Jul 25, 2017 at 1:06 PM, Tom Lane wrote:
> >> Is this assumption, like, documented someplace?
> >
> > Uh, right there?
>
> I don't think we can expect end-users to read the code comments to
> determine whether their
On Tue, Jul 25, 2017 at 1:06 PM, Tom Lane wrote:
>> Is this assumption, like, documented someplace?
>
> Uh, right there?
I don't think we can expect end-users to read the code comments to
determine whether their apparently-legal SQL is fully supported.
--
Robert Haas
Robert Haas writes:
> On Tue, Jul 25, 2017 at 10:31 AM, Tom Lane wrote:
>> pg_dump doesn't really support that scenario, and I don't feel any
>> great need to make it do so. Per the comment in dumpProcLang:
> Is this assumption, like, documented
On 7/25/17 5:04 PM, Tom Lane wrote:
Tomas Vondra writes:
On 7/25/17 12:55 AM, Tom Lane wrote:
I think the planner basically assumes that reltuples is the live
tuple count, so maybe we'd better change VACUUM to get in step.
Attached is a patch that (I think)
On Tue, Jul 25, 2017 at 5:57 AM, Teodor Sigaev wrote:
>> It's not clear from the web site in question that the relevant code is
>> released under the PostgreSQL license.
>
> As author I allow to use this code in PostgreSQL and under its license.
Great. As long as all authors
On Tue, Jul 25, 2017 at 10:31 AM, Tom Lane wrote:
> tushar writes:
>> postgres=# CREATE LANGUAGE alt_lang1 HANDLER plpgsql_call_handler;
>> CREATE LANGUAGE
>
> pg_dump doesn't really support that scenario, and I don't feel any
> great need to
On 8 April 2016 at 07:13, Craig Ringer wrote:
> On 6 April 2016 at 22:17, Andres Freund wrote:
>
>>
>> Quickly skimming 0001 in [4] there appear to be a number of issues:
>> * LWLockHeldByMe() is only for debugging, not functional differences
>> *
On Tue, Jul 25, 2017 at 8:59 PM, Robert Haas wrote:
> On Tue, Jul 25, 2017 at 1:31 AM, Rafia Sabih
> wrote:
>> - other queries show a good 20-30% improvement in performance. Performance
>> numbers are as follows,
>>
>> Query| un_part_head
On 07/25/2017 11:32 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jul 25, 2017 at 11:00 AM, Tom Lane wrote:
>>> Hm, I had the idea that we were already asking ExtUtils::Embed for that,
>>> but now I see we only inquire about LDFLAGS not
On Tue, Jul 25, 2017 at 11:32 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jul 25, 2017 at 11:00 AM, Tom Lane wrote:
>>> Hm, I had the idea that we were already asking ExtUtils::Embed for that,
>>> but now I see we only
On 07/25/2017 11:25 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 07/25/2017 11:11 AM, Tom Lane wrote:
>>> What I'm on about is that jacana still succeeds entirely, more than half
>>> the time. If this is a handle-duplication problem, how could it ever
>>>
Robert Haas writes:
> On Tue, Jul 25, 2017 at 11:00 AM, Tom Lane wrote:
>> Hm, I had the idea that we were already asking ExtUtils::Embed for that,
>> but now I see we only inquire about LDFLAGS not CCFLAGS. Yes, this sounds
>> like a promising avenue
On Tue, Jul 25, 2017 at 1:31 AM, Rafia Sabih
wrote:
> - other queries show a good 20-30% improvement in performance. Performance
> numbers are as follows,
>
> Query| un_part_head (seconds) | part_head (seconds) | part_patch (seconds) |
> 3 | 76 |127 | 88 |
> 4 |17 |
On Tue, Jul 25, 2017 at 11:00 AM, Tom Lane wrote:
> Hm, I had the idea that we were already asking ExtUtils::Embed for that,
> but now I see we only inquire about LDFLAGS not CCFLAGS. Yes, this sounds
> like a promising avenue to pursue.
>
> It would be useful to see the
Andrew Dunstan writes:
> On 07/25/2017 11:11 AM, Tom Lane wrote:
>> What I'm on about is that jacana still succeeds entirely, more than half
>> the time. If this is a handle-duplication problem, how could it ever
>> succeed?
> No, it hangs 100% of the time. The
On 07/25/2017 11:11 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 07/24/2017 09:33 PM, Tom Lane wrote:
>>> Seems like the TAP test should fail every time, if this is a full
>>> description. But maybe it's part of the answer, so it seems worth
>>>
On 07/25/2017 11:00 AM, Tom Lane wrote:
> Robert Haas writes:
>> Perl also has a mechanism for flags added to Configure to be passed
>> along when building loadable modules; if it didn't, not just plperl
>> but every Perl module written in C would have this issue if any
Andrew Dunstan writes:
> On 07/24/2017 09:33 PM, Tom Lane wrote:
>> Seems like the TAP test should fail every time, if this is a full
>> description. But maybe it's part of the answer, so it seems worth
>> experimenting in this direction.
> The test that hangs is
On 25 July 2017 at 22:18, Tom Lane wrote:
> =?UTF-8?B?WmVocmEgR8O8bCDDh2FidWs=?= writes:
> > => ALTER TABLE test ALTER COLUMN x TYPE integer USING
> > (trim(x)::integer);ALTER TABLE
> > Last command I've executed to alter column data type creates an
Tomas Vondra writes:
> On 7/25/17 12:55 AM, Tom Lane wrote:
>> I think the planner basically assumes that reltuples is the live
>> tuple count, so maybe we'd better change VACUUM to get in step.
> Attached is a patch that (I think) does just that. The disagreement
Robert Haas writes:
> Perl also has a mechanism for flags added to Configure to be passed
> along when building loadable modules; if it didn't, not just plperl
> but every Perl module written in C would have this issue if any such
> flags where used.
> ...
> While I'm not
Andrew Dunstan writes:
> No amount of checking with the Perl community is likely to resolve this
> quickly w.r.t. existing releases of Perl.
Yes, but if they are shipping broken perl builds that cannot support
building of extension modules, they need to be made
On 07/24/2017 09:33 PM, Tom Lane wrote:
>
> [good theory about why pg_ctl hangs in TAP test]
>
> Now, this theory still has a Mack-truck-sized hole in it, which is
> if that's the failure mechanism then why isn't it 100% effective?
> Seems like the TAP test should fail every time, if this is a
Alexey Bashtanov writes:
> Is there a reason that join cardinality estimates are not limited by the
> product of the joined parts cardinalities like in the
> join-card-est.patch attached?
Because that would be giving an unfair advantage to some paths over
others based on
Amit Kapila writes:
> I think the real question is where do we go from here. Ashutosh has
> proposed a patch up-thread based on a suggestion from Andrew, but it
> is not clear if we want to go there as that seems to be bypassing
> handshake mechanism.
That definitely
On 07/25/2017 08:58 AM, Amit Kapila wrote:
>
> I think the real question is where do we go from here. Ashutosh has
> proposed a patch up-thread based on a suggestion from Andrew, but it
> is not clear if we want to go there as that seems to be bypassing
> handshake mechanism. The other tests
tushar writes:
> postgres=# CREATE LANGUAGE alt_lang1 HANDLER plpgsql_call_handler;
> CREATE LANGUAGE
pg_dump doesn't really support that scenario, and I don't feel any
great need to make it do so. Per the comment in dumpProcLang:
* Try to find the
On Mon, Jul 24, 2017 at 6:16 PM, Tom Lane wrote:
> Mat Arye writes:
> > On Mon, Jul 24, 2017 at 1:38 PM, Tom Lane wrote:
> >> I'm not really sure why planner hooks would have anything to do with
> your
> >> exposed SQL API?
>
> >
Hello Hackers,
The attached patch moves declarations of
ExplainOpenGroup()/ExplainCloseGroup() from explain.c to explain.h.
This can be useful for extensions that need explain groups in their
custom-scan explain output.
For example, Citus uses groups in its custom explain outputs [1]. But it
On Wed, Jul 19, 2017 at 5:01 PM, Tom Lane wrote:
> I am really suspicious that this means your libperl was built in an unsafe
> fashion, that is, by injecting configuration choices as random -D switches
> in the build process rather than making sure the choices were recorded
=?UTF-8?B?WmVocmEgR8O8bCDDh2FidWs=?= writes:
> => ALTER TABLE test ALTER COLUMN x TYPE integer USING
> (trim(x)::integer);ALTER TABLE
> Last command I've executed to alter column data type creates an event like
> this:
> BEGIN 500913table public.pg_temp_1077668: INSERT:
Rushabh Lathia writes:
> On Mon, Jul 24, 2017 at 7:23 PM, Tom Lane wrote:
>> Some looking around says that this *isn't* the only place that just
>> blithely assumes that it will find an opfamily entry. But I agree
>> that not checking for that isn't
Hello,
Postgres can produce a plan with a nested loop node having rows estimate
much more than the product of underlying nodes' estimates, relying only
on outer relation size:
alexey=# explain
SELECT oid, relname
FROM (
SELECT m.oid, m.relname
FROM pg_class m
UNION ALL
On Mon, Jul 24, 2017 at 11:58 AM, Noah Misch wrote:
> On Wed, Jul 19, 2017 at 05:01:31PM -0400, Tom Lane wrote:
>> Ashutosh Sharma writes:
>> > Here are the list of macros and variables from 'intrpvar.h' file that
>> > are just defined in perl module but
On 25 July 2017 at 12:09, tushar wrote:
> v9.6
>
> postgres=# CREATE LANGUAGE alt_lang1 HANDLER plpgsql_call_handler;
> CREATE LANGUAGE
> postgres=# \q
>
> v10 , run pg_upgrade - failing with this error -
>
> pg_restore: creating pg_largeobject_metadata
On Tue, Jul 25, 2017 at 3:54 PM, Amit Khandekar
wrote:
> On 25 July 2017 at 15:02, Rajkumar Raghuwanshi
> wrote:
> > On Mon, Jul 24, 2017 at 11:23 AM, Amit Khandekar >
> > wrote:
> >>
> >>
> >> Attached
On 7/25/17 12:55 AM, Tom Lane wrote:
Tomas Vondra writes:
It seems to me that VACUUM and ANALYZE somewhat disagree on what
exactly reltuples means. VACUUM seems to be thinking that reltuples
= live + dead while ANALYZE apparently believes that reltuples =
live
v9.6
postgres=# CREATE LANGUAGE alt_lang1 HANDLER plpgsql_call_handler;
CREATE LANGUAGE
postgres=# \q
v10 , run pg_upgrade - failing with this error -
pg_restore: creating pg_largeobject_metadata "pg_largeobject_metadata"
pg_restore: creating COMMENT "postgres"
pg_restore: creating SCHEMA
On 25 July 2017 at 15:02, Rajkumar Raghuwanshi
wrote:
> On Mon, Jul 24, 2017 at 11:23 AM, Amit Khandekar
> wrote:
>>
>>
>> Attached update-partition-key_v13.patch now contains this
>> make_resultrels_ordered.patch changes.
>>
>
> I
On Tue, Jul 25, 2017 at 4:43 AM, Michael Paquier
wrote:
> On Mon, Jul 24, 2017 at 6:45 PM, Stephen Frost wrote:
>> What the change would do is make the pg_stop_backup() caller block until
>> the last WAL is archvied, and perhaps that ends up taking
On 2017-07-10 21:39:09 +1200, Thomas Munro wrote:
> Here's a new version that introduces a per-session DSM segment to hold
> the shared record typmod registry (and maybe more things later).
You like to switch it up. *.patchset.tgz??? ;)
It does concern me that we're growing yet another somewhat
It's not clear from the web site in question that the relevant code is
released under the PostgreSQL license.
As author I allow to use this code in PostgreSQL and under its license.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
On 25/07/17 01:33, Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>> I'm back at looking into this again, after a rather exhausting week. I
>> think I have a better grasp of what is going on in this code now,
>
> Here's an updated patch, which I intend to push tomorrow.
>
I think the
On Mon, Jul 24, 2017 at 11:23 AM, Amit Khandekar
wrote:
>
> Attached update-partition-key_v13.patch now contains this
> make_resultrels_ordered.patch changes.
>
>
I have applied attach patch and got below observation.
Observation : if join producing multiple output rows
Hello,
8bf58c0d9bd33686 badly conflicts with this patch, so I'll rebase
this and added a patch to refactor the function that Anotonin
pointed. This would be merged into 0002 patch.
At Tue, 18 Jul 2017 16:24:52 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
On Mon, Jul 24, 2017 at 11:38 PM, Robert Haas wrote:
> On Fri, Jul 21, 2017 at 8:05 AM, Alexey Chernyshov
> wrote:
>> the following patch transfers functionality from gevel module
>> (http://www.sai.msu.su/~megera/wiki/Gevel) which provides
We can't create any schema dump with another (user defined) name. E.g.
we dump schema test and we want to save it's dump with test2 name in
any format. Those refers to databases dump.
Hello,
Do you expect to have some flag like '--rename=test->test2'?
Will dump with test replaced by test2(of
At Mon, 24 Jul 2017 10:23:07 +0530, Ashutosh Bapat
wrote in
> On Fri, Jul 21, 2017 at 10:39 PM, Tom Lane wrote:
> > Ashutosh Bapat writes:
94 matches
Mail list logo