Hi,
On Fri, Apr 16, 2021, at 20:18, Justin Pryzby wrote:
> On Fri, Apr 16, 2021 at 09:48:54PM -0500, Justin Pryzby wrote:
> > On Fri, Apr 16, 2021 at 07:17:55PM -0700, Andres Freund wrote:
> > > Hi,
> > >
> > > On 2020-12-18 17:56:07 -0600, Justin Pryzby wrote:
> > > > I'd be happy to run with a
On Fri, Apr 16, 2021 at 11:24 PM Andres Freund wrote:
>
> > I think it is also important to *not* acquire any lock on relation
> > otherwise it can lead to some sort of deadlock or infinite wait in the
> > decoding process. Consider a case for operations like Truncate (or if
> > the user has
On Saturday, April 17, 2021 12:53 AM Japin Li
> On Fri, 16 Apr 2021 at 17:19, osumi.takami...@fujitsu.com
> wrote:
> > On Friday, April 16, 2021 5:50 PM Amit Kapila
> wrote:
> >> On Fri, Apr 16, 2021 at 12:56 PM osumi.takami...@fujitsu.com
> >> wrote:
> >> >
> >> > > Thanks for your reminder.
On Fri, Apr 16, 2021 at 09:48:54PM -0500, Justin Pryzby wrote:
> On Fri, Apr 16, 2021 at 07:17:55PM -0700, Andres Freund wrote:
> > Hi,
> >
> > On 2020-12-18 17:56:07 -0600, Justin Pryzby wrote:
> > > I'd be happy to run with a prototype fix for the leak to see if the other
> > > issue
> > >
On Fri, Apr 16, 2021 at 07:17:55PM -0700, Andres Freund wrote:
> Hi,
>
> On 2020-12-18 17:56:07 -0600, Justin Pryzby wrote:
> > I'd be happy to run with a prototype fix for the leak to see if the other
> > issue
> > does (not) recur.
>
> I just posted a prototype fix to
>
Thomas Munro writes:
> On Sat, Apr 17, 2021 at 10:47 AM Tom Lane wrote:
>> Although there are only a few buildfarm members complaining, I don't
>> really want to leave them red all weekend. I could either commit the
>> patch I just presented, or revert ef387bed8 ... got a preference?
> +1 for
Hi,
On 2020-12-18 17:56:07 -0600, Justin Pryzby wrote:
> I'd be happy to run with a prototype fix for the leak to see if the other
> issue
> does (not) recur.
I just posted a prototype fix to
https://www.postgresql.org/message-id/20210417021602.7dilihkdc7oblrf7%40alap3.anarazel.de
(just
On Fri, Apr 16, 2021 at 1:16 PM Peter Geoghegan wrote:
> I'm not sure what to do, though. Both the INDEX_CLEANUP = off case and
> the failsafe case are only intended for emergencies. And it's hard to
> know what to do in a code path that is designed to rarely or never be
> used.
How about just
On Sat, Apr 17, 2021 at 10:47 AM Tom Lane wrote:
> Thomas Munro writes:
> > I'll look into the details some more on Monday.
>
> Fair enough.
>
> Although there are only a few buildfarm members complaining, I don't
> really want to leave them red all weekend. I could either commit the
> patch I
Hi,
This patch is a WIP fix for the issue described in [1], where the
planner picks a more expensive plan with partition-wise joins enabled,
and disabling this option produces a cheaper plan. That's a bit strange
because with the option disabled we consider *fewer* plans, so we should
not be able
On Fri, Apr 16, 2021 at 2:20 PM Matthias van de Meent
wrote:
> > Interesting approach. I think that in an ideal world we would have a
> > tuple format with attribute lengths/offsets right in the header.
>
> I believe that that would indeed be ideal w.r.t. access speed, but
> also quite expensive
Thomas Munro writes:
> I'll look into the details some more on Monday.
Fair enough.
Although there are only a few buildfarm members complaining, I don't
really want to leave them red all weekend. I could either commit the
patch I just presented, or revert ef387bed8 ... got a preference?
On Sat, Apr 17, 2021 at 8:39 AM Tom Lane wrote:
> Per the changes in collate.icu.utf8.out, this gets rid of
> a lot of imaginary collation dependencies, but it also gets
> rid of some arguably-real ones. In particular, calls of
> record_eq and its siblings will be considered not to have
> any
On Fri, 16 Apr 2021 at 18:03, Peter Geoghegan wrote:
>
> On Thu, Apr 15, 2021 at 11:06 AM Matthias van de Meent
> wrote:
> > I've noticed there are a lot of places in the btree index
> > infrastructure (and also some other index AMs) that effectively
> > iterate over the attributes of the index
On Fri, Apr 16, 2021 at 04:19:18PM -0400, Alvaro Herrera wrote:
> Maybe we can reword it in some other way. "If this parameter is set
> when a partitioned table is created, it will become the default
> tablespace for future partitions too, even if default_tablespace itself
> is reset later" ...??
On 4/16/21 3:32 PM, Esteban Zimanyi wrote:
> Many thanks Tom for your help !
>
> I removed the flag -fshort-enums and everything works fine !
>
>
If you build with pgxs it should supply the appropriate compiler flags.
Alternatively, get the right settings from pg_config. In general rolling
I wrote:
> I feel like this is telling us that there's a fundamental
> misunderstanding in find_expr_references_walker about which
> collation dependencies to report. It's reporting all the
> leaf-node collations, and ignoring the ones that actually
> count semantically, that is the inputcollid
On 2021-Apr-16, Justin Pryzby wrote:
> +++ b/doc/src/sgml/config.sgml
> @@ -7356,7 +7356,8 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH
> csv;
>
> This variable specifies the default tablespace in which to create
> objects (tables and indexes) when a
On Wed, Apr 14, 2021 at 7:11 AM Masahiko Sawada wrote:
> If we create a table with vacuum_index_cleanup = off or execute VACUUM
> with INDEX_CLEANUP = off, vacuum updates pg_stat_all_tables.n_dead_tup
> to the number of HEAPTUPLE_RECENTLY_DEAD tuples. Whereas analyze
> updates it to the sum of
Many thanks Tom for your help !
I removed the flag -fshort-enums and everything works fine !
On Fri, Apr 16, 2021 at 7:04 PM Tom Lane wrote:
> Esteban Zimanyi writes:
> > When debugging the function with gdb, I noticed that the rsinfo variable
> of
> > the PostgreSQL function
Hi,
Peter Geoghegan suggested that I have the cross version upgrade checker
run pg_amcheck on the upgraded module. This seemed to me like a good
idea, so I tried it, only to find that it refuses to run unless the
amcheck extension is installed. That's fair enough, but it also seems to
me like
Hi,
On 2021-04-16 08:42:40 +0530, Amit Kapila wrote:
> I think it is because relation_open expects either caller to have a
> lock on the relation or don't use 'NoLock' lockmode. AFAIU, we don't
> need to acquire a lock on relation while decoding changes from WAL
> because it uses a historic
I wrote:
> Oh, I bet it's "C.utf8", because I can reproduce the failure with that.
> This crystallizes a nagging feeling I'd had that you were misdescribing
> the collate.icu.utf8 test as not being run under --no-locale. Actually,
> it's only skipped if the encoding isn't UTF8, not the same
Andres Freund writes:
> On 2021-04-16 12:55:28 -0400, Tom Lane wrote:
>> ... or maybe not just yet. Andres' buildfarm critters seem to have
>> a different opinion than my machine about what the output of
>> collate.icu.utf8 ought to be. I wonder what the prevailing LANG
>> setting is for them,
I wrote:
> ... or maybe not just yet. Andres' buildfarm critters seem to have
> a different opinion than my machine about what the output of
> collate.icu.utf8 ought to be. I wonder what the prevailing LANG
> setting is for them, and which ICU version they're using.
Oh, I bet it's "C.utf8",
Esteban Zimanyi writes:
> When debugging the function with gdb, I noticed that the rsinfo variable of
> the PostgreSQL function ExecMakeFunctionResultSet is modified in the
> macro SRF_RETURN_NEXT causing the problem. Any idea how to solve this?
Well, what SRF_RETURN_NEXT thinks it's doing is
Hi,
On 2021-04-16 12:55:28 -0400, Tom Lane wrote:
> I wrote:
> >> That's what I ended up with too, so LGTM!
>
> > Pushed, thanks for review! (and I'll update the open items list in a
> > sec)
>
> ... or maybe not just yet. Andres' buildfarm critters seem to have
> a different opinion than my
I wrote:
>> That's what I ended up with too, so LGTM!
> Pushed, thanks for review! (and I'll update the open items list in a
> sec)
... or maybe not just yet. Andres' buildfarm critters seem to have
a different opinion than my machine about what the output of
collate.icu.utf8 ought to be. I
Dear Tom
Many thanks for asking my question so quickly. After your answer, I
downloaded brand new versions of PostgreSQL 13.2, PostGIS 2.5.5, and
compiled/installed with the standard parameters. I didn't get any error
messages in the build. I then recompiled again MobilityDB and got the same
Julien Rouhaud writes:
> On Fri, Apr 16, 2021 at 10:03:42AM -0400, Tom Lane wrote:
>> So I propose that we do 0001 below, which is my first patch plus your
>> suggestion about fixing up create_index.sql. This passes check-world
>> for me under both C and en_US.utf8 prevailing locales.
> That's
On Thu, Apr 15, 2021 at 11:06 AM Matthias van de Meent
wrote:
> I've noticed there are a lot of places in the btree index
> infrastructure (and also some other index AMs) that effectively
> iterate over the attributes of the index tuple, but won't use
> index_deform_tuple for reasons. However,
On Fri, Apr 16, 2021 at 10:03:42AM -0400, Tom Lane wrote:
>
> Since the proposed patch removes the dependency code's special-case
> handling of the default collation, I don't feel like we need to jump
> through hoops to prove that the default collation is tracked the
> same as other collations.
On Fri, 16 Apr 2021 at 17:19, osumi.takami...@fujitsu.com
wrote:
> Hi
>
>
> On Friday, April 16, 2021 5:50 PM Amit Kapila wrote:
>> On Fri, Apr 16, 2021 at 12:56 PM osumi.takami...@fujitsu.com
>> wrote:
>> >
>> > > Thanks for your reminder. It might be a way to solve this problem.
>> > Yeah.
Justin Pryzby writes:
> Text mode uses appendStringInfo() for high density output, so this only
> affects
> non-text output, but it turns out that units aren't shown for nontext format
> anyway - this seems like a deficiency, but it means there's no visible bug.
Yeah, I concur: these should say
commit 87259588d0ab0b8e742e30596afa7ae25caadb18
Author: Alvaro Herrera
Date: Thu Apr 25 10:20:23 2019 -0400
Fix tablespace inheritance for partitioned rels
This doc change doesn't make sense to me:
+++ b/doc/src/sgml/config.sgml
@@ -7356,7 +7356,8 @@ COPY postgres_log FROM
Esteban Zimanyi writes:
> Since I was receiving an error when defining a set returning function, I
> borrowed a function from PostgreSQL as follows
> ...
> When I execute this function I obtain
> select testSRF(1,10, 2);
> ERROR: unrecognized table-function returnMode: 257
Hmm, I compiled this
On Fri, Apr 16, 2021 at 11:00 AM Michael Paquier wrote:
> On Sat, Apr 03, 2021 at 02:28:38PM +0200, Erik Rijkers wrote:
> > So, that gives information on two operators, and then gives one
> > example query for each. Clearly, the second example was meant to
> > illustrate a where-clause with the
Julien Rouhaud writes:
> On Thu, Apr 15, 2021 at 10:06:24AM -0400, Tom Lane wrote:
>> 0001 fails for me :-(. I think that requires default collation to be C.
> Oh right, adding --no-locale to the regress opts I see that create_index is
> failing, and that's not the one I was expecting.
> We
Dear all
Since I was receiving an error when defining a set returning function, I
borrowed a function from PostgreSQL as follows
/* C definition */
typedef struct testState
{
int current;
int finish;
int step;
} testState;
/**
* test_srf(startval int, endval int, step int)
*/
> This usecase is not about benchmarking. It's about generating constant trafic
> to be able to practice/train some [auto]switchover procedures while being
> close
> to production activity.
>
> In this contexte, a max-saturated TPS of one node is not relevant. But being
> able to add some stats
On Fri, 16 Apr 2021 10:28:48 +0900 (JST)
Tatsuo Ishii wrote:
> > By the way, I've been playing with the idea of failing gracefully and retry
> > indefinitely (or until given -T) on SQL error AND connection issue.
> >
> > It would be useful to test replicating clusters with a (switch|fail)over
>
On Sat, Apr 10, 2021 at 2:16 AM Thomas Munro wrote:
>
In commit 1d257577e08d3e598011d6850fd1025858de8c8c, there is a change
in file format for stats, won't it require bumping
PGSTAT_FILE_FORMAT_ID?
Actually, I came across this while working on my today's commit
f5fc2f5b23 where I forgot to bump
On Thu, 15 Apr 2021 at 21:24, Justin Pryzby wrote:
>
> On Thu, Apr 15, 2021 at 08:47:26PM +0200, Matthias van de Meent wrote:
> > I recently noticed that ATTACH PARTITION also recursively locks the
> > default partition with ACCESS EXCLUSIVE mode when its constraints do
> > not explicitly exclude
On Fri, Apr 16, 2021 at 11:28 AM Amit Kapila wrote:
>
> On Thu, Apr 15, 2021 at 4:35 PM Masahiko Sawada wrote:
> >
> > Thank you for the update! The patch looks good to me.
> >
>
> I have pushed the first patch. Comments on the next patch
> v13-0001-Use-HTAB-for-replication-slot-statistics:
On Fri, Apr 16, 2021 at 3:16 PM Amit Kapila wrote:
>
> On Mon, Apr 12, 2021 at 2:57 PM vignesh C wrote:
> >
> > On Sat, Mar 20, 2021 at 9:26 AM Amit Kapila wrote:
> > >
> > > On Sat, Mar 20, 2021 at 12:22 AM Andres Freund wrote:
> > > >
> > > > And then more generally about the feature:
> > >
On Tue, Mar 16, 2021 at 2:21 AM Tom Lane wrote:
>
> Bharath Rupireddy writes:
> > Thanks for pointing to the changes in the commit message. I corrected
> > them. Attaching v4 patch set, consider it for further review.
>
> I took a quick look at this. I'm quite worried about the potential
>
On Fri, Apr 16, 2021 at 3:08 PM Japin Li wrote:
>
> On Fri, 16 Apr 2021 at 16:52, Amit Kapila wrote:
> > On Fri, Apr 16, 2021 at 12:55 PM Japin Li wrote:
> > It is okay as POC but we can't change the existing function
> > RelationGetIndexAttrBitmap. It is used from other places as well. It
> >
On Mon, Apr 12, 2021 at 2:57 PM vignesh C wrote:
>
> On Sat, Mar 20, 2021 at 9:26 AM Amit Kapila wrote:
> >
> > On Sat, Mar 20, 2021 at 12:22 AM Andres Freund wrote:
> > >
> > > And then more generally about the feature:
> > > - If a slot was used to stream out a large amount of changes (say an
On Fri, 16 Apr 2021 at 16:52, Amit Kapila wrote:
> On Fri, Apr 16, 2021 at 12:55 PM Japin Li wrote:
>>
>> On Thu, 15 Apr 2021 at 19:25, Amit Kapila wrote:
>> > On Thu, Apr 15, 2021 at 4:30 PM Japin Li wrote:
>> >>
>> >>
>> >> On Thu, 15 Apr 2021 at 18:22, Amit Kapila wrote:
>> >> > On Wed,
Hi
On Friday, April 16, 2021 5:50 PM Amit Kapila wrote:
> On Fri, Apr 16, 2021 at 12:56 PM osumi.takami...@fujitsu.com
> wrote:
> >
> > > Thanks for your reminder. It might be a way to solve this problem.
> > Yeah. I've made the 1st patch for this issue.
> >
> > In my env, with the patch
> >
On Fri, Apr 16, 2021 at 12:55 PM Japin Li wrote:
>
> On Thu, 15 Apr 2021 at 19:25, Amit Kapila wrote:
> > On Thu, Apr 15, 2021 at 4:30 PM Japin Li wrote:
> >>
> >>
> >> On Thu, 15 Apr 2021 at 18:22, Amit Kapila wrote:
> >> > On Wed, Apr 14, 2021 at 3:31 PM Amit Kapila
> >> > wrote:
> >> >>
>
On Fri, Apr 16, 2021 at 12:56 PM osumi.takami...@fujitsu.com
wrote:
>
> > Thanks for your reminder. It might be a way to solve this problem.
> Yeah. I've made the 1st patch for this issue.
>
> In my env, with the patch
> the TRUNCATE in synchronous logical replication doesn't hang.
>
Few
On Thu, Apr 15, 2021 at 07:25:39PM -0400, Tom Lane wrote:
> Here's a draft patch that converts all the built-in and information_schema
> SQL functions to new style, except for half a dozen that cannot be
> converted because they use polymorphic arguments.
This patch looks good.
> One thing I was
On Sat, Apr 03, 2021 at 02:28:38PM +0200, Erik Rijkers wrote:
> So, that gives information on two operators, and then gives one
> example query for each. Clearly, the second example was meant to
> illustrate a where-clause with the @? operator.
>
> Small change to prevent great confusion
On Mon, Apr 12, 2021 at 02:35:27PM -0700, Andres Freund wrote:
> On 2021-04-12 17:14:20 -0400, Tom Lane wrote:
> > I doubt that falsely labeling a function LEAKPROOF can get you more
> > than the ability to read data you're not supposed to be able to read
> > ... but that ability is then available
Hi
On Friday, April 16, 2021 11:02 AM Japin Li
> On Thu, 15 Apr 2021 at 19:25, Amit Kapila wrote:
> > On Thu, Apr 15, 2021 at 4:30 PM Japin Li wrote:
> >>
> >>
> >> On Thu, 15 Apr 2021 at 18:22, Amit Kapila
> wrote:
> >> > On Wed, Apr 14, 2021 at 3:31 PM Amit Kapila
> wrote:
> >> >>
> >> >>
On Thu, 15 Apr 2021 at 19:25, Amit Kapila wrote:
> On Thu, Apr 15, 2021 at 4:30 PM Japin Li wrote:
>>
>>
>> On Thu, 15 Apr 2021 at 18:22, Amit Kapila wrote:
>> > On Wed, Apr 14, 2021 at 3:31 PM Amit Kapila
>> > wrote:
>> >>
>> >> On Tue, Apr 13, 2021 at 8:07 PM Petr Jelinek
>> >> wrote:
>>
A bunch more found with things like this.
find src -name '*.c' |xargs grep '^[[:space:]]*/\?\*' |grep -woE
'[[:lower:]]{3,8}' |sed 's/.*/\L&/' |
sort |uniq -c |sort -nr |awk '$1==1' |less
>From 9fd5e2797efc14f83bfb2d47d5174de81a34ac6e Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date:
From: Pavel Stehule
--
I am sorry, but in this topic we have different opinions. The variables in
PLpgSQL are not transactional too (same is true in Perl, Python, ...). Session
variables in Oracle, MS SQL, DB2, MySQL are not transactional too. My
pá 16. 4. 2021 v 8:07 odesílatel Joel Jacobson napsal:
> On Thu, Apr 15, 2021, at 10:42, Pavel Stehule wrote:
>
> *Attachments:*
>
>- schema-variables-v-execnode-2021-01.patch
>- schema-variables-v-utility-2021-01.patch
>
>
> Applications are currently know to be misusing
>
On Tue, Apr 06, 2021 at 02:25:05PM +0900, Amit Langote wrote:
> While updating the patch to do so, it occurred to me that maybe we
> could move the ExecInitResultRelation() call into
> create_estate_for_relation() too, in the spirit of removing
> duplicative code. See attached updated patch.
On Fri, Apr 16, 2021 at 8:24 AM Fujii Masao wrote:
> We are still discussing whether RESTRICT option should be pushed down to
> a foreign data wrapper. But ISTM at least we could reach the consensus about
> the drop of extra information for each foreign table. So what about applying
> the
On Thu, Apr 15, 2021, at 10:42, Pavel Stehule wrote:
> *Attachments:*
> * schema-variables-v-execnode-2021-01.patch
> * schema-variables-v-utility-2021-01.patch
Applications are currently know to be misusing set_config()+current_setting()
to pass information in a session or transaction.
Such
63 matches
Mail list logo
