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

On 01.10.2015 00:27, Tom Lane wrote: Josh Berkus writes: On 09/30/2015 03:10 PM, Tom Lane wrote: I'd be feeling a lot more positive about this whole thread if any people had stepped up and said "yes, *I* will put in a lot of grunt-work to make something happen here". The

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: Thursday, October 01, 2015 5:50 PM > To: Kaigai Kouhei(海外 浩平); Robert Haas > Cc: PostgreSQL-development; 花田茂 > Subject: Re: [HACKERS] Foreign

Re: [HACKERS] Parallel Seq Scan

On Wed, Sep 30, 2015 at 7:05 AM, Robert Haas wrote: > > 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

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

On 2015-09-29 15:49:28 -0400, Stephen Frost wrote: > From Andres' reply, it looks like this is about the EXCLUDED pseudo > relation which comes from the INSERT'd values themselves Right. > in which case, I tend to agree with his assessment that it doesn't > make sense for those to be subject to

Re: [HACKERS] Parallel Seq Scan

On Thu, Oct 1, 2015 at 2:35 AM, Kouhei Kaigai wrote: > Gather node was oversight by readfunc.c, even though it shall not be > serialized actually. > Also, it used incompatible WRITE_xxx_FIELD() macro on outfuncs.c. > > The attached patch fixes both of incomsistence. Thanks.

Re: [HACKERS] [DOCS] max_worker_processes on the standby

On Thu, Oct 1, 2015 at 7:48 AM, Alvaro Herrera wrote: > oonish...@nttdata.co.jp wrote: > >> The below error messages were shown in standby server log: >> >> FATAL: could not access status of transaction 9009 >> DETAIL: Could not read from file "pg_commit_ts/" at

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On 2015/10/01 19:02, Kyotaro HORIGUCHI wrote: At Thu, 1 Oct 2015 17:50:25 +0900, Etsuro Fujita wrote in <560cf3d1.9060...@lab.ntt.co.jp> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas So, if we

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

On 2015-09-29 11:52:14 -0700, Peter Geoghegan wrote: > On Tue, Sep 29, 2015 at 8:24 AM, Andres Freund wrote: > > So, took a bit longer than "tomorrow. I fought for a long while with a > > mysterious issue, which turned out to be separate bug: The excluded > > relation was

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

В письме от 30 сентября 2015 13:49:00 пользователь Michael Paquier написал: > > - errmsg("input page too small (%d bytes)", > raw_page_size))); > +errmsg("input page too small (%d > bytes)", raw_page_size))); > Please be

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

Robert Haas writes: > - Bug numbers are sometimes preserved in commit messages, but they > never make it into release notes. This actually seems like something > we could improve pretty easily and without a lot of extra work (and > also without a bug tracker). If every

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

On 10/01/2015 10:35 AM, Robert Haas wrote: On Wed, Sep 30, 2015 at 10:44 AM, Merlin Moncure wrote: I'm not trolling in any way. I'm just challenging you to back up your blanket assertions with evidence. For example, you're assertion that mailing lists are insufficient

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

On 2015-10-01 16:48:32 +0200, Magnus Hagander wrote: > That would require people to actually use the bug form to submit the > initial thread as well of course - which most developers don't do > themselves today. But there is in itself nothing that prevents them from > doing that, of course - other

Re: [HACKERS] Parallel Seq Scan

On Thu, Oct 1, 2015 at 7:52 AM, Amit Kapila wrote: > On Wed, Sep 30, 2015 at 7:05 AM, Robert Haas wrote: >> On Thu, Sep 24, 2015 at 2:31 PM, Amit Kapila >> wrote: >> > [ parallel_seqscan_partialseqscan_v18.patch ] >> >> I

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

On Fri, Sep 18, 2015 at 8:14 PM, Masahiko Sawada wrote: > On Fri, Sep 18, 2015 at 6:13 PM, Fujii Masao wrote: >> On Fri, Sep 4, 2015 at 2:55 PM, Masahiko Sawada >> wrote: >>> On Fri, Sep 4, 2015 at 10:35 AM, Fujii Masao

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

On Thu, Oct 1, 2015 at 4:35 PM, Robert Haas wrote: > On Wed, Sep 30, 2015 at 10:44 AM, Merlin Moncure > wrote: > > I'm not trolling in any way. I'm just challenging you to back up your > > blanket assertions with evidence. For example, you're

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

Andres Freund writes: > On 2015-10-01 11:07:12 -0400, Tom Lane wrote: >> As one of the people who do most of the gruntwork for release notes, >> I can tell you that that sort of fixed-format annotation is useless >> and usually annoying. I can see what branches you fixed the

Re: [HACKERS] pg_dump LOCK TABLE ONLY question

