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

On 2016/02/16 16:02, Ashutosh Bapat wrote: On Tue, Feb 16, 2016 at 12:26 PM, Etsuro Fujita > wrote: On 2016/02/16 15:22, Ashutosh Bapat wrote: During join planning, the planner tries multiple combinations of

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Tue, Feb 16, 2016 at 5:29 AM, Joe Conway wrote: > I believe this takes care of all open issues with this, so I plan to > commit it as attached in a day or two. Thanks for your reviews and comments! Here are just a couple of cosmetic comments. + The view pg_config

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

On Mon, Feb 15, 2016 at 2:54 PM, Michael Paquier wrote: > On Mon, Feb 15, 2016 at 2:11 PM, Kyotaro HORIGUCHI wrote: >> Surprizingly yes. The list is handled as an identifier list and >> parsed by SplitIdentifierString thus it can accept double-quoted >> names. >

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

On Tue, Feb 16, 2016 at 12:26 PM, Etsuro Fujita wrote: > On 2016/02/16 15:22, Ashutosh Bapat wrote: > >> During join planning, the planner tries multiple combinations of joining >> relations, thus the same base or join relation can be part of multiple >> of

Re: [HACKERS] planstats.sgml

>> Tatsuo Ishii writes: >>> While reading planstats.sgml, I encounted a sentence which I don't >>> understand. >> >>> These numbers are current as of the last VACUUM or >>> ANALYZE on the table. The planner then fetches the >>> actual current number of pages in

Re: [HACKERS] extend pgbench expressions with functions

On Tue, Feb 16, 2016 at 9:18 AM, Robert Haas wrote: > I experimented with trying to do this and ran into a problem: where > exactly would you store the evaluated arguments when you don't know > how many of them there will be? And even if you did know how many of > them

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

On 2016/02/16 15:22, Ashutosh Bapat wrote: During join planning, the planner tries multiple combinations of joining relations, thus the same base or join relation can be part of multiple of combination. Hence remote_conds or joinclauses will get linked multiple times as they are bidirectional

Re: [HACKERS] Re: Reusing abbreviated keys during second pass of ordered [set] aggregates

On Tue, Feb 16, 2016 at 5:58 AM, Alvaro Herrera wrote: > Peter Geoghegan wrote: > >> Michael (the CF manager at the time) remembered to change the status >> to "Ready for Committer" again; you see this entry immediately >> afterwards: >> >> "New status: Ready for

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

On 2016/02/15 21:33, Ashutosh Bapat wrote: Here's patch with better way to fix it. I think while concatenating the lists, we need to copy the lists being appended and in all the cases. If we don't copy, a change in those lists can cause changes in the upward linkages and thus lists of any higher

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

During join planning, the planner tries multiple combinations of joining relations, thus the same base or join relation can be part of multiple of combination. Hence remote_conds or joinclauses will get linked multiple times as they are bidirectional lists, thus breaking linkages of previous join

Re: [HACKERS] Incorrect formula for SysV IPC parameters

On Fri, Feb 12, 2016 at 11:19 PM, Fujii Masao wrote: > On Fri, Feb 5, 2016 at 2:17 PM, Kyotaro HORIGUCHI > wrote: >> At Thu, 4 Feb 2016 21:43:04 +0900, Fujii Masao wrote >> in

Re: [HACKERS] planstats.sgml

On 16/02/16 12:46, David G. Johnston wrote: On Mon, Feb 15, 2016 at 4:23 PM, Tatsuo Ishii >wrote: While reading planstats.sgml, I encounted a sentence which I don't understand. These numbers are current as of the last VACUUM

Re: [HACKERS] custom function for converting human readable sizes to bytes

Hi 2016-02-15 10:16 GMT+01:00 Dean Rasheed : > > On 12/02/16 10:19, Dean Rasheed wrote: > >> This seems like a reasonable first patch for me as a committer, so > >> I'll take it unless anyone else was planning to do so. > > > > So looking at this, it seems that for the

