[HACKERS] DROP FUNCTION of multiple functions

2016-10-31 Thread Peter Eisentraut
Here is a patch series that implements several changes in the internal grammar and node representation of function signatures. They are not necessarily meant to be applied separately, but they explain the progression of the changes nicely, so I left them like that for review. The end goal is to

Re: [HACKERS] Indirect indexes

2016-10-31 Thread Alvaro Herrera
Alvaro Herrera wrote: > I propose we introduce the concept of "indirect indexes". This is a WIP non-functional patch for indirect indexes. I've been distracted from working on it for some time already and will be off-line for half this month yet, but since this was discussed and seems to be

Re: [HACKERS] ECPG BUlk insert support using arrays

2016-10-31 Thread Tsunakawa, Takayuki
From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Haribabu Kommi > I didn't find any relevant thread about the discussion of Bulk insert support > in ECPG using arrays. Oracle supports the same and details are available > in [1]. > > > I see some

Re: [HACKERS] WIP: Barriers

2016-10-31 Thread Thomas Munro
On Thu, Aug 18, 2016 at 1:55 PM, Thomas Munro wrote: > On Tue, Aug 16, 2016 at 1:55 AM, Robert Haas wrote: >> If we're going to remove barrier.h, I think that should be a separate >> commit from creating a new barrier.h. > > OK. Here's a

Re: [HACKERS] identity columns

2016-10-31 Thread Peter Eisentraut
New patch. On 9/9/16 11:45 PM, Vitaly Burovoy wrote: > 1. The standard requires "... ALTER COLUMN ... SET GENERATED { ALWAYS > | BY DEFAULT }" (9075-2:2011 subcl 11.20), but the patch implements it > as "... ALTER COLUMN ... ADD GENERATED { ALWAYS | BY DEFAULT } AS > IDENTITY" Has both now.

[HACKERS] ECPG BUlk insert support using arrays

2016-10-31 Thread Haribabu Kommi
Hi All, I didn't find any relevant thread about the discussion of Bulk insert support in ECPG using arrays. Oracle supports the same and details are available in [1]. I see some performance benefits in supporting the same in ECPG also. Does any one worked on this area before? Are there any

[HACKERS] background sessions

2016-10-31 Thread Peter Eisentraut
Here is a patch for the background sessions C API and PL/Python support. This was previously submitted as "autonomous transactions", which proved controversial, and there have been several suggestions for a new name. I have renamed everything, removed all the incomplete PL/pgSQL stuff, did some

Re: [HACKERS] commit fest manager for CF 2016-11?

2016-10-31 Thread Thomas Munro
On Tue, Nov 1, 2016 at 4:15 PM, Peter Eisentraut wrote: > On 10/31/16 9:39 PM, Michael Paquier wrote: >> We are on the 1st, at least in my timezone. So the CF should start >> really soon, meaning that no new patches would get in. In a couple of >> hours that

Re: [HACKERS] commit fest manager for CF 2016-11?

2016-10-31 Thread Peter Eisentraut
On 10/31/16 9:39 PM, Michael Paquier wrote: > We are on the 1st, at least in my timezone. So the CF should start > really soon, meaning that no new patches would get in. In a couple of > hours that would be fine? I recall that the last times we tried to > sync with the US East coast time.

Re: [HACKERS] WAL logging problem in 9.4.3?

2016-10-31 Thread Kyotaro HORIGUCHI
Hi, At Sun, 2 Oct 2016 21:43:46 +0900, Michael Paquier wrote in > On Thu, Sep 29, 2016 at 10:02 PM, Kyotaro HORIGUCHI > wrote: > > Hello, > > > > At Thu, 29 Sep 2016

Re: [HACKERS] commit fest manager for CF 2016-11?

2016-10-31 Thread Michael Paquier
On Tue, Nov 1, 2016 at 10:27 AM, Haribabu Kommi wrote: > On Mon, Oct 31, 2016 at 4:31 PM, Michael Paquier > wrote: >> >> On Mon, Oct 31, 2016 at 1:49 PM, Peter Eisentraut >> wrote: >> > Commit fest CF 2016-11

Re: [HACKERS] commit fest manager for CF 2016-11?