(sorry I lost the original thread somehow) tgl wrote: > Filip wrote: > > I'm running pg_dump constrained to one schema. It appears that pg_dump runs > > "LOCK TABLE %s IN ACCESS SHARE MODE" for each table. > > Naturally it makes sense, but... > > This schema has a table that serves as parent

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

On Wed, Sep 30, 2015 at 10:44 AM, Merlin Moncure wrote: > I'm not trolling in any way. I'm just challenging you to back up your > blanket assertions with evidence. For example, you're assertion that > mailing lists are insufficient is simply stated and expected to be > taken

Re: [HACKERS] Typo in /src/backend/optimizer/README

Etsuro Fujita writes: > The following is a remark added to /src/backend/optimizer/README by > commit 8703059c6b55c427100e00a09f66534b6ccbfaa1, and IIUC, I think "LHS" > in the last sentence "We prevent that by forcing the min LHS for the > upper join to include B."

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

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Josh Berkus writes: > > On 09/30/2015 03:10 PM, Tom Lane wrote: > >> I'd be feeling a lot more positive about this whole thread if any people > >> had stepped up and said "yes, *I* will put in a lot of grunt-work to make > >> something

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

On 2015-10-01 11:07:12 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2015-10-01 16:48:32 +0200, Magnus Hagander wrote: > >> That would require people to actually use the bug form to submit the > >> initial thread as well of course - which most developers don't do > >>

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

On Thu, Oct 1, 2015 at 9:44 AM, Fujii Masao wrote: > I wonder how much it's worth renaming only the file extension while > there are many places where "visibility map" and "vm" are used, > for example, log messages, function names, variables, etc. I'd be inclined to keep

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

Andres Freund writes: > On 2015-10-01 16:48:32 +0200, Magnus Hagander wrote: >> That would require people to actually use the bug form to submit the >> initial thread as well of course - which most developers don't do >> themselves today. But there is in itself nothing that

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

On 10/01/2015 07:48 AM, Magnus Hagander wrote: But using the bugtracker for the discussion itself is usually not a win. I know you said usually but: In fact, I'd say in most cases it's counterproductive because it forces a single tool upon everybody, instead of email which allows each

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

On Thu, Oct 1, 2015 at 10:18 AM, Tom Lane wrote: > Andres Freund writes: >> On 2015-10-01 11:07:12 -0400, Tom Lane wrote: >>> As one of the people who do most of the gruntwork for release notes, >>> I can tell you that that sort of fixed-format annotation

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

On 10/01/2015 08:18 AM, Tom Lane wrote: Andres Freund writes: On 2015-10-01 11:07:12 -0400, Tom Lane wrote: I'm inclined to think that commit messages are not really the right medium for that at all. Commit messages ought to be primarily text for consumption by humans.

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

On 10/01/2015 07:55 AM, Tom Lane wrote: > Playing devil's advocate ... would this really do much other than bloat > the release notes? The entire assumption of this thread is that people > don't, or don't want to, use the release notes to find out what got fixed; > they'd rather search a tracker.

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

On 10/01/2015 05:10 PM, Andres Freund wrote: > On 2015-10-01 11:07:12 -0400, Tom Lane wrote: >> Andres Freund writes: >>> On 2015-10-01 16:48:32 +0200, Magnus Hagander wrote: That would require people to actually use the bug form to submit the initial thread as well

Re: [HACKERS] [DOCS] max_worker_processes on the standby

Fujii Masao wrote: > I've not read the patch yet, but the patched server with > track_commit_timestamp > enabled caused the following PANIC error when I ran pgbench. Ah, that was a stupid typo: I used || instead of &&. Fixed that. I also changed DeactivateCommitTs() so that it removes all

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

On Thu, Oct 1, 2015 at 12:09 PM, Josh Berkus wrote: > On 10/01/2015 07:55 AM, Tom Lane wrote: >> Playing devil's advocate ... would this really do much other than bloat >> the release notes? The entire assumption of this thread is that people >> don't, or don't want to, use

Re: [HACKERS] Potential GIN vacuum bug

On Tue, Sep 1, 2015 at 8:05 AM, Robert Haas wrote: > On Sun, Aug 30, 2015 at 6:57 PM, Tom Lane wrote: > >> But we would still have to deal with the > >> fact that unconditional acquire attempt by the backends will cause a > vacuum > >> to cancel

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

On 10/01/2015 07:43 AM, Robert Haas wrote: > On Thu, Oct 1, 2015 at 9:44 AM, Fujii Masao wrote: >> I wonder how much it's worth renaming only the file extension while >> there are many places where "visibility map" and "vm" are used, >> for example, log messages, function

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