Re: [HACKERS] xlc atomics

On 5 July 2015 at 06:54, Andres Freund wrote: > I wrote this entirely blindly, as evidenced here by the changes you > needed. At the time somebody had promised to soon put up an aix animal, > but that apparently didn't work out. > Similarly, I asked IBM for XL/C for a

Re: [HACKERS] innocuous: pgbench does FD_ISSET on invalid socket

On Tue, Feb 16, 2016 at 8:47 AM, Alvaro Herrera wrote: > Michael Paquier wrote: > >> Different issues in the same area: >> 1) In vacuumdb.c, init_slot() does not check for the return value of >> PQsocket(): >> slot->sock = PQsocket(conn); >> 2) In isolationtester.c,

Re: [HACKERS] Declarative partitioning

Hi Josh, On 2016/02/16 11:41, Josh berkus wrote: > On 02/15/2016 04:28 PM, Amit Langote wrote: >> Also, you won't see any optimizer and executor changes. Queries will still >> use the same plans as existing inheritance-based partitioned tables, >> although as I mentioned, constraint exclusion

Re: [HACKERS] Declarative partitioning

On 02/15/2016 04:28 PM, Amit Langote wrote: Also, you won't see any optimizer and executor changes. Queries will still use the same plans as existing inheritance-based partitioned tables, although as I mentioned, constraint exclusion won't yet kick in. That will be fixed very shortly. We're

Re: [HACKERS] A bit of PG archeology uncovers an interesting Linux/Unix factoid

On 02/15/16 20:03, Greg Stark wrote: > On Tue, Feb 16, 2016 at 12:51 AM, Chapman Flack wrote: >> If the calling process subsequently waits for its >> children, and the process has no unwaited for children that were >> transformed into zombie processes, it will block

Re: [HACKERS] Remove or weaken hints about "effective resolution of sleep delays is 10 ms"?

On Wed, Feb 10, 2016 at 4:15 PM, Andres Freund wrote: > Hi, > > Several places in our docs have blurbs like >> Note that on many systems, the effective resolution of sleep delays is >> 10 milliseconds; setting wal_writer_delay to a value that >> is not a multiple of 10 might

Re: [HACKERS] Declarative partitioning

> > Also, you won't see any optimizer and executor changes. Queries will still > use the same plans as existing inheritance-based partitioned tables, > although as I mentioned, constraint exclusion won't yet kick in. That will > be fixed very shortly. > > And of course, comments on syntax are

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

Hello, On 2016/02/15 20:21, Kyotaro HORIGUCHI wrote: > At Mon, 8 Feb 2016 11:37:17 +0900, Amit Langote wrote: >> On 2016/02/05 17:15, poku...@pm.nttdata.co.jp wrote: >>> Please find attached updated patch. [ ... ] >> >> Instead of passing the array of char *'s, why not just pass a single char

Re: [HACKERS] A bit of PG archeology uncovers an interesting Linux/Unix factoid

On Tue, Feb 16, 2016 at 12:51 AM, Chapman Flack wrote: > If the calling process subsequently waits for its > children, and the process has no unwaited for children that were > transformed into zombie processes, it will block until all of its > children

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

Noah Misch writes: > On Mon, Feb 15, 2016 at 07:31:40PM -0500, Robert Haas wrote: >> Oh, crap. I didn't realize that TEMP_CONFIG didn't affect the contrib >> test suites. Is there any reason for that, or is it just kinda where >> we ended up? > To my knowledge, it's just the

Re: [HACKERS] Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl

Robert Haas writes: > On Sun, Feb 14, 2016 at 5:26 PM, Tom Lane wrote: >> Also, after fixing that it would be good to add a comment explaining why >> it's not fundamentally unsafe for BecomeLockGroupMember() to examine >> leader->pgprocno without having

Re: [HACKERS] A bit of PG archeology uncovers an interesting Linux/Unix factoid

