Re: [HACKERS] postgres_fdw behaves oddly

(2014/11/19 15:56), Ashutosh Bapat wrote: On Wed, Nov 19, 2014 at 12:14 PM, Etsuro Fujita mailto:fujita.ets...@lab.ntt.co.jp>> wrote: (2014/11/19 14:58), Ashutosh Bapat wrote: May be we should modify use_physical_tlist() to return false in case of RELKIND_FOREIGN_TA

Re: [HACKERS] postgres_fdw behaves oddly

(2014/11/19 14:55), Etsuro Fujita wrote: (2014/11/18 18:37), Ashutosh Bapat wrote: On Tue, Nov 18, 2014 at 1:55 PM, Etsuro Fujita mailto:fujita.ets...@lab.ntt.co.jp>> wrote: (2014/11/17 19:54), Ashutosh Bapat wrote: Here are comments for postgres_fdw-syscol patch. 3. Si

Re: [HACKERS] postgres_fdw behaves oddly

On Wed, Nov 19, 2014 at 12:14 PM, Etsuro Fujita wrote: > (2014/11/19 14:58), Ashutosh Bapat wrote: > >> On Wed, Nov 19, 2014 at 11:18 AM, Etsuro Fujita >> mailto:fujita.ets...@lab.ntt.co.jp>> wrote: >> (2014/11/18 18:27), Ashutosh Bapat wrote: >> On Tue, Nov 18, 2014 at 1:50 PM, Etsur

Re: [HACKERS] postgres_fdw behaves oddly

(2014/11/19 14:58), Ashutosh Bapat wrote: On Wed, Nov 19, 2014 at 11:18 AM, Etsuro Fujita mailto:fujita.ets...@lab.ntt.co.jp>> wrote: (2014/11/18 18:27), Ashutosh Bapat wrote: On Tue, Nov 18, 2014 at 1:50 PM, Etsuro Fujita Here are my comments about the pat

Re: [HACKERS] psql \watch always ignores \pset null

Will Leinweber writes: > On Tue, Nov 18, 2014 at 9:54 PM, Tom Lane wrote: >> Fujii Masao writes: >>> Is there any reason why \watch must ignore \pset null setting? >> Hmmm ... the comment offers a reasonable argument for forcing pager = 0, >> but I agree the nullPrint change is not adequately e

Re: [HACKERS] psql \watch always ignores \pset null

On Tue, Nov 18, 2014 at 9:54 PM, Tom Lane wrote: > > Fujii Masao writes: > > Hi, > >> /* > >> * Set up rendering options, in particular, disable the pager, because > >> * nobody wants to be prompted while watching the output of 'watch'. > >> */ > >> myopt.nullPrint = NULL; > >> myopt.topt.page

Re: [HACKERS] postgres_fdw behaves oddly

On Wed, Nov 19, 2014 at 11:18 AM, Etsuro Fujita wrote: > (2014/11/18 18:27), Ashutosh Bapat wrote: > >> On Tue, Nov 18, 2014 at 1:50 PM, Etsuro Fujita >> mailto:fujita.ets...@lab.ntt.co.jp>> wrote: >> (2014/11/17 19:36), Ashutosh Bapat wrote: >> > > Here are my comments about the pat

Re: [HACKERS] postgres_fdw behaves oddly

(2014/11/18 18:37), Ashutosh Bapat wrote: On Tue, Nov 18, 2014 at 1:55 PM, Etsuro Fujita mailto:fujita.ets...@lab.ntt.co.jp>> wrote: (2014/11/17 19:54), Ashutosh Bapat wrote: Here are comments for postgres_fdw-syscol patch. Code --- 1. Instead of a si

Re: [HACKERS] psql \watch always ignores \pset null

Fujii Masao writes: > Hi, >> /* >> * Set up rendering options, in particular, disable the pager, because >> * nobody wants to be prompted while watching the output of 'watch'. >> */ >> myopt.nullPrint = NULL; >> myopt.topt.pager = 0; > I found psql's \watch command always ignores \pset null se

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On Thu, Nov 13, 2014 at 10:25 AM, Alvaro Herrera wrote: > Andres Freund wrote: >> On 2014-11-12 18:23:38 -0500, Robert Haas wrote: > >> > > The problem is that it's very hard to avoid the wrong index's >> > > relfilenode being used when swapping the relfilenodes between two >> > > indexes. >> > >>

