On 2018/05/11 15:27, Michael Paquier wrote:
> That's really up to the patch
> author at the end (I prefer matching with NULL, but usually it is better
> to comply with the surroundings for consistency).
Yeah. I think in this case I'll have to withdraw my comment because most
places that check ri_
On Fri, May 11, 2018 at 12:59:27PM +0900, Amit Langote wrote:
> On 2018/05/11 2:13, Robert Haas wrote:
>> On Thu, May 10, 2018 at 12:58 PM, Alvaro Herrera
>> wrote:
>>> David G. Johnston wrote:
As a user I don't really need to know which model is implemented and the
name doesn't necessar
On 2018/05/11 15:12, David Rowley wrote:
> Thanks for looking
>
> On 11 May 2018 at 17:48, Amit Langote wrote:
>> By the way,
>>
>> +!resultRelInfo->ri_PartitionRoot)
>>
>> This should be resultRelInfo->ri_PartitionRoot == NULL, because the above
>> gives an impression that ri_Partiti
On Fri, May 11, 2018 at 06:12:38PM +1200, David Rowley wrote:
> On 11 May 2018 at 17:48, Amit Langote wrote:
>> By the way,
>>
>> +!resultRelInfo->ri_PartitionRoot)
>>
>> This should be resultRelInfo->ri_PartitionRoot == NULL, because the above
>> gives an impression that ri_PartitionR
Thanks for looking
On 11 May 2018 at 17:48, Amit Langote wrote:
> By the way,
>
> +!resultRelInfo->ri_PartitionRoot)
>
> This should be resultRelInfo->ri_PartitionRoot == NULL, because the above
> gives an impression that ri_PartitionRoot is a Boolean.
If this is some new coding rule
Hi David.
On 2018/05/10 18:56, David Rowley wrote:
> On 10 May 2018 at 17:42, Simon Riggs wrote:
>> Patch is good.
>>
>> The cause of this oversight is the lack of comments to explain the
>> original coding, so we need to correct that in this patch, please.
>
> Thanks for looking.
>
> Yeah, the
Hi.
On 2018/05/11 4:45, Alvaro Herrera wrote:
> I'm thinking something like this.
+1 to this more radical overhaul of this part of the documentation.
> The examples for runtime pruning are lame -- in the first, the text says
> "watch out for Subplans Removed" and then the example provided doesn'
On Thursday, February 1, 2018, Konstantin Knizhnik <
k.knizh...@postgrespro.ru> wrote:
>
> Old + New for check = 2
>> plus calculate again in index = 3
>>
>
> Yes, we have to calculate the value of index expression for original and
> updated version of the record. If them are equal, then it is all
On 2018/05/11 2:13, Robert Haas wrote:
> On Thu, May 10, 2018 at 12:58 PM, Alvaro Herrera
> wrote:
>> David G. Johnston wrote:
>>> As a user I don't really need to know which model is implemented and the
>>> name doesn't necessarily imply the implementation. Pruning seems to be the
>>> commonly-u
On Thu, May 10, 2018 at 10:52:12AM +0530, Pavan Deolasee wrote:
> I propose that we should always clear the minRecoveryPoint after promotion
> to ensure that crash recovery always run to the end if a just-promoted
> standby crashes before completing its first regular checkpoint. A WIP patch
> is at
On 2018-05-10 23:25:58 -0400, Robert Haas wrote:
> On Thu, Mar 1, 2018 at 2:48 PM, Andres Freund wrote:
> > I still don't think, as commented upon by Tom and me upthread, that we
> > want this feature in the current form.
>
> Was this concern ever addressed, or did the patch just get committed an
On Thu, Mar 1, 2018 at 2:48 PM, Andres Freund wrote:
> I still don't think, as commented upon by Tom and me upthread, that we
> want this feature in the current form.
Was this concern ever addressed, or did the patch just get committed anyway?
--
Robert Haas
EnterpriseDB: http://www.enterprised
On 11 May 2018 at 08:05, Robert Haas wrote:
>
> On Thu, May 10, 2018 at 3:45 PM, Alvaro Herrera
> wrote:
> > The examples for runtime pruning are lame -- in the first, the text says
> > "watch out for Subplans Removed" and then the example provided doesn't
> > show one. (That example is probably
On Wed, Apr 25, 2018 at 6:31 PM, Andrey Borodin wrote:
> 4. Using O_DIRECT while writing data files
One interesting thing about O_DIRECT that I haven't seen mentioned in
these discussions:
POSIX effectively requires writes to the same file to be serialised,
meaning in practice that [p]write[v]()
On Tue, May 8, 2018 at 7:13 PM, Peter Eisentraut
wrote:
> On 5/8/18 11:31, Tom Lane wrote:
>> Paul Howells writes:
>>> Has there been or is there any current effort to implement SQL:2011
>>> valid-time support in Postgres?
>>
>> Searching the archives, I can only find "valid-time" appearing in th
On Fri, May 4, 2018 at 2:11 AM, Stas Kelvich wrote:
>
>
>> On 3 May 2018, at 18:28, Masahiko Sawada wrote:
>>
>> On Wed, May 2, 2018 at 1:27 AM, Stas Kelvich
>> wrote:
>>> 1) To achieve commit atomicity of different nodes intermediate step is
>>> introduced: at first running transaction is ma
Thank you for the comment.
On Fri, May 11, 2018 at 3:57 AM, Robert Haas wrote:
> On Tue, Feb 27, 2018 at 2:21 AM, Masahiko Sawada
> wrote:
>> I might be missing your point. As for API breaking, this patch doesn't
>> break any existing FDWs. All new APIs I proposed are dedicated to 2PC.
>> In ot
"Jonathan S. Katz" writes:
>> On May 10, 2018, at 12:37 PM, Tom Lane wrote:
>> OTOH, in view of Josh's old gripe, maybe it could be argued to be a bug
>> fix, at least on platforms where it does anything.
> Read back to get some history/context on this, and from my vantage
> point it sounds like
> On May 10, 2018, at 12:37 PM, Tom Lane wrote:
>
> Andres Freund writes:
>> On 2018-05-10 12:18:19 -0400, Tom Lane wrote:
>>> Next question is what to do with this. Do we want to sit on it till
>>> v12, or sneak it in now?
>
>> Is there a decent argument for sneaking it in? I don't really ha
Robert Haas writes:
> On Thu, May 10, 2018 at 3:37 PM, Tom Lane wrote:
>> Yeah, I had hoped that this might make a noticeable difference on slower
>> buildfarm animals, but some testing shows that it's more likely to be
>> barely above the noise floor.
> Any idea why?
Well, maybe the noise floo
On 2018-05-10 16:41:53 -0400, Robert Haas wrote:
> On Mon, Mar 26, 2018 at 4:16 PM, Andres Freund wrote:
> > I dug up a thread about the introduction of the warning:
> > https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00423.html
> >
> > Sounds like we should add something like
> > typedef void (*Gen
On Mon, Mar 26, 2018 at 4:16 PM, Andres Freund wrote:
> I dug up a thread about the introduction of the warning:
> https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00423.html
>
> Sounds like we should add something like
> typedef void (*GenericFuncPtr) (void);
> or such? Similar to what Tom proposed
On Mon, Mar 26, 2018 at 7:51 PM, Craig Ringer wrote:
> There's been no visible consideration of overheads and comparison with
> existing v3 protocol. Personally I'm fine with adding some protocol overhead
> in bytes terms; low latency links have the bandwidth not to care much
> compared to payload
On Thu, May 10, 2018 at 3:37 PM, Tom Lane wrote:
> Yeah, I had hoped that this might make a noticeable difference on slower
> buildfarm animals, but some testing shows that it's more likely to be
> barely above the noise floor.
Any idea why?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.
On Thu, May 10, 2018 at 3:45 PM, Alvaro Herrera
wrote:
> The examples for runtime pruning are lame -- in the first, the text says
> "watch out for Subplans Removed" and then the example provided doesn't
> show one. (That example is probably exercising the wrong thing.)
It seems to me that EXPLAI
I'm thinking something like this.
The examples for runtime pruning are lame -- in the first, the text says
"watch out for Subplans Removed" and then the example provided doesn't
show one. (That example is probably exercising the wrong thing.)
Anyway, wording suggestions for 5.10.4 and 5.10.5 in
> On May 10, 2018, at 10:16 AM, Tom Lane wrote:
>
> Douglas Doole writes:
>> The release notes say:
>> ALTER FUNCTION pg_catalog.ts_rewrite(tsquery, tsquery, tsquery) PARALLEL
>> UNSAFE;
>
>> But when I pull pg_proc.h from 10.4, I find:
>> DATA(insert OID = 3684 ( ts_rewrite PGNSP PGUID 12 1
Andres Freund writes:
> On 2018-05-10 12:18:19 -0400, Tom Lane wrote:
>> Next question is what to do with this. Do we want to sit on it till
>> v12, or sneak it in now?
> Is there a decent argument for sneaking it in? I don't really have an
> opinion. I don't think it'd really be arguable that t
On Fri, Mar 30, 2018 at 5:36 AM, Paul Guo wrote:
> There is no diff in functionality of the dump SQLs, but it is annoying. The
> simple patch below could fix this. Thanks.
>
> --- a/src/backend/utils/adt/ruleutils.c
> +++ b/src/backend/utils/adt/ruleutils.c
> @@ -9389,7 +9389,7 @@ get_const_expr(C
On Tue, Feb 27, 2018 at 2:21 AM, Masahiko Sawada wrote:
> I might be missing your point. As for API breaking, this patch doesn't
> break any existing FDWs. All new APIs I proposed are dedicated to 2PC.
> In other words, FDWs that work today can continue working after this
> patch gets committed, b
On Thu, May 10, 2018 at 1:51 PM, Alvaro Herrera
wrote:
> David G. Johnston wrote:
>> Seems like if it stays the name is good - but at this point no has voiced
>> opposition to removing it and making the name a moot point.
>
> If we think the probability of bugs is 0%, then I'm all for removing it.
David G. Johnston wrote:
> Seems like if it stays the name is good - but at this point no has voiced
> opposition to removing it and making the name a moot point.
If we think the probability of bugs is 0%, then I'm all for removing it.
I don't. I vote to remove the GUC in a couple of releases,
Hi,
On 2018-05-10 12:18:19 -0400, Tom Lane wrote:
> Next question is what to do with this. Do we want to sit on it till
> v12, or sneak it in now?
Is there a decent argument for sneaking it in? I don't really have an
opinion. I don't think it'd really be arguable that this'll make testing
meanin
On Thu, May 10, 2018 at 10:13 AM, Robert Haas wrote:
> On Thu, May 10, 2018 at 12:58 PM, Alvaro Herrera
> wrote:
> > David G. Johnston wrote:
> >> As a user I don't really need to know which model is implemented and the
> >> name doesn't necessarily imply the implementation. Pruning seems to be
Douglas Doole writes:
> The release notes say:
> ALTER FUNCTION pg_catalog.ts_rewrite(tsquery, tsquery, tsquery) PARALLEL
> UNSAFE;
> But when I pull pg_proc.h from 10.4, I find:
> DATA(insert OID = 3684 ( ts_rewrite PGNSP PGUID 12 1 0 0 0 f f f f t f i s
> 3 0 3615 "3615 3615 3615" ...
> Which
On Thu, May 10, 2018 at 12:58 PM, Alvaro Herrera
wrote:
> David G. Johnston wrote:
>> As a user I don't really need to know which model is implemented and the
>> name doesn't necessarily imply the implementation. Pruning seems to be the
>> commonly-used term for this feature and we should stick w
As I was double checking that the new function marking from 10.4 merged
correctly to our fork, I noticed that one of the ts_rewrite entries looks
wrong.
The release notes say:
ALTER FUNCTION pg_catalog.ts_rewrite(tsquery, tsquery, tsquery) PARALLEL
UNSAFE;
But when I pull pg_proc.h from 10.4, I f
David G. Johnston wrote:
> As a user I don't really need to know which model is implemented and the
> name doesn't necessarily imply the implementation. Pruning seems to be the
> commonly-used term for this feature and we should stick with that.
I agree with this conclusion. So we have it right
On Thu, May 10, 2018 at 8:57 AM, Alvaro Herrera
wrote:
> b) by default, no partitions are
> scanned, and we examine the query to determine which ones must be
> scanned.
>
There is an element of logic that says "by default, no partitions are
scanned" is not a reasonable behavior mode. Thus an a
I wrote:
> ... I'll
> take a look at whipping up something that checks /etc/localtime.
Here's a draft patch. It seems to do what I expect on a couple of
different macOS releases as well as recent Fedora. Googling finds
some suggestions that there might be other locations for the symlink,
for ins
David Rowley wrote:
> On 1 May 2018 at 21:44, Amit Langote wrote:
> > About the patch in general, it seems like the newly added documentation
> > talks about "Partition Pruning" as something that *replaces* constraint
> > exclusion. But, I think "Partition Pruning" is not the thing that
> > repla
On Thu, May 10, 2018 at 10:50 AM, Heikki Linnakangas wrote:
> I came up with the attached patch, which is similar to Mario's, but it
> introduces a new "hook" for this.
I'd rather have the hook be executed whenever ProcessInterrupts() is
called, rather than only in the query-cancel case.
--
Rob
On 10/05/18 09:32, Hubert Zhang wrote:
Hi all,
I want to support canceling for a plpython query which may be a busy loop.
I found some discussions on pgsql-hackers 2 years ago. Below is the link.
https://www.postgresql.org/message-id/cafywgj3+xg7ecl2nu-mxx6p+o6c895pm3myz-b+9n9dffeh...@mail.gma
Robert Haas wrote:
> In defense of constraint exclusion, let me note that constraint
> exclusion is not restricted to inheritance cases. It could eliminate
> the need to scan a completely unpartitioned table if the WHERE clause
> can be refuted by CHECK constraints. It could eliminate the need t
On Wed, May 9, 2018 at 10:20 PM, Amit Langote
wrote:
> But it seems I've misinterpreted what he was saying. He doesn't seem to
> be saying anything about how or whether we enforce the unique constraint
> on foreign tables. Only that if someone creates a constraint index on the
> partitioned tabl
On Wed, May 9, 2018 at 10:10 PM, David Rowley
wrote:
> On 10 May 2018 at 14:01, Alvaro Herrera wrote:
>> I'm thinking something a bit more radical. First, since partition
>> pruning is the future and constraint exclusion is soon to be a thing of
>> the past, we should describe pruning first, and
On Thu, May 10, 2018 at 8:30 AM, Amit Langote
wrote:
>
> How about we error out even *before* calling DefineIndex for the 1st time?
> I see that ProcessUtilitySlow() gets a list of all partitions when
> locking them for index creation before calling DefineIndex. Maybe, just
> go through the list
(2018/05/10 13:04), Ashutosh Bapat wrote:
On Wed, May 9, 2018 at 5:20 PM, Etsuro Fujita
wrote:
(2018/04/25 18:51), Ashutosh Bapat wrote:
Actually I noticed that ConvertRowtypeExpr are used to cast a child's
whole row reference expression (not just a Var node) into that of its
parent and not.
While doing a bit more review of the partitionwise-join-fix patch, I
noticed $SUBJECT. Here is an example that causes an assertion failure
"TRAP: FailedAssertion("!(foreignrel)", File: "postgres_fdw.c", Line:
2213)":
postgres=# create table t1 (a int, b text);
CREATE TABLE
postgres=# create table
On Monday, April 9, 2018 11:04:33 PM CEST Tom Lane wrote:
> Stephen Frost writes:
> > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> >> On 4/5/18 02:04, Pavel Raiskup wrote:
> >>> As a followup thought; there are probably two major obstacles ATM
> >>> - the DSOs' symbols are not ye
thanks to everyone, pushed
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
On 10 May 2018 at 17:42, Simon Riggs wrote:
> Patch is good.
>
> The cause of this oversight is the lack of comments to explain the
> original coding, so we need to correct that in this patch, please.
Thanks for looking.
Yeah, the comments do need work. In order to make it a bit easier to
docume
On 09-05-2018 17:30, Alvaro Herrera wrote:
Marina Polyakova wrote:
Hello everyone in this thread!
I got a similar server crash as in [1] on the master branch since the
commit
9fdb675fc5d2de825414e05939727de8b120ae81 when the assertion fails
because
the second argument ScalarArrayOpExpr is no
Hi,
I was investigating the cases when the system attributes are accessed
beyond the scans. After investigating set_plan_references(), I thought
that we never access system attributes beyond scans. This lead me to
assume that EEOP_INNER/OUTER_SYSVAR are not needed since we do not
access system attr
On 05/08/2018 02:05 PM, Justin Pryzby wrote:
3rd iteration ; thanks for bearing with me.
On Tue, May 08, 2018 at 12:35:00PM +0300, Alexander Korotkov wrote:
Hi, Justin!
Thank you for revising documentation patch.
On Mon, May 7, 2018 at 7:55 PM, Justin Pryzby wrote:
+In order to det
On 2018/05/10 14:42, Simon Riggs wrote:
> On 10 May 2018 at 05:33, David Rowley wrote:
>> On 10 May 2018 at 16:13, Amit Langote wrote:
>>> The patch to ExecInsert looks good, but I think we also need to do the
>>> same thing in CopyFrom.
>>
>> I think so too.
>>
>> Updated patch attached.
>
> Pa
56 matches
Mail list logo
