Hello,
In my previous patch 0001, the resulting opblock consisted of a single
br instruction to it's successor opblock. Such a block represents
unnecessary overhead. Even though such a block would be optimized
away, what if optimization is not performed (perhaps due to
jit_optimize_above_cost)?
On Sat, Sep 21, 2019 at 12:26 AM Fabien COELHO wrote:
>
> >> I would not bother to create a patch for so small an improvement. This
> >> makes sense in passing because the created function makes it very easy,
> >> but otherwise I'll just drop it.
> >
> > I would prefer to drop for now.
>
>
> "David" == David Fetter writes:
David> + /* Compute the result string. */
David> + if (value >= 1)
David> + {
David> + const uint32 value2 = value % 1;
David> +
David> + const uint32 c = value2 % 1;
David> +
On Fri, Sep 20, 2019 at 10:57:04AM -0700, Jeff Davis wrote:
> Thank you, applied.
Okay, I can see which parts you have changed.
> * I also changed the comment above pg_fe_scram_channel_bound() to
> clarify that the caller must also check that the exchange was
> successful.
>
> * I changed the
On Fri, Sep 20, 2019 at 05:30:48PM +0200, Tomas Vondra wrote:
> But even with that change you haven't managed to reproduce the issue,
> right? Or am I misunderstanding?
No, I was not able to see it on my laptop running Debian.
--
Michael
signature.asc
Description: PGP signature
On 2019-Sep-20, Tom Lane wrote:
> =?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?=
> writes:
> > I have come around a strange situation when using a unicode string
> > that has non normalized characters. The attached script 'initcap.sql'
> > can reproduce the problem.
For illustration
I pushed the first few parts. The attached is a rebased copy of the
last remaining piece. However, I didn't quite understand what this was
doing, so I refrained from pushing. I think there are two patches here:
one that adapts the API of findJsonbValueFromContainer and
Peter Eisentraut writes:
> It looks like there is documentation for PG_COLORS in the release notes
> now, which seems like an odd place. Suggestions for a better place?
BTW, as far as that goes, it looks like PG_COLOR is documented separately
in each frontend program's "Environment" man page
Peter Eisentraut writes:
>> Here is a draft patch.
Where are we on pushing that? I'm starting to get antsy about the
amount of time remaining before rc1. It's a low-risk fix, but still,
it'd be best to have a complete buildfarm cycle on it before Monday's
wrap.
=?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?=
writes:
> I have come around a strange situation when using a unicode string
> that has non normalized characters. The attached script 'initcap.sql'
> can reproduce the problem.
> The attached patch can fix the issue.
If we're going to start
Hi,
On September 20, 2019 5:45:34 AM PDT, Jeff Janes wrote:
>While testing something else (whether "terminating walsender process
>due to
>replication timeout" was happening spuriously), I had logical
>replication
>set up streaming a default pgbench transaction load, with the publisher
>being
Alvaro Herrera writes:
> Uh .. I didn't think it was possible that we would build the same
> snapshot file more than once. Isn't that a waste of time anyway? Maybe
> we can fix the symptom by just not doing that in the first place?
> I don't have a strategy to do that, but seems worth
Hi,
On September 20, 2019 3:06:20 PM PDT, Alvaro Herrera
wrote:
>On 2019-Sep-20, Tom Lane wrote:
>
>> Actually, what I did was as attached [1], and I am getting traces
>like
>> [2]. The problem seems to occur only when there are two or three
>> processes concurrently creating the same
Hi,
On 2019-09-20 17:49:27 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-09-20 16:25:21 -0400, Tom Lane wrote:
> >> I recreated my freebsd-9-under-qemu setup and I can still reproduce
> >> the problem, though not with high reliability (order of 1 time in 10).
> >> Anything
Sigh, forgot about attaching the attachments ...
regards, tom lane
diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.c
index 0bd1d0f..53fd33c 100644
--- a/src/backend/replication/logical/snapbuild.c
+++
Andres Freund writes:
> On 2019-09-20 16:25:21 -0400, Tom Lane wrote:
>> I recreated my freebsd-9-under-qemu setup and I can still reproduce
>> the problem, though not with high reliability (order of 1 time in 10).
>> Anything particular you want logged?
> A DEBUG2 log would help a fair bit,
On Fri, Sep 20, 2019 at 11:09:16PM +0200, David Fetter wrote:
> On Fri, Sep 20, 2019 at 09:14:51PM +0200, David Fetter wrote:
> > On Wed, Sep 18, 2019 at 04:27:46PM +0900, Kyotaro Horiguchi wrote:
> > > Hello.
> > >
> > > At Wed, 18 Sep 2019 05:42:01 +0200, David Fetter wrote
> > > in
On Fri, Sep 20, 2019 at 09:14:51PM +0200, David Fetter wrote:
> On Wed, Sep 18, 2019 at 04:27:46PM +0900, Kyotaro Horiguchi wrote:
> > Hello.
> >
> > At Wed, 18 Sep 2019 05:42:01 +0200, David Fetter wrote
> > in <20190918034201.gx31...@fetter.org>
> > > On Tue, Sep 17, 2019 at 09:01:57AM +0200,
Hello,
I have come around a strange situation when using a unicode string
that has non normalized characters. The attached script 'initcap.sql'
can reproduce the problem.
The attached patch can fix the issue.
Regards,
Juan José Santamaría Flecha
initcap.sql
Description: application/sql
diff
Hi,
On 2019-09-20 16:56:57 -0300, Alvaro Herrera wrote:
> > > +/*
> > > + * The top-level portal that the client is immediately working with:
> > > + * creating, binding, executing, or all at one using simple protocol
> > > + */
> > > +Portal current_top_portal = NULL;
> > > +
> >
> > This
On Wed, Jul 17, 2019 at 5:20 PM Darafei "Komяpa" Praliaskouski
wrote:
> Indeed, it seems I failed to minimize my example.
>
> Here is the actual one, on 90GB table with 16M rows:
> https://gist.github.com/Komzpa/8d5b9008ad60f9ccc62423c256e78b4c
>
> I can share the table on request if needed, but
Hi,
On 2019-09-13 22:22:50 +0300, Alexander Korotkov wrote:
> On Thu, Sep 12, 2019 at 4:55 PM Alexander Korotkov
> wrote:
> > On Wed, Sep 11, 2019 at 3:30 PM Amit Kapila wrote:
> > > On Sun, Sep 1, 2019 at 1:37 PM Alexander Korotkov
> > > wrote:
> > > > I found it weird that CLUSTER/VACUUM
Hi, thanks for looking.
On 2019-Sep-20, Andres Freund wrote:
> On 2019-09-18 17:58:53 -0300, Alvaro Herrera wrote:
> > + > xreflabel="log_parameters_on_error">
> > + log_parameters_on_error
> > (boolean)
> > +
> > + log_parameters_on_error configuration
> > parameter
> >
On Wed, Sep 18, 2019 at 04:27:46PM +0900, Kyotaro Horiguchi wrote:
> Hello.
>
> At Wed, 18 Sep 2019 05:42:01 +0200, David Fetter wrote in
> <20190918034201.gx31...@fetter.org>
> > On Tue, Sep 17, 2019 at 09:01:57AM +0200, David Fetter wrote:
> > > On Tue, Sep 17, 2019 at 08:55:05AM +0200, David
Hello Amit,
I would not bother to create a patch for so small an improvement. This
makes sense in passing because the created function makes it very easy,
but otherwise I'll just drop it.
I would prefer to drop for now.
Attached v13 does that, I added a comment instead. I do not think that
On Fri, Sep 20, 2019 at 11:09 AM David Steele wrote:
> Seems to me we are overdue for elog()/ereport() compatible
> error-handling in the front end. Plus mem contexts.
>
> It sucks to make that a prereq for this project but the longer we kick
> that can down the road...
There are no doubt many
Hi,
On 2019-09-19 17:46:06 +0300, Sergei Kornilov wrote:
>
> - This parameter can only be set at server start.
> + This parameter can only be set in the
> postgresql.conf
> + file or on the server command line.
>This setting has no effect if the
On Fri, 2019-09-20 at 13:07 +0900, Michael Paquier wrote:
> Those are mainly nits, and attached are the changes I would do to
> your
> patch. Please feel free to consider those changes as you see fit.
> Anyway, the base logic looks good to me, so I am switching the patch
> as ready for committer.
Hi,
On 2019-09-19 17:20:15 +0530, Kuntal Ghosh wrote:
> It seems there is a pattern how the error is occurring in different
> systems. Following are the relevant log snippets:
>
> nightjar:
> sub3 LOG: received replication command: CREATE_REPLICATION_SLOT
> "sub3_16414_sync_16394" TEMPORARY
"kuroda.hay...@fujitsu.com" writes:
>> If a solid case can be made that ECPG's DECLARE STATEMENT was done
>> wrong, we'd be better off to just revert the feature out of v12
>> and try again, under less time pressure, for v13.
> I see, I'll propose this at the next commitfest.
> But I'm now
On 2019-Sep-18, Michael Paquier wrote:
> On Tue, Sep 17, 2019 at 10:50:22PM -0300, Alvaro Herrera wrote:
> > On 2019-Sep-18, Michael Paquier wrote:
> >> So, with the clock ticking and the release getting close by, what do
> >> we do for this set of issues? REINDEX, CREATE INDEX and CLUSTER all
>
On Thu, Sep 19, 2019 at 01:23:05PM +0900, Michael Paquier wrote:
On Wed, Sep 18, 2019 at 11:58:08PM +0200, Tomas Vondra wrote:
I kinda suspect it might be just a coincidence that it fails during that
particular test. What likely plays a role here is a checkpoint timing
(AFAICS that's the thing
I have added support of all indexes (brin, btree, gin, gist, hash,
spgist) for global temp tables (before only B-Tree index was supported).
It will be nice to have some generic mechanism for it, but I do not
understand how it can look like.
The problem is that normal relations are initialized at
On 9/20/19 9:46 AM, Robert Haas wrote:
> On Thu, Sep 19, 2019 at 11:06 PM David Steele wrote:
>
>> My experience is that JSON is simple to implement and has already dealt
>> with escaping and data structure considerations. A home-grown solution
>> will be at least as complex but have the
On Fri, Sep 20, 2019 at 9:46 AM Robert Haas wrote:
> - appendStringInfo et. al. I don't think it would be that hard to move
> this to src/common, but I'm also not sure it really solves the
> problem, because StringInfo has a 1GB limit, and there's no rule at
> all that a backup manifest has got
On Thu, 19 Sep 2019 at 12:26, Isaac Morland wrote:
> If we're going to open this up, can we add an option to say "this key is
> allowed to log in to this account", SSH style?
>
> I like the idea of using keys rather than .pgpass, but I like the
> ~/.ssh/authorized_keys model and don't like the
On Thu, Sep 19, 2019 at 11:06 PM David Steele wrote:
> > I don't think it's a good idea to duplicate the information that's
> > already in the backup_label. Storing two copies of the same
> > information is just an invitation to having to worry about what
> > happens if they don't agree.
>
> OK,
Hi Surafel,
On 16.07.2019 10:08, Surafel Temesgen wrote:
i also add an option to ignore all errors in ERROR set to -1
Great!
The patch still applies cleanly (tested on e1c8743e6c), but I've got
some problems using more elaborated tests.
First of all, there is definitely a problem with
On Thu, Sep 19, 2019 at 11:10 PM David Steele wrote:
> Overall we have found it's much simpler to label each backup and
> cross-check that against the pg version and system id. Start LSN is
> pretty unique, but backup labels work really well and are more widely
> understood.
I see your point,
While testing something else (whether "terminating walsender process due to
replication timeout" was happening spuriously), I had logical replication
set up streaming a default pgbench transaction load, with the publisher
being 13devel-e1c8743 and subscriber being 12BETA4. Eventually I started
On Thu, Sep 19, 2019 at 5:29 PM Asim R P wrote:
>
> In order to fix the test failures, we need to distinguish between a
missing database directory and a missing tablespace directory. And also
add logic to forget missing directories during tablespace drop. I am
working on it.
Please find
On Fri, Sep 20, 2019 at 09:16:58AM +0900, Michael Paquier wrote:
> On Thu, Sep 19, 2019 at 02:13:23PM +0300, Nikolay Shaplov wrote:
>> What a good catch! dummy_index already proved to be useful ;-)
>
> Yes, the testing around custom reloptions is rather poor now, so this
> module has value. I
Hi John,
Thanks for pushing this, for me it looks like promising start! I need a bit
more time to go through the code (and I'm not an expert in Postgres
internals in any way) but I really appreciate you doing this.
Roman
On Fri, Sep 20, 2019 at 10:29 AM Fabien COELHO wrote:
>
> >> The behavior is not actually changed, but I had to move fillfactor away
> >> because it cannot be declared on partitioned tables, it must be declared
> >> on partitions only. Once there is a function to handle that it is pretty
> >>
On 2019-09-20 01:14, Tom Lane wrote:
> Chapman Flack writes:
>> Sure, against *every* non-spec feature we have or ever will have, someone
>> /could/ raise a generic "what if SQL committee might add something pretty
>> similar in future".
>> But what we have in this case are specific non-spec
On Thu, Sep 19, 2019 at 4:15 PM Amit Langote
wrote:
> Hi Richard,
>
> Thanks a lot for taking a close look at the patch and sorry about the
> delay.
>
> On Wed, Sep 4, 2019 at 5:29 PM Richard Guo wrote:
> >> On Wed, Sep 4, 2019 at 10:01 AM Amit Langote
> wrote:
> > I'm reviewing v2-0002 and I
On Fri, Sep 20, 2019 at 1:41 PM Fabien COELHO wrote:
>
>
> > Should we add function header for the below function to maintain the
> > common standard of this file:
>
> Yes. Attached v6 does that.
>
Thanks for fixing it.
The below addition can be removed, it seems to be duplicate:
@@ -3734,6
Hi Dilip,
Thank you for reviewing this patch.
On Fri, Sep 20, 2019 at 12:48 PM Dilip Kumar wrote:
> On Thu, Aug 29, 2019 at 3:15 PM Richard Guo wrote:
> >
> >
> > Attached is a patch as an attempt to address this issue. The idea is
> > quite straightforward. When building partition info for
On 20/9/19 4:06, Michael Paquier wrote:
On Thu, Sep 19, 2019 at 05:40:41PM +0300, Alexey Kondratov wrote:
On 19.09.2019 16:21, Robert Haas wrote:
So, earlier in this thread, I suggested making this part of ALTER
TABLE, and several people seemed to like that idea. Did we have a
reason for
Should we add function header for the below function to maintain the
common standard of this file:
Yes. Attached v6 does that.
--
Fabien.diff --git a/contrib/pg_stat_statements/expected/pg_stat_statements.out b/contrib/pg_stat_statements/expected/pg_stat_statements.out
index
The patch series failed on Windows CI. I modified the Windows build file to
fix that. See attached for the v7 version.
v7-0003-Ensure-target-clean-shutdown-at-the-beginning-of-.patch
Description: Binary data
v7-0001-Extact-common-recovery-related-functions-from-pg_.patch
Description: Binary
On Thu, Sep 19, 2019 at 11:10:46PM -0400, David Steele wrote:
> On 9/19/19 11:00 AM, Robert Haas wrote:
>> On Thu, Sep 19, 2019 at 9:51 AM Robert Haas wrote:
>> > I intend that we should be able to support incremental backups based
>> > either on a previous full backup or based on a previous
On Fri, Sep 20, 2019 at 12:38 PM Michael Paquier wrote:
>
> > One small thing:
> >
> > add_int_reloption(bl_relopt_kind, buf,
> >"Number of bits generated for each index column",
> > - DEFAULT_BLOOM_BITS, 1, MAX_BLOOM_BITS);
> > + DEFAULT_BLOOM_BITS, 1, MAX_BLOOM_BITS,
> > +
On Fri, Sep 20, 2019 at 11:59:13AM +0530, Kuntal Ghosh wrote:
> On Fri, Sep 20, 2019 at 7:08 AM Michael Paquier wrote:
>> Hence attached is a patch set to address those issues:
>> - 0001 makes sure that any existing module creating a custom reloption
>> has the lock mode set to
On Fri, Sep 20, 2019 at 7:08 AM Michael Paquier wrote:
>
> Hence attached is a patch set to address those issues:
> - 0001 makes sure that any existing module creating a custom reloption
> has the lock mode set to AccessExclusiveMode, which would be a sane
> default anyway. I think that we
55 matches
Mail list logo
