Re: [HACKERS] Pulling up more complicated subqueries

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.

Re: [HACKERS] Disallowing multiple queries per PQexec()

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

Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.

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

Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur

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

Re: [HACKERS] [PATCH v2] Progress command to monitor progression of long running SQL queries

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

Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur

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

Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur

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

Re: [HACKERS] 10beta1 sequence regression failure on sparc64

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

[HACKERS] Pulling up more complicated subqueries

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);

Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur

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

Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur

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

Re: [HACKERS] remove unnecessary flag has_null from PartitionBoundInfoData

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

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

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

Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.

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

Re: [HACKERS] [COMMITTERS] pgsql: Tag refs/tags/REL_10_BETA1 was created

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

Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.

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

Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.

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

[HACKERS] 10beta1 sequence regression failure on sparc64

The sequence regression tests are failing on Debian/sparc64: sequence ... FAILED polymorphism ... ok rowtypes ... ok returning... ok largeobject ... ok with ... ok xml

Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.

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

Re: [HACKERS] [PATCH v2] Progress command to monitor progression of long running SQL queries

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

Re: [HACKERS] Improvement in log message of logical replication worker

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

Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.

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

Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.

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

Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur

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

Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur

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

Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.

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

Re: [HACKERS] [PATCH v2] Progress command to monitor progression of long running SQL queries

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

Re: [HACKERS] COPY FROM STDIN behaviour on end-of-file

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() >

pgindent (was Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)

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.

Re: pgindent (was Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)

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

Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur

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 > >

Re: pgindent (was Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)

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 > >

Re: [HACKERS] Hash Functions

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

Re: [HACKERS] Hash Functions

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

[HACKERS] 10beta1/m68k: static assertion failed: "MAXALIGN too small to fit int32"

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

Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.

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

Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur

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

Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.

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

Re: [HACKERS] fix hard-coded index in make_partition_op_expr

On Thu, May 18, 2017 at 12:13 AM, Robert Haas wrote: > > Agreed. Committed your patch. > Thanks Robert!

[HACKERS] postgres_fdw aggregation pushdown has collation change in 10beta.

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

Re: pgindent (was Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)

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.

Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.

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

Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.

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

Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.

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 --

Re: [HACKERS] [POC] hash partitioning

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.

Re: [HACKERS] PROVE_FLAGS

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

Re: pgindent (was Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)

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 >>

Re: [HACKERS] Hash Functions

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

pgindent (was Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)

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

Re: pgindent (was Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)

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

Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur

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

Re: [HACKERS] remove unnecessary flag has_null from PartitionBoundInfoData

> 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.

Re: pgindent (was Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)

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

Re: [HACKERS] fix hard-coded index in make_partition_op_expr

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

Re: pgindent (was Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)

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 >

Re: pgindent (was Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)

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

Re: [HACKERS] Pulling up more complicated subqueries

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

Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.

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

Re: [HACKERS] transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

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

[HACKERS] Re: Event triggers + table partitioning cause server crash in current master

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

Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.

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 >

Re: [HACKERS] PG10 pgindent run

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: > > >

Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.

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

Re: pgindent (was Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)

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

Re: [HACKERS] Server Crashes if try to provide slot_name='none' at the time of creating subscription.

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

Re: [HACKERS] Race conditions with WAL sender PID lookups

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 >

Re: [HACKERS] fix hard-coded index in make_partition_op_expr

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 >>

Re: [HACKERS] [POC] hash partitioning

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

Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur

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

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

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

Re: [HACKERS] Disallowing multiple queries per PQexec()

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

Re: [HACKERS] 10beta1 sequence regression failure on sparc64

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.)

Re: [HACKERS] Hash Functions

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. >

Re: [HACKERS] Improvement in log message of logical replication worker

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

[HACKERS] Re: [BUGS] BUG #14657: Server process segmentation fault in v10, May 10th dev snapshot

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

Re: [HACKERS] postgres_fdw aggregation pushdown has collation change in 10beta.

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

Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur

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

Re: [HACKERS] Server Crashes if try to provide slot_name='none' at the time of creating subscription.

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

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

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

Re: [HACKERS] Race conditions with WAL sender PID lookups

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 >

Re: [HACKERS] Improvement in log message of logical replication worker

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

Re: [HACKERS] Improvement in log message of logical replication worker

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] UPDATE of partition key

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 to delete+insert, just skip the update > triggers

Re: [HACKERS] synchronous_commit option is not visible after pressing TAB

On Wed, May 17, 2017 at 11:21 AM, Peter Eisentraut wrote: > On 5/16/17 19:45, Michael Paquier wrote: >> On Tue, May 16, 2017 at 8:18 PM, tushar >> wrote: >>> While creating subscription - if we press TAB button to see the