Re: [HACKERS] Multiple call of GetTransactionSnapshot in single flow

Rajeev rastogi writes: > What is the reason for taking snapshot multiple time: To get the right answer. I believe Robert Haas has been down this rabbit hole most recently before you: see commits d573e239f and 532994299. The execution snapshot has to be (at minimum) later than acquisition of all

Re: [HACKERS] postgres_fdw behaves oddly

(2014/11/18 18:27), Ashutosh Bapat wrote: On Tue, Nov 18, 2014 at 1:50 PM, Etsuro Fujita mailto:fujita.ets...@lab.ntt.co.jp>> wrote: (2014/11/17 19:36), Ashutosh Bapat wrote: Here are my comments about the patch fscan_reltargetlist.patch 2. Instead of using rel->reltarge

Re: [HACKERS] inherit support for foreign tables

(2014/11/18 18:09), Ashutosh Bapat wrote: I looked at the patch. It looks good now. Once we have the inh patch ready, we can mark this item as ready for commiter. Thanks for the review! Best regards, Etsuro Fujita -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

[HACKERS] Multiple call of GetTransactionSnapshot in single flow

I have observed in some places like exec_bind_message and exec_simple_query, Though these two function have already got snapshot but before they call function PortalStart, current snapshot gets popped off and then they pass InvalidSnapshot as parameter because of which inside PortalStart again

[HACKERS] psql \watch always ignores \pset null

Hi, >/* > * Set up rendering options, in particular, disable the pager, because > * nobody wants to be prompted while watching the output of 'watch'. > */ >myopt.nullPrint = NULL; >myopt.topt.pager = 0; I found psql's \watch command always ignores \pset null setting. The a

Re: [HACKERS] pg_receivexlog --status-interval add fsync feedback

On Wed, Nov 19, 2014 at 10:20 AM, Michael Paquier wrote: > > > On Tue, Nov 18, 2014 at 2:36 AM, Fujii Masao wrote: >> >> On Thu, Nov 13, 2014 at 12:38 PM, Fujii Masao >> wrote: >> > Thanks for reviewing the patch! >> > >> > On Thu, Nov 13, 2014 at 4:05 AM, Alvaro Herrera >> > wrote: >> >> Fujii

Re: [HACKERS] PostgreSQL doesn't stop propley when --slot option is specified with pg_receivexlog.

On Mon, Nov 17, 2014 at 12:30 PM, Michael Paquier wrote: > On Mon, Nov 17, 2014 at 10:02 AM, Fujii Masao wrote: >> On Sat, Nov 15, 2014 at 9:10 PM, Michael Paquier >> wrote: >>> Yep, sounds a good thing to do if master requested answer from the >>> client in the keepalive message. Something like

Re: [HACKERS] pg_basebackup vs. Windows and tablespaces

On Tue, Nov 18, 2014 at 7:49 PM, Alvaro Herrera wrote: > > Amit Kapila wrote: > > On Sun, Nov 16, 2014 at 6:15 AM, Alvaro Herrera < alvhe...@2ndquadrant.com> > > wrote: > > > > > > > One use case mentioned upthread is having the clone be created in the > > > > > same machine as the source server.

Re: [HACKERS] tracking commit timestamps

On 15/11/14 13:36, Simon Riggs wrote: On 15 November 2014 04:32, Steve Singer wrote: The use cases I'm talking about aren't really replication related. Often I have come across systems that want to do something such as 'select * from orders where X > the_last_row_I_saw order by X' and then do

Re: [HACKERS] pg_receivexlog --status-interval add fsync feedback

On Tue, Nov 18, 2014 at 2:36 AM, Fujii Masao wrote: > On Thu, Nov 13, 2014 at 12:38 PM, Fujii Masao > wrote: > > Thanks for reviewing the patch! > > > > On Thu, Nov 13, 2014 at 4:05 AM, Alvaro Herrera > > wrote: > >> Fujii Masao wrote: > >> > >>> --- 127,152 > >>>When this opti

Re: [HACKERS] Doing better at HINTing an appropriate column within errorMissingColumn()

