On Fri, Mar 13, 2020 at 1:06 PM James Coleman wrote:
>
> On Thu, Mar 12, 2020 at 5:53 PM Alvaro Herrera
> wrote:
> >
> > I gave this a very quick look; I don't claim to understand it or
> > anything, but I thought these trivial cleanups worthwhile. The only
> > non-cosmetic thing is changing
On Sun, Mar 15, 2020 at 02:48:02PM +1300, Thomas Munro wrote:
On Sun, Mar 15, 2020 at 1:08 PM Tomas Vondra
wrote:
On Sat, Mar 14, 2020 at 05:56:10PM +0100, Tomas Vondra wrote:
>Attached is a patch series rebased on top of the current master, after
>committing the ScalarArrayOpExpr
On Sun, Mar 15, 2020 at 1:08 PM Tomas Vondra
wrote:
> On Sat, Mar 14, 2020 at 05:56:10PM +0100, Tomas Vondra wrote:
> >Attached is a patch series rebased on top of the current master, after
> >committing the ScalarArrayOpExpr enhancements. I've updated the OR patch
> >to get rid of the code
On Fri, 13 Mar 2020 at 15:04, Andres Freund wrote:
> On 2020-03-13 14:08:12 +0800, Craig Ringer wrote:
> > The alternative would be to detect a missing clang and emit a much more
> > informative error than the current one that explicitly suggests retrying
> > with
> >
> > make with_llvm=no
>
On Sat, Mar 14, 2020 at 05:56:10PM +0100, Tomas Vondra wrote:
...
Attached is a patch series rebased on top of the current master, after
committing the ScalarArrayOpExpr enhancements. I've updated the OR patch
to get rid of the code duplication, and barring objections I'll get it
committed
Bruce Momjian writes:
> I am sorry --- I am confused. Why are we truncating or allowing control
> of truncation of BIND parameter values, but have no such facility for
> queries. Do we assume queries are shorter than BIND parameters, or is
> it just that it is easier to trim BIND parameters
On Thu, Mar 12, 2020 at 12:01:24PM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > The reason I'm so hot about parameter truncation is that we've seen
> > cases where customers' log files contain log lines many megabytes long
> > because of gigantic parameters; UUID arrays with tens of
On Sat, Mar 14, 2020 at 02:41:09PM -0400, James Coleman wrote:
It looks like the issue is actually into the `tuplecontext`, which is
currently a child context of `sortcontext`:
#3 0x558cd153b565 in AllocSetCheck
(context=context@entry=0x558cd28e0b70) at aset.c:1573
1573
Hi There!
I forgot about that ... It passed a little time from my new pushed
changes. So go ahead :)
On Tue, Mar 10, 2020 at 3:15 PM Stephen Frost wrote:
>
> Greetings,
>
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Stephen Frost writes:
> > > Anyway, I don't anticipate having time to do
Hi,
I realized there's one more thing that probably needs discussing.
Essentially, these two clause types are the same:
a IN (1, 2, 3)
(a = 1 OR a = 2 OR a = 3)
but with 8f321bd1 we only recognize the first one as compatible with
functional dependencies. It was always the case that we
On Sat, Mar 14, 2020 at 12:36 PM James Coleman wrote:
>
> On Sat, Mar 14, 2020 at 12:24 PM James Coleman wrote:
> >
> > On Sat, Mar 14, 2020 at 12:07 PM James Coleman wrote:
> > >
> > > On Fri, Mar 13, 2020 at 8:23 PM James Coleman wrote:
> > > >
> > > > On Friday, March 13, 2020, Tomas Vondra
On Tue, Mar 03, 2020 at 04:24:59PM +0100, Julien Rouhaud wrote:
>
> cfbot reports a failure since 2f9661311b (command completion tag
> change), so here's a rebased v6, no change otherwise.
Conflict with 8e8a0becb3 (Unify several ways to tracking backend type), thanks
again to cfbot, rebased v7
On Fri, Mar 13, 2020 at 2:39 PM Alvaro Herrera wrote:
> Here's the rebased version.
>
> I just realized I didn't include the API change I proposed in
> https://postgr.es/m/20200306200343.GA625@alvherre.pgsql ...
Thanks for your help with this Alvaro!
I was just adding your changes to my own
On Sat, Mar 14, 2020 at 03:04:00AM -0700, legrand legrand wrote:
> imai.yoshik...@fujitsu.com wrote
> > On Thu, Mar 12, 2020 at 6:37 PM, Julien Rouhaud wrote:
> >> That's very interesting feedback, thanks! I'm not a fan of giving a way
> >> for
> >> queries to say that they want to be ignored by
On Fri, Mar 13, 2020 at 04:54:51PM +, Dean Rasheed wrote:
On Mon, 9 Mar 2020 at 00:06, Tomas Vondra wrote:
On Mon, Mar 09, 2020 at 01:01:57AM +0100, Tomas Vondra wrote:
>
>Attaches is an updated patch series
>with parts 0002 and 0003 adding tests demonstrating the issue and then
>fixing
On Sat, Mar 14, 2020 at 12:24 PM James Coleman wrote:
>
> On Sat, Mar 14, 2020 at 12:07 PM James Coleman wrote:
> >
> > On Fri, Mar 13, 2020 at 8:23 PM James Coleman wrote:
> > >
> > > On Friday, March 13, 2020, Tomas Vondra
> > > wrote:
> > >>
> > >> On Fri, Mar 13, 2020 at 04:31:16PM -0400,
On Sat, Mar 14, 2020 at 12:07 PM James Coleman wrote:
>
> On Fri, Mar 13, 2020 at 8:23 PM James Coleman wrote:
> >
> > On Friday, March 13, 2020, Tomas Vondra
> > wrote:
> >>
> >> On Fri, Mar 13, 2020 at 04:31:16PM -0400, James Coleman wrote:
> >>>
> >>> On Fri, Mar 13, 2020 at 2:23 PM James
parse_coerce.c's resolve_generic_type() is written on the assumption
that it might be asked to infer any polymorphic type's concrete type
given any other polymorphic type's concrete type. This is overkill,
because the only call sites look like
anyelement_type =
On Fri, Mar 13, 2020 at 8:23 PM James Coleman wrote:
>
> On Friday, March 13, 2020, Tomas Vondra wrote:
>>
>> On Fri, Mar 13, 2020 at 04:31:16PM -0400, James Coleman wrote:
>>>
>>> On Fri, Mar 13, 2020 at 2:23 PM James Coleman wrote:
On Tue, Mar 10, 2020 at 10:44 PM Tomas Vondra
On Fri, Feb 21, 2020 at 10:09:38AM +0100, Peter Eisentraut wrote:
> From 75ac8ed0c47801712eb2aa300d9cb29767d2e121 Mon Sep 17 00:00:00 2001
> From: Peter Eisentraut
> Date: Thu, 20 Feb 2020 18:16:39 +0100
> Subject: [PATCH v2 3/4] Add backend type to csvlog and optionally
> log_line_prefix
>
Hi,
I've pushed the first part of the patch, adding ScalarArrayOpExpr as
supported clause for functional dependencies, and then also doing the
same for MCV lists.
As discussed, I'm not going to do anything about the array containment
clauses for PG13, that needs more discussion.
I have a bunch
On 2020/02/19 21:46 Fujii Masao :
>> I agree to the former, I think RecoveryWalInterval works well enough.
>RecoveryWalInterval sounds confusing to me...
IMHO as a user, I prefer RecoveryRetrieveRetryInterval because
it's easy to understand this wait_event is related to the
parameter
so 14. 3. 2020 v 14:26 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > pá 13. 3. 2020 v 23:42 odesílatel Tom Lane napsal:
> >> The reason that this might be controversial is that it forces a slightly
> >> less precise error detail message to be issued, since the call site
> that's
> >>
On Fri, Mar 13, 2020 at 7:02 PM Dilip Kumar wrote:
>
> Apart from that, I have also extended the solution for the page lock.
> And, I have also broken down the 3rd patch in two parts for relation
> extension and for the page lock.
>
Thanks, I have made a number of cosmetic changes and written
Pavel Stehule writes:
> pá 13. 3. 2020 v 23:42 odesílatel Tom Lane napsal:
>> The reason that this might be controversial is that it forces a slightly
>> less precise error detail message to be issued, since the call site that's
>> throwing the error doesn't know exactly which rule was being
Victor Wagner writes:
> Tom Lane пишет:
>> Read the whole thread. We fixed the issue with recursion in the
>> postmaster (9abb2bfc0); but the intermittent failure in
>> infinite_recurse is exactly the same as what we've been seeing for a
>> long time in the buildfarm, and there is zero doubt
> I don't know it is useful but there are also codes that avoid an error when
> sourceText is NULL.
> executor_errposition(EState *estate, int location)
> {
> ...
>/* Can't do anything if source text is not available */
>if (estate == NULL || estate->es_sourceText == NULL)
> }
or
imai.yoshik...@fujitsu.com wrote
> On Thu, Mar 12, 2020 at 6:37 PM, Julien Rouhaud wrote:
>> On Thu, Mar 12, 2020 at 1:11 PM Marco Slot
> marco.slot@
> wrote:
>> > On Thu, Mar 12, 2020 at 11:31 AM Julien Rouhaud
> rjuju123@
>
>> wrote:
>> > > There's at least the current version of IVM
В Fri, 13 Mar 2020 10:56:15 -0400
Tom Lane пишет:
> Victor Wagner writes:
> > Justin Pryzby wrote:
> >> On Fri, Mar 13, 2020 at 10:29:13AM +0300, Victor Wagner wrote:
> >>> I've encountered a problem with Postgres on PowerPC machine.
>
> >> Is it related to
> >>
pá 13. 3. 2020 v 23:42 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > [ anycompatible-types-20191127.patch ]
>
> I'm starting to review this patch seriously. I've found some bugs and
> things I didn't like, and the documentation certainly needs work, but
> I think I can get it to a
30 matches
Mail list logo