2016-10-31 Thread Haribabu Kommi
On Mon, Oct 31, 2016 at 4:31 PM, Michael Paquier wrote: > On Mon, Oct 31, 2016 at 1:49 PM, Peter Eisentraut > wrote: > > Commit fest CF 2016-11 is supposed to start in about a day. I don't > > think a commit fest manager was chosen

Re: [HACKERS] Logical decoding and walsender timeouts

2016-10-31 Thread Vladimir Gordiychuk
>>> When sending a big message, WalSndWriteData() notices that it's >>> approaching timeout and tries to send a keepalive request, but the >>> request just gets buffered behind the remaining output plugin data and >>> isn't seen by the client until the client has received the rest of the >>>

Re: [HACKERS] Unsafe use of relation->rd_options without checking its type

2016-10-31 Thread neha khatri
> > > ^ > > The reason for the error is that transformOnConflictArbiter applies > RelationIsUsedAsCatalogTable() to something that it doesn't know to > be a plain relation --- it's a view in this case. And that macro > blindly assumes

[HACKERS] WIP: [[Parallel] Shared] Hash

2016-10-31 Thread Thomas Munro
Hi hackers, In PostgreSQL 9.6, hash joins can be parallelised under certain conditions, but a copy of the hash table is built in every participating backend. That means that memory and CPU time are wasted. In many cases, that's OK: if the hash table contents are small and cheap to compute, then

Re: [HACKERS] WAL consistency check facility

2016-10-31 Thread Michael Paquier
On Mon, Oct 31, 2016 at 9:31 PM, Robert Haas wrote: > On Fri, Oct 28, 2016 at 2:05 AM, Michael Paquier >> - Instead of palloc'ing the old and new pages to compare, it would be >> more performant to keep around two static buffers worth of BLCKSZ and >> just use that. This

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-10-31 Thread Abhijit Menon-Sen
At 2016-09-28 13:13:56 -0400, robertmh...@gmail.com wrote: > > I hope that the fact that there's been no discussion for the last > three weeks doesn't mean this effort is dead; I would like very > much to see it move forward. Here's an updated patch. Sorry, I got busy elswhere. I struggled with

[HACKERS] auto_explain vs. parallel query

2016-10-31 Thread Tomas Vondra
Hi, While debugging something on 9.6, I've noticed that auto_explain handles parallel queries in a slightly strange way - both the leader and all the workers log their chunk of the query (i.e. the leader logs explain for the whole query, while workers only log the parts they've been

Re: [HACKERS] Improvements in psql hooks for variables