Peter Geoghegan writes: > On Tue, Nov 18, 2014 at 3:29 PM, Robert Haas wrote: >> On Mon, Nov 17, 2014 at 3:04 PM, Peter Geoghegan wrote: >>> postgres=# select qty from orderlines ; >>> ERROR: 42703: column "qty" does not exist >>> HINT: Perhaps you meant to reference the column "orderlines"."q

Re: [HACKERS] Doing better at HINTing an appropriate column within errorMissingColumn()

On Tue, Nov 18, 2014 at 3:29 PM, Robert Haas wrote: > On Mon, Nov 17, 2014 at 3:04 PM, Peter Geoghegan wrote: >> postgres=# select qty from orderlines ; >> ERROR: 42703: column "qty" does not exist >> LINE 1: select qty from orderlines ; >>^ >> HINT: Perhaps you meant to referen

Re: [HACKERS] Doing better at HINTing an appropriate column within errorMissingColumn()

On Mon, Nov 17, 2014 at 3:04 PM, Peter Geoghegan wrote: > postgres=# select qty from orderlines ; > ERROR: 42703: column "qty" does not exist > LINE 1: select qty from orderlines ; >^ > HINT: Perhaps you meant to reference the column "orderlines"."quantity". > """ I don't buy th

Re: [HACKERS] GIN pageinspect functions

On Tue, Nov 18, 2014 at 2:01 PM, Peter Geoghegan wrote: > Do you intend to fix this up? BTW, how do you feel about the B-Tree check extension [1]? It's very much related to pageinspect -- it's more or less a derivative. I don't think I'm going to have time (or that there is sufficient review band

Re: [HACKERS] Use of recent Russian TZ changes in regression tests

I wrote: > Another thought that just occurred to me is that we need to test > both advance and retreat of a zone's notion of standard time, but > that doesn't mean that both cases have to be tested in the same > zone. The 2011 Russian advance is probably reasonable to depend > on by now, but maybe

Re: [HACKERS] Use of recent Russian TZ changes in regression tests

David G Johnston writes: > Tom Lane-2 wrote >> The good thing about testing with the MSK changes is that those are >> quite well-documented and so we don't have to fear getting blindsided >> by future updates to the IANA database. So basically we are trading off >> known short term pain (for peop

Re: [HACKERS] New Event Trigger: table_rewrite

Dimitri Fontaine wrote: > In the CLUSTER implementation we have only one call site for invoking > the Event Trigger, in cluster_rel(). While it's true that in the single > relation case, the relation is opened in cluster() then cluster_rel() is > called, the opening is done with NoLock in cluster(

Re: [HACKERS] Additional role attributes && superuser review

On 11/18/2014 04:58 PM, Adam Brightwell wrote: All, Currently, I am using int32 simply because int64 is causing some issues. The issue is that genbki.pl is not able to associate it with the int8 type as defined in pg_type.h. Therefore Schema_pg_authid in sch

Re: [HACKERS] Use of recent Russian TZ changes in regression tests

Tom Lane-2 wrote > The good thing about testing with the MSK changes is that those are > quite well-documented and so we don't have to fear getting blindsided > by future updates to the IANA database. So basically we are trading off > known short term pain (for people on machines with old TZ files

Re: [HACKERS] Additional role attributes && superuser review

Adam Brightwell writes: > Currently, I am using int32 simply because int64 is causing some issues. > The issue is that genbki.pl is not able to associate it with the int8 type > as defined in pg_type.h. Therefore Schema_pg_authid in schemapg.h isn't > defined correctly. I've been digging and scr

Re: [HACKERS] New Event Trigger: table_rewrite

Hi, Michael Paquier writes: > 1) This patch is authorizing VACUUM and CLUSTER to use the event > triggers ddl_command_start and ddl_command_end, but aren't those > commands actually not DDLs but control commands? Reverted in the attached version 3 of the patch. > 6) in_table_rewrite seems unnec

Re: [HACKERS] Add shutdown_at_recovery_target option to recovery.conf