On Thu, Oct 1, 2015 at 3:42 AM, Andres Freund wrote: > Yes, that what I think as well. At this point we'll already have > executed insert rls stuff on the EXCLUDED tuple: > /* > * Check any RLS INSERT WITH CHECK policies > * >

Re: [HACKERS] pg_dump LOCK TABLE ONLY question

On Thu, Oct 1, 2015 at 10:43 PM, Filip Rembiałkowski wrote: > I just want to understand why there is LOCK TABLE not LOCK TABLE ONLY. It seems to me that you'd still want to use LOCK TABLE particularly if the dump is only done on a subset of tables, using --table

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

On Thu, Oct 1, 2015 at 3:53 AM, Andres Freund wrote: >> I specifically remember discussing this with you off list (on IM, >> roughly a couple of weeks prior to initial commit). I recommended that >> we err towards a more restrictive behavior in the absence of any >> strong

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

On Thu, Oct 1, 2015 at 4:17 PM, Andres Freund wrote: > On 2015-10-01 16:13:12 -0700, Peter Geoghegan wrote: >> However, we're checking the excluded tuple (the might-be-inserted, >> might-be-excluded tuple that reflects before row insert trigger >> effects) with

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

On Thu, Oct 1, 2015 at 4:26 PM, Peter Geoghegan wrote: >> You can already see the effects of an INSERT modified by before triggers >> via RETURNING. No? > > I'm not saying that I agree with the decision to not do anything > special with RLS + RETURNING in general. I'm also not

Re: [HACKERS] Idea for improving buildfarm robustness

I wrote: > It strikes me that a different approach that might be of value would > be to re-read postmaster.pid and make sure that (a) it's still there > and (b) it still contains the current postmaster's PID. This would > be morally equivalent to what Jim suggests above, and it would dodge > the

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

On 2015-10-01 16:13:12 -0700, Peter Geoghegan wrote: > However, we're checking the excluded tuple (the might-be-inserted, > might-be-excluded tuple that reflects before row insert trigger > effects) with WCO_RLS_INSERT_CHECK, not WCO_RLS_UPDATE_CHECK. The > WCO_RLS_UPDATE_CHECK applies to the

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

On 2015-10-01 16:26:07 -0700, Peter Geoghegan wrote: > FWIW, I think that this technically wasn't a bug Meh. In which scenario would do a policy applied to EXCLUDED actually anything reasonable? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

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

On Thu, Oct 1, 2015 at 4:49 PM, Andres Freund wrote: > On 2015-10-01 16:26:07 -0700, Peter Geoghegan wrote: >> FWIW, I think that this technically wasn't a bug > > Meh. In which scenario would do a policy applied to EXCLUDED actually > anything reasonable? I agree that it's

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

Hello, I caught up this thread, maybe. > > So, if we wanted to fix this in a way that preserves the spirit of > > what's there now, it seems to me that we'd want the FDW to return > > something that's like a whole row reference, but represents the output > > of the foreign join rather than some

Re: [HACKERS] Parallel Seq Scan

Hi Robert, Gather node was oversight by readfunc.c, even though it shall not be serialized actually. Also, it used incompatible WRITE_xxx_FIELD() macro on outfuncs.c. The attached patch fixes both of incomsistence. Thanks, -- NEC Business Creation Division / PG-Strom Project KaiGai Kohei

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

On 2015-10-01 16:55:23 -0700, Peter Geoghegan wrote: > On Thu, Oct 1, 2015 at 4:49 PM, Andres Freund wrote: > > On 2015-10-01 16:26:07 -0700, Peter Geoghegan wrote: > >> FWIW, I think that this technically wasn't a bug > > > > Meh. In which scenario would do a policy applied

Re: [HACKERS] [DOCS] max_worker_processes on the standby

On Fri, Oct 2, 2015 at 3:12 AM, Alvaro Herrera wrote: > Fujii Masao wrote: > >> I've not read the patch yet, but the patched server with >> track_commit_timestamp >> enabled caused the following PANIC error when I ran pgbench. > > Ah, that was a stupid typo: I used ||

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

> -Original Message- > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kyotaro HORIGUCHI > Sent: Friday, October 02, 2015 9:50 AM > To: Kaigai Kouhei(海外 浩平) > Cc: fujita.ets...@lab.ntt.co.jp; robertmh...@gmail.com; >

Re: [HACKERS] row_security GUC, BYPASSRLS

On Mon, Sep 28, 2015 at 05:13:56PM -0400, Stephen Frost wrote: > * Noah Misch (n...@leadboat.com) wrote: > > In schema reviews, I will raise a red flag for use of this feature; the best > > designs will instead use additional roles. I forecast that PostgreSQL would > > fare better with no

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