2016-10-31 Thread Rahila Syed
Hello, I have applied this patch on latest HEAD and have done basic testing which works fine. Some comments, >if (current->assign_hook) >- (*current->assign_hook) (current->value); >- return true; >+ { >+ confirmed =

Re: [HACKERS] WAL consistency check facility

2016-10-31 Thread Michael Paquier
On Mon, Oct 31, 2016 at 9:31 PM, Robert Haas wrote: > On Fri, Oct 28, 2016 at 2:05 AM, Michael Paquier > wrote: >> And here we go. Here is a review as well as a large brush-up for this >> patch. A couple of things: >> - wal_consistency is using a

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

2016-10-31 Thread Tomas Vondra
On 10/31/2016 02:24 PM, Tomas Vondra wrote: On 10/31/2016 05:01 AM, Jim Nasby wrote: On 10/30/16 1:32 PM, Tomas Vondra wrote: Now, maybe this has nothing to do with PostgreSQL itself, but maybe it's some sort of CPU / OS scheduling artifact. For example, the system has 36 physical cores, 72

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

2016-10-31 Thread Tomas Vondra
On 10/31/2016 08:43 PM, Amit Kapila wrote: On Mon, Oct 31, 2016 at 7:58 PM, Tomas Vondra wrote: On 10/31/2016 02:51 PM, Amit Kapila wrote: And moreover, this setup (single device for the whole cluster) is very common, we can't just neglect it. But my main point

Re: [HACKERS] sequential scan result order vs performance

2016-10-31 Thread Corey Huinker
On Sun, Oct 30, 2016 at 11:37 PM, Jim Nasby wrote: > BTW, I've sometimes wished for a mode where queries would silently have > result ordering intentionally futzed, to eliminate any possibility of > dependence on tuple ordering (as well as having sequences start at some

Re: [HACKERS] COPY as a set returning function

2016-10-31 Thread Corey Huinker
Attached is a patch that implements copy_srf(). The function signature reflects cstate more than it reflects the COPY options (filename+is_program instead of FILENAME or PROGRAM, etc) CREATE OR REPLACE FUNCTION copy_srf( filenametext DEFAULT null, is_program boolean DEFAULT false,

[HACKERS] Increase pltcl test coverage

2016-10-31 Thread Jim Nasby
This patch increases test coverage for pltcl, from 70% to 83%. Aside from that, the work on this uncovered 2 new bugs (the trigger return one I just submitted, as well as a bug in the SRF/composite patch). -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics,

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

2016-10-31 Thread Amit Kapila
On Mon, Oct 31, 2016 at 7:58 PM, Tomas Vondra wrote: > On 10/31/2016 02:51 PM, Amit Kapila wrote: > And moreover, this setup (single device for the whole cluster) is very > common, we can't just neglect it. > > But my main point here really is that the trade-off in

[HACKERS] Fix bug in handling of dropped columns in pltcl triggers

2016-10-31 Thread Jim Nasby
While reviewing code coverage in pltcl, I uncovered a bug in trigger function return handling. If you returned the munged name of a dropped column, that would silently be ignored. It would be unusual to hit this, since dropped columns end up with names like "...pg.dropped.2...", but

Re: [HACKERS] Unsafe use of relation->rd_options without checking its type

2016-10-31 Thread Peter Geoghegan
On Mon, Oct 31, 2016 at 11:57 AM, Tom Lane wrote: > Now that I've seen this I wonder which other uses of rd_options are > potentially broken. RelationIsUsedAsCatalogTable() is hardly the > only macro that is assuming with little justification that it's > applied to the right

[HACKERS] Unsafe use of relation->rd_options without checking its type

2016-10-31 Thread Tom Lane
I looked into bug#14397. The submitter was discourteous enough not to provide an in-line example, but here it is: CREATE TABLE IF NOT EXISTS TEST_1 ( ID SERIAL PRIMARY KEY, C1 BYTEA, C2 TEXT NOT NULL, C3 BOOLEAN NOT NULL DEFAULT FALSE, CONSTRAINT TEST_1_unique_idx

Re: [HACKERS] Query regarding selectDumpableExtension()

2016-10-31 Thread Tom Lane
amul sul writes: > Thanks for your explanation, I agree that this is not a single scenario > where we need special care, but still my question stands there, why do we > really need to dump built-in extension? It's not built-in. It's installed by default, yes, but it's also

Re: [HACKERS] Query regarding selectDumpableExtension()

2016-10-31 Thread amul sul
On 31 Oct 2016 6:48 pm, "Tom Lane" wrote: > > amul sul writes: > > On Fri, Oct 28, 2016 at 6:22 PM, Robert Haas wrote: > >> There's a comment in dumpExtension() that explains it. > > > Let me explain the case I'm trying to tackle. I

Re: [HACKERS] pg_sequence catalog

2016-10-31 Thread Peter Eisentraut
On 9/10/16 7:17 AM, Peter Eisentraut wrote: > Let's start with that. Here is a patch that adds a pg_sequences view in > the style of pg_tables, pg_indexes, etc. This seems useful independent > of anything else, but would give us more freedom to change things around > behind the scenes. I have

Re: [HACKERS] Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)

2016-10-31 Thread Tom Lane
Andres Freund writes: > On 2016-09-14 19:28:25 -0400, Tom Lane wrote: >> So I think we should continue investigating this way of doing things. >> I'll try to take a look at the executor end of it tomorrow. However >> I'm leaving Friday for a week's vacation, and may not have

Re: [HACKERS] Proposal: scan key push down to heap [WIP]

2016-10-31 Thread Andres Freund
On 2016-10-31 09:28:00 -0400, Robert Haas wrote: > On Fri, Oct 28, 2016 at 2:46 AM, Andres Freund wrote: > > Well, that'll also make the feature not particularly useful :(. My > > suspicion is that the way to suceed here isn't to rely more on testing > > as part of the scan,

Re: [HACKERS] Radix tree for character conversion

2016-10-31 Thread Daniel Gustafsson
> On 27 Oct 2016, at 09:23, Kyotaro HORIGUCHI > wrote: > > Hello, thank you very much for the work. My work became quite > easier with it. > > At Tue, 25 Oct 2016 12:23:48 +0300, Heikki Linnakangas > wrote in

Re: [HACKERS] Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)

