Re: [HACKERS] In-core regression tests for replication, cascading, archiving, PITR, etc.

On Thu, Feb 4, 2016 at 5:23 PM, Stas Kelvich wrote: (Please do not top-post, this breaks the thread flow.) > I’ve looked over proposed patch and migrated my shell tests scripts that i’ve > used for testing twophase commits on master/slave to this test framework. >

Re: [HACKERS] 2016-01 Commitfest

On 2016-02-03 12:32:47 -0500, Tom Lane wrote: > Heikki and/or Andres have their names on three of the remaining RFC > patches; it's unlikely any other committer will touch those patches > unless they take their names off. If you want to take over the timestamp patch, please feel free to do so.

Re: [HACKERS] Using quicksort for every external sort run

On Sat, Jan 30, 2016 at 5:29 AM, Robert Haas wrote: >> I meant use "quicksort with spillover" simply because an estimated >> 90%+ of all tuples have already been consumed. Don't consider the >> tuple width, etc. > > Hmm, it's a thought. To be honest, it's a bit annoying

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

On Thu, Feb 4, 2016 at 3:28 PM, Etsuro Fujita wrote: > On 2016/02/04 17:58, Etsuro Fujita wrote: > >> On 2016/02/04 8:00, Robert Haas wrote: >> >>> On Wed, Feb 3, 2016 at 5:56 PM, Robert Haas >>> wrote: >>> On Wed, Feb 3, 2016 at 12:08

Re: [HACKERS] WIP: Detecting SSI conflicts before reporting constraint violations

On Wed, Feb 3, 2016 at 10:48 AM, Robert Haas wrote: > I don't feel qualified to have an opinion on whether this is an > improvement. I'm a little skeptical of changes like this on general > principle because sometimes one clientele wants error A to be reported > rather

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On Tue, Feb 2, 2016 at 7:19 PM, Robert Haas wrote: > > On Mon, Feb 1, 2016 at 12:27 AM, Amit Kapila wrote: > > Fixed. > > This patch doesn't build: > > ./xfunc.sgml:int lwlock_count = 0; > Tabs appear in SGML/XML

Re: [HACKERS] WAL logging problem in 9.4.3?

On 22/10/15 03:56, Michael Paquier wrote: On Wed, Oct 21, 2015 at 11:53 PM, Alvaro Herrera wrote: Heikki Linnakangas wrote: Thanks. For comparison, I wrote a patch to implement what I had in mind. When a WAL-skipping COPY begins, we add an entry for that relation

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

> >If so, my concern is, the helper function probably wouldn't >> extend to the parameterized-foreign-join-path cases, though that >> would work well for the unparameterized-foreign-join-path cases. We >> don't support parameterized-foreign-join paths for 9.6? >> > > If we do

Re: [HACKERS] Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby

On Wed, Feb 3, 2016 at 3:08 PM, Andres Freund wrote: > > On 2016-02-02 10:12:25 +0530, Amit Kapila wrote: > > @@ -8239,7 +8262,7 @@ CreateCheckPoint(int flags) > > if ((flags & (CHECKPOINT_IS_SHUTDOWN | > > CHECKPOINT_END_OF_RECOVERY | > >CHECKPOINT_FORCE)) == 0) > > {

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

On 2016/02/04 17:58, Etsuro Fujita wrote: On 2016/02/04 8:00, Robert Haas wrote: On Wed, Feb 3, 2016 at 5:56 PM, Robert Haas wrote: On Wed, Feb 3, 2016 at 12:08 PM, Ashutosh Bapat wrote: PFA patches with naming conventions similar to

Re: [HACKERS] silent data loss with ext4 / all current versions

On Thu, Feb 4, 2016 at 12:02 PM, Michael Paquier wrote: > On Tue, Feb 2, 2016 at 4:20 PM, Michael Paquier wrote: >> Not wrong, and this leads to the following: >> void rename_safe(const char *old, const char *new, bool isdir, int elevel); >> Controlling elevel is

Re: [HACKERS] Raising the checkpoint_timeout limit

On 2016-02-03 15:07:12 -0600, Jim Nasby wrote: > On 2/2/16 10:10 PM, Robert Haas wrote: > >Now, you could also set such configuration settings in > >a situation where it will not work out well. But that is true of most > >configuration settings. By that argument we should probably raise the

Re: [HACKERS] Raising the checkpoint_timeout limit

On Mon, Feb 1, 2016 at 8:16 PM, Noah Misch wrote: >> I'm not sure what'd actually be a good upper limit. I'd be inclined to >> even go to as high as a week or so. A lot of our settings have >> upper/lower limits that aren't a good idea in general. > > In general, I favor having

Re: [HACKERS] Incorrect formula for SysV IPC parameters

On Wed, Feb 3, 2016 at 12:51 PM, Kyotaro HORIGUCHI wrote: > Hello, I found that the formulas to calculate SEMMNI and SEMMNS > are incorrect in 9.2 and later. > > http://www.postgresql.org/docs/9.5/static/kernel-resources.html > > All of them say that the same

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

> * Is it safe to replace outerjoinpath with its fdw_outerpath the following > way? I think that if the join relation represented by outerjoinpath has > local conditions that can't be executed remotely, we have to keep > outerjoinpath in the path tree; we will otherwise fail to execute the local

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

On Wed, Feb 3, 2016 at 3:31 PM, Etsuro Fujita wrote: > On 2016/01/28 15:20, Rushabh Lathia wrote: > >> On Thu, Jan 28, 2016 at 11:33 AM, Etsuro Fujita >> > wrote: >> >> On 2016/01/27 21:23, Rushabh

Re: [HACKERS] Using quicksort for every external sort run

On Thu, Feb 4, 2016 at 1:46 AM, Peter Geoghegan wrote: > It wasn't my original insight that replacement selection has become > all but obsolete. It took me a while to come around to that point of > view. Nyberg et al may have said it best in 1994, in the Alphasort Paper [1]:

Re: [HACKERS] checkpoints after database start/immediate checkpoints

On 2016-02-03 09:57:00 -0500, Robert Haas wrote: > On Mon, Feb 1, 2016 at 7:43 PM, Andres Freund wrote: > > I wonder if this essentially point at checkpoint_timeout being wrongly > > defined: Currently it means we'll try to finish a checkpoint > >

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

On Thu, Feb 4, 2016 at 11:55 AM, Ashutosh Bapat wrote: > Patches attached with the previous mail. The core patch seemed to me to be in good shape now, so I committed that. Not sure I'll be able to get to another read-through of the main patch today. -- Robert

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On Thu, Feb 4, 2016 at 7:00 AM, Amit Kapila wrote: > [ new patch ] I've committed this after heavy rewriting. In particular, I merged two loops, used local variables to get rid of the very long and quite repetitive lines, and did various cleanup on the documentation and

Re: [HACKERS] UNIQUE capability to hash indexes

Alvaro Herrera writes: > Tom Lane wrote: >> Not that I've heard of. It's very hard to muster any enthusiasm for >> improving hash indexes unless their lack of WAL-logging is fixed first. > This is really strange though. Surely adding WAL-logging is not an > enormous

Re: [HACKERS] "using previous checkpoint record at" maybe not the greatest idea?

David G. Johnston wrote: > ​Learning by reading here... > > http://www.postgresql.org/docs/current/static/wal-internals.html > """ > ​After a checkpoint has been made and the log flushed, the checkpoint's > position is saved in the file pg_control. Therefore, at the start of > recovery, the

Re: [HACKERS] insufficient qualification of some objects in dump files

Peter Eisentraut wrote: > Some dump objects whose names are not unique on a schema level have > insufficient details in the dump TOC. For example, a column default > might have a TOC entry like this: > > 2153; 2604 39696 DEFAULT public a rolename > I think we should amend the archive tag for

Re: [HACKERS] "using previous checkpoint record at" maybe not the greatest idea?

On Thu, Feb 4, 2016 at 3:57 PM, Alvaro Herrera wrote: > David G. Johnston wrote: > > > ​Learning by reading here... > > > > http://www.postgresql.org/docs/current/static/wal-internals.html > > """ > > ​After a checkpoint has been made and the log flushed, the

Re: [HACKERS] checkpoints after database start/immediate checkpoints

On Thu, Feb 4, 2016 at 4:42 PM, Andres Freund wrote: > On 2016-02-03 09:57:00 -0500, Robert Haas wrote: >> On Mon, Feb 1, 2016 at 7:43 PM, Andres Freund wrote: >> > I wonder if this essentially point at checkpoint_timeout being wrongly >> > defined:

Re: [HACKERS] UNIQUE capability to hash indexes

On 02/04/2016 11:34 PM, Tom Lane wrote: Alvaro Herrera writes: This is really strange though. Surely adding WAL-logging is not an enormous task anymore ... I mean, we're undertaking far larger efforts now, the WAL logging code is simpler than before, and we even have

Re: [HACKERS] UNIQUE capability to hash indexes

Tom Lane wrote: > Shubham Barai writes: > > I wanted to know if anyone is working on these projects from todo list. > > 1.Add UNIQUE capability to hash indexes > > 2.Allow multi-column hash indexes > > Not that I've heard of. It's very hard to muster any enthusiasm for

Re: [HACKERS] "using previous checkpoint record at" maybe not the greatest idea?

On 2016-02-03 09:28:24 -0500, Robert Haas wrote: > Would we still have some way of forcing the older checkpoint record to > be used if somebody wants to try to do that? I think currently the best way to force an arbitrary checkpoint to be used is creating a "custom" backup label. Not that nice.

Re: [HACKERS] count_nulls(VARIADIC "any")

Pavel Stehule writes: > [ num_nulls_v6.patch ] I started looking through this. It seems generally okay, but I'm not very pleased with the function name "num_notnulls". I think it would be better as "num_nonnulls", as I see Oleksandr suggested already.

Re: [HACKERS] Development with Eclipse - Wrong error messages in IDE

Peter Moser wrote: > I have some strange error message inside Eclipse, that some symbols cannot > be found. I work with version 9.6 currently. For instance, > > Symbol 'RM_HEAP_ID' could not be resolved > src/backend/access/heap/heapam.c > > It affects all occurrences of symbols that are

Re: [HACKERS] Support for N synchronous standby servers - take 2

Hello, At Thu, 4 Feb 2016 23:06:45 +0300, Michael Paquier wrote in

Re: [HACKERS] Batch update of indexes

On 2/4/16 1:37 AM, konstantin knizhnik wrote: >My suspicion is that it would be useful to pre-order the new data before trying to apply it to the indexes. Sorry, but ALTER INDEX is expected to work for all indexes, not only B-Tree, and for them sorting may not be possible... But for B-Tree

Re: [HACKERS] "using previous checkpoint record at" maybe not the greatest idea?

On February 5, 2016 2:52:20 AM GMT+03:00, Jim Nasby wrote: >On 2/4/16 3:37 PM, Andres Freund wrote: >> On 2016-02-03 09:28:24 -0500, Robert Haas wrote: >>> Would we still have some way of forcing the older checkpoint record >to >>> be used if somebody wants to try to do

Re: [HACKERS] In-core regression tests for replication, cascading, archiving, PITR, etc.

On Thu, Feb 4, 2016 at 11:58 PM, Stas Kelvich wrote: >> On 04 Feb 2016, at 12:59, Michael Paquier wrote: >>> 0) There are several routines that does actual checking, like >>> is/command_ok/command_fails. I think it will be very handy to have

