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 definitely incorrect. Any query string in

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 argument. I have been looking at the

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. Thanks for looking at this! > ..

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 21:11, Ashutosh Bapat wrote: > >> > On Tue, May 16, 2017 at 5:35 PM, Ildus Kurbangalie

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 patch on latest commit. > > +boolhas_defau

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 wrote: On 2017/05/16 21:11, Ashutosh Bapat wrote: On Tue, May 16, 2017 at 5

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 messages if it's valid. >>> I'd like to propose it for PG10 if possible,

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 adjustments due to recent commit. >>> I have re-based the patc

Re: [HACKERS] Increasing parallel workers at runtime

On Wed, May 17, 2017 at 5:45 AM, Haribabu Kommi wrote: > > > On Wed, May 17, 2017 at 2:35 AM, Robert Haas wrote: >> > > > Ok. In this approach, we need to share some of the gatherstate structure > members in the shared memory to access by the other background process > or some better logic to upd

Re: [HACKERS] Increasing parallel workers at runtime

On Tue, May 16, 2017 at 2:14 PM, Ashutosh Bapat wrote: > On Mon, May 15, 2017 at 9:23 PM, Robert Haas wrote: > > Also, looking at the patch, it doesn't look like it take enough care > to build execution state of new worker so that it can participate in a > running query. I may be wrong, but the e

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

On Wed, May 17, 2017 at 2:28 PM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> 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 adjustme

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

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. >> >> Rationale : >> Since the update is converted to delet

Re: [HACKERS] UPDATE of partition key

On Mon, May 15, 2017 at 5:28 PM, Robert Haas wrote: > On Fri, May 12, 2017 at 3:07 AM, Amit Kapila wrote: >> I agree with you that it might not be straightforward to make it work, >> but now that earliest it can go is v11, do we want to try doing >> something other than just documenting it. What

Re: [HACKERS] UPDATE of partition key

On Wed, May 17, 2017 at 3:15 PM, Amit Kapila wrote: >> Earlier I thought that option1 is better but later I think that this >> can complicate the situation as we are firing first BR update then BR >> delete and can change the row multiple time and defining such >> behaviour can be complicated. >>

Re: [HACKERS] [POC] hash partitioning

On Wed, May 17, 2017 at 11:11 AM, Ashutosh Bapat wrote: > On Wed, May 17, 2017 at 12:04 AM, amul sul wrote: >> On Tue, May 16, 2017 at 10:00 PM, Dilip Kumar wrote: >>> On Tue, May 16, 2017 at 4:22 PM, amul sul wrote: v6 patch has bug in partition oid mapping and indexing, fixed in the

[HACKERS] remove unnecessary flag has_null from PartitionBoundInfoData

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

Re: [HACKERS] statement_timeout is not working as expected with postgres_fdw

On Tue, May 16, 2017 at 9:39 PM, Robert Haas wrote: > On Sun, May 7, 2017 at 11:54 AM, Robert Haas wrote: >> I'm having second thoughts based on some more experimentation I did >> this morning. I'll update again once I've had a bit more time to poke >> at it. > > So the issue that I noticed here

Re: [HACKERS] Get stuck when dropping a subscription during synchronizing table

On Mon, May 15, 2017 at 8:02 PM, Kyotaro HORIGUCHI wrote: > Hello, > > At Fri, 12 May 2017 17:24:07 +0900, Masahiko Sawada > wrote in >> On Fri, May 12, 2017 at 11:24 AM, Masahiko Sawada >> wrote: >> > On Thu, May 11, 2017 at 6:16 PM, Petr Jelinek >> > wrote: >> >> On 11/05/17 10:10, Masahik

Re: [HACKERS] UPDATE of partition key

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 would that work? -- Robert Haas EnterpriseDB: http://www.enterp

Re: [HACKERS] Increasing parallel workers at runtime

On Tue, May 16, 2017 at 8:15 PM, Haribabu Kommi wrote: > Ok. In this approach, we need to share some of the gatherstate structure > members in the shared memory to access by the other background process > or some better logic to update these details whenever a new worker gets > allotted. What I'm

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. > > > > Rationale : > > Since the update is converted

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

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

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

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

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

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 "

Re: [HACKERS] [POC] hash partitioning

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.

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

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

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

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(_("

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

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

Re: [HACKERS] Small improvement to compactify_tuples

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

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 lock here, the relation might be gone, or the >>

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

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 a/src/b

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 setu

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 don't think that's a good idea. The existing progre

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 changin

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 http://www.

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 requests the > child > > progression directly in or

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 work, we'll just need two underscor

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 the progress facility > >> already in place. So why don't you extend it for the

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() > implementations return immediately if the EOF flag is set[1],

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. And like a > semi-jo

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 checkpoint, libpq tries to conne

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 are all quite a bit worse. No, th

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 completely > terrible behavior anyw

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 > > problem. The alternatives are

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 with an opinion here? I

[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] 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 bound is having a null value or n

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 change, not just a bug > >

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 Lane wrote: > > Surafel T

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 blacklist of >> SQLST

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 a definition change, not just a bug >> fix.

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 question while we discuss it. Ch

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 su

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 failure earlier in

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] [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 design and >> nobody

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

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 fix

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. Messing with pgindent didn't seem

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 server takes a long time to do >> chec

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: [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 as pg_dump's help() too. >

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 ignored

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 to a partition by n

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. Well, that's not very good termi

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 -- Sent via pgsql-hacke

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 > > to our preferences. > > Mes

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 start from. +1. T

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 added -X to psql invocations in t

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 our repo, and patch it >> to o

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 every place where > you are currently allowed

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 sour

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 >> around another 150K of sour

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 make_partition_op_expr, that > takes keyn

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 want to be carrying >

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: [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 attached a reproducing case.

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 the naming problem. > >> Hmm, yeah, something like that could b

[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: 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. I propose we take that inden

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 recommendations for the switches to use

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 -bl -d0 -cdb -nce -nfc1 -di12 -

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 and set its options like this

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

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 returns >> all rows from the left side, a

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 continuati

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

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 100K lines :-( which I will not p

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 this more consistently than t

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 above, IOW, as follows: >> >> /* Partitioned table. */ >>

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: > > > https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=calliphoridae&dt=2017-05-16%2023:16:53&stg=typedefs > > > > Y

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 mor

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 09:54:29 2016 -0400 > > postgres_fdw: Push down

[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 in ExecInitMergeAppend () >>>

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

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 >> partitioning constraints, introduced a func

  1   2   >