Re: [HACKERS] postgres_fdw : altering foreign table not invalidating prepare statement execution plan.

On 2016/10/19 12:20, Etsuro Fujita wrote: > Having said that, I like the latest version (v6), so I'd vote for marking > this as Ready For Committer. +1, thanks a lot! Regards, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Parallel bitmap heap scan

On Tue, Oct 18, 2016 at 1:45 AM, Andres Freund wrote: > I don't quite understand why the bitmap has to be parallel at all. As > far as I understand your approach as described here, the only thing that > needs to be shared are the iteration arrays. Since they never need to >

Re: [HACKERS] Parallel bitmap heap scan

On Tue, Oct 18, 2016 at 1:42 AM, Robert Haas wrote: > But what's the impact on performance? Presumably parallel bitmap heap > scan was already slower than the non-parallel version, and that commit > presumably widens the gap. Seems like something to worry about... I have

[HACKERS] Change of schedule for the next batch of PG update releases

We previously stated that the next regularly-scheduled set of PG back-branch updates would be the week of Nov. 7th, announcing on the 10th. In view of some particularly nasty bugs that have surfaced in 9.6.0 (e.g. pg_upgrade's corruption of visibility maps), we're going to move that up by two

Re: [HACKERS] postgres_fdw : altering foreign table not invalidating prepare statement execution plan.

On 2016/10/18 22:04, Ashutosh Bapat wrote: On Tue, Oct 18, 2016 at 6:18 PM, Etsuro Fujita wrote: On 2016/10/17 20:12, Ashutosh Bapat wrote: On 2016/10/07 10:26, Amit Langote wrote: I think this (v4) patch is in the best shape so far. +1, except one small

Re: [HACKERS] "make check" and pg_hba.conf

On 10/18/16 6:31 PM, Jeff Janes wrote: > I would want to do that so that the code dealing with password-based > logins doesn't go completely untested by "make check", like it currently is. Write a TAP test for it. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL

Re: [HACKERS] Hash Indexes

On Wed, Oct 19, 2016 at 5:57 AM, Amit Kapila wrote: > On Tue, Oct 18, 2016 at 10:52 PM, Robert Haas wrote: >> On Tue, Oct 18, 2016 at 5:37 AM, Amit Kapila wrote: >>> On Wed, Oct 5, 2016 at 10:22 PM, Robert Haas

Re: [HACKERS] Query cancel seems to be broken in master since Oct 17

On Tue, Oct 18, 2016 at 11:40 PM, Tom Lane wrote: > I wrote: >> The cleanest fix might be to change those various "long" variables >> to uint32. You'd have to think about how to handle the ntohl/htonl >> calls that are used on them, though. > > Or actually, no, you wouldn't

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

On Wed, Oct 19, 2016 at 5:11 AM, Robert Haas wrote: > On Thu, Sep 29, 2016 at 1:45 AM, Haribabu Kommi > wrote: > > Currently, The SQL stats is a fixed size counter to track the all the > ALTER > > cases as single counter. So while sending the

Re: [HACKERS] Hash Indexes

On Tue, Oct 18, 2016 at 10:52 PM, Robert Haas wrote: > On Tue, Oct 18, 2016 at 5:37 AM, Amit Kapila wrote: >> On Wed, Oct 5, 2016 at 10:22 PM, Robert Haas wrote: >>> On Tue, Oct 4, 2016 at 12:36 AM, Amit Kapila

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

On Wed, Oct 12, 2016 at 08:33:00AM -0400, Tom Lane wrote: > As others have noted, there is no likelihood that we'd take a disk-format- > compatibility-breaking patch for v10. Even if we wanted to do that, the > above proposal would also break send/recv (binary COPY) compatibility for > macaddr. >

Re: [HACKERS] Indirect indexes

On Tue, Oct 18, 2016 at 5:48 PM, Simon Riggs wrote: > On 18 October 2016 at 22:04, Claudio Freire wrote: >> On Tue, Oct 18, 2016 at 3:28 PM, Alvaro Herrera >> wrote: >>> I propose we introduce the concept of "indirect

Re: [HACKERS] "make check" and pg_hba.conf

Jeff Janes writes: > On Tue, Oct 18, 2016 at 2:28 PM, Tom Lane wrote: >> No. Why would you want that? External connections to the test DB seem >> like exactly what you *don't* want, for reproducibility's sake. > I would want to do that so that the

Re: [HACKERS] "make check" and pg_hba.conf

On Tue, Oct 18, 2016 at 2:28 PM, Tom Lane wrote: > Jeff Janes writes: > > Is there a way to get "make check" to install a custom pg_hba.conf for > its > > temporary installation? Something like pre-prending the line: > > local all password_user md5 >

Re: [HACKERS] PATCH: two slab-like memory allocators

On 18/10/16 22:25, Robert Haas wrote: > On Wed, Oct 5, 2016 at 12:22 AM, Tomas Vondra > wrote: >> attached is v3 of the patches, with a few minor fixes in Slab, and much >> larger fixes in GenSlab. >> >> Slab (minor fixes) >> -- >> - Removed the

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On Fri, Oct 14, 2016 at 07:19:02PM +0200, Christoph Berg wrote: > Re: Stephen Frost 2016-10-14 <20161014113523.gz13...@tamriel.snowman.net> > > > We have a tool called pg_xlogdump in the standard installation. initdb > > > has an option --xlogdir, pg_basebackup has --xlog and others. Renaming >

Re: [HACKERS] Mention column name in error messages

On Wed, Oct 19, 2016 at 3:14 AM, Robert Haas wrote: > On Mon, Oct 17, 2016 at 3:18 AM, Michael Paquier > wrote: >> Andres wrote: >>> +/* Support for TransformExprCallback */ >>> +typedef struct TransformExprState >>> +{ >>> + const char

Re: [HACKERS] Indirect indexes

On Wed, Oct 19, 2016 at 12:21 AM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Tue, Oct 18, 2016 at 9:28 PM, Alvaro Herrera > wrote: > >> Vacuuming presents an additional challenge: in order to remove index >> items from an indirect index, it's critical

Re: [HACKERS] Remove vacuum_defer_cleanup_age

On 10/18/2016 01:37 PM, Andres Freund wrote: > Hi, > > On 2016-10-09 21:51:07 -0700, Josh Berkus wrote: >> Given that hot_standby_feedback is pretty bulletproof now, and a lot of >> the work in reducing replay conflicts, I think the utility of >> vacuum_defer_cleanup_age is at an end. I really

Re: [HACKERS] "make check" and pg_hba.conf

Jeff Janes writes: > Is there a way to get "make check" to install a custom pg_hba.conf for its > temporary installation? Something like pre-prending the line: > local all password_user md5 > To the default pg_hba.conf? No. Why would you want that? External connections

[HACKERS] "make check" and pg_hba.conf

Is there a way to get "make check" to install a custom pg_hba.conf for its temporary installation? Something like pre-prending the line: local all password_user md5 To the default pg_hba.conf? Thanks, Jeff

Re: [HACKERS] Indirect indexes

Hi, Alvaro! Thank you for your proposal. One question about vacuum excites me most. On Tue, Oct 18, 2016 at 9:28 PM, Alvaro Herrera wrote: > Vacuuming presents an additional challenge: in order to remove index > items from an indirect index, it's critical to scan the

Re: [HACKERS] Indirect indexes

On 18 October 2016 at 22:04, Claudio Freire wrote: > On Tue, Oct 18, 2016 at 3:28 PM, Alvaro Herrera > wrote: >> I propose we introduce the concept of "indirect indexes". I have a toy >> implementation and before I go further with it, I'd like

Re: [HACKERS] Remove vacuum_defer_cleanup_age

Hi, On 2016-10-09 21:51:07 -0700, Josh Berkus wrote: > Given that hot_standby_feedback is pretty bulletproof now, and a lot of > the work in reducing replay conflicts, I think the utility of > vacuum_defer_cleanup_age is at an end. I really meant so submit a patch > to remove it to 9.6, but it

Re: [HACKERS] Remove vacuum_defer_cleanup_age

On 10/18/2016 01:28 PM, Robert Haas wrote: > On Tue, Oct 18, 2016 at 4:18 PM, Josh Berkus wrote: >> On 10/12/2016 05:00 PM, Robert Haas wrote: >>> On Sun, Oct 9, 2016 at 9:51 PM, Josh Berkus wrote: Given that hot_standby_feedback is pretty bulletproof

Re: [HACKERS] Remove vacuum_defer_cleanup_age

On Tue, Oct 18, 2016 at 4:18 PM, Josh Berkus wrote: > On 10/12/2016 05:00 PM, Robert Haas wrote: >> On Sun, Oct 9, 2016 at 9:51 PM, Josh Berkus wrote: >>> Given that hot_standby_feedback is pretty bulletproof now, and a lot of >>> the work in reducing replay

Re: [HACKERS] PATCH: two slab-like memory allocators

On Wed, Oct 5, 2016 at 12:22 AM, Tomas Vondra wrote: > attached is v3 of the patches, with a few minor fixes in Slab, and much > larger fixes in GenSlab. > > Slab (minor fixes) > -- > - Removed the unnecessary memset() of new blocks in SlabAlloc(),

Re: [HACKERS] Remove vacuum_defer_cleanup_age

On 10/12/2016 05:00 PM, Robert Haas wrote: > On Sun, Oct 9, 2016 at 9:51 PM, Josh Berkus wrote: >> Given that hot_standby_feedback is pretty bulletproof now, and a lot of >> the work in reducing replay conflicts, I think the utility of >> vacuum_defer_cleanup_age is at an end.

Re: [HACKERS] Indirect indexes

On Tue, Oct 18, 2016 at 3:28 PM, Alvaro Herrera wrote: > I propose we introduce the concept of "indirect indexes". I have a toy > implementation and before I go further with it, I'd like this assembly's > input on the general direction. > > Indirect indexes are similar

Re: [HACKERS] Indirect indexes

On 18 October 2016 at 21:41, Joshua D. Drake wrote: > Are we > trading initial performance gains for performance degradation through > maintenance? Eh? That's backwards, so No. The whole point of this is it avoids long term degradation currently caused by non-HOT

Re: [HACKERS] "Some tests to cover hash_index"

On Wed, Oct 12, 2016 at 1:17 AM, Mithun Cy wrote: > On Wed, Sep 28, 2016 at 9:56 PM, Robert Haas wrote: >> something committable will come from it, but with 2 days left it's not >> going to happen this CF. > Adding a new patch. This one uses

Re: [HACKERS] Indirect indexes

On 10/18/2016 11:28 AM, Alvaro Herrera wrote: Vacuuming presents an additional challenge: in order to remove index items from an indirect index, it's critical to scan the PK index first and collect the PK values that are being removed. Then scan the indirect index and remove any items that

Re: [HACKERS] [ADMIN] 9.5 new setting "cluster name" and logging

Robert Haas writes: > On Mon, Oct 17, 2016 at 6:24 PM, Stephen Frost wrote: >> I'm with Thomas on this and I disagree that the "csvlog bloat" argument >> has merit. If we're worried about bloat in csv then we should provide a >> way for users to

Re: [HACKERS] [ADMIN] 9.5 new setting "cluster name" and logging

Robert Haas wrote: > On Mon, Oct 17, 2016 at 6:24 PM, Stephen Frost wrote: > > I'm with Thomas on this and I disagree that the "csvlog bloat" argument > > has merit. If we're worried about bloat in csv then we should provide a > > way for users to control what goes into the

[HACKERS] Indirect indexes

I propose we introduce the concept of "indirect indexes". I have a toy implementation and before I go further with it, I'd like this assembly's input on the general direction. Indirect indexes are similar to regular indexes, except that instead of carrying a heap TID as payload, they carry the

Re: [HACKERS] [ADMIN] 9.5 new setting "cluster name" and logging

On Mon, Oct 17, 2016 at 6:24 PM, Stephen Frost wrote: > I'm with Thomas on this and I disagree that the "csvlog bloat" argument > has merit. If we're worried about bloat in csv then we should provide a > way for users to control what goes into the csvlog, not argue that >

Re: [HACKERS] minor issue: \c without parameter disconnect current user

Alvaro Herrera writes: > Robert Haas wrote: >> On Mon, Oct 17, 2016 at 12:49 AM, Pavel Stehule >> wrote: >>> I expect so \c without parameters has only informational character. But \c >>> reset user. >> Yeah, I use that feature all the time.

Re: [HACKERS] Mention column name in error messages

On Mon, Oct 17, 2016 at 3:18 AM, Michael Paquier wrote: > Andres wrote: >> +/* Support for TransformExprCallback */ >> +typedef struct TransformExprState >> +{ >> + const char *column_name; >> + Oid expected_type; >> +} TransformExprState; >> I see no need for

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

On Thu, Sep 29, 2016 at 1:45 AM, Haribabu Kommi wrote: > Currently, The SQL stats is a fixed size counter to track the all the ALTER > cases as single counter. So while sending the stats from the backend to > stats collector at the end of the transaction, the cost is

Re: [HACKERS] minor issue: \c without parameter disconnect current user

Robert Haas wrote: > On Mon, Oct 17, 2016 at 12:49 AM, Pavel Stehule > wrote: > > I expect so \c without parameters has only informational character. But \c > > reset user. > > Yeah, I use that feature all the time. And so do the regression tests. I think what Pavel

Re: [HACKERS] simplehash.h typo fix

Hi, On 2016-10-18 09:41:14 +0200, Erik Rijkers wrote: > it's -> its > the the -> the Thanks! Committed. - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] minor issue: \c without parameter disconnect current user

On Mon, Oct 17, 2016 at 12:49 AM, Pavel Stehule wrote: > I expect so \c without parameters has only informational character. But \c > reset user. Yeah, I use that feature all the time. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL

Re: [HACKERS] Minor improvement to delete.sgml

On Fri, Oct 14, 2016 at 12:05 AM, Etsuro Fujita wrote: > I think it's better to mention that an alias is needed for the target table > specified in the USING clause of a DELETE statement, to set up a self-join, > as the documentation on the from_list parameter of

Re: [HACKERS] Multiple psql history files

On Tue, Oct 18, 2016 at 10:21 AM, Tom Lane wrote: > "David G. Johnston" writes: > > On Tue, Oct 18, 2016 at 9:45 AM, Tom Lane wrote: > >> One interesting point, if you wish to consider history as being > >>

Re: [HACKERS] Hash Indexes

On 2016-10-18 13:38:14 -0400, Tom Lane wrote: > Robert Haas writes: > > On Tue, Oct 18, 2016 at 5:37 AM, Amit Kapila > > wrote: > >> I have implemented this idea and it works for MVCC scans. However, I > >> think this might not work for non-MVCC

Re: [HACKERS] Typo in foreign.h

On Wed, Oct 12, 2016 at 9:20 PM, Amit Langote wrote: > Attached fixes a minor typo: s/Thes/These/g Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Hash Indexes

Robert Haas writes: > On Tue, Oct 18, 2016 at 5:37 AM, Amit Kapila wrote: >> I have implemented this idea and it works for MVCC scans. However, I >> think this might not work for non-MVCC scans. Consider a case where >> in Process-1, hash scan

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

On Wed, Oct 12, 2016 at 9:18 AM, Jeevan Chalke wrote: > I did performance testing for aggregate push down and see good performance > with the patch. Are you planning another update to this patch based on Ashutosh's comments? -- Robert Haas EnterpriseDB:

Re: [HACKERS] Hash Indexes

On Tue, Oct 18, 2016 at 5:37 AM, Amit Kapila wrote: > On Wed, Oct 5, 2016 at 10:22 PM, Robert Haas wrote: >> On Tue, Oct 4, 2016 at 12:36 AM, Amit Kapila wrote: >>> I think one way to avoid the risk of deadlock in above

Re: [HACKERS] Multiple psql history files

"David G. Johnston" writes: > On Tue, Oct 18, 2016 at 9:45 AM, Tom Lane wrote: >> One interesting point, if you wish to consider history as being >> connection-specific, is what happens during a \c command. Right >> now the answer is "nothing" but

Re: [HACKERS] Multiple psql history files

On Tue, Oct 18, 2016 at 9:45 AM, Tom Lane wrote: > Jonathan Jacobson writes: > > The .psql_history file is naturally used by different DB connections > > (distinguished by a different combination of host + port + database + > user). > > At least in my

Re: [HACKERS] Multiple psql history files

Jonathan Jacobson writes: > The .psql_history file is naturally used by different DB connections > (distinguished by a different combination of host + port + database + user). > At least in my multi-database working environment, this leads sometimes to > frustration because

Re: [HACKERS] Multiple psql history files

On Tue, Oct 18, 2016 at 9:26 AM, Jonathan Jacobson wrote: > The .psql_history file is naturally used by different DB connections > (distinguished by a different combination of host + port + database + user). > At least in my multi-database working environment, this leads

Re: [HACKERS] Multiple psql history files

On 18/10/2016 18:26, Jonathan Jacobson wrote: > The .psql_history file is naturally used by different DB connections > (distinguished by a different combination of host + port + database + user). > At least in my multi-database working environment, this leads sometimes > to frustration because

Re: [HACKERS] Multiple psql history files

On Tue, Oct 18, 2016 at 9:26 AM, Jonathan Jacobson wrote: > The .psql_history file is naturally used by different DB connections > (distinguished by a different combination of host + port + database + user). > At least in my multi-database working environment, this leads

Re: [HACKERS] Multiple psql history files

On Tue, Oct 18, 2016 at 12:26 PM, Jonathan Jacobson wrote: > The .psql_history file is naturally used by different DB connections > (distinguished by a different combination of host + port + database + user). > At least in my multi-database working environment, this leads

[HACKERS] Multiple psql history files

The .psql_history file is naturally used by different DB connections (distinguished by a different combination of host + port + database + user). At least in my multi-database working environment, this leads sometimes to frustration because there are commands that cannot or should not be used by

Re: [HACKERS] [PATCH] pgpassfile connection option

On Tue, Oct 11, 2016 at 5:06 PM, Oskari Saarenmaa wrote: > $ PASSWORD=xyz psql 'password=$PASSWORD dbname=foo' > > This does have the hazard of making it very easy to accidentally use double > quotes instead of single quotes and have the shell expand the variable > making it

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

Albe Laurenz writes: > The buildfarm log at > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=thrips=2016-10-12%2018%3A37%3A26 > shows the build failing (among others) for contrib/tablefunc > (close to the bottom end of the log). That's a build of 9.6. > Now when

Re: [HACKERS] VACUUM's ancillary tasks

On Sun, Oct 16, 2016 at 3:35 PM, Jeff Janes wrote: > On Fri, Oct 7, 2016 at 6:14 AM, Robert Haas wrote: >> On Thu, Oct 6, 2016 at 8:40 PM, Jeff Janes wrote: >> > In commit 37484ad2aacef5ec7, you changed the way that frozen

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

Tom Lane wrote: > No, it's cross *file* references within a single contrib module that > would be likely to need extern declarations in a header file. That's > not especially weird IMO. I'm not sure how many cases there actually > are though. I went through the contrib moules and tried to look

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

I wrote: > No, it's cross *file* references within a single contrib module that > would be likely to need extern declarations in a header file. That's > not especially weird IMO. I'm not sure how many cases there actually > are though. I poked at this a little bit. AFAICT, the only actual

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Fri, Oct 14, 2016 at 12:37 AM, Ashutosh Bapat wrote: >> Have you tested the effect of this patch on planner memory consumption >> with multi-way joins between tables with many partitions? If you >> haven't, you probably should. (Testing runtime would be good,

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

Craig Ringer writes: > On 18 October 2016 at 04:11, Tom Lane wrote: >> As for the core problem, I wonder why we aren't recommending that >> third-party modules be built using the same infrastructure contrib >> uses, rather than people ginning up their

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

Craig Ringer writes: > On 18 October 2016 at 04:19, Andres Freund wrote: >> On 2016-10-17 16:16:37 -0400, Robert Haas wrote: >>> I wouldn't think that cross-file references would be especially >>> common. Functions that take PG_FUNCTION_ARGS and return

Re: [HACKERS] Move pg_largeobject to a different tablespace *without* turning on system_table_mods.

På tirsdag 18. oktober 2016 kl. 16:26:37, skrev Euler Taveira < eu...@timbira.com.br >: On 18-10-2016 10:13, Andreas Joseph Krogh wrote: > From time to time pg_largeobject comes up as an issue with being > implemented as a system-catalog. >  Did you read the

Re: [HACKERS] Query cancel seems to be broken in master since Oct 17

I wrote: > The cleanest fix might be to change those various "long" variables > to uint32. You'd have to think about how to handle the ntohl/htonl > calls that are used on them, though. Or actually, no, you wouldn't have to think very hard. I was supposing that those calls were declared to

Re: [HACKERS] Move pg_largeobject to a different tablespace *without* turning on system_table_mods.

On 18-10-2016 10:13, Andreas Joseph Krogh wrote: > From time to time pg_largeobject comes up as an issue with being > implemented as a system-catalog. > Did you read the archives [1]? > As I see it, there are 2 relevant use-cases for improving the situation: > 1. Being able to pg_dump *without*

Re: [HACKERS] Query cancel seems to be broken in master since Oct 17

Heikki Linnakangas writes: > On 10/18/2016 04:13 PM, Tom Lane wrote: >> There's a smoking gun in the postmaster log: >> 2016-10-18 09:10:34.547 EDT [18502] LOG: wrong key in cancel request for >> process 18491 > Ok, I've reverted that commit for now. It clearly needs more

Re: [HACKERS] emergency outage requiring database restart

On Mon, Oct 17, 2016 at 2:04 PM, Alvaro Herrera wrote: > Merlin Moncure wrote: > >> castaging=# CREATE OR REPLACE VIEW vw_ApartmentSample AS >> castaging-# SELECT ... >> ERROR: 42809: "pg_cast_oid_index" is an index >> LINE 11: FROM ApartmentSample s >>

Re: [HACKERS] Query cancel seems to be broken in master since Oct 17

On 10/18/2016 04:13 PM, Tom Lane wrote: Magnus Hagander writes: On Tue, Oct 18, 2016 at 1:00 AM, Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: The test executes "select pg_sleep(10)" and tries to cancel it. In recent master builds, cancel seems to be ignored,

Re: [HACKERS] Query cancel seems to be broken in master since Oct 17

Magnus Hagander writes: > On Tue, Oct 18, 2016 at 1:00 AM, Vladimir Sitnikov < > sitnikov.vladi...@gmail.com> wrote: >> The test executes "select pg_sleep(10)" and tries to cancel it. In recent >> master builds, cancel seems to be ignored, and the statement lasts for 10 >>

[HACKERS] Move pg_largeobject to a different tablespace *without* turning on system_table_mods.

Hi -hackers.   >From time to time pg_largeobject comes up as an issue with being implemented as a system-catalog.   As I see it, there are 2 relevant use-cases for improving the situation: 1. Being able to pg_dump *without* any LOs (think of it as    without the contents of pg_largeobject). This

Re: [HACKERS] postgres_fdw : altering foreign table not invalidating prepare statement execution plan.

On Tue, Oct 18, 2016 at 6:18 PM, Etsuro Fujita wrote: > On 2016/10/17 20:12, Ashutosh Bapat wrote: > >>> On 2016/10/07 10:26, Amit Langote wrote: I think this (v4) patch is in the best shape so far. >> >> +1, except one small change. > > >> The comment "...

Re: [HACKERS] postgres_fdw : altering foreign table not invalidating prepare statement execution plan.

On 2016/10/17 20:12, Ashutosh Bapat wrote: On 2016/10/07 10:26, Amit Langote wrote: I think this (v4) patch is in the best shape so far. +1, except one small change. The comment "... On relcache invalidation events or the relevant syscache invalidation events, ..." specifies relcache

Re: [HACKERS] Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran

On Tue, Oct 18, 2016 at 12:34 PM, Tom Lane wrote: > Michael Paquier writes: >> And actually, enabling prngd would need to be controlled by a >> configure switch as well disabled by default, no? > > AFAICT, openssl has no configuration options

Re: [HACKERS] Patch to implement pg_current_logfile() function

Le 14/10/2016 à 20:45, Christoph Berg a écrit : > Re: Gilles Darold 2016-10-14 >> Agree, the usability of the current version is really a pain. What I've >> thought is that the function could return the csv log in all case when >> csvlog is set in

Re: [HACKERS] Parallel Index Scans

On Tue, Oct 18, 2016 at 4:08 PM, Rahila Syed wrote: >>Another point which needs some thoughts is whether it is good idea to >>use index relation size to calculate parallel workers for index scan. >>I think ideally for index scans it should be based on number of pages >>to

Re: [HACKERS] Gather Merge

Thanks Amit for reviewing this patch. On Mon, Oct 17, 2016 at 2:26 PM, Amit Kapila wrote: > On Wed, Oct 5, 2016 at 11:35 AM, Rushabh Lathia > wrote: > > Hi hackers, > > > > Attached is the patch to implement Gather Merge. > > > > Couple of

Re: [HACKERS] Parallel Index Scans

>Another point which needs some thoughts is whether it is good idea to >use index relation size to calculate parallel workers for index scan. >I think ideally for index scans it should be based on number of pages >to be fetched/scanned from index. IIUC, its not possible to know the exact number of

Re: [HACKERS] [PATCH] Better logging of COPY queries if log_statement='all'

> > According to my colleagues it would be very nice to have this feature. > > For instance, if you are trying to optimize PostgreSQL for application > > that uses COPY and you don't have access to or something like this. > > It could also be useful in some other cases. > > This use-case doesn't

Re: [HACKERS] Hash Indexes

On Wed, Oct 5, 2016 at 10:22 PM, Robert Haas wrote: > On Tue, Oct 4, 2016 at 12:36 AM, Amit Kapila wrote: >> I think one way to avoid the risk of deadlock in above scenario is to >> take the cleanup lock conditionally, if we get the cleanup lock

Re: [HACKERS] Query cancel seems to be broken in master since Oct 17

>What platform does the postgres server run on? Ubuntu OS name: "linux", version: "3.19.0-66-generic", arch: "amd64", family: "unix" 2016-10-18 11:05 GMT+03:00 Magnus Hagander : > > > On Tue, Oct 18, 2016 at 1:00 AM, Vladimir Sitnikov < > sitnikov.vladi...@gmail.com> wrote:

Re: [HACKERS] Batches, error handling and transaction in the protocol

> More generally speaking, the protocol appears to couple two different things which may be unrelated. On the one hand, we have a protocol > sync mechanism for error recovery (skip until Sync). One the other hand, we have an implicit transaction for extended query messages until > that same Sync.

Re: [HACKERS] Query cancel seems to be broken in master since Oct 17

On Tue, Oct 18, 2016 at 1:00 AM, Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > Hi, > > In pgjdbc we have regular regression testing against "build from > master" PostgreSQL, and recent master builds fail for "statement cancel" > test. > > The PostgreSQL as of Mon Oct 17 00:09:39 UTC

[HACKERS] Query cancel seems to be broken in master since Oct 17

Hi, In pgjdbc we have regular regression testing against "build from master" PostgreSQL, and recent master builds fail for "statement cancel" test. The PostgreSQL as of Mon Oct 17 00:09:39 UTC 2016 was fine, then "statement cancel" started to fail. The test executes "select pg_sleep(10)" and

[HACKERS] simplehash.h typo fix

it's -> its the the -> the--- ./src/include/lib/simplehash.h.orig 2016-10-18 09:31:22.712028458 +0200 +++ ./src/include/lib/simplehash.h 2016-10-18 09:37:00.050970588 +0200 @@ -256,7 +256,7 @@ return curelem; } -/* return distance between bucket and it's optimal position */ +/* return