Re: [HACKERS] "using previous checkpoint record at" maybe not the greatest idea?

On 2/4/16 5:09 PM, David G. Johnston wrote: What the 2nd para in the documentation is saying is something different: it is talking about reading all the pg_xlog files (in reverse order), which is not pg_control, and see what checkpoint records are there, then figure out which

Re: [HACKERS] "using previous checkpoint record at" maybe not the greatest idea?

On 2/4/16 3:37 PM, Andres Freund wrote: On 2016-02-03 09:28:24 -0500, Robert Haas wrote: Would we still have some way of forcing the older checkpoint record to be used if somebody wants to try to do that? I think currently the best way to force an arbitrary checkpoint to be used is creating a

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On 2/4/16 3:13 AM, Catalin Iacob wrote: Thanks for the overview. Very helpful. I find existing behaviour for 2, 3 and 4 unlike other Python APIs I've seen, surprising and not very useful. If I want to log a tuple I can construct and pass a single tuple, I don't see why plpy.info() needs to

Re: [HACKERS] Way to check whether a particular block is on the shared_buffer?

On 2/4/16 12:30 AM, Kouhei Kaigai wrote: >> 2. A feature to suspend i/o write-out towards a particular blocks >> >that are registered by other concurrent backend, unless it is not >> >unregistered (usually, at the end of P2P DMA). >> >==> to be discussed. I think there's still a race

[HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Thu, Feb 04, 2016 at 09:13:46PM +0300, Victor Wagner wrote: > On Thu, 4 Feb 2016 18:33:27 +0300 Michael Paquier > wrote: > > > Really, it is not so hard to add configure checks for perl modules. > > > And we need to test not only for IPC::Run, but for Test::More

Re: [HACKERS] pgcommitfest reply having corrupted subject line

On Thu, Feb 04, 2016 at 09:19:19AM +0100, Magnus Hagander wrote: > On Thu, Feb 4, 2016 at 7:26 AM, Noah Misch wrote: > > The following message, which bears "User-Agent: pgcommitfest", > > > > > >

Re: [HACKERS] UNIQUE capability to hash indexes

Tom Lane wrote: > Alvaro Herrera writes: > > Tom Lane wrote: > >> Not that I've heard of. It's very hard to muster any enthusiasm for > >> improving hash indexes unless their lack of WAL-logging is fixed first. > > > This is really strange though.

Re: [HACKERS] proposal: multiple psql option -c

On 12/29/15 10:38 AM, Bruce Momjian wrote: > On Thu, Dec 10, 2015 at 11:10:55AM -0500, Robert Haas wrote: >> On Wed, Dec 9, 2015 at 12:15 AM, Pavel Stehule >> wrote: On Wed, Dec 9, 2015 at 2:07 PM, Pavel Stehule wrote: > should be

Re: [HACKERS] 2016-01 Commitfest

Hello Andres, I'm working on/off on the checkpointer flushing thing, so I don't think it makes sense for somebody else to take that over at this point. Yep. I still wish you could share your current working version? The last version sent is from November 11th, and I think someone said that

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 4 February 2016 at 14:34, Fujii Masao wrote: > On Wed, Feb 3, 2016 at 11:00 AM, Robert Haas wrote: >> On Tue, Feb 2, 2016 at 8:48 PM, Fujii Masao wrote: >>> So you disagree with only third version that I proposed, i.e., >>>

Re: [HACKERS] Idle In Transaction Session Timeout, revived

On Sun, Jan 31, 2016 at 10:33 PM, Vik Fearing wrote: > Attached is a rebased and revised version of my > idle_in_transaction_session_timeout patch from last year. > > This version does not suffer the problems the old one did where it would > jump out of SSL code thanks to

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

On Tue, Feb 2, 2016 at 3:59 AM, Thom Brown wrote: > public | pgbench_accounts_pkey | index | thom | pgbench_accounts | 214 MB | > public | pgbench_branches_pkey | index | thom | pgbench_branches | 24 kB | > public | pgbench_tellers_pkey | index | thom | pgbench_tellers |

Re: [HACKERS] Idle In Transaction Session Timeout, revived

David Steele wrote: > > <...> But what I think really happens is > > some badly-written Java application loses track of a connection > > someplace and just never finds it again. <...> I've seen that also, plenty of times. > That's what I've seen over and over again. And then sometimes it's not

Re: [HACKERS] In-core regression tests for replication, cascading, archiving, PITR, etc.

On Thu, 4 Feb 2016 12:59:03 +0300 Michael Paquier wrote: for it? > > > 1) Better to raise more meaningful error when IPC::Run is absent. > > This has been discussed before, and as far as I recall the current > behavior has been concluded as being fine. That's

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Wed, Feb 3, 2016 at 11:00 AM, Robert Haas wrote: > On Tue, Feb 2, 2016 at 8:48 PM, Fujii Masao wrote: >> So you disagree with only third version that I proposed, i.e., >> adding some hooks for sync replication? If yes and you're OK >> with the

