Re: [HACKERS] Declarative partitioning - another take

On Thu, Oct 6, 2016 at 12:44 PM, Amit Langote wrote: > On 2016/10/05 2:12, Robert Haas wrote: >> On Tue, Oct 4, 2016 at 4:02 AM, Amit Langote >> wrote: Even if we leave the empty relfilenode around for now -- in the long run I think it should die -- I think we should prohibit the creati

Re: [HACKERS] planet postgresql issue

On Tue, Oct 25, 2016 at 08:36:22AM +0200, hubert depesz lubaczewski wrote: > Same here. feed url is https://www.depesz.com/tag/postgresql/feed/ and > as far as I can tell, it works OK. Magnus is looking into the problem now. Seems to be something related to networking in the box that hosts planet.

Re: [HACKERS] planet postgresql issue

I got a email about issues with reading feed URL. [...] Same here. [...] Same issue here. [...] Same. I would guess that the feed loader has some connectivity problems. -- Fabien. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] planet postgresql issue

On Tue, Oct 25, 2016 at 3:36 PM, hubert depesz lubaczewski wrote: > On Tue, Oct 25, 2016 at 08:28:00AM +0200, Pavel Stehule wrote: >> Hi >> >> I got a email about issues with reading feed URL. >> >> I checked manually URL and it looks well. http://okbob.blogspot.com/ >> feeds/posts/default > > Sam

Re: [HACKERS] [BUG] pg_basebackup from disconnected standby fails

On Tue, Oct 25, 2016 at 11:07 AM, Kyotaro HORIGUCHI wrote: > At Mon, 24 Oct 2016 15:55:58 +0900, Michael Paquier > wrote in > >> Anyway, we can clearly reject 1. in the light of >> https://www.postgresql.org/message-id/caa4ek1kmjtsxqf0cav7cs4d4vwv2h_pc8d8q1bucqdzaf+7...@mail.gmail.com >> when

Re: [HACKERS] planet postgresql issue

On Tue, Oct 25, 2016 at 08:28:00AM +0200, Pavel Stehule wrote: > Hi > > I got a email about issues with reading feed URL. > > I checked manually URL and it looks well. http://okbob.blogspot.com/ > feeds/posts/default Same here. feed url is https://www.depesz.com/tag/postgresql/feed/ and as far a

[HACKERS] planet postgresql issue

Hi I got a email about issues with reading feed URL. I checked manually URL and it looks well. http://okbob.blogspot.com/ feeds/posts/default Regards Pavel

Re: [HACKERS] pg_hba_file_settings view patch

On Mon, Oct 3, 2016 at 3:51 PM, Michael Paquier wrote: > On Mon, Sep 5, 2016 at 4:09 PM, Haribabu Kommi > wrote: > > On Sun, Sep 4, 2016 at 1:44 AM, Simon Riggs > wrote: > >> On 15 August 2016 at 12:17, Haribabu Kommi > >> wrote: > >> > >> > comments? > >> > >> This looks like a good feature c

Re: [HACKERS] Minor code improvement to postgresGetForeignJoinPaths

Hi Ashutosh, You are right. Every call except that one is using NIL, so better to fix it. The pattern was repeated in the recent aggregate pushdown support. Here's patch to fix create_foreignscan_path() call in add_foreign_grouping_paths() as well. Thanks for the review! Tatsuro Yamada NTT Op

Re: [HACKERS] [COMMITTERS] pgsql: Remove extra comma at end of enum list

On Tue, Oct 25, 2016 at 1:17 PM, Tom Lane wrote: > Michael Paquier writes: >> Well... Coming back to the subject, are there any recommendations from >> committers? -std=c89 in CFLAGS does not seem to help much to detect >> extra commas in enums, even if this has been added in C99. > > My opinion

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

On Tue, Oct 18, 2016 at 1:51 AM, Shay Rojansky wrote: > The current macaddr datatype needs to be kept for some time by renaming >> it without changing OID and use the newer one for further usage. >> > > From the point of view of a driver maintainer... Npgsql looks up data > types by their name -

Re: [HACKERS] [COMMITTERS] pgsql: Remove extra comma at end of enum list

Michael Paquier writes: > Well... Coming back to the subject, are there any recommendations from > committers? -std=c89 in CFLAGS does not seem to help much to detect > extra commas in enums, even if this has been added in C99. My opinion is don't worry about it. The buildfarm will find such pro

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Mon, Oct 24, 2016 at 2:48 PM, Dilip Kumar wrote: > On Fri, Oct 21, 2016 at 7:57 AM, Dilip Kumar wrote: >> On Thu, Oct 20, 2016 at 9:03 PM, Tomas Vondra >> wrote: >> >>> In the results you've posted on 10/12, you've mentioned a regression with 32 >>> clients, where you got 52k tps on master bu