On 02/15/16 13:42, Greg Stark wrote: > (it returns error with errno ECHILD upon successful completion of > commands). > This fix ignores an error from system() if errno == ECHILD. > > It looks like Linux now behaves similarly, It seems to be official, in the Single Unix Specification:

Re: [HACKERS] Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl

On Sun, Feb 14, 2016 at 5:26 PM, Tom Lane wrote: > Robert Haas writes: >> On Sun, Feb 14, 2016 at 1:33 PM, Tom Lane wrote: >>> pgprocno of the specific PGPROC, or of the group leader? If it's >>> the former, I'm pretty suspicious

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

On Mon, Feb 15, 2016 at 07:31:40PM -0500, Robert Haas wrote: > On Mon, Feb 15, 2016 at 5:52 PM, Noah Misch wrote: > > On Mon, Feb 08, 2016 at 02:49:27PM -0500, Robert Haas wrote: > >> force_parallel_mode=regress > >> max_parallel_degree=2 > >> > >> And then run this: make

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

On Mon, Feb 15, 2016 at 5:52 PM, Noah Misch wrote: > On Mon, Feb 08, 2016 at 02:49:27PM -0500, Robert Haas wrote: >> Well, what I've done is push into the buildfarm code that will allow >> us to do *the most exhaustive* testing that I know how to do in an >> automated fashion.

Re: [HACKERS] Declarative partitioning

Hi Corey, On 2016/02/16 5:15, Corey Huinker wrote: >> >> The individual patches have commit messages that describe code changes. >> This is registered in the upcoming CF. Feedback and review is greatly >> welcomed! >> > We have a current system that is currently a mix of tables, each of which >

Re: [HACKERS] extend pgbench expressions with functions

On Mon, Feb 15, 2016 at 4:58 AM, Fabien COELHO wrote: > Indeed! > >> Taking patch 1 as a completely independent thing, there is no need to >> introduce PgBenchValueType yet. Similar remark for setIntValue and >> coerceToInt. They are useful afterwards when introducing double

Re: [HACKERS] planstats.sgml

> Tatsuo Ishii writes: >> While reading planstats.sgml, I encounted a sentence which I don't >> understand. > >> These numbers are current as of the last VACUUM or >> ANALYZE on the table. The planner then fetches the >> actual current number of pages in the

Re: [HACKERS] planstats.sgml

Tatsuo Ishii writes: > While reading planstats.sgml, I encounted a sentence which I don't > understand. > These numbers are current as of the last VACUUM or > ANALYZE on the table. The planner then fetches the > actual current number of pages in the table (this

Re: [HACKERS] innocuous: pgbench does FD_ISSET on invalid socket

I noticed that strerror(errno) wasn't the most helpful error context ever, so I changed it to PQerrorMessage(). There may be room for additional improvement there. I also noticed that if one connection dies, we terminate the whole thread, and if the thread is serving multiple connections, the

Re: [HACKERS] planstats.sgml

On Mon, Feb 15, 2016 at 4:23 PM, Tatsuo Ishii wrote: > While reading planstats.sgml, I encounted a sentence which I don't > understand. > > These numbers are current as of the last VACUUM or > ANALYZE on the table. The planner then fetches the > actual current

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

On Mon, Feb 15, 2016 at 8:43 PM, Jim Nasby wrote: > On 2/7/16 8:57 PM, Peter Geoghegan wrote: >> >> It seems less than ideal that DBAs have to be so >> conservative in sizing work_mem. > > > +10 I was thinking about this over the past couple weeks. I'm starting to

[HACKERS] planstats.sgml

While reading planstats.sgml, I encounted a sentence which I don't understand. These numbers are current as of the last VACUUM or ANALYZE on the table. The planner then fetches the actual current number of pages in the table (this is a cheap operation, not requiring a table

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