Re: [HACKERS] Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby

On Thu, Feb 4, 2016 at 6:40 PM, Andres Freund wrote: > > On 2016-02-04 18:21:41 +0530, Amit Kapila wrote: > > I think generally it is good idea, but one thing worth a thought is that > > by doing so, we need to acquire all WAL Insertion locks every > > LOG_SNAPSHOT_INTERVAL_MS

Re: [HACKERS] Idle In Transaction Session Timeout, revived

On 2/4/16 5:00 AM, Alvaro Herrera wrote: > David Steele wrote: > >>> <...> But what I think really happens is >>> some badly-written Java application loses track of a connection >>> someplace and just never finds it again. <...> > > I've seen that also, plenty of times. > >> That's what I've

Re: [HACKERS] pg_dump data structures for triggers

Vik Fearing writes: > On 02/04/2016 01:44 AM, Tom Lane wrote: >> I'm looking into fixing the problem reported here: >> http://www.postgresql.org/message-id/1445a624-d09f-4b51-9c41-46ba1e2d6...@neveragain.de >> namely that if we split a view into a table + rule (because of

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

On Thu, Feb 4, 2016 at 11:55 AM, Ashutosh Bapat wrote: > A query with FOR UPDATE/SHARE will be considered parallel unsafe in > has_parallel_hazard_walker() and root->glob->parallelModeOK will be marked > false. This implies that none of the base relations and

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

On 2016/02/04 19:44, Rushabh Lathia wrote: I just started reviewing this and realized that patch is not getting applied cleanly on latest source, it having some conflicts. Can you please upload the correct version of patch. I rebased the patch to the latest HEAD. Attached is a rebased version

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On Fri, Feb 5, 2016 at 3:17 AM, Robert Haas wrote: > > On Thu, Feb 4, 2016 at 7:00 AM, Amit Kapila wrote: > > [ new patch ] > > I've committed this after heavy rewriting. In particular, I merged > two loops, used local variables to get rid of the

Re: [HACKERS] Way to check whether a particular block is on the shared_buffer?

> -Original Message- > From: Jim Nasby [mailto:jim.na...@bluetreble.com] > Sent: Friday, February 05, 2016 9:17 AM > To: Kaigai Kouhei(海外 浩平); pgsql-hackers@postgresql.org; Robert Haas > Cc: Amit Langote > Subject: Re: [HACKERS] Way to check whether a particular block is on the >

Re: [HACKERS] pg_hba_lookup function to get all matching pg_hba.conf entries

On Tue, Feb 2, 2016 at 8:57 AM, Alvaro Herrera wrote: > Haribabu Kommi wrote: > >> Hi, Do you have any further comments on the patch that needs to be >> taken care? > > I do. I think the jsonb functions you added should be added to one of > the json .c files instead,

Re: Odd behavior in foreign table modification (Was: Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW)

On Thu, Jan 28, 2016 at 7:36 AM, Etsuro Fujita wrote: > Attached is that version of the patch. > > I think that postgres_fdw might be able to insert a tableoid value in the > returned slot in e.g., postgresExecForeignInsert if AFTER ROW Triggers or > RETURNING

Re: [HACKERS] Way to check whether a particular block is on the shared_buffer?