Re: [HACKERS] transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

On 2017/05/17 11:22, Thomas Munro wrote: > On Wed, May 17, 2017 at 10:13 AM, Kevin Grittner wrote: >> On Tue, May 16, 2017 at 4:50 PM, Thomas Munro >> wrote: >>> >>> I'm about to post a much simpler patch that collects uniform tuples >>> from

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

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 > * RangeVar might no longer

Re: [HACKERS] Bug in ExecModifyTable function and trigger issues for foreign tables

On Tue, May 16, 2017 at 11:26 PM, Ildus Kurbangaliev wrote: > On Tue, 16 May 2017 21:36:11 +0900 > Etsuro Fujita wrote: >> On 2017/05/16 21:11, Ashutosh Bapat wrote: >> > On Tue, May 16, 2017 at 5:35 PM, Ildus Kurbangaliev >> >

Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur

Hello Robert, Tom, Thank you for being kind enough to explain. I think I could understand your concern. 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 >

Re: [HACKERS] [bug fix] Savepoint-related statements terminates connection

On Fri, Mar 31, 2017 at 9:58 PM, Ashutosh Bapat wrote: > Then the question is why not to allow savepoints as well? For that we > have to fix transaction block state machine. I agree with this argument. I have been looking at the patch, and what it does is

Re: [HACKERS] Hash Functions

On Tue, May 16, 2017 at 8:40 PM, Jeff Davis wrote: > On Mon, May 15, 2017 at 1:04 PM, David Fetter wrote: >> As the discussion has devolved here, it appears that there are, at >> least conceptually, two fundamentally different classes of partition: >> public,

Re: [HACKERS] [bug fix] Savepoint-related statements terminates connection

From: Michael Paquier [mailto:michael.paqu...@gmail.com] > On Fri, Mar 31, 2017 at 9:58 PM, Ashutosh Bapat > wrote: > > Then the question is why not to allow savepoints as well? For that we > > have to fix transaction block state machine. > > I agree with this

Re: [HACKERS] transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

On Wed, May 17, 2017 at 6:04 PM, Amit Langote wrote: > On 2017/05/17 11:22, Thomas Munro wrote: >> Here is that patch. Thoughts? > > I looked at the patch and noticed that there might be some confusion about > what's in the EState.es_root_result_relations array.

Re: [HACKERS] Bug in ExecModifyTable function and trigger issues for foreign tables

On Wed, 17 May 2017 15:28:24 +0900 Michael Paquier wrote: > On Tue, May 16, 2017 at 11:26 PM, Ildus Kurbangaliev > wrote: > > On Tue, 16 May 2017 21:36:11 +0900 > > Etsuro Fujita wrote: > >> On 2017/05/16

Re: [HACKERS] Adding support for Default partition in partitioning

On 2017/05/17 17:58, Ashutosh Bapat wrote: > On Tue, May 16, 2017 at 9:01 PM, Robert Haas wrote: >> On Tue, May 16, 2017 at 8:57 AM, Jeevan Ladhe >> wrote: >>> I have fixed the crash in attached patch. >>> Also the patch needed bit of

[HACKERS] fix hard-coded index in make_partition_op_expr

Hi, 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 keynum as a input parameter to identify the index of the

Re: [HACKERS] UPDATE of partition key

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. >> >>

Re: [HACKERS] Bug in ExecModifyTable function and trigger issues for foreign tables

On 2017/05/17 17:54, Ildus Kurbangaliev wrote: On Wed, 17 May 2017 15:28:24 +0900 Michael Paquier wrote: On Tue, May 16, 2017 at 11:26 PM, Ildus Kurbangaliev wrote: On Tue, 16 May 2017 21:36:11 +0900 Etsuro Fujita

Re: [HACKERS] Improvement in log message of logical replication worker

On Wed, May 17, 2017 at 11:33 AM, Masahiko Sawada wrote: > On Wed, May 17, 2017 at 4:08 AM, Robert Haas wrote: >> On Fri, May 12, 2017 at 12:30 AM, Masahiko Sawada >> wrote: >>> Attached small patch adds relid to these log

Re: [HACKERS] Adding support for Default partition in partitioning

On Tue, May 16, 2017 at 9:01 PM, Robert Haas wrote: > On Tue, May 16, 2017 at 8:57 AM, Jeevan Ladhe > wrote: >> I have fixed the crash in attached patch. >> Also the patch needed bit of adjustments due to recent commit. >> I have re-based the

  1   2   >