2016-10-31 Thread Andres Freund
Hi Tom, On 2016-09-14 19:28:25 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2016-09-12 19:35:22 -0400, Tom Lane wrote: > >> Anyway I'll draft a prototype and then we can compare. > > > Ok, cool. > > Here's a draft patch that is just meant to investigate what the

Re: [HACKERS] emergency outage requiring database restart

2016-10-31 Thread Oskari Saarenmaa
27.10.2016, 21:53, Merlin Moncure kirjoitti: As noted earlier, I was not able to reproduce the issue with crashme.sh, which was: NUM_FORKS=16 do_parallel psql -p 5432 -c"select PushMarketSample('1740')" castaging_test do_parallel psql -p 5432 -c"select PushMarketSample('4400')" castaging_test

Re: [HACKERS] WAL consistency check facility

2016-10-31 Thread Kuntal Ghosh
On Fri, Oct 28, 2016 at 11:35 AM, Michael Paquier wrote: > And here we go. Here is a review as well as a large brush-up for this > patch. A couple of things: Thanks for reviewing the patch in detail. > - Speaking of which using BKPIMAGE_IS_REQUIRED_FOR_REDO stored in

ParallelFinish-hook of FDW/CSP (Re: [HACKERS] Steps inside ExecEndGather)

2016-10-31 Thread Kouhei Kaigai
Hello, The attached patch implements the suggestion by Amit before. What I'm motivated is to collect extra run-time statistics specific to a particular ForeignScan/CustomScan, not only the standard Instrumentation; like DMA transfer rate or execution time of GPU kernels in my case. Per-node DSM

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

2016-10-31 Thread Tomas Vondra
On 10/31/2016 02:51 PM, Amit Kapila wrote: On Mon, Oct 31, 2016 at 12:02 AM, Tomas Vondra wrote: Hi, On 10/27/2016 01:44 PM, Amit Kapila wrote: I've read that analysis, but I'm not sure I see how it explains the "zig zag" behavior. I do understand that shifting

[HACKERS] PassDownLimitBound for ForeignScan/CustomScan [take-2]

2016-10-31 Thread Kouhei Kaigai
Hello, The attached patch is revised version of the pass-down-bounds feature. Its functionality is not changed from the previous version, however, implementation was revised according to the discussion at the last CF. This patch add a new fields (ps_numTuples) to the PlanState. This is a hint

Re: [HACKERS] DML and column cound in aggregated subqueries

2016-10-31 Thread Andres Freund
On 2016-10-31 09:35:57 -0400, Tom Lane wrote: > Andres Freund writes: > > this doesn't look right. The ctid shouldn't be in the aggregate output - > > after all it's pretty much meaningless here. > > I suspect it's being added to support EvalPlanQual row re-fetches. Hm, that

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

2016-10-31 Thread Amit Kapila
On Mon, Oct 31, 2016 at 7:02 PM, Tomas Vondra wrote: > > The remaining benchmark with 512 clog buffers completed, and the impact > roughly matches Dilip's benchmark - that is, increasing the number of clog > buffers eliminates all positive impact of the patches

Re: [HACKERS] Dumb mistakes in WalSndWriteData()

2016-10-31 Thread Andres Freund
On 2016-10-31 09:44:16 -0400, Robert Haas wrote: > On Mon, Oct 31, 2016 at 4:59 AM, Andres Freund wrote: > > I^Wsomebody appears to have made a number of dumb mistakes in > > WalSndWriteData(), namely: > > 1) The timestamp is set way too late, after > >

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

2016-10-31 Thread Amit Kapila
On Mon, Oct 31, 2016 at 12:02 AM, Tomas Vondra wrote: > Hi, > > On 10/27/2016 01:44 PM, Amit Kapila wrote: > > I've read that analysis, but I'm not sure I see how it explains the "zig > zag" behavior. I do understand that shifting the contention to some other >

Re: [HACKERS] Dumb mistakes in WalSndWriteData()