> On 2/4/16 12:30 AM, Kouhei Kaigai wrote: > >> 2. A feature to suspend i/o write-out towards a particular blocks > >> >that are registered by other concurrent backend, unless it is not > >> >unregistered (usually, at the end of P2P DMA). > >> >==> to be discussed. > > I think there's

Re: [HACKERS] count_nulls(VARIADIC "any")

I wrote: > Pavel Stehule writes: >> [ num_nulls_v6.patch ] > I started looking through this. It seems generally okay, but I'm not > very pleased with the function name "num_notnulls". I think it would > be better as "num_nonnulls", as I see Oleksandr suggested already.

Re: [HACKERS] count_nulls(VARIADIC "any")

Dne 5. 2. 2016 1:33 napsal uživatel "Tom Lane" : > > Pavel Stehule writes: > > [ num_nulls_v6.patch ] > > I started looking through this. It seems generally okay, but I'm not > very pleased with the function name "num_notnulls". I think it would > be

Re: [HACKERS] Incorrect formula for SysV IPC parameters

At Thu, 4 Feb 2016 21:43:04 +0900, Fujii Masao wrote in > On Wed, Feb 3, 2016 at 12:51 PM, Kyotaro HORIGUCHI > wrote: > > Hello, I found that the formulas to calculate

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Thu, Feb 4, 2016 at 9:34 AM, Fujii Masao wrote: > Now I'm thinking that mini-language is better choice. A json has some good > points, but its big problem is that the setting value is likely to be very > long. > For example, when the master needs to wait for one local

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

On Thu, Feb 4, 2016 at 8:25 AM, Thom Brown wrote: > > No, I'm not. I've just realised that all I've been checking is the > primary key expecting it to change in size, which is, of course, > nonsense. I should have been creating an index on the bid field of > pgbench_accounts and

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Hi I tested last version, v11 and I have not any objection It is working as expected all regress tests passed, there is related documentation and new test is attached. This patch is ready form commiter. Daniel, thank you very much, it is interesting feature. Regards Pavel

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

Hello, I'm studying this. Two hunks in 0003 needed a fix but the other part applied cleanly on master. At Fri, 22 Jan 2016 15:17:51 +0900, Michael Paquier wrote in

Re: [HACKERS] Generalizing SortSupport for text to work with char(n), bytea, and alternative opclasses

On Sun, Jan 31, 2016 at 7:59 PM, Andreas Karlsson wrote: > Nice work, I like your sorting patches. Thanks. I like your reviews of my sorting patches. :-) -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Tue, Feb 2, 2016 at 11:52 PM, Alvaro Herrera wrote: > Robert Haas wrote: >> The eventual committer is likely to be much happier with this patch if >> you guys have achieved consensus among yourselves on the best >> approach. > > Actually I imagine that if there's no

[HACKERS] Comment typo in slot.c

