Re: [HACKERS] No Issue Tracker - Say it Ain't So!

Hello, On 29.09.2015 00:34, Tom Lane wrote: Jim Nasby writes: On 9/28/15 11:43 AM, Andres Freund wrote: It has been stated pretty clearly in this thread by a number of senior community people that we're not going to use a closed source system. GitLab OTOH is

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On 2015/09/29 13:55, Kouhei Kaigai wrote: From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Etsuro Fujita On 2015/09/29 9:13, Kouhei Kaigai wrote: From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of

Re: [HACKERS] unclear about row-level security USING vs. CHECK

I had not seen this. > -Original Message- > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > Sent: Montag, 28. September 2015 21:43 > To: Stephen Frost > Cc: Peter Eisentraut ;

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 29.09.2015 05:54, Tom Lane wrote: Stephen Frost writes: * Jim Nasby (jim.na...@bluetreble.com) wrote: 2 years ago is when they first released the enterprise edition, which according to [1] had "The most important new feature is that you can now add members to groups of

Re: [HACKERS] [Proposal] Table partition + join pushdown

Hello, KaiGai-san Thank you for your introduction and comments. > * Suppose we focus on only HashJoin in the first version? > This patch also add support on NestLoop and MergeJoin, however, NestLoop > has no valuable scenario without parallel execution capability, and the > most valuable

Re: [HACKERS] track_commit_timestamp and COMMIT PREPARED

On 2015-09-29 13:44, Fujii Masao wrote: On Tue, Sep 29, 2015 at 12:05 PM, Alvaro Herrera wrote: Petr Jelinek wrote: On 2015-09-02 16:14, Fujii Masao wrote: On Wed, Aug 5, 2015 at 2:16 AM, Robert Haas wrote: On Mon, Aug 3, 2015 at 10:31 AM,

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

> -Original Message- > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Etsuro Fujita > Sent: Tuesday, September 29, 2015 8:00 PM > To: Kaigai Kouhei(海外 浩平); Robert Haas > Cc: PostgreSQL-development; 花田茂 > Subject: Re: [HACKERS]

Re: [HACKERS] Improving test coverage of extensions with pg_dump

On Sat, Sep 26, 2015 at 10:22 PM, Andres Freund wrote: > On 2015-09-26 21:54:46 +0900, Michael Paquier wrote: >> On Wed, Sep 23, 2015 at 1:04 AM, Alvaro Herrera >> wrote: >> > We discussed this in some other thread, not long ago. I looked briefly >>

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On Mon, Sep 28, 2015 at 4:41 PM, Jim Nasby wrote: > Note that since they also offer a hosted solution we should use that to > play with instead of trying to install it at this point. > > Integrating the issue tracker looks like it's just a call to this API: >

Re: [HACKERS] Rework the way multixact truncations work

Robert Haas wrote: > On Mon, Sep 28, 2015 at 10:48 PM, Jim Nasby wrote: > > Maybe I'm confused, but I thought the whole purpose of this was to get rid > > of the risk associated with that calculation in favor of explicit truncation > > boundaries in the WAL log. > >

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On 2015/09/29 17:49, Kouhei Kaigai wrote: From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Etsuro Fujita RefetchForeignRow() does not take ForeignScanState as its argument, so it is not obvious to access its private field, isn't it? ExecRowMark

Re: [HACKERS] track_commit_timestamp and COMMIT PREPARED

On Tue, Sep 29, 2015 at 12:05 PM, Alvaro Herrera wrote: > Petr Jelinek wrote: >> On 2015-09-02 16:14, Fujii Masao wrote: >> >On Wed, Aug 5, 2015 at 2:16 AM, Robert Haas wrote: >> >>On Mon, Aug 3, 2015 at 10:31 AM, Fujii Masao

Re: [HACKERS] track_commit_timestamp and COMMIT PREPARED

On 2015-09-29 05:05, Alvaro Herrera wrote: Petr Jelinek wrote: On 2015-09-02 16:14, Fujii Masao wrote: On Wed, Aug 5, 2015 at 2:16 AM, Robert Haas wrote: On Mon, Aug 3, 2015 at 10:31 AM, Fujii Masao wrote: track_commit_timestamp tracks COMMIT