2016-10-31 Thread Robert Haas
On Mon, Oct 31, 2016 at 4:59 AM, Andres Freund wrote: > I^Wsomebody appears to have made a number of dumb mistakes in > WalSndWriteData(), namely: > 1) The timestamp is set way too late, after >pq_putmessage_noblock(). That'll sometimes work, sometimes not. I >have no

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

2016-10-31 Thread Tomas Vondra
On 10/30/2016 07:32 PM, Tomas Vondra wrote: Hi, On 10/27/2016 01:44 PM, Amit Kapila wrote: On Thu, Oct 27, 2016 at 4:15 AM, Tomas Vondra wrote: FWIW I plan to run the same test with logged tables - if it shows similar regression, I'll be much more worried,

Re: [HACKERS] DML and column cound in aggregated subqueries

2016-10-31 Thread Tom Lane
Andres Freund writes: > this doesn't look right. The ctid shouldn't be in the aggregate output - > after all it's pretty much meaningless here. I suspect it's being added to support EvalPlanQual row re-fetches. > Casting a wider net: find_hash_columns() and it's subroutines

Re: [HACKERS] Logical decoding and walsender timeouts

2016-10-31 Thread Craig Ringer
On 31 October 2016 at 16:52, Andres Freund wrote: > Hi, > > On 2016-10-31 16:34:38 +0800, Craig Ringer wrote: >> TL;DR: Logical decoding clients need to generate their own keepalives >> and not rely on the server requesting them to prevent timeouts. Or >> admins should raise

Re: [HACKERS] Proposal: scan key push down to heap [WIP]

2016-10-31 Thread Robert Haas
On Fri, Oct 28, 2016 at 2:46 AM, Andres Freund wrote: > Well, that'll also make the feature not particularly useful :(. My > suspicion is that the way to suceed here isn't to rely more on testing > as part of the scan, but create a more general fastpath for qual > evaluation,

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

2016-10-31 Thread Tomas Vondra
On 10/31/2016 05:01 AM, Jim Nasby wrote: On 10/30/16 1:32 PM, Tomas Vondra wrote: Now, maybe this has nothing to do with PostgreSQL itself, but maybe it's some sort of CPU / OS scheduling artifact. For example, the system has 36 physical cores, 72 virtual ones (thanks to HT). I find it strange

Re: [HACKERS] Overlook in 2bd9e412?

2016-10-31 Thread Robert Haas
On Fri, Oct 28, 2016 at 8:46 AM, Julien Rouhaud wrote: > It looks like pq_putmessage_hook and pq_flush_hook were meant for > development purpose and not supposed to be committed. > > Attached patch remove them. Thanks. Those were actually remnants of an earlier design

Re: [HACKERS] Query regarding selectDumpableExtension()

2016-10-31 Thread Tom Lane
amul sul writes: > On Fri, Oct 28, 2016 at 6:22 PM, Robert Haas wrote: >> There's a comment in dumpExtension() that explains it. > Let me explain the case I'm trying to tackle. I have two old dump > data, each of them have couple objects depend on

Re: [HACKERS] Proposal : For Auto-Prewarm.

2016-10-31 Thread Robert Haas
On Fri, Oct 28, 2016 at 3:40 AM, Andres Freund wrote: >> >> There is not much common functionality between the two. > > I don't really agree. For me manual and automated prewarming are pretty > closely related. Sure they have their independent usages, and not too > much code

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

2016-10-31 Thread Robert Haas
On Fri, Oct 28, 2016 at 3:09 AM, Ashutosh Bapat wrote: > I think there are going to be two kinds of partitioning use-cases. > First, carefully hand-crafted by DBAs so that every partition is > different from other and so is every join between two partitions. >

Re: [HACKERS] sequences and pg_upgrade

2016-10-31 Thread Peter Eisentraut
On 9/30/16 12:50 PM, Anastasia Lubennikova wrote: > The patches are good, no complaints. > But again, I have the same question. > I was confused, why do we always dump sequence data, > because I'd overlooked the --sequence-data key. I'd rather leave this > option, > because it's quite non

Re: [HACKERS] WAL consistency check facility