On Mon, Feb 15, 2016 at 06:07:48PM -0500, Tom Lane wrote: > Noah Misch writes: > > I configured a copy of animal "mandrill" that way and launched a test run. > > The postgres_fdw suite failed as attached. A manual "make -C contrib > > installcheck" fails the same way on a

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

Noah Misch writes: > I configured a copy of animal "mandrill" that way and launched a test run. > The postgres_fdw suite failed as attached. A manual "make -C contrib > installcheck" fails the same way on a ppc64 GNU/Linux box, but it passes on > x86_64 and aarch64. Since

Re: [HACKERS] Clock with Adaptive Replacement

Jim Nasby writes: > On 2/12/16 9:55 AM, Robert Haas wrote: >> I think it's important to spend time and energy figuring out exactly >> what the problems with our current algorithm are. We know in general >> terms that usage counts tend to converge to either 5 or 0 and >>

Re: [HACKERS] Re: Reusing abbreviated keys during second pass of ordered [set] aggregates

Alvaro Herrera writes: > (FWIW I'm not the "current" CF manager, because the CF I managed is > already over. I'm not sure that we know who the manager for the > upcoming one is.) We had a vict^H^H^H^Hvolunteer a few days ago:

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

On Wed, Feb 3, 2016 at 5:12 PM, Thomas Munro wrote: > I don't see it as a difficult choice between two reasonable > alternatives. It quacks suspiciously like a bug. That seems a little strong to me; I think it would be an unacceptable change in behavior to

Re: [HACKERS] Re: [COMMITTERS] pgsql: Add some isolation tests for deadlock detection and resolution.

Andres Freund writes: > I wonder if we shouldn't just expose a 'which pid is process X waiting > for' API, implemented serverside. That's generally really useful, and > looks like it's actually going to be less complicated than that > query... And it's surely going to be

Re: [HACKERS] Freeze avoidance of very large table.

On Wed, Feb 10, 2016 at 04:39:15PM +0900, Kyotaro HORIGUCHI wrote: > > I still agree with this plugin approach, but I felt it's still > > complicated a bit, and I'm concerned that patch size has been > > increased. > > Please give me feedbacks. > > Yeah, I feel the same. What make it worse, the

Re: [HACKERS] Re: Reusing abbreviated keys during second pass of ordered [set] aggregates

On Mon, Feb 15, 2016 at 12:58 PM, Alvaro Herrera wrote: > (FWIW I'm not the "current" CF manager, because the CF I managed is > already over. I'm not sure that we know who the manager for the > upcoming one is.) It's pretty easy to forget that this was the first time

Re: [HACKERS] Clock with Adaptive Replacement

On 2/12/16 9:55 AM, Robert Haas wrote: I think it's important to spend time and energy figuring out exactly what the problems with our current algorithm are. We know in general terms that usage counts tend to converge to either 5 or 0 and therefore sometimes evict buffers both at great cost and

Re: [HACKERS] Re: Reusing abbreviated keys during second pass of ordered [set] aggregates

Peter Geoghegan wrote: > Michael (the CF manager at the time) remembered to change the status > to "Ready for Committer" again; you see this entry immediately > afterwards: > > "New status: Ready for Committer" > > but I gather from the CF app history that Alvaro (the current CF > manager) did

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

On 2/7/16 8:57 PM, Peter Geoghegan wrote: It seems less than ideal that DBAs have to be so conservative in sizing work_mem. +10 -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble!

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 01/20/2016 08:08 PM, Michael Paquier wrote: > On Wed, Jan 20, 2016 at 2:32 AM, Joe Conway wrote: >> The only things I know of still lacking is: >> 1) Documentation Done and included in the attached. >> 2) Decision on REVOKE ... FROM PUBLIC > > Yep, regarding 2) I am the

Re: [HACKERS] Declarative partitioning

> > > The individual patches have commit messages that describe code changes. > This is registered in the upcoming CF. Feedback and review is greatly > welcomed! > > Thanks, > Amit > > We have a current system that is currently a mix of tables, each of which is range partitioned into approximately