Re: [HACKERS] emergency outage requiring database restart

Merlin Moncure wrote: > On Mon, Oct 24, 2016 at 6:01 PM, Merlin Moncure wrote: > > Corruption struck again. > > This time got another case of view busted -- attempting to create > > gives missing 'type' error. > > Call it a hunch -- I think the problem is in pl/sh. I've heard that before. --

Re: [HACKERS] [PATCH] Logical decoding timeline following take II

On 24 October 2016 at 23:49, Petr Jelinek wrote: > Hi Craig, > > On 01/09/16 06:08, Craig Ringer wrote: >> Hi all >> >> Attached is a rebased and updated logical decoding timeline following >> patch for 10.0. >> >> This is a pre-requisite for the pending work on logical decoding on >> standby serv

Re: [HACKERS] [BUG] pg_basebackup from disconnected standby fails

Hi, At Mon, 24 Oct 2016 15:55:58 +0900, Michael Paquier wrote in > On Mon, Oct 24, 2016 at 1:39 PM, Amit Kapila wrote: > > On Mon, Oct 24, 2016 at 9:18 AM, Kyotaro HORIGUCHI > > wrote: > >> Thank you for looking and retelling this. > > +1. > > >> At Fri, 21 Oct 2016 13:02:21 -0400, Robert H

Re: [HACKERS] [COMMITTERS] pgsql: Remove extra comma at end of enum list

On Tue, Oct 25, 2016 at 2:34 PM, Peter Eisentraut wrote: > On 10/24/16 8:37 PM, Michael Paquier wrote: >> Well... Coming back to the subject, are there any recommendations from >> committers? -std=c89 in CFLAGS does not seem to help much to detect >> extra commas in enums, even if this has been ad

Re: [HACKERS] [COMMITTERS] pgsql: Remove extra comma at end of enum list

On 10/24/16 8:37 PM, Michael Paquier wrote: > Well... Coming back to the subject, are there any recommendations from > committers? -std=c89 in CFLAGS does not seem to help much to detect > extra commas in enums, even if this has been added in C99. The only option that gives you a warning for this

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Fri, Oct 7, 2016 at 5:47 PM, Peter Geoghegan wrote: > Work is still needed on: > > * Cost model. Should probably attempt to guess final index size, and > derive calculation of number of workers from that. Also, I'm concerned > that I haven't given enough thought to the low end, where with defau

Re: [HACKERS] [COMMITTERS] pgsql: Remove extra comma at end of enum list

On Tue, Oct 25, 2016 at 6:59 AM, Tom Lane wrote: > Fabien COELHO writes: >>> An alternative that would be worth considering is to adopt a uniform >>> rule of // for line-ending comments and /* for all other uses. > >> Why not. As far as comments are concerned, editors usually highlight them >> in

Re: [HACKERS] emergency outage requiring database restart

On Mon, Oct 24, 2016 at 6:01 PM, Merlin Moncure wrote: > On Thu, Oct 20, 2016 at 1:52 PM, Merlin Moncure wrote: >> On Wed, Oct 19, 2016 at 2:39 PM, Merlin Moncure wrote: >>> On Wed, Oct 19, 2016 at 9:56 AM, Bruce Momjian wrote: On Wed, Oct 19, 2016 at 08:54:48AM -0500, Merlin Moncure wrote

Re: [HACKERS] emergency outage requiring database restart

On Thu, Oct 20, 2016 at 1:52 PM, Merlin Moncure wrote: > On Wed, Oct 19, 2016 at 2:39 PM, Merlin Moncure wrote: >> On Wed, Oct 19, 2016 at 9:56 AM, Bruce Momjian wrote: >>> On Wed, Oct 19, 2016 at 08:54:48AM -0500, Merlin Moncure wrote: > Yeah. Believe me -- I know the drill. Most or all

Re: [HACKERS] [COMMITTERS] pgsql: Remove extra comma at end of enum list

Fabien COELHO writes: >> An alternative that would be worth considering is to adopt a uniform >> rule of // for line-ending comments and /* for all other uses. > Why not. As far as comments are concerned, editors usually highlight them > in some color, and my eyes get used to the comment color,

