I would like to propose a patch to improve the cost of bitmap heap
scan that is sensitive to work_mem. Currently, in bitmap scan, we
don't consider work_mem. Now, in cases when there are a lot of lossy
pages bitmap scan gets selected that eventually leads to degraded
performance.
While evaluating
On Thu, May 18, 2017 at 3:19 PM, Michael Paquier
wrote:
> On Thu, May 18, 2017 at 2:59 PM, Masahiko Sawada
> wrote:
>> It seems to me that it's not good idea to forcibly set ANALYZE in
>> spite of ANALYZE option is not specified. One reason is that it would
>> make us difficult to grep it from
From: Michael Paquier [mailto:michael.paqu...@gmail.com]
> Does JDBC use something like that to make a difference between a failure
> and a move-on-to-next-one?
No, it just tries the next host. See the first while loop in
org/postgresql/jdbc/core/v3/ConnectionFactoryImpl.java.
> From maintena
On 05/15/2017 07:03 AM, Noah Misch wrote:
On Thu, May 11, 2017 at 10:08:30AM +0900, Michael Paquier wrote:
On Wed, May 10, 2017 at 10:22 PM, Michael Paquier
wrote:
On Wed, May 10, 2017 at 10:01 PM, Tom Lane wrote:
Heikki Linnakangas writes:
Also note that changing the signature check_pass
On 17 May 2017 at 17:29, Rushabh Lathia wrote:
>
>
> On Wed, May 17, 2017 at 12:06 PM, Dilip Kumar wrote:
>>
>> On Fri, May 12, 2017 at 4:17 PM, Amit Khandekar
>> wrote:
>> > Option 3
>> >
>> >
>> > BR, AR delete triggers on source partition
>> > BR, AR insert triggers on destination pa
On Thu, May 18, 2017 at 2:59 PM, Masahiko Sawada wrote:
> It seems to me that it's not good idea to forcibly set ANALYZE in
> spite of ANALYZE option is not specified. One reason is that it would
> make us difficult to grep it from such as server log. I think It's
> better to use the same vacuum
On Wed, May 17, 2017 at 11:35 AM, Tom Lane wrote:
> I think the question is whether we are going to make a distinction between
> logical partitions (where the data division rule makes some sense to the
> user) and physical partitions (where it needn't). I think it might be
> perfectly reasonable
On Thu, May 18, 2017 at 11:01 AM, Michael Paquier
wrote:
> On Thu, May 18, 2017 at 12:06 AM, Bossart, Nathan wrote:
>> I agree with you here, too. I stopped short of allowing customers to
>> explicitly provide per-table options, so the example you provided wouldn’t
>> work here. This is more
On Wed, May 17, 2017 at 12:10 PM, Robert Haas wrote:
> 1. To handle dump-and-reload the way we partitioning does today, hash
> functions would need to be portable across encodings.
> 2. That's impractically difficult.
> 3. So let's always load data through the top-parent.
> 4. But that could fail
Re: Tom Lane 2017-05-17 <30016.1495041...@sss.pgh.pa.us>
> Christoph Berg writes:
> > The sequence regression tests are failing on Debian/sparc64:
> > ...
> > (This is only the last 100 lines of regression.diffs, if it helps I
> > can try rebuilding and grabbing the full file.)
>
> Yes please.
On Thu, May 18, 2017 at 2:56 AM, Surafel Temesgen
wrote:
> Sorry for being very late. I also think guc version of the patch can be
> acceptable and useful.
>
> I modified the patch as such and added to commitfest 2017-07.
>
>
>
You need documentation changes in "libpq - C Library" chapter's PQexe
On Thu, May 18, 2017 at 7:38 AM, Bossart, Nathan wrote:
> I’ve attached a v4 of the patch.
>
> Changes:
> - Early in vacuum(…), emit an ERROR if any specified columns do not exist.
> - Emit a WARNING and skip any specified tables or columns that disappear
> before they are actually processed.
>
On Thu, May 18, 2017 at 12:07 PM, Tsunakawa, Takayuki
wrote:
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
>> Maybe add this to the list of open issues to reconsider mid-beta?
>
> Done. I'll examine whether we can use SQLSTATE.
Does JDBC use something like that to make a difference between a
fail
On Thu, May 11, 2017 at 1:48 PM, Michael Paquier
wrote:
> I had my eyes on the WAL sender code this morning, and I have noticed
> that walsender.c is not completely consistent with the PID lookups it
> does in walsender.c. In two code paths, the PID value is checked
> without holding the WAL sende
On Wed, May 17, 2017 at 11:51 PM, Robert Haas wrote:
> On Wed, May 17, 2017 at 1:41 AM, Ashutosh Bapat
> wrote:
>>> Fixed in the attached version; used "hash partition remainder must be
>>> greater than or equal to 0" instead.
>>
>> I would suggest "non-zero positive", since that's what we are u
On Wed, May 17, 2017 at 5:17 PM, Robert Haas wrote:
> On Wed, May 17, 2017 at 6:29 AM, Amit Kapila wrote:
>> I think we can do this even without using an additional infomask bit.
>> As suggested by Greg up thread, we can set InvalidBlockId in ctid to
>> indicate such an update.
>
> Hmm. How wou
On Thu, May 18, 2017 at 1:00 AM, Peter Eisentraut
wrote:
> On 5/17/17 05:15, Masahiko Sawada wrote:
>> BTW, why should max_replication_slots be set more than 0 even on the
>> subscriber side? It's documented but I could not understand reason.
>
> Because that setting also controls replication orig
On Thu, May 18, 2017 at 11:29 AM, Peter Eisentraut
wrote:
> On 5/12/17 00:30, Masahiko Sawada wrote:
>> I got same log messages 'starting logical replication worker for
>> subscription' total 5 times but actually 4 of them mean to launch
>> table sync worker and another one means apply worker. We
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Sure, but part of the point of beta testing is to get user feedback.
Yes, and I'm also proposing this in the user's point of view, which I believe
holds true for people here. I'm worried from my support experience that strict
customers would complain
On Thu, May 18, 2017 at 10:33 AM, Peter Eisentraut
wrote:
> On 5/16/17 22:21, Masahiko Sawada wrote:
>> I think there are two bugs; pg_dump should dump slot_name = NONE
>> instead of '' and subscription should not be created if given slot
>> name is invalid. The validation check for replication sl
On 5/12/17 00:30, Masahiko Sawada wrote:
> I got same log messages 'starting logical replication worker for
> subscription' total 5 times but actually 4 of them mean to launch
> table sync worker and another one means apply worker. We cannot
> distinguish them. Also, I got same log messages 'logica
On Wed, May 17, 2017 at 12:14 AM, Robert Haas wrote:
> Well, it's probably worth changing for consistency, but I'm not sure
> that it rises to the level of "a very bad idea". It actually seems
> almost entirely harmless. Spuriously setting the needreload flag on a
> just-deceased WAL sender will
On 2017/05/18 3:43, Robert Haas wrote:
> On Wed, May 17, 2017 at 5:38 AM, Jeevan Ladhe
> wrote:
>> While browsing through the partitioning code, I noticed that a recent commit
>> f8bffe9e6d700fd34759a92e47930ce9ba7dcbd5, which fixes multi-column range
>> partitioning constraints, introduced a func
On Thu, May 18, 2017 at 12:06 AM, Bossart, Nathan wrote:
> I agree with you here, too. I stopped short of allowing customers to
> explicitly provide per-table options, so the example you provided wouldn’t
> work here. This is more applicable for something like the following:
>
> VACUUM
On 2017/05/18 10:49, Amit Langote wrote:
> On 2017/05/18 2:14, Dilip Kumar wrote:
>> On Wed, May 17, 2017 at 7:41 PM, wrote:
>>> (gdb) bt
>>> #0 0x0061ab1b in list_nth ()
>>> #1 0x005e4081 in ExecLockNonLeafAppendTables ()
>>> #2 0x005f4d52 in ExecInitMergeAppend ()
>>>
On Thu, May 18, 2017 at 12:37 AM, Jeff Janes wrote:
> It is shipping collation-sensitive aggregates between servers which have
> different collations.
>
> commit 7012b132d07c2b4ea15b0b3cb1ea9f3278801d98
> Author: Robert Haas
> Date: Fri Oct 21 09:54:29 2016 -0400
>
> postgres_fdw: Push down
On 5/16/17 22:21, Masahiko Sawada wrote:
> I think there are two bugs; pg_dump should dump slot_name = NONE
> instead of '' and subscription should not be created if given slot
> name is invalid. The validation check for replication slot name is
> done when creating it actually but I think it's mor
On Tue, May 16, 2017 at 09:00:38PM -0400, Bruce Momjian wrote:
> On Tue, May 16, 2017 at 08:39:36PM -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > There we go:
> > > https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=calliphoridae&dt=2017-05-16%2023:16:53&stg=typedefs
> >
> > Y
On Wed, May 17, 2017 at 7:42 PM, Thomas Munro
wrote:
> On Wed, May 17, 2017 at 6:04 PM, Amit Langote
> wrote:
>> targetRelInfo should instead be set to mtstate->rootResultRelInfo that was
>> set in ExecInitModifyTable() as described above, IOW, as follows:
>>
>> /* Partitioned table. */
>>
Alvaro Herrera writes:
> Piotr Stefaniak wrote:
>> If I remember correctly, it tries to right-align string literals to
>> whatever -l ("Maximum length of an output line") was set to.
> Yeah, it does that (for error messages too).
Piotr's version seems to at least do this more consistently than t
Piotr Stefaniak writes:
> Full copy of my pgindent attached. Changes commented below.
Thanks! I ran this, along with the indent copy I pulled from your
github repo a couple hours ago, over the current PG tree (post
Bruce's run). I got a diff extending to about 100K lines :-(
which I will not p
On Mon, May 15, 2017 at 03:02:54PM +0900, Amit Langote wrote:
> On 2017/05/14 12:03, Mark Dilger wrote:
> > I discovered a reproducible crash using event triggers in the current
> > development version, 29c7d5e483acaa74a0d06dd6c70b320bb315.
> > I was getting a crash before this version, and clo
Piotr Stefaniak wrote:
> On 2017-05-17 17:55, Peter Eisentraut wrote:
> > On 5/17/17 10:14, Tom Lane wrote:
> >> What I was concerned about was that pgindent will reindent the second
> >> line so that it's impossible to tell whether the spacing is correct.
> >
> > pgindent moving string continuati
On 18 May 2017 at 04:30, Robert Haas wrote:
> On Wed, May 17, 2017 at 11:08 AM, Heikki Linnakangas wrote:
>> That's not a straight semi-join, but we could still turn it into a new kind
>> of LEFT-SEMI join. A left-semi join is like a left join, in that it returns
>> all rows from the left side, a
On 2017-05-17 17:55, Peter Eisentraut wrote:
> On 5/17/17 10:14, Tom Lane wrote:
>> What I was concerned about was that pgindent will reindent the second
>> line so that it's impossible to tell whether the spacing is correct.
>
> pgindent moving string continuations to the left is a completely
> t
On 2017-05-17 22:11, Tom Lane wrote:
> Piotr Stefaniak writes:
>> The third significant issue I kept in my mind was to shift some
>> work-arounds from pgindent to indent.
>
> Yeah, I was wondering about that too.
>
>> When I use my indent as the base
>> for pgindent and set its options like this
Piotr Stefaniak writes:
> The third significant issue I kept in my mind was to shift some
> work-arounds from pgindent to indent.
Yeah, I was wondering about that too.
> When I use my indent as the base
> for pgindent and set its options like this:
> -bad -bap -bc -bl -d0 -cdb -nce -nfc1 -di12 -
Piotr Stefaniak writes:
> That, I assume, would be me. Coincidentally, I'm about to push my fixes
> upstream (FreeBSD). Before that happens, my changes can be obtained from
> https://github.com/pstef/freebsd_indent and tested, if anyone wishes.
Do you have recommendations for the switches to use
On 2017-05-17 20:31, Tom Lane wrote:
> Piotr Stefaniak writes:
>> On 2017-05-17 19:16, Alvaro Herrera wrote:
>>> We have someone who has studied the BSD indent code and even sent us
>>> patches to fix quite a few bugs, but we've largely ignored his efforts
>>> so far. I propose we take that inden
Not sure if a lot of people still care about m68k, but it's still one
of the unofficial Debian ports (it used to be the first non-x86 port
done decades ago):
gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement
-Wendif-labels -Wmissing-format-attribute -Wformat-security
-
On Wed, May 17, 2017 at 2:35 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, May 16, 2017 at 4:25 PM, Jeff Davis wrote:
>>> Why can't hash partitions be stored in tables the same way as we do TOAST?
>>> That should take care of the naming problem.
>
>> Hmm, yeah, something like that could b
It is shipping collation-sensitive aggregates between servers which have
different collations.
commit 7012b132d07c2b4ea15b0b3cb1ea9f3278801d98
Author: Robert Haas
Date: Fri Oct 21 09:54:29 2016 -0400
postgres_fdw: Push down aggregates to remote servers.
I've attached a reproducing case.
On Thu, May 18, 2017 at 12:13 AM, Robert Haas wrote:
>
> Agreed. Committed your patch.
>
Thanks Robert!
On 2017-05-17 14:44:31 -0400, Tom Lane wrote:
> $ tar xfz ~/archive/pg_bsd_indent-1.3.tar.gz
> $ wc pg_bsd_indent/*
> 38122928 pg_bsd_indent/Makefile
>107831 4835 pg_bsd_indent/README
>508 1743 11988 pg_bsd_indent/args.c
>569 2727 14732 pg_bsd_indent/indent.1
>
Andres Freund writes:
> On 2017-05-17 13:35:22 -0400, Tom Lane wrote:
>> Not sure about actually incorporating it into our repo. Doing so would
>> make it easier for people to use, for sure, and the license seems to be
>> regular 3-clause BSD, so that angle is OK. But do we want to be carrying
>
On Wed, May 17, 2017 at 5:38 AM, Jeevan Ladhe
wrote:
> While browsing through the partitioning code, I noticed that a recent commit
> f8bffe9e6d700fd34759a92e47930ce9ba7dcbd5, which fixes multi-column range
> partitioning constraints, introduced a function make_partition_op_expr, that
> takes keyn
Alvaro Herrera writes:
> Tom Lane wrote:
>> Not sure about actually incorporating it into our repo. Doing so would
>> make it easier for people to use, for sure, and the license seems to be
>> regular 3-clause BSD, so that angle is OK. But do we want to be carrying
>> around another 150K of sour
On 2017-05-17 13:35:22 -0400, Tom Lane wrote:
> Not sure about actually incorporating it into our repo. Doing so would
> make it easier for people to use, for sure, and the license seems to be
> regular 3-clause BSD, so that angle is OK. But do we want to be carrying
> around another 150K of sour
Robert Haas writes:
> On Tue, May 16, 2017 at 4:25 PM, Jeff Davis wrote:
>> Why can't hash partitions be stored in tables the same way as we do TOAST?
>> That should take care of the naming problem.
> Hmm, yeah, something like that could be done, but every place where
> you are currently allowed
Piotr Stefaniak writes:
> On 2017-05-17 19:16, Alvaro Herrera wrote:
>> We have someone who has studied the BSD indent code and even sent us
>> patches to fix quite a few bugs, but we've largely ignored his efforts
>> so far. I propose we take that indent as part of our repo, and patch it
>> to o
On Tue, May 16, 2017 at 9:20 PM, Andrew Dunstan
wrote:
> Inheriting variables from the environment is a part of make by design.
> We have PG_PROVE_FLAGS for our own forced settings.
I don't buy this argument. We've had previous cases where we've gone
through and added -X to psql invocations in t
Tom, all,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Bruce Momjian writes:
> > Are we ready for a pgindent run now?
>
> Yes, might as well do it. Some of these discussions might lead to
> a re-run with a newer version of pgindent, but it would be good to
> have a clean tree to start from.
+1.
T
Tom Lane wrote:
> Alvaro Herrera writes:
> > We have someone who has studied the BSD indent code and even sent us
> > patches to fix quite a few bugs, but we've largely ignored his efforts
> > so far. I propose we take that indent as part of our repo, and patch it
> > to our preferences.
>
> Mes
Bruce Momjian writes:
> Are we ready for a pgindent run now?
Yes, might as well do it. Some of these discussions might lead to
a re-run with a newer version of pgindent, but it would be good to
have a clean tree to start from.
regards, tom lane
--
Sent via pgsql-hacke
On Wed, May 17, 2017 at 1:41 AM, Ashutosh Bapat
wrote:
>> Fixed in the attached version; used "hash partition remainder must be
>> greater than or equal to 0" instead.
>
> I would suggest "non-zero positive", since that's what we are using in
> the documentation.
Well, that's not very good termi
On Tue, May 16, 2017 at 4:25 PM, Jeff Davis wrote:
> Why can't hash partitions be stored in tables the same way as we do TOAST?
> That should take care of the naming problem.
Hmm, yeah, something like that could be done, but every place where
you are currently allowed to refer to a partition by n
On 2017-05-17 19:16, Alvaro Herrera wrote:
> Tom Lane wrote:
>
>> Changing the pgindent rule for such cases sounds kind of promising,
>> but will anyone pursue it?
>
> We have someone who has studied the BSD indent code and even sent us
> patches to fix quite a few bugs, but we've largely ignored
On Wed, May 17, 2017 at 01:06:26PM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> No, the previous setup hasn't been "in place for years". These programs
> >> were only NLS-ified last fall.
>
> > We use the same technique in other places such as pg_dump's help() too.
>
> I committed this with fixes for those issues, plus I renamed the macro
> to partition_bound_accepts_nulls, which I think is more clear.
Thanks Robert.
Moin,
On Wed, May 17, 2017 12:34 pm, Robert Haas wrote:
> On Wed, May 17, 2017 at 3:06 AM, Tsunakawa, Takayuki
> wrote:
>> What do you think of the following cases? Don't you want to connect to
>> other servers?
>>
>> * The DBA shuts down the database. The server takes a long time to do
>> chec
Alvaro Herrera writes:
> We have someone who has studied the BSD indent code and even sent us
> patches to fix quite a few bugs, but we've largely ignored his efforts
> so far. I propose we take that indent as part of our repo, and patch it
> to our preferences.
Messing with pgindent didn't seem
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I agree with Robert's point that major redesign of the feature on the
> basis of one complaint isn't necessarily the way to go. Since the
> existing behavior is already out in beta1, let's wait and see if anyone
> else complains. We don't need to fix
On Wed, May 17, 2017 at 12:06 AM, Tsunakawa, Takayuki <
tsunakawa.ta...@jp.fujitsu.com> wrote:
> From: pgsql-hackers-ow...@postgresql.org
> > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas
> > Who is right is a judgement call, but I don't think it's self-evident
> that
> > us
Stephen Frost writes:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> One good argument for leaving this alone entirely is that this feature
>> was committed on November 3rd and this thread began on May 12th. If
>> there was ample time before feature freeze to question the design and
>> nobody
Tom Lane wrote:
> Changing the pgindent rule for such cases sounds kind of promising,
> but will anyone pursue it?
We have someone who has studied the BSD indent code and even sent us
patches to fix quite a few bugs, but we've largely ignored his efforts
so far. I propose we take that indent as
Christoph Berg writes:
> The sequence regression tests are failing on Debian/sparc64:
> ...
> (This is only the last 100 lines of regression.diffs, if it helps I
> can try rebuilding and grabbing the full file.)
Yes please. What we can see here looks to be just fallout from
a failure earlier in
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> One good argument for leaving this alone entirely is that this feature
> was committed on November 3rd and this thread began on May 12th. If
> there was ample time before feature freeze to question the design and
> nobody did, then I'm not su
Alvaro Herrera writes:
> Tom Lane wrote:
>> No, the previous setup hasn't been "in place for years". These programs
>> were only NLS-ified last fall.
> We use the same technique in other places such as pg_dump's help() too.
Meh. Well, I reverted the changes in question while we discuss it.
Ch
On Wed, May 17, 2017 at 12:48 PM, Tom Lane wrote:
> Robert Haas writes:
>> Yeah, you have a point. I'm willing to admit that we may have defined
>> the behavior of the feature incorrectly, provided that you're willing
>> to admit that you're proposing a definition change, not just a bug
>> fix.
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I suggest that we need to conditionalize the decision based on what
>> SQLSTATE is reported. Not sure offhand if it's better to have a whitelist
>> of SQLSTATEs that allow failing over to the next server, or a blacklist of
>> SQLST
Sorry for being very late. I also think guc version of the patch can be
acceptable and useful.
I modified the patch as such and added to commitfest 2017-07.
Regards
Surafel
On Sat, Mar 4, 2017 at 10:24 AM, Robert Haas wrote:
> On Tue, Feb 28, 2017 at 7:34 PM, Tom Lane wrote:
> > Surafel T
Tom, Robert,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > Yeah, you have a point. I'm willing to admit that we may have defined
> > the behavior of the feature incorrectly, provided that you're willing
> > to admit that you're proposing a definition change, not just a bug
> >
On Wed, May 17, 2017 at 6:53 AM, Jeevan Ladhe
wrote:
> As discussed in default partition thread[1], here is the patch to remove
> has_null from PartitionBoundInfoData structure.
> Basically flag has_null is not needed and null_index can be checked if the
> current bound is having a null value or n
The sequence regression tests are failing on Debian/sparc64:
sequence ... FAILED
polymorphism ... ok
rowtypes ... ok
returning... ok
largeobject ... ok
with ... ok
xml
Robert Haas writes:
> Yeah, you have a point. I'm willing to admit that we may have defined
> the behavior of the feature incorrectly, provided that you're willing
> to admit that you're proposing a definition change, not just a bug
> fix.
> Anybody else want to weigh in with an opinion here?
I
Tom Lane wrote:
> Peter Eisentraut writes:
> > On 5/17/17 11:37, Tom Lane wrote:
> >> Concretely, how about the attached? I don't think this looks any
> >> worse than the current layout.
>
> > The previous setup has been in place for years and has never been a
> > problem. The alternatives are
Peter Eisentraut writes:
> On 5/17/17 10:14, Tom Lane wrote:
>> What I was concerned about was that pgindent will reindent the second
>> line so that it's impossible to tell whether the spacing is correct.
> pgindent moving string continuations to the left is a completely
> terrible behavior anyw
Peter Eisentraut writes:
> On 5/17/17 11:37, Tom Lane wrote:
>> Concretely, how about the attached? I don't think this looks any
>> worse than the current layout.
> The previous setup has been in place for years and has never been a
> problem. The alternatives are all quite a bit worse.
No, th
On Wed, May 17, 2017 at 3:06 AM, Tsunakawa, Takayuki
wrote:
> What do you think of the following cases? Don't you want to connect to other
> servers?
>
> * The DBA shuts down the database. The server takes a long time to do
> checkpointing. During the shutdown checkpoint, libpq tries to conne
On Wed, May 17, 2017 at 11:08 AM, Heikki Linnakangas wrote:
> That's not a straight semi-join, but we could still turn it into a new kind
> of LEFT-SEMI join. A left-semi join is like a left join, in that it returns
> all rows from the left side, and NULLs for any non-matches. And like a
> semi-jo
Thomas Munro writes:
> On Wed, May 17, 2017 at 2:39 PM, Tom Lane wrote:
>> Thanks for checking. So that's two major platforms where it works "as
>> expected" already.
> Ah... the reason this is happening is that BSD-derived fread()
> implementations return immediately if the EOF flag is set[1],
2017-05-16 8:17 GMT+02:00 Michael Paquier :
> On Sat, May 13, 2017 at 10:53 AM, Robert Haas
> wrote:
> > On Wed, May 10, 2017 at 10:05 PM, Michael Paquier
> > wrote:
> >> Regarding the patch, this is way to close to the progress facility
> >> already in place. So why don't you extend it for the
On Wed, May 17, 2017 at 8:04 AM, Andrew Dunstan
wrote:
>> When we get to v100, we'll need some other hack to make it work ...
>> but I plan to be safely dead by then.
>
> Me too. Since posterity will be deprived of both of us let's note that
> the same hack will work, we'll just need two underscor
2017-05-13 14:38 GMT+02:00 Amit Kapila :
> On Wed, May 10, 2017 at 10:10 PM, Remi Colinet
> wrote:
> >
> > Parallel queries can also be monitored. The same mecanism is used to
> monitor
> > child workers with a slight difference: the main worker requests the
> child
> > progression directly in or
On 5/17/17 05:15, Masahiko Sawada wrote:
> BTW, why should max_replication_slots be set more than 0 even on the
> subscriber side? It's documented but I could not understand reason.
Because that setting also controls replication origin tracking slots.
--
Peter Eisentraut http://www.
On 5/17/17 10:14, Tom Lane wrote:
> What I was concerned about was that pgindent will reindent the second
> line so that it's impossible to tell whether the spacing is correct.
pgindent moving string continuations to the left is a completely
terrible behavior anyway and we should look into changin
2017-05-13 3:53 GMT+02:00 Robert Haas :
> On Wed, May 10, 2017 at 10:05 PM, Michael Paquier
> wrote:
> > Regarding the patch, this is way to close to the progress facility
> > already in place. So why don't you extend it for the executor?
>
> I don't think that's a good idea. The existing progre
On 5/17/17 11:37, Tom Lane wrote:
> I wrote:
>> BTW, I would say that the problem with -p is that somebody failed to
>> understand the difference between --help and a man page.
>
> Concretely, how about the attached? I don't think this looks any
> worse than the current layout.
The previous setu
I wrote:
> BTW, I would say that the problem with -p is that somebody failed to
> understand the difference between --help and a man page.
Concretely, how about the attached? I don't think this looks any
worse than the current layout.
regards, tom lane
diff --git a/src/b
Hi,
I spent some time staring at TPC-DS benchmark's query 6. It contains a
somewhat complicated subquery, and most of the time spent on that query
is currently spent on executing the subquery again and again. The
essence of the query boils down to this:
CREATE TABLE foo (i int4, j int4);
CRE
On 5/16/17, 11:21 PM, "Michael Paquier" wrote:
> On Wed, May 17, 2017 at 7:56 AM, Bossart, Nathan wrote:
>> I think this issue already exists, as this comment in get_rel_oids(…) seems
>> to indicate:
>>
>> /*
>> * Since we don't take a lock here, the relation might be gone, or the
>>
Alvaro Herrera писал 2017-05-15 20:13:
As I understand, these patches are logically separate, so putting them
together in a single file isn't such a great idea. If you don't edit
the patches further, then you're all set because we already have the
previously archived patches. Next commitfest st
Alvaro Herrera writes:
>> ... Particularly in pg_waldump's -p, where a
>> phrase is now cut in the middle.
BTW, I would say that the problem with -p is that somebody failed to
understand the difference between --help and a man page. That entry
should be
-p, --path=PATHdirectory in whi
Alvaro Herrera writes:
> There are some changes here that should be reverted; for instance:
> - printf(_(" -c, --checkpoint=fast|spread\n"
> -" set fast or spread checkpointing\n"));
> + printf(_(" -c, --checkpoint=fast|spread\n"));
> + printf(_("
Tom Lane wrote:
> src/bin/pg_basebackup/pg_basebackup.c | 24 +-
> src/bin/pg_waldump/pg_waldump.c| 18 ++---
There are some changes here that should be reverted; for instance:
- printf(_(" -c, --checkpoint=fast|spread\n"
-"
On Wed, May 17, 2017 at 2:07 PM, amul sul wrote:
>
>> In partition_bounds_equal(), please add comments explaining why is it safe to
>> check just the indexes? May be we should add code under assertion to make
>> sure
>> that the datums are equal as well.
>
> Added assert in the attached version.
On Wed, May 17, 2017 at 2:41 PM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 5/16/17 22:37, Tom Lane wrote:
> > BTW, I now remember having wondered[2] if we should make any other
> changes
> > in version-number formatting while we're at it, like maybe "10beta1"
> > should be "
On 5/16/17 22:37, Tom Lane wrote:
> BTW, I now remember having wondered[2] if we should make any other changes
> in version-number formatting while we're at it, like maybe "10beta1"
> should be "10.beta1".
That's not a naming format I've ever seen.
I think the current format is fine.
--
Peter E
On 05/16/2017 10:37 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 5/16/17 18:14, pg...@postgresql.org wrote:
>>> Tag refs/tags/REL_10_BETA1 was created.
>> Was this change in naming pattern intentional?
> Yes, it was. Andrew Dunstan suggested[1] during the
> two-part-version-number discu
On Wed, May 17, 2017 at 12:06 PM, Dilip Kumar wrote:
> On Fri, May 12, 2017 at 4:17 PM, Amit Khandekar
> wrote:
> > Option 3
> >
> >
> > BR, AR delete triggers on source partition
> > BR, AR insert triggers on destination partition.
> >
> > Rationale :
> > Since the update is converted
1 - 100 of 122 matches
Mail list logo