Hi all, I just bumped into the following typo in slot.c: /* * If we'd now fail - really unlikely - we wouldn't know whether this slot * would persist after an OS crash or not - so, force a restart. The -* restart would try to fysnc this again till it works. +

Re: [HACKERS] [REVIEW] In-core regression tests for replication, cascading, archiving, PITR, etc.

On Thu, Feb 4, 2016 at 9:18 PM, Victor Wagner wrote: > It's quite good that patch sets standard of using 'use strict; use > warnings;' in the test script. FWIW, this is decided as being a standard rule for any modules/script added in the main tree. > It is bad, that Postgres-specific perl

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Thu, Feb 4, 2016 at 7:27 PM, Robert Haas wrote: > I don't in the end care very much about how we solve this problem. > But I'm glad you agree that whatever we do to solve the simple problem > should be a logical subset of what the full solution will eventually > look

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Thu, Feb 4, 2016 at 2:21 PM, Michael Paquier wrote: > Yes, please let's use the custom language, and let's not care of not > more than 1 level of nesting so as it is possible to represent > pg_stat_replication in a simple way for the user. "not" is used twice in

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

On Thu, Feb 4, 2016 at 4:30 AM, Robert Haas wrote: > On Wed, Feb 3, 2016 at 5:56 PM, Robert Haas wrote: > > On Wed, Feb 3, 2016 at 12:08 PM, Ashutosh Bapat > > wrote: > >> PFA patches with naming conventions similar

Re: [HACKERS] Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby

On 2016-02-04 18:21:41 +0530, Amit Kapila wrote: > I think generally it is good idea, but one thing worth a thought is that > by doing so, we need to acquire all WAL Insertion locks every > LOG_SNAPSHOT_INTERVAL_MS to check the last_insert_pos for > every slot, do you think it is matter of concern

Re: [HACKERS] Idle In Transaction Session Timeout, revived

On 02/04/2016 02:24 PM, Fujii Masao wrote: > On Sun, Jan 31, 2016 at 10:33 PM, Vik Fearing wrote: >> Attached is a rebased and revised version of my >> idle_in_transaction_session_timeout patch from last year. >> >> This version does not suffer the problems the old one did

Re: [HACKERS] pgbench stats per script & other stuff

Hello Alvaro, Something is wrong with patch d. I noticed two things, 1. the total_weight stuff can overflow, It can generate an error on overflow by checking the total_weight while it is being computed. I've switched total_weight to int64 so it is now really impossible to overflow with

Re: [HACKERS] In-core regression tests for replication, cascading, archiving, PITR, etc.

On Thu, Feb 4, 2016 at 4:43 PM, Victor Wagner wrote: > On Thu, 4 Feb 2016 12:59:03 +0300 > Michael Paquier wrote: >> > 1) Better to raise more meaningful error when IPC::Run is absent. >> >> This has been discussed before, and as far as I recall the

Re: [HACKERS] Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby

On Thu, Feb 4, 2016 at 4:10 PM, Andres Freund wrote: > On 2016-02-04 18:21:41 +0530, Amit Kapila wrote: >> I think generally it is good idea, but one thing worth a thought is that >> by doing so, we need to acquire all WAL Insertion locks every >> LOG_SNAPSHOT_INTERVAL_MS to

Re: [HACKERS] checkpointer continuous flushing - V16

Hi, Fabien asked me to post a new version of the checkpoint flushing patch series. While this isn't entirely ready for commit, I think we're getting closer. I don't want to post a full series right now, but my working state is available on

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

On 4 February 2016 at 15:07, Peter Geoghegan wrote: > On Tue, Feb 2, 2016 at 3:59 AM, Thom Brown wrote: >> public | pgbench_accounts_pkey | index | thom | pgbench_accounts | 214 MB | >> public | pgbench_branches_pkey | index | thom | pgbench_branches | 24 kB

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

On Fri, Jan 29, 2016 at 8:50 AM, Anastasia Lubennikova wrote: > I fixed it in the new version (attached). Some quick remarks on your V2.0: * Seems unnecessary that _bt_binsrch() is passed a real pointer by all callers. Maybe the one current posting list caller

Re: [HACKERS] UNIQUE capability to hash indexes

Shubham Barai writes: > I wanted to know if anyone is working on these projects from todo list. > 1.Add UNIQUE capability to hash indexes > 2.Allow multi-column hash indexes Not that I've heard of. It's very hard to muster any enthusiasm for improving hash indexes

Re: [HACKERS] UNIQUE capability to hash indexes

On 2/4/16 1:12 PM, Tom Lane wrote: > Shubham Barai writes: >> I wanted to know if anyone is working on these projects from todo list. >> 1.Add UNIQUE capability to hash indexes >> 2.Allow multi-column hash indexes > > Not that I've heard of. It's very hard to muster

[HACKERS] UNIQUE capability to hash indexes

Hello hackers , I wanted to know if anyone is working on these projects from todo list. 1.Add UNIQUE capability to hash indexes 2.Allow multi-column hash indexes I couldn't find any discussion about these projects. Thanks, Shubham Barai

Re: [HACKERS] In-core regression tests for replication, cascading, archiving, PITR, etc.

On Thu, 4 Feb 2016 18:33:27 +0300 Michael Paquier wrote: > > Really, it is not so hard to add configure checks for perl modules. > > And we need to test not only for IPC::Run, but for Test::More too, > > because some Linux distributions put modules which come with

Re: [HACKERS] [REVIEW] In-core regression tests for replication, cascading, archiving, PITR, etc.

This patch adds a long-awaited functionality to the PostgreSQL test suite - testing of cluster configuration. It contains bare minimum of replication and recovery test, but it should be a good starting point for other people. Really, adding a much more tests for replication and recovery is

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Thu, Feb 4, 2016 at 2:49 PM, Michael Paquier wrote: > On Thu, Feb 4, 2016 at 10:40 PM, Robert Haas wrote: >> On Thu, Feb 4, 2016 at 2:21 PM, Michael Paquier >> wrote: >>> Yes, please let's use the custom language,

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Thu, Feb 4, 2016 at 10:49 PM, Michael Paquier wrote: > On Thu, Feb 4, 2016 at 10:40 PM, Robert Haas wrote: >> On Thu, Feb 4, 2016 at 2:21 PM, Michael Paquier >> wrote: >>> Yes, please let's use the custom language,

Re: [HACKERS] Idle In Transaction Session Timeout, revived

On 2016-02-04 22:24:50 +0900, Fujii Masao wrote: > But, IIRC, one of the problems that prevent the adoption of this feature is > the addition of gettimeofday() call after every SQL command receipt. > Have you already resolved that problem? Or we don't need to care about > it because it's almost

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Thu, Feb 4, 2016 at 10:40 PM, Robert Haas wrote: > On Thu, Feb 4, 2016 at 2:21 PM, Michael Paquier > wrote: >> Yes, please let's use the custom language, and let's not care of not >> more than 1 level of nesting so as it is possible to

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

On 2016/01/29 17:52, Ashutosh Bapat wrote: On Fri, Jan 29, 2016 at 2:05 PM, Etsuro Fujita > wrote: On 2016/01/29 1:26, Ashutosh Bapat wrote: Here is the summary of changes from the last set of patches 2.

Re: [HACKERS] pgcommitfest reply having corrupted subject line

On Thu, Feb 4, 2016 at 7:26 AM, Noah Misch wrote: > The following message, which bears "User-Agent: pgcommitfest", > > > http://www.postgresql.org/message-id/flat/20160202164101.1291.30526.p...@coridan.postgresql.org > > added spaces after commas in its subject line, compared

Re: [HACKERS] In-core regression tests for replication, cascading, archiving, PITR, etc.

Hi. I’ve looked over proposed patch and migrated my shell tests scripts that i’ve used for testing twophase commits on master/slave to this test framework. Everything looks mature, and I didn’t encountered any problems with writing new tests using this infrastructure. >From my point of view I

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

On 2016/02/04 8:00, Robert Haas wrote: On Wed, Feb 3, 2016 at 5:56 PM, Robert Haas wrote: On Wed, Feb 3, 2016 at 12:08 PM, Ashutosh Bapat wrote: PFA patches with naming conventions similar to previous ones. pg_fdw_core_v7.patch: core

Re: [HACKERS] silent data loss with ext4 / all current versions

On Tue, Feb 2, 2016 at 9:59 AM, Andres Freund wrote: > On 2016-02-02 09:56:40 +0900, Michael Paquier wrote: >> And there is no actual risk of data loss > > Huh? More precise: what I mean here is that should an OS crash or a power failure happen, we would fall back to recovery

Re: [HACKERS] silent data loss with ext4 / all current versions

On Tue, Feb 2, 2016 at 4:20 PM, Michael Paquier wrote: > Not wrong, and this leads to the following: > void rename_safe(const char *old, const char *new, bool isdir, int elevel); > Controlling elevel is necessary per the multiple code paths that would > use it. Some use ERROR, most of them FATAL,