Re: [HACKERS] [COMMITTERS] pgsql: Remove extra comma at end of enum list

I find it annoying that "//" comments are not supported, or having to declare variables at the beginning of a block instead of when first used... I think some c99 features would be nice (variadic macros for one), but those particular two get a big "meh" from me. This is probably a matter of

Re: [HACKERS] [COMMITTERS] pgsql: Remove extra comma at end of enum list

On 24/10/16 21:11, Stephen Frost wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Alvaro Herrera writes: >>> Fabien COELHO wrote: I find it annoying that "//" comments are not supported, or having to declare variables at the beginning of a block instead of when first used... >> >>> I

Re: [HACKERS] Press Release Draft - 2016-10-27 Cumulative Update

> On Oct 24, 2016, at 2:59 PM, Tom Lane wrote: > > Jonathan Katz writes: >> Below is the draft of the press release for the update this Thursday: > >> https://git.postgresql.org/gitweb/?p=press.git;a=blob;f=update_releases/current/update_201610.md;h=aac4d0b36f3f3017d319ac617eff901efe0c10c0;hb=

Re: [HACKERS] [COMMITTERS] pgsql: Remove extra comma at end of enum list

I find it annoying that "//" comments are not supported, or having to declare variables at the beginning of a block instead of when first used... I think some c99 features would be nice (variadic macros for one), but those particular two get a big "meh" from me. Yeah. Personally, I'd want

Re: [HACKERS] Patch: Implement failover on libpq connect level.

Robert Haas wrote: > While I was experimenting with this today, I discovered a problem of > interpretation related to IPv6 addresses. Internally, a postgresql:// > URL and a connection string are converted into the same format, so > postgresql://a,b/ means just the same thing as host=a,b. I thou

Re: [HACKERS] Press Release Draft - 2016-10-27 Cumulative Update

> On Oct 24, 2016, at 2:49 PM, Robert Haas wrote: > > On Mon, Oct 24, 2016 at 1:14 PM, Jonathan Katz > wrote: >> Hello, >> >> Below is the draft of the press release for the update this Thursday: >> >> https://git.postgresql.org/gitweb/?p=press.git;a=blob;f=update_releases/current/update_2016

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On 10/24/16 11:57 AM, Robert Haas wrote: > Today, since the host part can't include a > port specifier, it's regarded as part of the IP address, and I think > it would probably be a bad idea to change that, as I believe Victor's > patch would. He seems to have it in mind that we could allow things

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On 10/24/16 6:36 AM, Thom Brown wrote: > So should it be the case that it disallows UNIX socket addresses > entirely? I can't imagine a list of UNIX socket addresses being that > useful. But maybe a mixed list of Unix-domain sockets and TCP connections? The nice thing is that is it currently tra

Re: [HACKERS] Rename max_parallel_degree?

On 10/12/16 7:58 PM, Robert Haas wrote: > I don't think it's wrong that the handling is done there, though. The > process that is registering the background worker is well-placed to > check whether there are already too many, and if it does not then the > slot is consumed at least temporarily even

Re: [HACKERS] [COMMITTERS] pgsql: Remove extra comma at end of enum list

On Mon, Oct 24, 2016 at 03:03:19PM -0400, Tom Lane wrote: > Alvaro Herrera writes: > > Fabien COELHO wrote: > >> I find it annoying that "//" comments are not supported, or having to > >> declare variables at the beginning of a block instead of when first used... > > > I think some c99 features w

Re: [HACKERS] PL/Python adding support for multi-dimensional arrays

Hi 2016-10-14 10:53 GMT+02:00 Heikki Linnakangas : > On 10/11/2016 08:56 AM, Pavel Stehule wrote: > >> 2016-10-11 7:49 GMT+02:00 Heikki Linnakangas : >> >> Unfortunately there are cases that are fundamentally ambiguous. >>> >>> create type comptype as (intarray int[]); >>> create function array_r

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On Wed, 19 Oct 2016 12:04:27 -0400 Robert Haas wrote: > On Thu, Oct 13, 2016 at 5:53 AM, Victor Wagner > wrote: > > On Thu, 13 Oct 2016 12:30:59 +0530 > > Mithun Cy wrote: > >> On Fri, Sep 30, 2016 at 2:14 PM, Victor Wagner > >> wrote: > >> Okay but for me consistency is also important. Sinc