On 18/11/14 12:57, Simon Riggs wrote: On 31 October 2014 15:18, Petr Jelinek wrote: Attached is the v2 of the patch with the review comments addressed (see below). ... Done, there is now action_at_recovery_target which can be set to either pause, continue or shutdown, defaulting to pause (wh

Re: [HACKERS] GIN pageinspect functions

On Tue, Nov 4, 2014 at 7:26 AM, Amit Kapila wrote: > I think these functions will be quite useful for debugging purpose > and we already have similar function's for other index (btree). This patch has bitrotted. I attach rebased revision, for the convenience of others - V1.3 of pageinspect will n

Re: [HACKERS] Additional role attributes && superuser review

All, > Currently, I am using int32 simply because int64 is causing some issues. > The issue is that genbki.pl is not able to associate it with the int8 > type as defined in pg_type.h. Therefore Schema_pg_authid in schemapg.h > isn't defined correctly. I've been digging and scratching my head on

[HACKERS] Use of recent Russian TZ changes in regression tests

[ moving discussion from -packagers to -hackers ] Summary for onlookers: Bjorn Munch complained that the timestamptz regression tests added in commit b2cbced9e failed on his Solaris machine; it emerged that he uses --with-system-tzdata and the tzdata files on his machine predate 2014h when the rec

Re: [HACKERS] proposal: plpgsql - Assert statement

2014-11-18 22:28 GMT+01:00 Andrew Dunstan : > > On 11/18/2014 04:11 PM, Pavel Stehule wrote: > >> >> >> 2014-11-18 21:27 GMT+01:00 Andrew Dunstan > and...@dunslane.net>>: >> >> >> >> On 11/18/2014 02:53 PM, Jim Nasby wrote: >> >> On 11/18/14, 9:31 AM, Andrew Dunstan wrote: >> >> >>

Re: [HACKERS] proposal: plpgsql - Assert statement

On 11/18/2014 04:11 PM, Pavel Stehule wrote: 2014-11-18 21:27 GMT+01:00 Andrew Dunstan >: On 11/18/2014 02:53 PM, Jim Nasby wrote: On 11/18/14, 9:31 AM, Andrew Dunstan wrote: Frankly, I find this whole proposal, and all the suggested

Re: [HACKERS] Review of Refactoring code for sync node detection

On Tue, Nov 18, 2014 at 6:33 PM, Simon Riggs wrote: > Can we just wait on this patch until we have the whole feature? > Well, this may take some time to even define, and even if goals are clearly defined this may take even more time to have a prototype to discuss about. > We quite often break l

Re: [HACKERS] proposal: plpgsql - Assert statement

On 18/11/14 22:11, Pavel Stehule wrote: 2014-11-18 21:27 GMT+01:00 Andrew Dunstan mailto:and...@dunslane.net>>: I frequently write one-statement bodies of IF statements. To me that's not a big deal either :-) anybody did it, but it doesn't need so it is perfect :) I understand well t

Re: [HACKERS] proposal: plpgsql - Assert statement

2014-11-18 21:27 GMT+01:00 Andrew Dunstan : > > On 11/18/2014 02:53 PM, Jim Nasby wrote: > >> On 11/18/14, 9:31 AM, Andrew Dunstan wrote: >> >>> >>> Frankly, I find this whole proposal, and all the suggested alternatives, >>> somewhat ill-conceived. PLPGSQL is a wordy language. If you want somethi

[HACKERS] pg_test_fsync file descriptor leak

The open_datasync code opens the output file as a test to make sure the flags are accepted by the OS, and if it succeeds it then immediately opens the file again with the same flags, overwriting and so leaking the descriptor from the previous open. On Windows MinGW, this prevents the final unlink

Re: [HACKERS] 9.5: Better memory accounting, towards memory-bounded HashAgg

On 11/17/14, 10:50 AM, Tomas Vondra wrote: Either of these restrictions would prevent a situation where a context has to update accounting for two parent contexts. That'd allow updating a single place (because each context has a single parent context with tracking requested). Another option mig

Re: [HACKERS] Additional role attributes && superuser review

All, > 2. Catalog Representation: > > Condense all attributes in pg_authid to single int64 column and create > bitmasks accordingly. > I have been working on these changes and I was hoping for some assistance/recommendations. Currently, I am using int32 simply because int64 is causing some issu

Re: [HACKERS] proposal: plpgsql - Assert statement