On Thu, Oct 1, 2015 at 5:12 PM, Andres Freund wrote: > I'm can't see how the current code can do anything sensible at all. What > do you think is going to be the effect of an excluded row that doesn't > meet security quals? Even if it worked in the sense that the correct >

Re: [HACKERS] Obsolete use of volatile in walsender.c, walreceiver.c, walreceiverfuncs.c?

On Tue, Sep 22, 2015 at 7:25 AM, Thomas Munro wrote: > On Tue, Sep 22, 2015 at 8:19 AM, Alvaro Herrera > wrote: >> Thomas Munro wrote: >> >>> In walsender.c, walreceiver.c, walreceiverfuncs.c there are several >>> places where volatile

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

Hello, I had more condieration on this. > As long as FDW author can choose their best way to produce a joined > tuple, it may be worth to investigate. > > My comments are: > * ForeignRecheck is the best location to call RefetchForeignJoinRow > when scanrelid==0, not ExecScanFetch. Why you try

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

> On 09/30/2015 03:27 PM, Tom Lane wrote: >> Josh Berkus writes: >>> On 09/30/2015 03:10 PM, Tom Lane wrote: I'd be feeling a lot more positive about this whole thread if any people had stepped up and said "yes, *I* will put in a lot of grunt-work to make

[HACKERS] Typo in /src/backend/optimizer/README

The following is a remark added to /src/backend/optimizer/README by commit 8703059c6b55c427100e00a09f66534b6ccbfaa1, and IIUC, I think "LHS" in the last sentence "We prevent that by forcing the min LHS for the upper join to include B." should be "RHS". The use of minimum Relid sets has some

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

Hello, At Thu, 1 Oct 2015 17:50:25 +0900, Etsuro Fujita wrote in <560cf3d1.9060...@lab.ntt.co.jp> > On 2015/10/01 11:15, Kouhei Kaigai wrote: > >> From: pgsql-hackers-ow...@postgresql.org > >> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > >>

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

Hello, At Fri, 2 Oct 2015 03:10:01 +, Kouhei Kaigai wrote in <9a28c8860f777e439aa12e8aea7694f80114d...@bpxm15gp.gisp.nec.co.jp> > > > As long as FDW author can choose their best way to produce a joined > > > tuple, it may be worth to investigate. > > > > > > My

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

Hello, At Fri, 2 Oct 2015 12:51:42 +0900, Etsuro Fujita wrote in <560dff4e.2000...@lab.ntt.co.jp> > On 2015/10/02 9:50, Kyotaro HORIGUCHI wrote: Most of the citation are of Kiagai-san's mentions:) > >> As long as FDW author can choose their best way to produce a

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

> -Original Message- > From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp] > Sent: Friday, October 02, 2015 1:28 PM > To: Kaigai Kouhei(海外 浩平) > Cc: fujita.ets...@lab.ntt.co.jp; robertmh...@gmail.com; > pgsql-hackers@postgresql.org; shigeru.han...@gmail.com > Subject: Re:

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On 2015/10/02 9:50, Kyotaro HORIGUCHI wrote: As long as FDW author can choose their best way to produce a joined tuple, it may be worth to investigate. My comments are: * ForeignRecheck is the best location to call RefetchForeignJoinRow when scanrelid==0, not ExecScanFetch. Why you try to

Re: [HACKERS] Typo in /src/backend/optimizer/README

On 2015/10/01 22:31, Tom Lane wrote: > Etsuro Fujita writes: >> The following is a remark added to /src/backend/optimizer/README by >> commit 8703059c6b55c427100e00a09f66534b6ccbfaa1, and IIUC, I think "LHS" >> in the last sentence "We prevent that by forcing the min

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

On Thu, Oct 1, 2015 at 8:13 PM, Nikolay Shaplov wrote: > В письме от 30 сентября 2015 13:49:00 пользователь Michael Paquier написал: >> >> - errmsg("input page too small (%d bytes)", >> raw_page_size))); >> +errmsg("input page

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

On Thu, Oct 1, 2015 at 9:50 AM, Torsten Zuehlsdorff < mailingli...@toco-domains.de> wrote: > On 01.10.2015 00:27, Tom Lane wrote: > >> Josh Berkus writes: >> >>> On 09/30/2015 03:10 PM, Tom Lane wrote: >>> I'd be feeling a lot more positive about this whole thread if any

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On 2015/10/01 11:15, Kouhei Kaigai wrote: From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas On Mon, Sep 28, 2015 at 11:15 PM, Etsuro Fujita wrote: I thought the same thing [1]. While I thought it was

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On 2015/10/01 15:38, Kyotaro HORIGUCHI wrote: >> I expect FDW driver needs to handle EPQ recheck in the case below: >> * ForeignScan on base relation and it uses late row locking. > I think this is indisputable. I think so. But I think this case would probably be handled by the existing