On Fri, Sep 25, 2015 at 2:03 AM, Fujii Masao wrote:
> On Wed, Sep 23, 2015 at 12:24 AM, Syed, Rahila
> wrote:
>> Hello,
>>
>> Please find attached patch with bugs reported by Thom and Sawada-san solved.
>
> The regression test failed on my machine, so you need to update the
> regression test,
>
> -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: [HACK
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 joined
> >> tuple, it may be wo
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 comments are:
> > > * ForeignR
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
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 LHS for the
>> upper join to i
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 add
> -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;
> pgsql-hackers@postgres
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 owner-co
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 || instead of &&. Fixed that.
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 qualifiers are used apparently only to prevent
>>> reordering
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 t
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
> data were accessed and e
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 to EXCLUDED actually
>
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 very unlikely to matte
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 going to say
> that
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 subscr
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 WCO_RLS_INSERT_CHECK, not WCO_RLS_UP
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 for
example.
--
Michael
--
Sen
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 principle pushing us one
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 tuple
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
> *
> * E
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 c
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 names, variables, etc.
>
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 itself, which is undesirable.
> >
> > Good point.
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 the release notes to f
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 slru
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 of course - which mos
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.
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. If we had a tracker,
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 is useless
>>> and usually annoying. I c
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 person
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 bug in
>> anyway, fro
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
> >> themselves today. But
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 prevents them from
>> d
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
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 is simply stated and e
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 committer makes a practice
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 assertion that
> > mailing lists are insufficient i
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 calling it the visibility
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 on faith: *How* is i
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 spent a bit of time reviewing the heapam.c changes in this patch
>> this e
* 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 happen here". The la
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 wrote:
On Fri, Sep 4, 2015 at 2:23 AM, Masahiko Sawada
wrote:
(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 fo
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." should be "RHS".
Mmm, yeah, tha
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. You missed READ_DONE(
> -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 join
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 I think that your attempt to add support for
> s
В письме от 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 ca
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 wanted to fix this in a way that p
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 affected by row level sec
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 offset 90112:
>> Success.
>>
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 R
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
> >> On Mon, Sep 28, 2015 at 11:15
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 pitfal
> 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
something happen here". Th
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 relatively easy to
make changes to
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 RefetchF
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 people
had step
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 lack of any volunte
61 matches
Mail list logo