On 11/18/2014 02:53 PM, Jim Nasby wrote: On 11/18/14, 9:31 AM, Andrew Dunstan wrote: Frankly, I find this whole proposal, and all the suggested alternatives, somewhat ill-conceived. PLPGSQL is a wordy language. If you want something more terse, use something else. Adding these sorts of synt

Re: [HACKERS] BRIN and PageIndexDeleteNoCompact

On 11/18/2014 09:46 PM, Alvaro Herrera wrote: Heikki Linnakangas wrote: How about replacing PageIndexDeleteNoCompact() with something more like PageIndexTupleDelete()? It ought to be both faster and simpler. No objection. Are you working on this, or do you intend me to? You, please ;-). H

Re: [HACKERS] proposal: plpgsql - Assert statement

On 11/18/14, 9:31 AM, Andrew Dunstan wrote: Frankly, I find this whole proposal, and all the suggested alternatives, somewhat ill-conceived. PLPGSQL is a wordy language. If you want something more terse, use something else. Adding these sorts of syntactic sugar warts onto the language doesn't

Re: [HACKERS] BRIN and PageIndexDeleteNoCompact

Heikki Linnakangas wrote: > BRIN added a new function, PageIndexDeleteNoCompact(), which is like > PageIndexMultiDelete but does not remove unused line pointers. However, all > the callers pass it just a single offset. So the callers would really be > more interested in efficiently squeezing out a

Re: [HACKERS] pg_locks doesn't check for interrupts?

On 11/18/2014 10:47 AM, Tom Lane wrote: > Josh Berkus writes: >> Since querying pg_locks can be intrusive due to needing to lock the lock >> partitions, when I'm collecting data about locks I generally put a >> statement_timeout on it. However, I'm noticing that this >> statement_timeout appears

Re: [HACKERS] pg_locks doesn't check for interrupts?

Josh Berkus writes: > Since querying pg_locks can be intrusive due to needing to lock the lock > partitions, when I'm collecting data about locks I generally put a > statement_timeout on it. However, I'm noticing that this > statement_timeout appears to be completely ignored; I've seen this query

[HACKERS] pg_locks doesn't check for interrupts?

Hackers, Since querying pg_locks can be intrusive due to needing to lock the lock partitions, when I'm collecting data about locks I generally put a statement_timeout on it. However, I'm noticing that this statement_timeout appears to be completely ignored; I've seen this query run for up to 10 m

Re: [HACKERS] PageRepairFragmentation performance

On 11/18/2014 07:03 PM, Heikki Linnakangas wrote: When profiling replay the WAL generated by pgbench, I noticed the PageRepairFragmentation consumes a large fraction of the CPU time: [snip] 1. Replace the qsort with something cheaper. The itemid arrays being sorted are small, a few hundred ite

[HACKERS] PageRepairFragmentation performance

When profiling replay the WAL generated by pgbench, I noticed the PageRepairFragmentation consumes a large fraction of the CPU time: Per "perf report": + 33.44% 6.79% postmaster postgres[.] PageRepairFragmentation The 33.44% figure includes all the functions called by Pa

Re: [HACKERS] proposal: plpgsql - Assert statement

2014-11-18 17:08 GMT+01:00 Simon Riggs : > On 18 November 2014 12:29, Pavel Stehule wrote: > > >> Why is that not a requirement for a less wordier form of IF? > >> > >> IF (something) THEN action > > > > > > statement IF is a control statement - and syntax, pattern for control > > statements in p

Re: [HACKERS] double counting of lines in psql

On 11/18/2014 10:43 AM, David Fetter wrote: On Mon, Nov 17, 2014 at 11:13:15AM -0500, Andrew Dunstan wrote: This tiny change fixes what I think is a longstanding bug in psql. I causes the first line of every cell to be counted twice, whereas it should in fact be excluded from extra_lines / extr

Re: [HACKERS] Removing unreferenced files

Bruce Momjian writes: > > Here is a cleaned-up version of the unreference file patch that was > discussed extensively in May of 2005. I want to get it into the > archives in case someone else want to work on it. > > Here is a reference to the work still needed on the patch: > > http://arch

Re: [HACKERS] Proposal : REINDEX SCHEMA

