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 com
В 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
> >> https://www.postgresql.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
> 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 may
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 tha
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 viol
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
app
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 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 'wal_retrieve
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 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
> diff
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
>
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 = resolve_generic_type(ANYELE
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 Co
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 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 it
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 p
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 bran
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 at
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
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 esti
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 anythi
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
1573Assert(t
On Fri, Feb 7, 2020 at 02:49:14PM +0530, Kuntal Ghosh wrote:
> Hello Hackers,
>
> While working on some issue in logical decoding, I found some
> inconsistencies in the comment for defining max_cached_tuplebufs in
> reorderbuffer.c. It only exists till PG10 because after that the
> definition got
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 thousan
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 than
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 shor
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 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 duplic
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 enhancements.
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 or
On Fri, Mar 13, 2020 at 7:48 PM Isaac Morland wrote:
>
> On Fri, 13 Mar 2020 at 03:13, John Naylor wrote:
>
>> - align weeks to start on Sunday
>> select date_trunc_interval('7 days'::interval, TIMESTAMP '2020-02-11
>> 01:01:01.0', TIMESTAMP '1900-01-02');
>> date_trunc_interval
>> -
32 matches
Mail list logo