Re: [HACKERS] PATCH: index-only scans with partial indexes

Hi, At Sat, 26 Sep 2015 18:00:33 +0200, Tomas Vondra wrote in <5606c121.10...@2ndquadrant.com> > Hi, > > On 09/26/2015 01:28 PM, Tomas Vondra wrote: > > > The patch does not change the check_index_only implementation - it > > still needs to check the clauses,

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On Tue, Sep 29, 2015 at 12:28 AM, Jim Nasby wrote: > On 9/18/15 5:05 AM, Shulgin, Oleksandr wrote: > >> >> So this has to be the responsibility of the reply sending backend in the >> end: to create and release the DSM *at some point*. >> > > What's wrong with just

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On Tue, Sep 29, 2015 at 12:57 PM, Andres Freund wrote: > On 2015-09-25 19:13:13 +0200, Shulgin, Oleksandr wrote: > > the auto_explain contrib module. I now propose the most simple thing > > possible in my opinion: a new GUC option for auto_explain. It will make > > every

Re: [HACKERS] Rework the way multixact truncations work

On Mon, Sep 28, 2015 at 10:48 PM, Jim Nasby wrote: > Maybe I'm confused, but I thought the whole purpose of this was to get rid > of the risk associated with that calculation in favor of explicit truncation > boundaries in the WAL log. Yes. But if the master hasn't

Re: [HACKERS] Rework the way multixact truncations work

On Tue, Sep 22, 2015 at 3:20 PM, Andres Freund wrote: > What I've tested is the following: > * continous burning of multis, both triggered via members and offsets > * a standby keeping up when the primary is old > * a standby keeping up when the primary is new > * basebackups

Re: [HACKERS] unclear about row-level security USING vs. CHECK

On 28 September 2015 at 20:15, Stephen Frost wrote: > I listed out the various alternatives but didn't end up getting any > responses to it. I'm still of the opinion that the documentation is the > main thing which needs improving here, but we can also change CREATE > POLICY,

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On 2015-09-25 19:13:13 +0200, Shulgin, Oleksandr wrote: > the auto_explain contrib module. I now propose the most simple thing > possible in my opinion: a new GUC option for auto_explain. It will make > every backend, in which the module is loaded via *_preload_libraries > mechanism or using

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

> -Original Message- > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Etsuro Fujita > Sent: Tuesday, September 29, 2015 4:36 PM > To: Kaigai Kouhei(海外 浩平); Robert Haas > Cc: PostgreSQL-development; 花田茂 > Subject: Re: [HACKERS] Foreign

Re: [HACKERS] Rework the way multixact truncations work

On 2015-09-28 21:48:00 -0500, Jim Nasby wrote: > On 9/28/15 8:49 PM, Robert Haas wrote: > >If at some point we back-patch this further, then it potentially > >becomes a live issue, but I would like to respectfully inquire what > >exactly you think making it a PANIC would accomplish? There are a

Re: [HACKERS] Comment update to pathnode.c

On Tue, Sep 29, 2015 at 1:55 AM, Etsuro Fujita wrote: > Thanks for the comments! Attached is an updated version of the patch. Committed and back-patched to 9.5. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On Wed, Sep 23, 2015 at 1:18 PM, Kam Lasater wrote: > Hello, > > Last night I heard that Postgres had no issue/bug tracker. At first I > thought the guy was trolling me. Seriously, how could this be. Certainly a > mature open source project that is the database for a measurable

Re: [HACKERS] 9.5: Can't connect with PGSSLMODE=require on Windows

Thank you Tom. The issue seems not reproducible anymore with latest PG95 source code (commit 60fcee9e5e77dc748a9787fae34328917683b95e) Windows build i.e. C:\PG\postgresql\pg95_with_openssl>bin\psql.exe -d postgres -h > 172.16.141.232 > psql (9.5alpha2) > WARNING: Console code page (437) differs

Re: [HACKERS] row_security GUC, BYPASSRLS