On 23 October 2014 00:21, Alvaro Herrera wrote: >> Attached patch is latest version patch I modified above. >> Also, I noticed I had forgotten to add the patch regarding document of >> reindexdb. > > Please don't use pg_catalog in the regression test. That way we will > need to update the expect

Re: [HACKERS] proposal: plpgsql - Assert statement

On 18 November 2014 12:29, Pavel Stehule wrote: >> Why is that not a requirement for a less wordier form of IF? >> >> IF (something) THEN action > > > statement IF is a control statement - and syntax, pattern for control > statements in plpgsql is consistent. I don't want to break it (more, > pro

Re: [HACKERS] double counting of lines in psql

On Mon, Nov 17, 2014 at 11:13:15AM -0500, Andrew Dunstan wrote: > > This tiny change fixes what I think is a longstanding bug in psql. I causes > the first line of every cell to be counted twice, whereas it should in fact > be excluded from extra_lines / extra_row_output_lines. The bug appears to

Re: [HACKERS] proposal: plpgsql - Assert statement

On 11/18/2014 04:23 AM, Simon Riggs wrote: On 18 November 2014 01:00, Jim Nasby wrote: On 11/17/14, 4:58 PM, Simon Riggs wrote: Great, looks good to me, marking as ready for committer. What is wrong with using IF ? It's a hell of a lot wordier. I've previously created a more sophisticated

[HACKERS] BRIN and PageIndexDeleteNoCompact

BRIN added a new function, PageIndexDeleteNoCompact(), which is like PageIndexMultiDelete but does not remove unused line pointers. However, all the callers pass it just a single offset. So the callers would really be more interested in efficiently squeezing out a single tuple from a page, like

Re: [HACKERS] pg_basebackup vs. Windows and tablespaces

Amit Kapila wrote: > On Sun, Nov 16, 2014 at 6:15 AM, Alvaro Herrera > wrote: > > I think the fact that we use symlinks is an implementation detail; > > aren't them actually junction points, not symlinks, in some Windows > > cases? > > Right, but they provide same functionality as symlinks and n

Re: [HACKERS] group locking: incomplete patch, just for discussion

On Tue, Nov 18, 2014 at 3:10 PM, Jeff Davis wrote: > On Mon, 2014-11-17 at 14:32 -0500, Robert Haas wrote: > > > To reiterate the basic problem here, if we do nothing at all about the > > lock manager, a parallel backend can stall trying to grab an > > AccessExclusiveLock that the user backend alr

Re: [HACKERS] alternative model for handling locking in parallel groups

On Fri, Nov 14, 2014 at 2:29 AM, Robert Haas wrote: > > Discussion of my incomplete group locking patch seems to have > converged around two points: (1) Everybody agrees that undetected > deadlocks are unacceptable. (2) Nobody agrees with my proposal to > treat locks held by group members as mutu

Re: [HACKERS] proposal: plpgsql - Assert statement

2014-11-18 10:23 GMT+01:00 Simon Riggs : > On 18 November 2014 01:00, Jim Nasby wrote: > > On 11/17/14, 4:58 PM, Simon Riggs wrote: > > Great, looks good to me, marking as ready for committer. > >> > >> > >> What is wrong with using IF ? > > > > > > It's a hell of a lot wordier. I've pr

Re: [HACKERS] [TODO] Track number of files ready to be archived in pg_stat_archiver

On 18 November 2014 06:20, Michael Paquier wrote: > the DBA may want to know how long is the queue of WAL files > waiting to be archived. Agreed > That's IMO something we simply forgot in the > first implementation of pg_stat_archiver That's not how it appears to me. ISTM that the information

Re: [HACKERS] Add shutdown_at_recovery_target option to recovery.conf