Re: [HACKERS] PoC: Partial sort

On Sun, Jan 31, 2016 at 4:16 AM, Alvaro Herrera wrote: > Great to have a new version -- there seems to be a lot of interest in > this patch. I'm moving this one to the next commitfest, thanks. I am signed up to review this patch. I was very surprised to see it in

Re: [HACKERS] Remove or weaken hints about "effective resolution of sleep delays is 10 ms"?

On Mon, Feb 15, 2016 at 11:23 AM, Peter Geoghegan wrote: > commit_delay doesn't have any guidance like this, where it could > certainly matter, because optimal settings are rarely greater than 10 > milliseconds. Actually, it does, but it's in "29.4. WAL Configuration", not next

Re: [HACKERS] Remove or weaken hints about "effective resolution of sleep delays is 10 ms"?

On Wed, Feb 10, 2016 at 2:15 PM, Andres Freund wrote: > Afaik that's not the case on any recent operating system/hardware. So > perhaps we should just remove all of those blurbs, or just replace them > with something like "on some older systems the effective resolution of >

Re: [HACKERS] [PATCH] Code refactoring related to -fsanitize=use-after-scope

Andres Freund writes: > On 2016-02-15 14:37:28 +0100, Martin Liška wrote: >> I've been currently working on support of -sanitize=use-after-scope in the >> GCC compiler and >> I decided to use postgresql as my test-case. The sanitation poisons every >> stack variable at the

Re: [HACKERS] xlc atomics

Noah Misch writes: > That commit (0d32d2e) permitted things to compile and usually pass tests, but > I missed the synchronization bug. Since 2015-10-01, the buildfarm has seen > sixteen duplicate-catalog-OID failures. I'd been wondering about those ... > These suggested

[HACKERS] A bit of PG archeology uncovers an interesting Linux/Unix factoid

For reasons, I was trying to compile older versions of Postgres and ran into a strange behaviour where system() worked normally but then returned -1 with errno set to ECHILD. And surprisingly it looks like we've seen this behaviour in the past but on a Solaris: commit

Re: [HACKERS] Re: Reusing abbreviated keys during second pass of ordered [set] aggregates

On Tue, Dec 22, 2015 at 10:49 PM, Peter Geoghegan wrote: > I attach a rebased patch for 9.6 only. I marked the patch -- my own patch -- "Ready for Committer". I'm the third person to have marked the patch "Ready for Committer", even though no committer bounced the patch back for

Re: [HACKERS] xlc atomics

On Mon, Feb 15, 2016 at 06:33:42PM +0100, Andres Freund wrote: > On 2016-02-15 12:11:29 -0500, Noah Misch wrote: > > These suggested OidGenLock wasn't doing its job. I've seen similar symptoms > > around WALInsertLocks with "IBM XL C/C++ for Linux, V13.1.2 (5725-C73, > > 5765-J08)" for ppc64le.

Re: [HACKERS] [PATCH v5] GSSAPI encryption support

David Steele writes: > Hi Robbie, > > On 2/10/16 4:06 PM, Robbie Harwood wrote: >> Hello friends, >> >> For your consideration, here is a new version of GSSAPI encryption >> support. For those who prefer, it's also available on my github: >>

Re: [HACKERS] [PATCH] Code refactoring related to -fsanitize=use-after-scope

Hi, On 2016-02-15 14:37:28 +0100, Martin Liška wrote: > I've been currently working on support of -sanitize=use-after-scope in the > GCC compiler and > I decided to use postgresql as my test-case. The sanitation poisons every > stack variable at the > very beginning of a function, unpoisons a

Re: [HACKERS] xlc atomics