> I've attached a patch to implement it. It's not fully polished but it's > sufficient for comment, I believe. Additional comments, documentation > and regression tests are to be added, if we have agreement on the > grammer and implementation approach. I have given the first patch a quick

Re: [HACKERS] pageinspect patch, for showing tuple data

В письме от 26 сентября 2015 20:57:25 пользователь Michael Paquier написал: > > So I would consider two options: Either move t_infomask/t_infomask2 > > details > > into storage.sgml or leave as it is. > > The documentation redirects the reader to look at htup_details.h (the > documentation is

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On Tue, Sep 29, 2015 at 7:16 AM, David Fetter wrote: > ...What we're not fine with is depending on a proprietary system, no > matter what type of license, as infrastructure... > > Exactly. Which is why I was warning about latching onto features only available in the closed

Re: [HACKERS] 9.5: Can't connect with PGSSLMODE=require on Windows

Asif Naeem writes: > Thank you Tom. The issue seems not reproducible anymore with latest PG95 > source code (commit 60fcee9e5e77dc748a9787fae34328917683b95e) Windows build Thanks for testing! I've marked this issue resolved in the 9.5 open-items list.

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On Tue, Sep 29, 2015 at 07:01:16AM -0700, Steve Crawford wrote: > On Mon, Sep 28, 2015 at 4:41 PM, Jim Nasby wrote: > > > Note that since they also offer a hosted solution we should use that to > > play with instead of trying to install it at this point. > > > >

Re: [HACKERS] track_commit_timestamp and COMMIT PREPARED

Petr Jelinek wrote: > On 2015-09-29 13:44, Fujii Masao wrote: > >On Tue, Sep 29, 2015 at 12:05 PM, Alvaro Herrera > > wrote: > >-#define RecoveryRequiresBoolParameter(param_name, currValue, masterValue) \ > >-do { \ > >-bool _currValue = (currValue); \ > >-bool

Re: [HACKERS] PATCH: index-only scans with partial indexes

Hello, On 09/29/2015 12:27 PM, Kyotaro HORIGUCHI wrote: Hi, At Sat, 26 Sep 2015 18:00:33 +0200, Tomas Vondra wrote in <5606c121.10...@2ndquadrant.com> Hi, On 09/26/2015 01:28 PM, Tomas Vondra wrote: The patch does not change the check_index_only

Re: [HACKERS] unclear about row-level security USING vs. CHECK

> My vote would be to keep it as-is. Same for me. > It feels perfectly natural to me. USING clauses add to the query's > WHERE clause controlling which existing rows you can SELECT, UPDATE or > DELETE. WITH CHECK clauses control what new data you can add via > INSERT or UPDATE. UPDATE allows

Re: [HACKERS] ON CONFLICT issues around whole row vars,

On 2015-09-24 17:25:21 +0200, Andres Freund wrote: > Stuff I want to fix by tomorrow: > * Whole row var references to exclude > * wrong offsets for columns after dropped ones > * INSTEAD DO UPDATE for tables with oids > > Do you know of anything else? So, took a bit longer than "tomorrow. I

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

Robbie Harwood writes: Michael Paquier writes: > Well, the issue is still here: login through gssapi fails with > your patch, not with HEAD. This patch is next on my review list by > the way so I'll see what I can do about it

Re: [HACKERS] Box type equality

Stanislav Kelvich writes: > I've faced an issue with Box type comparison that exists almost for a five > years. Try twenty-five years. The code's been like that since Berkeley. > That can be fixed by b-tree equality for boxes, but we need some > decisions there.

Re: [HACKERS] Box type equality

The Box type is the oldest non-linear type in the Postgres system. We used it as the template for extensibility in the original system about thirty years ago. We had R-trees for box indexing. If you want fuzzy box matching, that seems possible with R-trees and some creativity by say matching

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On 25 September 2015 at 12:13, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > I now believe that use of ProcessInterrupts() in the recently proposed > design as well as manipulation of proc latch due to use of shared memory > queue are major blockers. > > In order to simplify things

Re: [HACKERS] GinPageIs* don't actually return a boolean

Andres Freund wrote: > I went through all headers in src/include and checked for macros > containing [^&]&[^&] and checked whether they have this hazard. Found a > fair number. > > That patch also changes !! tests into != 0 style. I don't think you pushed this, did you? -- Álvaro Herrera

Re: [HACKERS] PATCH: index-only scans with partial indexes

On 09/29/2015 04:57 PM, Tomas Vondra wrote: Hello, On 09/29/2015 12:27 PM, Kyotaro HORIGUCHI wrote: ... cost_index() seems to need to be fixed. It would count excluded clauses in estimate. Hmm, good point. The problem is that extract_nonindex_conditions uses baserel->baserestrictinfo

[HACKERS] Box type equality

Hi. I've faced an issue with Box type comparison that exists almost for a five years. > create table t (b box); CREATE TABLE > select count(*), b from t group by b; ERROR: could not identify an equality operator for type box As mentioned in

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 09/29/2015 10:55 AM, Steve Crawford wrote: On Tue, Sep 29, 2015 at 7:16 AM, David Fetter > wrote: ...What we're not fine with is depending on a proprietary system, no matter what type of license, as infrastructure... Exactly. Which is

Re: [HACKERS] Arguable RLS security bug, EvalPlanQual() paranoia

* Adam Brightwell (adam.brightw...@crunchydatasolutions.com) wrote: > On Mon, Aug 3, 2015 at 6:21 PM, Peter Geoghegan wrote: > > On Mon, Aug 3, 2015 at 3:07 PM, Stephen Frost wrote: > >> Thoughts? Trying to keep it straight-forward and provide a simple > >>

[HACKERS] [PATCH 6/6] pg_basebackup: add a single-tar output format.

This will write one single tar file containing all tablespaces, and can be written to stdout. --- src/bin/pg_basebackup/pg_basebackup.c | 282 -- 1 file changed, 269 insertions(+), 13 deletions(-) diff --git a/src/bin/pg_basebackup/pg_basebackup.c

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

Alvaro Herrera writes: > Merlin Moncure wrote: >> I've read this email about three times now and it's not clear at all >> to me what a issue/bug tracker brings to the table. > In my opinion, this thread is about a bug tracker, not a patch tracker. > We already have a

Re: [HACKERS] Idea for improving buildfarm robustness

On 09/29/2015 01:48 PM, Alvaro Herrera wrote: > Joe Conway wrote: >> On 09/29/2015 12:47 PM, Tom Lane wrote: >>> We could possibly add additional checks, like trying to verify that >>> pg_control has the same inode number it used to. But I'm afraid that >>> would add portability issues and

[HACKERS] [PATCH 5/6] pg_basebackup: allow GetConnection() to make non-replication connections.

--- src/bin/pg_basebackup/pg_basebackup.c | 4 ++-- src/bin/pg_basebackup/pg_receivexlog.c | 4 ++-- src/bin/pg_basebackup/pg_recvlogical.c | 4 ++-- src/bin/pg_basebackup/streamutil.c | 6 +++--- src/bin/pg_basebackup/streamutil.h | 2 +- 5 files changed, 10 insertions(+), 10

Re: [HACKERS] Arguable RLS security bug, EvalPlanQual() paranoia

On Mon, Aug 3, 2015 at 6:21 PM, Peter Geoghegan wrote: > On Mon, Aug 3, 2015 at 3:07 PM, Stephen Frost wrote: >> Thoughts? Trying to keep it straight-forward and provide a simple >> solution for users to be able to address the issue, if they're worried >>

Re: [HACKERS] Idea for improving buildfarm robustness

I wrote: > Josh Berkus writes: >> Give me source with the change, and I'll put it on a cheap, low-bandwith >> AWS instance and hammer the heck out of it. That should raise any false >> positives we can expect. > Here's a draft patch against HEAD (looks like it will work on

Re: [HACKERS] LISTEN denial of service with aborted transaction

On Monday, September 28, 2015 07:22:26 PM Tom Lane wrote: > Matt Newell writes: > > 1. When a connection issues it's first LISTEN command, in > > Exec_ListenPreCommit QUEUE_BACKEND_POS(MyBackendId) = QUEUE_TAIL; > > this causes the connection to iterate through every notify

Re: [HACKERS] Idea for improving buildfarm robustness

On 09/29/2015 12:47 PM, Tom Lane wrote: > We could possibly add additional checks, like trying to verify that > pg_control has the same inode number it used to. But I'm afraid that > would add portability issues and false-positive hazards that would > outweigh the value. Not sure you remember

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

Oleg Bartunov wrote: > me too, but I have to mention one problem we should have in mind - it's > independency from political games (sanctions). Think about developers from > Russia, who one day may be blocked by Github, for example. That's a very good point. I think Github and other sites are

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On 29 September 2015 at 20:52, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > On Tue, Sep 29, 2015 at 8:34 PM, Simon Riggs > wrote: > >> On 29 September 2015 at 12:52, Shulgin, Oleksandr < >> oleksandr.shul...@zalando.de> wrote: >> >> >>> Hitting a process

[HACKERS] Add pg_basebackup single tar output format

Hi. I have a need to pipe the output from pg_basebackup for a multi-tablespace cluster into another program without spooling to disk. Seeing as the current -F tar output format can't do that, I've made an attempt at implementing that myself. As a side effect I've refactored the some of the

Re: [HACKERS] unclear about row-level security USING vs. CHECK

* Dean Rasheed (dean.a.rash...@gmail.com) wrote: > On 28 September 2015 at 20:15, Stephen Frost wrote: > > I listed out the various alternatives but didn't end up getting any > > responses to it. I'm still of the opinion that the documentation is the > > main thing which

[HACKERS] [PATCH 4/6] pg_basebackup: don't lose a zero-length file at the end of a tablespace.

After a complete tar header was buffered it would only be processed during the next iteration of the read loop. A zero-length file such as a directory had no data to read, so the loop would exit without ever having processed the file. --- src/bin/pg_basebackup/pg_basebackup.c | 238

Re: [HACKERS] PATCH: use foreign keys to improve join estimates v1

On 29 September 2015 at 01:59, Tomas Vondra wrote: > > CREATE TABLE f (id1 INT, id2 INT, PRIMARY KEY (id1, id2)); > > CREATE TABLE d1 (id1 INT, id2 INT, FOREIGN KEY (id1, id2) REFERENCES > f(id1, id2)); > CREATE TABLE d2 (id1 INT, id2 INT, FOREIGN KEY (id1, id2)

[HACKERS] Re: BRIN Scan: Optimize memory allocation in function 'bringetbitmap'

I forgot disable-c-assert last test. The following show the test result when disable-c-assert. After optimize code (warm run) postgres=# select count(*) from lineitem where l_orderkey=1; count --- 6 (1 row) Time: 327.143 ms Before optimizing code (warm run) postgres=# select count(*)

Re: [HACKERS] Add pg_basebackup single tar output format

On Wed, Sep 30, 2015 at 7:16 AM, Joshua Elsasser wrote: > On Tue, Sep 29, 2015 at 11:50:37PM +0200, Andres Freund wrote: >> On 2015-09-29 14:38:11 -0700, Josh Elsasser wrote: >> > I've put my changes up as a series of relatively small commits on this >> > branch of a github

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On Tue, Sep 29, 2015 at 6:36 PM, Andrew Dunstan wrote: > > > On 09/29/2015 10:55 AM, Steve Crawford wrote: > >> On Tue, Sep 29, 2015 at 7:16 AM, David Fetter da...@fetter.org>> wrote: >> >> ...What we're not fine with is depending on a proprietary

Re: [HACKERS] Less than ideal error reporting in pg_stat_statements

On Fri, Sep 25, 2015 at 8:51 AM, Marti Raudsepp wrote: > I've also been seeing lots of log messages saying "LOG: out of > memory" on a server that's hosting development databases. I put off > debugging this until now because it didn't seem to have any adverse > effects on the

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On Tue, Sep 29, 2015 at 12:42 PM, Joshua D. Drake wrote: > On 09/29/2015 07:25 AM, Merlin Moncure wrote: >> >> On Wed, Sep 23, 2015 at 1:18 PM, Kam Lasater wrote: >>> >>> Hello, >>> >>> Last night I heard that Postgres had no issue/bug tracker. At

Re: [HACKERS] Idea for improving buildfarm robustness

Joe Conway wrote: > On 09/29/2015 01:48 PM, Alvaro Herrera wrote: > > I remember it, but I'm not sure it would have helped you. As I recall, > > your trouble was that after a reboot the init script decided to initdb > > the mount point -- postmaster wouldn't have been running at all ... > >

Re: [HACKERS] Add pg_basebackup single tar output format

Hi Josh, On 2015-09-29 14:38:11 -0700, Josh Elsasser wrote: > As a side effect I've refactored the some of the pg_basebackup code > for readability and reusability Cool, that's desperately needed. I've been trying to bug Magnus into doing that for a bunch of conferences now ;) > I've put my

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

Merlin Moncure wrote: > I've read this email about three times now and it's not clear at all > to me what a issue/bug tracker brings to the table. In my opinion, this thread is about a bug tracker, not a patch tracker. We already have a patch tracking system which works very well. (We are not

Re: [HACKERS] Idea for improving buildfarm robustness

On 09/29/2015 12:47 PM, Tom Lane wrote: > Josh Berkus writes: >> In general, having the postmaster survive deletion of PGDATA is >> suboptimal. In rare cases of having it survive installation of a new >> PGDATA (via PITR restore, for example), I've even seen the zombie >>

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 09/29/2015 03:08 PM, Merlin Moncure wrote: > I've read this email about three times now and it's not clear at all > to me what a issue/bug tracker brings to the table. Here are the problems I'd like to solve: 1. "Was this issue fixed in a Postgres update? Which one?" 2. Not losing track of

Re: [HACKERS] Idea for improving buildfarm robustness

Josh Berkus writes: > Give me source with the change, and I'll put it on a cheap, low-bandwith > AWS instance and hammer the heck out of it. That should raise any false > positives we can expect. Here's a draft patch against HEAD (looks like it will work on 9.5 or 9.4 without

[HACKERS] [PATCH 2/6] pg_basebackup: factor out tar open/close code for reusability.

This adds a simple struct and open and close functions to abstract and isolate the zlib vs. stdio output logic and allow it to be reused. --- src/bin/pg_basebackup/pg_basebackup.c | 300 +- 1 file changed, 154 insertions(+), 146 deletions(-) diff --git

Re: [HACKERS] Add pg_basebackup single tar output format

On Tue, Sep 29, 2015 at 11:50:37PM +0200, Andres Freund wrote: > On 2015-09-29 14:38:11 -0700, Josh Elsasser wrote: > > I've put my changes up as a series of relatively small commits on this > > branch of a github fork: > > > > https://github.com/jre/postgres/commits/single-tar > > > > Comments

[HACKERS] [PATCH 1/6] Add support for longer filenames in tar headers (up to 254 bytes).

New functions tarHeaderRename() and tarHeaderGetName() are exposed to store and retrieve the longer filenames. tarCreateHeader() continues to limit filenames to 99 bytes to preserve compatability with existing consumers. --- src/include/pgtar.h | 2 + src/port/tar.c | 134

[HACKERS] [PATCH 3/6] pg_basebackup: factor out code to add a recovery.conf file to the tar file.

This is just a simple refactor for readability and reusability. --- src/bin/pg_basebackup/pg_basebackup.c | 46 --- 1 file changed, 26 insertions(+), 20 deletions(-) diff --git a/src/bin/pg_basebackup/pg_basebackup.c b/src/bin/pg_basebackup/pg_basebackup.c index

Re: [HACKERS] Idea for improving buildfarm robustness

Joe Conway wrote: > On 09/29/2015 12:47 PM, Tom Lane wrote: > > We could possibly add additional checks, like trying to verify that > > pg_control has the same inode number it used to. But I'm afraid that > > would add portability issues and false-positive hazards that would > > outweigh the

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On Mon, Sep 28, 2015 at 11:15 PM, Etsuro Fujita wrote: > I thought the same thing [1]. While I thought it was relatively easy to > make changes to RefetchForeignRow that way for the foreign table case > (scanrelid>0), I was not sure how hard it would be to do so for

Re: [HACKERS] CustomScan support on readfuncs.c

> On Mon, Sep 28, 2015 at 8:31 PM, Kouhei Kaigai wrote: > >> Instead of doing this: > >> > >> +/* Dump library and symbol name instead of raw pointer */ > >> appendStringInfoString(str, " :methods "); > >> -_outToken(str, node->methods->CustomName); > >> +

Re: [HACKERS] Comment update to pathnode.c

On 2015/09/29 20:51, Robert Haas wrote: On Tue, Sep 29, 2015 at 1:55 AM, Etsuro Fujita wrote: Thanks for the comments! Attached is an updated version of the patch. Committed and back-patched to 9.5. Thanks! Best regards, Etsuro Fujita -- Sent via

Re: [HACKERS] [PATCH 5/6] pg_basebackup: allow GetConnection() to make non-replication connections.

On Tue, Sep 29, 2015 at 6:16 PM, Joshua Elsasser wrote: > --- Hi! Thanks for submitting patches to the PostgreSQL community. We need more developers, and appreciate contributions. However, I'm somewhat flummoxed by this particular patch series, because (1) there's no real

Re: [HACKERS] LISTEN denial of service with aborted transaction

On Tuesday, September 29, 2015 09:58:35 PM Tom Lane wrote: > Matt Newell writes: > > On Monday, September 28, 2015 07:22:26 PM Tom Lane wrote: > >> Possibly. sinval catchup notification works like that, so you could > >> maybe > >> invent a similar mechanism for notify. Beware

Re: [HACKERS] Idea for improving buildfarm robustness

On Wed, Sep 30, 2015 at 7:19 AM, Tom Lane wrote: > I wrote: >> Josh Berkus writes: >>> Give me source with the change, and I'll put it on a cheap, low-bandwith >>> AWS instance and hammer the heck out of it. That should raise any false >>> positives we can

Re: [HACKERS] PATCH: use foreign keys to improve join estimates v1

On 29 September 2015 at 01:59, Tomas Vondra wrote: > Hi, > > On 09/27/2015 02:00 PM, David Rowley wrote: > >> I've been working on this again. I've put back the code that you wrote >> for the looping over each combination of relations from either side of >> the

Re: [HACKERS] Parallel Seq Scan

On Thu, Sep 24, 2015 at 2:31 PM, Amit Kapila wrote: > [ parallel_seqscan_partialseqscan_v18.patch ] I spent a bit of time reviewing the heapam.c changes in this patch this evening, and I think that your attempt to add support for synchronized scans has some problems. -

[HACKERS] Removing max_connection requirement on hot_standby

I'm orchestrating Postgres to behave as a leader-follower cluster. I've run into issues when I am scaling down a connection count for a cluster (scaling up is fine -- scaling down results in fatal errors). I use an open source tool I've written to orchestrate the cluster called Governor (

Re: [HACKERS] LISTEN denial of service with aborted transaction

Matt Newell writes: > On Monday, September 28, 2015 07:22:26 PM Tom Lane wrote: >> Possibly. sinval catchup notification works like that, so you could maybe >> invent a similar mechanism for notify. Beware that we've had to fix >> performance issues with sinval catchup; you

Re: [HACKERS] Arguable RLS security bug, EvalPlanQual() paranoia

> I'm not convinced this is the right place, but at a minimum it should be > referenced from the RLS documentation. Further, it should be noted that > users who have direct SQL access can control what the isolation level > is for their transaction. I agree that it should be referenced by the RLS

Re: [HACKERS] Doubt in pgbench TPS number

>> Here conn_total_time is the sum of time to establish connection to >> PostgreSQL. Since establishing connections to PostgreSQL is done in >> serial rather than in parallel, conn_total_time should have been >> divided by nclients. > > After some more thinking and looking again at the connection

Re: [HACKERS] pageinspect patch, for showing tuple data

On Tue, Sep 29, 2015 at 11:39 PM, Nikolay Shaplov wrote: > But since now we actually parse data with tuple_data_split, we can provide a > precisely formed fake information, so you are not limited with how it is > actually stored in page. You just pass any arguments you want. So you does not >

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 09/29/2015 03:46 PM, Tom Lane wrote: Alvaro Herrera writes: Merlin Moncure wrote: I've read this email about three times now and it's not clear at all to me what a issue/bug tracker brings to the table. In my opinion, this thread is about a bug tracker, not a

Re: [HACKERS] [PATCH 5/6] pg_basebackup: allow GetConnection() to make non-replication connections.

On Wed, Sep 30, 2015 at 10:47 AM, Robert Haas wrote: > It would probably be a good idea to review > https://wiki.postgresql.org/wiki/Submitting_a_Patch -- the Linux style > of patch submission is generally not preferred here; we like to > discuss closely-related patches as

Re: [HACKERS] PATCH: index-only scans with partial indexes

Hello, At Tue, 29 Sep 2015 16:57:03 +0200, Tomas Vondra wrote in <560aa6bf.5030...@2ndquadrant.com> > >>> The patch does not change the check_index_only implementation - it > >>> still needs to check the clauses, just like in v1 of the patch. To > >>> make this

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On Wed, Sep 30, 2015 at 2:16 AM, Alvaro Herrera wrote: > > > That's a very good point. I think Github and other sites are already > blocked in countries like India and Cuba. Github is not blocked in India and was never as far as I know. Well our government recently

Re: [HACKERS] Doubt in pgbench TPS number

>> FWIW, I vote with Tatsuo-san. Such a change will break comparability of >> results with all previous versions, which means it's not something to do >> in minor releases, even if we now believe the previous results were >> somewhat bogus. Arguing that it's "not a behavioral change" seems >>

Re: [HACKERS] Parallel Seq Scan

On Tue, Sep 29, 2015 at 12:39 AM, Amit Kapila wrote: > Attached patch is a rebased patch based on latest commit (d1b7c1ff) > for Gather node. > > - I have to reorganize the defines in execParallel.h and .c. To keep > ParallelExecutorInfo, in GatherState node, we need to

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

Seems to me that there are a bunch of agendas here. I read about not wanting to be trapped into a proprietary system. You can be trapped in any software you depend upon. Compilers, Platforms, SCM, issue tracking are all places to be trapped. Postgres and Postgresql have been around a very

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 2015-09-29 13:27:15 -0400, Tom Lane wrote: > Corey Huinker writes: > >>> And they'd sure love to be in charge of our code repo. > > >> Mh - i'm not a native speaker. I didn't understand this line. > > > Tom was saying that the JIRA/Atlassian people would happily

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

Andres Freund writes: > On 2015-09-29 13:27:15 -0400, Tom Lane wrote: >> Not that so much as that the gitlab code really wants to be connected up >> to our code repo. That makes complete sense in terms of its goals as >> stated by Torsten upthread, namely to be a git repo

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On Tue, Sep 29, 2015 at 4:49 AM, Kouhei Kaigai wrote: > Also note that EvalPlanQualFetchRowMarks() will raise an error > if RefetchForeignRow callback returned NULL tuple. > Is it right or expected behavior? That's not how I read the code. If RefetchForeignRow returns

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

> > > And they'd sure love to be in charge of our code repo. >> > > Mh - i'm not a native speaker. I didn't understand this line. > > Tom was saying that the JIRA/Atlassian people would happily volunteer to host our code repository for no cost (in money) to us. The implication being that they have

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

Corey Huinker writes: >>> And they'd sure love to be in charge of our code repo. >> Mh - i'm not a native speaker. I didn't understand this line. > Tom was saying that the JIRA/Atlassian people would happily volunteer to > host our code repository for no cost (in money)

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 2015-09-29 13:40:28 -0400, Tom Lane wrote: > Andres Freund writes: > > I don't have any opinion WRT gitlab, but I'm fairly certain it'd be > > unproblematic to configure automatic mirroring into it from > > gitmaster. > > I think you missed my point: gitlab would then

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

Andres Freund writes: > On 2015-09-29 13:40:28 -0400, Tom Lane wrote: >> I think you missed my point: gitlab would then believe it's in charge of, >> eg, granting write access to that repo. We could perhaps whack it over >> the head till it only does what we want and not ten

  1   2   >