On 31 October 2014 15:18, Petr Jelinek wrote: > Attached is the v2 of the patch with the review comments addressed (see > below). ... > Done, there is now action_at_recovery_target which can be set to either > pause, continue or shutdown, defaulting to pause (which is same as old > behavior of pa

Re: [HACKERS] group locking: incomplete patch, just for discussion

On Mon, 2014-11-17 at 14:32 -0500, Robert Haas wrote: > I think I see your point, which it just so happens Amit articulated to > me in different words while we were chatting about this problem this > morning. We want to avoid waiving the mutual exclusion provided by > the lock manager only to end

Re: [HACKERS] postgres_fdw behaves oddly

On Tue, Nov 18, 2014 at 1:55 PM, Etsuro Fujita wrote: > (2014/11/17 19:54), Ashutosh Bapat wrote: > >> Here are comments for postgres_fdw-syscol patch. >> > > Thanks for the review! > > Code >> --- >> 1. Instead of a single liner comment "System columns can't be sent to >> remote.", it might

Re: [HACKERS] Review of Refactoring code for sync node detection

On 18 November 2014 00:02, Michael Paquier wrote: >> I've not read the patches yet. But while I was reading the code around >> sync node detection, I thought that it might be good idea to treat the >> node with priority as special. That is, if we find the active node with >> the priority 1, we ca

Re: [HACKERS] postgres_fdw behaves oddly

On Tue, Nov 18, 2014 at 1:50 PM, Etsuro Fujita wrote: > (2014/11/17 19:36), Ashutosh Bapat wrote: > >> Here are my comments about the patch fscan_reltargetlist.patch >> > > Thanks for the review! > > 1. This isn't your change, but we might be able to get rid of assignment >> 2071 /* Are any

Re: [HACKERS] proposal: plpgsql - Assert statement

On 18 November 2014 01:00, Jim Nasby wrote: > On 11/17/14, 4:58 PM, Simon Riggs wrote: Great, looks good to me, marking as ready for committer. >> >> >> What is wrong with using IF ? > > > It's a hell of a lot wordier. I've previously created a more sophisticated > "assert" framework to

Re: [HACKERS] inherit support for foreign tables

On Mon, Nov 17, 2014 at 1:25 PM, Etsuro Fujita wrote: > (2014/11/12 20:04), Ashutosh Bapat wrote: > >> I reviewed fdw-chk-3 patch. Here are my comments >> > > Thanks for the review! > > Tests >> --- >> 1. The tests added in file_fdw module look good. We should add tests for >> CREATE TABLE w

Re: [HACKERS] [GENERAL] Performance issue with libpq prepared queries on 9.3 and 9.4

On 17 November 2014 22:27, Tom Lane wrote: > Another idea that occurred to me is to run a planning cycle in which the > actual parameter values are made available to the planner, but as > estimates not hard constants (this facility already exists, it's just not > being used by plancache.c). This

Re: [HACKERS] WAL format and API changes (9.5)

On 11/18/2014 10:28 AM, Michael Paquier wrote: Btw, did you do a run with the buffer capture facility and checked for page differences? Yes. That's how I bumped into the bug fixed in c73669c0. That tool has been tremendously helpful. Except that, after going through the code once again, IST

Re: [HACKERS] Incorrect initialization of sentPtr in walsender.c

On Thu, Oct 16, 2014 at 9:01 PM, Michael Paquier wrote: > On Thu, Oct 16, 2014 at 7:09 PM, Simon Riggs > wrote: > >> I find it confusing that the "Lowest" pointer value is also "Invalid". >> Valid != Invalid >> > In complement to that, note that I mentioned Invalid should be UINT_MAX > for clari

Re: [HACKERS] WAL format and API changes (9.5)

On Tue, Nov 18, 2014 at 4:31 AM, Heikki Linnakangas wrote: > WAL insertion performance > = > To measure the performance of generating WAL, I ran the > wal-update-testsuite.sh that Amit also ran earlier. The cluster was > initialized with: > > shared_buffers=512MB > checkpoi

Re: [HACKERS] postgres_fdw behaves oddly

(2014/11/17 19:54), Ashutosh Bapat wrote: Here are comments for postgres_fdw-syscol patch. Thanks for the review! Code --- 1. Instead of a single liner comment "System columns can't be sent to remote.", it might be better to explain why system columns can't be sent to the remote. Done.

Re: [HACKERS] postgres_fdw behaves oddly

(2014/11/17 19:36), Ashutosh Bapat wrote: Here are my comments about the patch fscan_reltargetlist.patch Thanks for the review! 1. This isn't your change, but we might be able to get rid of assignment 2071 /* Are any system columns requested from rel? */ 2072 scan_plan->fsSystemCol =