On 2016-02-15 12:11:29 -0500, Noah Misch wrote: > These suggested OidGenLock wasn't doing its job. I've seen similar symptoms > around WALInsertLocks with "IBM XL C/C++ for Linux, V13.1.2 (5725-C73, > 5765-J08)" for ppc64le. The problem is generic-xlc.h > pg_atomic_compare_exchange_u32_impl()

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

Small update. I had to add one thing in /contrib/tcn/. diff --git a/contrib/tcn/tcn.c b/contrib/tcn/tcn.c index 7352b29..3a6d4f5 100644 --- a/contrib/tcn/tcn.c +++ b/contrib/tcn/tcn.c @@ -160,7 +160,7 @@ triggered_change_notification(PG_FUNCTION_ARGS) strcpy_quoted(payload,

Re: [HACKERS] New pg_upgrade data directory inside old one?

On Mon, Feb 15, 2016 at 6:29 PM, Bruce Momjian wrote: > Someone on IRC reported that if they had run the pg_upgrade-created > delete_old_cluster.sh shell script it would have deleted their old _and_ > new data directories. (Fortunately they didn't run it.) > > I was confused

[HACKERS] New pg_upgrade data directory inside old one?

Someone on IRC reported that if they had run the pg_upgrade-created delete_old_cluster.sh shell script it would have deleted their old _and_ new data directories. (Fortunately they didn't run it.) I was confused how this could have happened, and the user explained that their old cluster was in

[HACKERS] [PATCH] Code refactoring related to -fsanitize=use-after-scope

Hello. I've been currently working on support of -sanitize=use-after-scope in the GCC compiler and I decided to use postgresql as my test-case. The sanitation poisons every stack variable at the very beginning of a function, unpoisons a variable at the beginning of scope definition and finally

Re: [HACKERS] WIP: Failover Slots

Hi, here is my code level review: 0001: This one looks ok except for broken indentation in the new notes in xlogreader.c and .h. It's maybe slightly overdocumented but given the complicated way the timeline reading works it's probably warranted. 0002: +/* + * No

[HACKERS] Remove or weaken hints about "effective resolution of sleep delays is 10 ms"?

Hi, Several places in our docs have blurbs like > Note that on many systems, the effective resolution of sleep delays is > 10 milliseconds; setting wal_writer_delay to a value that > is not a multiple of 10 might have the same results as setting it to > the next higher multiple of 10. Afaik

Re: [HACKERS] Existence check for suitable index in advance when concurrently refreshing.

On Wed, Feb 10, 2016 at 10:35 AM, Michael Paquier wrote: > On Wed, Feb 10, 2016 at 2:23 AM, Fujii Masao wrote: >> On Wed, Feb 10, 2016 at 2:21 AM, Fujii Masao wrote: >>> On Tue, Feb 9, 2016 at 9:11 PM, Michael Paquier >>>

Re: [HACKERS] xlc atomics

On Sat, Jul 04, 2015 at 08:07:49PM -0400, Noah Misch wrote: > On Sun, Jul 05, 2015 at 12:54:43AM +0200, Andres Freund wrote: > > On 2015-07-04 18:40:41 -0400, Noah Misch wrote: > > > (1) "IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72)". Getting it > > > working > > > required the attached

Re: [HACKERS] [WIP] ALTER ... OWNER TO ... CASCADE

Teodor Sigaev writes: >> So basically, a generic CASCADE facility sounds like a lot of work to >> produce something that would seldom be anything but a foot-gun. > DELETE FROM or TRUNCATE could be a foot-gun too, but it's not a reason to > remove tham. I faced with problem

Re: [HACKERS] Small PATCH: check of 2 Perl modules

On 2/15/16 8:57 AM, Teodor Sigaev wrote: >> On 2/12/16 8:20 AM, Eugene Kazakov wrote: >>> TAP-tests need two Perl modules: Test::More and IPC::Run. >> I think those modules are part of a standard Perl installation. > > IPC::Run is not. At least for perl from ports tree in FreeBSD. Right, that's

Re: [HACKERS] [WIP] ALTER ... OWNER TO ... CASCADE

TBH, this sounds like a completely terrible idea. There are far too many sorts of dependencies across which one would not expect ownership to propagate; for example, use of a function in a view, or even just a foreign key dependency between two tables. I'm not even clear that there are *any*

Re: [HACKERS] [WIP] ALTER ... OWNER TO ... CASCADE

> Dmitry Ivanov writes: > > As of now there's no way to transfer the ownership of an object and all > > its > > dependent objects in one step. One has to manually alter the owner of each > > object, be it a table, a schema or something else. > > TBH, this sounds like a

[HACKERS] GetExistingLocalJoinPath() vs. the docs

Greetings, While getting back into the thread Re: Optimization for updating foreign tables in Postgres FDW, I noticed some issues with the docs and GetExistingLocalJoinPath(): GetExistingLocalJoinPath() exists in src/backend/foreign/foreign.c, but the docs include discussion of it under 54.2 -

Re: [HACKERS] [PATCH] we have added support for box type in SP-GiST index

It's very pity but author is not able to continue work on this patch, and I would like to raise this flag. I'd like to add some comments about patches: traversalValue patch adds arbitrary value assoсiated with branch in SP-GiST tree walk. Unlike to recostructedValue it could be just pointer,

Re: [HACKERS] Small PATCH: check of 2 Perl modules

Teodor Sigaev writes: >> On 2/12/16 8:20 AM, Eugene Kazakov wrote: >>> TAP-tests need two Perl modules: Test::More and IPC::Run. >> I think those modules are part of a standard Perl installation. > IPC::Run is not. At least for perl from ports tree in FreeBSD. Yeah, I

Re: [HACKERS] [WIP] ALTER ... OWNER TO ... CASCADE

Dmitry Ivanov writes: > As of now there's no way to transfer the ownership of an object and all its > dependent objects in one step. One has to manually alter the owner of each > object, be it a table, a schema or something else. TBH, this sounds like a completely

Re: [HACKERS] Small PATCH: check of 2 Perl modules

On Mon, Feb 15, 2016 at 10:57 PM, Teodor Sigaev wrote: >> On 2/12/16 8:20 AM, Eugene Kazakov wrote: >>> >>> TAP-tests need two Perl modules: Test::More and IPC::Run. >> >> I think those modules are part of a standard Perl installation. > > IPC::Run is not. At least for perl from

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

Dean Rasheed wrote: > My biggest problem is with the sorting, for all the reasons discussed > above. There is absolutely no reason for \crosstabview to be > re-sorting rows -- they should just be left in the original query > result order We want the option to sort the vertical the header

Re: [HACKERS] Small PATCH: check of 2 Perl modules

On 2/12/16 8:20 AM, Eugene Kazakov wrote: TAP-tests need two Perl modules: Test::More and IPC::Run. I think those modules are part of a standard Perl installation. IPC::Run is not. At least for perl from ports tree in FreeBSD. -- Teodor Sigaev E-mail:

Re: [HACKERS] Refectoring of receivelog.c

On Mon, Feb 15, 2016 at 7:15 AM, Craig Ringer wrote: > On 15 February 2016 at 04:48, Magnus Hagander wrote: > >> I was working on adding the tar streaming functionality we talked about >> at the developer meeting to pg_basebackup, and rapidly ran

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

Alvaro Herrera wrote: > So please can we have that wiki page so that the syntax can be hammered > out a bit more. I've added a wiki page with explanation and examples here: https://wiki.postgresql.org/wiki/Crosstabview Best regards, -- Daniel Vérité PostgreSQL-powered mailer:

Re: [HACKERS] Small PATCH: check of 2 Perl modules

On 2/12/16 8:20 AM, Eugene Kazakov wrote: > TAP-tests need two Perl modules: Test::More and IPC::Run. > > The patch adds checking of modules in configure.in and configure. I think those modules are part of a standard Perl installation. -- Sent via pgsql-hackers mailing list

Re: [HACKERS] custom function for converting human readable sizes to bytes

On 2/15/16, Vitaly Burovoy wrote: > P.S.: "bytes" size unit was added just for consistency: each group > should have a name, even with an exponent of 1. Oops... Of course, "even with an exponent of 0". -- Best regards, Vitaly Burovoy -- Sent via pgsql-hackers

Re: [HACKERS] custom function for converting human readable sizes to bytes

On 2/15/16, Dean Rasheed wrote: >> On 12/02/16 10:19, Dean Rasheed wrote: >>> This seems like a reasonable first patch for me as a committer, so >>> I'll take it unless anyone else was planning to do so. >> > > So looking at this, it seems that for the most part

Re: [HACKERS] Small PATCH: check of 2 Perl modules

13.02.2016 16:04, Michael Paquier : On Sat, Feb 13, 2016 at 1:47 PM, Robert Haas wrote: On Fri, Feb 12, 2016 at 8:20 AM, Eugene Kazakov wrote: TAP-tests need two Perl modules: Test::More and IPC::Run. The patch adds checking of modules in

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

On 05.02.2016 11:09, Kyotaro HORIGUCHI wrote: Hello, I considered how to make tab-completion robust for syntactical noises, in other words, optional words in syntax. Typically "IF (NOT) EXISTS", UNIQUE and TEMPORARY are words that don't affect further completion. However, the current

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

Thanks Fujita-san for bug report and the fix. Sorry for bug. Here's patch with better way to fix it. I think while concatenating the lists, we need to copy the lists being appended and in all the cases. If we don't copy, a change in those lists can cause changes in the upward linkages and thus

Re: [HACKERS] Incorrect formula for SysV IPC parameters

On Mon, Feb 15, 2016 at 2:31 PM, Kyotaro HORIGUCHI wrote: > Thanks for looking at this. > > At Fri, 12 Feb 2016 23:19:45 +0900, Fujii Masao wrote > in >> >> ISTM that

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

Hello, At Mon, 8 Feb 2016 11:37:17 +0900, Amit Langote wrote in <56b7ff5d.7030...@lab.ntt.co.jp> > > Hi Vinayak, > > Thanks for updating the patch, a couple of comments: > > On 2016/02/05 17:15, poku...@pm.nttdata.co.jp wrote: > > Hello, > > > > Please find

Re: [HACKERS] innocuous: pgbench does FD_ISSET on invalid socket

Hello Alvaro, Any objections to changing it like this? I'd probably backpatch to 9.5, but no further (even though this pattern actually appears all the way back.) My 0.02€: if the pattern is repeated, maybe a function which incorporates the check would save lines and improve overall

[HACKERS] [WIP] ALTER ... OWNER TO ... CASCADE

Hi hackers, Recently I've been working on a CASCADE option for ALTER ... OWNER TO statement. Although it's still a working prototype, I think it's time to share my work. Introduction As of now there's no way to transfer the ownership of an object and all its dependent objects

Re: [HACKERS] extend pgbench expressions with functions

Hello Michaël, + * Recursive evaluation of int or double expressions + * + * Note that currently only integer variables are available, with values + * stored as text. This comment is incorrect, we only care about integers in this patch. Indeed! Taking patch 1 as a completely independent

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

On 2016/02/15 15:20, Rushabh Lathia wrote: On Fri, Feb 12, 2016 at 5:40 PM, Etsuro Fujita > wrote: As a result of our discussions, we reached a conclusion that the DML pushdown APIs should be provided together with

Re: [HACKERS] custom function for converting human readable sizes to bytes

> On 12/02/16 10:19, Dean Rasheed wrote: >> This seems like a reasonable first patch for me as a committer, so >> I'll take it unless anyone else was planning to do so. > So looking at this, it seems that for the most part pg_size_bytes() will parse any output produced by pg_size_pretty(). The