2016-10-31 Thread Robert Haas
On Fri, Oct 28, 2016 at 2:05 AM, Michael Paquier wrote: > And here we go. Here is a review as well as a large brush-up for this > patch. A couple of things: > - wal_consistency is using a list of RMGRs, at the cost of being > PGC_POSTMASTER. I'd suggest making it

[HACKERS] DML and column cound in aggregated subqueries

2016-10-31 Thread Andres Freund
Hi, while hacking up nodeAgg.c to use a dedicated slot/desc for the hashtable, an assert I placed brought up a weird case: regression[29535][1]=# EXPLAIN VERBOSE update bar set f2 = f2 + 100 where f1 in (select f1 from foo);

Re: [HACKERS] Improve output of BitmapAnd EXPLAIN ANALYZE

2016-10-31 Thread Emre Hasegeli
The BRIN Bitmap Index Scan has the same problem. I have seen people confused by this. I think N/A would clearly improve the situation. -- 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] sequential scan result order vs performance

2016-10-31 Thread Dagfinn Ilmari Mannsåker
Jim Nasby writes: > BTW, I've sometimes wished for a mode where queries would silently have > result ordering intentionally futzed, to eliminate any possibility of > dependence on tuple ordering (as well as having sequences start at some > random value). FWIW, SQLite

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

2016-10-31 Thread Andreas Karlsson
I have attached a version of the patch rebased on top of the OpenSSL 1.1 changes. Andreas diff --git a/src/backend/libpq/be-secure-openssl.c b/src/backend/libpq/be-secure-openssl.c index 668f217..a1b582f 100644 --- a/src/backend/libpq/be-secure-openssl.c +++

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

2016-10-31 Thread Gilles Darold
Le 31/10/2016 à 04:35, Karl O. Pinc a écrit : > Hi Gilles, > > On Sat, 29 Oct 2016 22:00:08 +0200 > Gilles Darold wrote: > >> The attached v10 of the current_logfiles patch > Attached is a patch to apply on top of the v10 patch. > > It updates current_logfiles only once

[HACKERS] Dumb mistakes in WalSndWriteData()

2016-10-31 Thread Andres Freund
Hi, I^Wsomebody appears to have made a number of dumb mistakes in WalSndWriteData(), namely: 1) The timestamp is set way too late, after pq_putmessage_noblock(). That'll sometimes work, sometimes not. I have no idea how that ended up happening. It's eye-wateringly dumb. 2) We only do

Re: [HACKERS] Logical decoding and walsender timeouts

2016-10-31 Thread Andres Freund
Hi, On 2016-10-31 16:34:38 +0800, Craig Ringer wrote: > TL;DR: Logical decoding clients need to generate their own keepalives > and not rely on the server requesting them to prevent timeouts. Or > admins should raise the wal_sender_timeout by a LOT when using logical > decoding on DBs with any

[HACKERS] Logical decoding and walsender timeouts

2016-10-31 Thread Craig Ringer
Hi all I've been investigating some intermittent timeout issues I've seen with BDR users in the wild and I think I've identified an issue with how logical decoding sends data and handles feedback. TL;DR: Logical decoding clients need to generate their own keepalives and not rely on the server

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

2016-10-31 Thread Gilles Darold
Le 30/10/2016 à 08:04, Karl O. Pinc a écrit : > On Sat, 29 Oct 2016 22:00:08 +0200 > Gilles Darold wrote: > >> The attached v10 of the current_logfiles patch include your last >> changes on documentation but not the patch on v9 about the >> user-supplied GUC value. I

Re: [HACKERS] sequential scan result order vs performance

2016-10-31 Thread Albe Laurenz
Jim Nasby wrote: > On 10/30/16 9:12 AM, Tom Lane wrote: >> I think there will be a lot of howls. People expect that creating >> a table by inserting a bunch of rows, and then reading back those >> rows, will not change the order. We already futzed with that guarantee >> a bit with syncscans, but

Re: [HACKERS] Query regarding selectDumpableExtension()

2016-10-31 Thread amul sul
On Fri, Oct 28, 2016 at 6:22 PM, Robert Haas wrote: > On Thu, Oct 27, 2016 at 2:11 AM, amul sul wrote: >> selectDumpableExtension() function skip >> s dump of >> built-in extensions in case of binary-upgrade only, >> why not in normal >> dump >> ? >>