Re: [HACKERS] [COMMITTERS] pgsql: Remove extra comma at end of enum list

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Alvaro Herrera writes: > > Fabien COELHO wrote: > >> I find it annoying that "//" comments are not supported, or having to > >> declare variables at the beginning of a block instead of when first used... > > > I think some c99 features would be nice (varia

Re: [HACKERS] Press Release Draft - 2016-10-27 Cumulative Update

Jonathan Katz writes: > Below is the draft of the press release for the update this Thursday: > https://git.postgresql.org/gitweb/?p=press.git;a=blob;f=update_releases/current/update_201610.md;h=aac4d0b36f3f3017d319ac617eff901efe0c10c0;hb=880dc99766ee0e608e95d9c0f36ce3cde59f470f > >

Re: [HACKERS] [COMMITTERS] pgsql: Remove extra comma at end of enum list

Alvaro Herrera writes: > Fabien COELHO wrote: >> I find it annoying that "//" comments are not supported, or having to >> declare variables at the beginning of a block instead of when first used... > I think some c99 features would be nice (variadic macros for one), but > those particular two get

Re: [HACKERS] Press Release Draft - 2016-10-27 Cumulative Update

On Mon, Oct 24, 2016 at 1:14 PM, Jonathan Katz wrote: > Hello, > > Below is the draft of the press release for the update this Thursday: > > https://git.postgresql.org/gitweb/?p=press.git;a=blob;f=update_releases/current/update_201610.md;h=aac4d0b36f3f3017d319ac617eff901efe0c10c0;hb=880dc99766ee0e

Re: [HACKERS] FSM corruption leading to errors

Alvaro Herrera writes: > Tom Lane wrote: >> Also, we could at least discount the FSM root page and first intermediate >> page, no? That is, the upper limit could be >> >> pg_relation_size(oid::regclass, 'fsm') / 2 - >> 2*current_setting('block_size')::BIGINT >> >> I think this is a worthwhile

Re: [HACKERS] [COMMITTERS] pgsql: Remove extra comma at end of enum list

Fabien COELHO wrote: > I find it annoying that "//" comments are not supported, or having to > declare variables at the beginning of a block instead of when first used... I think some c99 features would be nice (variadic macros for one), but those particular two get a big "meh" from me. .oO( I w

Re: [HACKERS] FSM corruption leading to errors

Tom Lane wrote: > Ah, scratch that, after rereading the FSM README I see it's correct, > because there's a binary tree within each page; I'd only remembered > that there was a search tree of pages. > > Also, we could at least discount the FSM root page and first intermediate > page, no? That is,

Re: [HACKERS] Renaming of pg_xlog and pg_clog

Bruce Momjian wrote: > On Mon, Oct 24, 2016 at 11:59:42AM -0300, Alvaro Herrera wrote: > > There is one difference though, which is that the really destructive > > use of pg_resetxlog is the one that removes pg_xlog files. The other > > uses that simply set flags in the control file are not as ba

[HACKERS] Press Release Draft - 2016-10-27 Cumulative Update

Hello, Below is the draft of the press release for the update this Thursday: https://git.postgresql.org/gitweb/?p=press.git;a=blob;f=update_releases/current/update_201610.md;h=aac4d0b36f3f3017d319ac617eff901efe0c10c0;hb=880dc99766ee0e608e95d9c0f36ce3cde59f470f

Re: [HACKERS] FSM corruption leading to errors

On Mon, Oct 24, 2016 at 9:47 PM, Tom Lane wrote: > > > Also, we could at least discount the FSM root page and first intermediate > page, no? That is, the upper limit could be > > pg_relation_size(oid::regclass, 'fsm') / 2 - > 2*current_setting('block_size')::BIGINT > > +1 for doing that.

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

Tom Lane wrote: > I poked at this a little bit. AFAICT, the only actual cross-file > references are in contrib/ltree/, which has quite a few. Maybe we > could hold our noses and attach PGDLLEXPORT to the declarations in > ltree.h. > > hstore's HSTORE_POLLUTE macro would also need PGDLLEXPORT-ifi

Re: [HACKERS] [PATCH] Logical decoding timeline following take II

Hi Craig, On 01/09/16 06:08, Craig Ringer wrote: > Hi all > > Attached is a rebased and updated logical decoding timeline following > patch for 10.0. > > This is a pre-requisite for the pending work on logical decoding on > standby servers and simplified failover of logical decoding. > I went

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On Wed, Oct 19, 2016 at 7:26 PM, Peter van Hardenberg wrote: > Supporting different ports on different servers would be a much appreciated > feature (I can't remember if it was Kafka or Cassandra that didn't do this > and it was very annoying.) > > Remember, as the connection string gets more comp

Re: [HACKERS] FSM corruption leading to errors

Michael Paquier writes: > Release notes refer to this page for methods to fix corrupted instances: > https://wiki.postgresql.org/wiki/Free_Space_Map_Problems > I just typed something based on Pavan's upper method, feel free to > jump in and improve it as necessary. Thanks for drafting that, but i

Re: [HACKERS] FSM corruption leading to errors

I wrote: > It looks to me like this is approximating the highest block number that > could possibly have an FSM entry as size of the FSM fork (in bytes) > divided by 2. But the FSM stores one byte per block. There is overhead > for the FSM search tree, but in a large relation it's not going to be

Re: [HACKERS] FSM corruption leading to errors

On Mon, Oct 24, 2016 at 9:34 PM, Tom Lane wrote: > > SELECT blkno, pg_freespace(oid::regclass, blkno) > FROM generate_series(pg_relation_size(oid::regclass) / > current_setting('block_size')::BIGINT, > pg_relation_size(oid::regclass, 'fsm') / 2) AS > blkno > > It

Re: [HACKERS] [PATCH] Send catalog_xmin separately in hot standby feedback

Hi Craig, On 05/09/16 11:28, Craig Ringer wrote: > On 5 September 2016 at 14:44, Craig Ringer wrote: >> On 5 September 2016 at 12:40, Craig Ringer wrote: >>> Hi all >>> >>> Currently hot standby feedback sends GetOldestXmin()'s result to the >>> upstream as the required xmin. GetOldestXmin() ret

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On Mon, Oct 24, 2016 at 11:59:42AM -0300, Alvaro Herrera wrote: > Bruce Momjian wrote: > > On Sat, Oct 22, 2016 at 11:18:28PM +0300, Greg Stark wrote: > > > > I think the apt-get behaviour was specifically designed to ensure it > > > couldn't easily be put into a script which I would have said was

Re: [HACKERS] Renaming of pg_xlog and pg_clog

Bruce Momjian wrote: > On Sat, Oct 22, 2016 at 11:18:28PM +0300, Greg Stark wrote: > > I think the apt-get behaviour was specifically designed to ensure it > > couldn't easily be put into a script which I would have said was > > desirable -- except I suspect there are situations where Postgres > >

Re: [HACKERS] Hash Indexes

On Mon, Oct 24, 2016 at 8:00 PM, Amit Kapila wrote: > On Thu, Sep 29, 2016 at 6:04 AM, Robert Haas wrote: >> On Wed, Sep 28, 2016 at 3:04 PM, Robert Haas wrote: > > > Thanks for the valuable feedback. > Forgot to mention that in addition to fixing the review comments, I had made an additional c

[HACKERS] repmgr: this node should be a standby

Hello, I am using repmgr 3.2 (PostgreSQL 9.6.0), postgresql-9.5. I have a master, a slave and a third server for my setup. The third server is used to house the rep mgr database. my config is as below : ===MASTER= cluster=test node=1 node_name=node1 conninfo='host=192.168.2.33 user=repuser pa

Re: [HACKERS] On conflict update & hint bits

On Sun, Oct 23, 2016 at 3:42 PM, Tom Lane wrote: > The business about not throwing a serialization failure due to actions > of our own xact does seem worth fixing now, but if I understand correctly, > we can deal with that by adding a test for xmin-is-our-own-xact into > the existing code structu

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On Sat, Oct 22, 2016 at 11:18:28PM +0300, Greg Stark wrote: > On Fri, Oct 21, 2016 at 9:03 PM, Stephen Frost wrote: > > WARNING: The following essential packages will be removed. > > This should NOT be done unless you know exactly what you are doing! > > login > > 0 upgraded, 0 newly installed,

Re: [HACKERS] issue with track_commit_timestamp and server restart

Alvaro Herrera writes: > Now let's discuss a release note entry for 9.5 and 9.6, shall we? The text in your commit message seems sufficient from here. On it now (although if somebody doesn't fix anon git PDQ, we're not releasing today anyway). regards, tom lane -- Sent

Re: [HACKERS] issue with track_commit_timestamp and server restart

Now let's discuss a release note entry for 9.5 and 9.6, shall we? -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your su

Re: [HACKERS] issue with track_commit_timestamp and server restart

Craig Ringer wrote: > I initially could'n't see this when tested on 8f1fb7d with a > src/test/recovery/t test script. But it turns out it's OK on immediate > shutdown and crash recovery, but not on clean shutdown and restart. Oh, oops. > The attached patch adds a TAP test to src/test/recovery to

Re: [HACKERS] On conflict update & hint bits

Konstantin Knizhnik writes: > Just for information: I know that you are working on this issue, but as > far as we need to proceed further with our testing of multimaster, > I have done the following obvious changes and it fixes the problem (at > least this assertion failure is not happen any mor

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On Wed, 19 Oct 2016 20:15:38 -0400 Robert Haas wrote: > > Some more comments: > > - I am pretty doubtful that the changes to connectOptions2() work as > intended. I think that's only going to be called before actualhost > and actualport could possibly get set. I don't think we keep > reinvoki

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On Mon, 24 Oct 2016 11:36:31 +0100 Thom Brown wrote: > > - It's pretty clear that this isn't going to work if the host list > > includes a mix of hostnames and UNIX socket addresses. The code > > that handles the UNIX socket address case is totally separate from > > the code that handles the mu

Re: [HACKERS] Aggregate Push Down - Performing aggregation on foreign server

On Sat, Oct 22, 2016 at 9:09 PM, Tom Lane wrote: > brolga is still not terribly happy with this patch: it's choosing not to > push down the aggregates in one of the queries. While I failed to > duplicate that result locally, investigation suggests that brolga's result > is perfectly sane; in fac

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On 20 October 2016 at 01:15, Robert Haas wrote: > > On Wed, Oct 19, 2016 at 12:04 PM, Robert Haas wrote: > > On Thu, Oct 13, 2016 at 5:53 AM, Victor Wagner wrote: > >> On Thu, 13 Oct 2016 12:30:59 +0530 > >> Mithun Cy wrote: > >>> On Fri, Sep 30, 2016 at 2:14 PM, Victor Wagner > >>> wrote: > >

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Fri, Oct 21, 2016 at 7:57 AM, Dilip Kumar wrote: > On Thu, Oct 20, 2016 at 9:03 PM, Tomas Vondra > wrote: > >> In the results you've posted on 10/12, you've mentioned a regression with 32 >> clients, where you got 52k tps on master but only 48k tps with the patch (so >> ~10% difference). I hav

Re: [HACKERS] Push down more full joins in postgres_fdw

On 2016/10/22 17:19, Ashutosh Bapat wrote: Review for postgres-fdw-more-full-join-pushdown-v6 patch. The patch applies cleanly and regression is clean (make check in regress directory and that in postgres_fdw). Thanks for the review! Here are some comments. 1. Because of the following code c

[HACKERS] Microvacuum support for Hash Index

Hi All, I have added a microvacuum support for hash index access method and attached is the v1 patch for the same. The patch basically takes care of the following things: 1. Firstly, it changes the marking of dead tuples from 'tuple-at-a-time' to 'page-at-a-time' during hash index scan. For this

Re: [HACKERS] issue with track_commit_timestamp and server restart

On 24/10/2016 06:58, Craig Ringer wrote: > On 22 October 2016 at 19:51, Julien Rouhaud wrote: >> I just noticed that if track_commit_timestamp is enabled, the >> oldestCommitTsXid and newestCommitTsXid don't persist after a server >> restart, so you can't ask for the commit ts of a transaction tha

Re: [HACKERS] Rename max_parallel_degree?

On Thu, Oct 13, 2016 at 5:28 AM, Robert Haas wrote: > On Wed, Oct 12, 2016 at 8:13 AM, Peter Eisentraut > wrote: >> On 10/4/16 10:16 AM, Julien Rouhaud wrote: >>> Please find attached v9 of the patch, adding the parallel worker class >>> and changing max_worker_processes default to 16 and max_par

Re: [HACKERS] [BUG] pg_basebackup from disconnected standby fails

On Mon, Oct 24, 2016 at 1:26 PM, Amit Kapila wrote: > On Fri, Oct 21, 2016 at 10:32 PM, Robert Haas wrote: >> 2. In perform_base_backup(), if the endptr returned by >> do_pg_stop_backup() precedes the end of the checkpoint record returned >> by do_pg_start_backup(), use the latter value instead.

Re: [HACKERS] On conflict update & hint bits

On 24.10.2016 00:49, Peter Geoghegan wrote: On Sun, Oct 23, 2016 at 2:46 PM, Tom Lane wrote: What's bothering me is (a) it's less than 24 hours to release wrap and (b) this patch changes SSI-relevant behavior and hasn't been approved by Kevin. I'm not familiar enough with that logic to commi