Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2019-03-12 14:42:14 +0900, Michael Paquier wrote:
> > On Mon, Mar 11, 2019 at 08:38:56PM +, Regina Obe wrote:
> > > I tested on windows mingw64 (as of a week ago) and confirmed the
> > > patch applies cleanly and significantly faster
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> If we want to run it from the server itself, then I guess a background
> worker would be a better solution. Incidentally, that's something I've
> been toying with some time ago, see [1].
So, I'm a big fan of this idea of having a
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> On 3/2/19 12:03 AM, Robert Haas wrote:
> > On Tue, Sep 18, 2018 at 10:37 AM Michael Banck
> > wrote:
> >> I have added a retry for this as well now, without a pg_sleep() as well.
> >> This catches around 80% of the half-reads, but
Hello.
At Sun, 17 Mar 2019 20:23:05 -0400, Hugh Ranalli wrote in
> Hi Ram,
> Thanks for doing this; I've been overestimating my ability to get to things
> over the last couple of weeks.
>
> I've looked at the patch and have made one minor change. I had moved all
> the imports up to the top,
Chapman Flack writes:
> Given a Portal, or an _SPI_plan, is there a practical way to tell whether
> it came from a query with FOR UPDATE or FOR SHARE?
In principle, you could do something like drilling down into the plan
tree to see if there's a LockRows node, but this wouldn't necessarily
be a
On Mon, 18 Mar 2019 at 14:06, David Rowley wrote:
>
> On Mon, 18 Mar 2019 at 10:08, Tom Lane wrote:
> > If that doesn't work (because we need the index info sooner), maybe we
> > could consider never removing ECs from eq_classes, so that their indices
> > never change, then teaching most/all of
On Sun, Mar 17, 2019 at 09:00:57PM +0800, Chris Travers wrote:
> I also added test cases and some docs. I don't know if the docs are
> sufficient. Feedback is appreciated.
To be honest, I don't think that this approach is a good idea per the
same reasons as mentioned the last time, as this can
On Sun, Mar 17, 2019 at 12:44:39PM +0100, Fabien COELHO wrote:
> I kept the initial no-parameter function which calls the new one with 4
> parameters, though, because it looks more homogeneous this way in the
> backend code. This is debatable.
From a compatibility point of view, your position
On Sun, Mar 17, 2019 at 5:53 PM Arseny Sher wrote:
> Thomas Munro writes:
>
> > 1. Why does pmdie()'s SIGTERM case terminate parallel workers
> > immediately? That breaks aborts running parallel queries, so they
> > don't get to end their work normally.
> > 2. Why are new parallel workers not
Hi Nikolay,
This patch does not apply. Please refer to http://commitfest.cputube.org/ and
update it.
How about separating your patch by feature or units that can be phased commit.
For example, adding assert macro at first, refactoring StdRdOptions by the
next, etc.
So I change status to
On Tue, Feb 26, 2019 at 7:20 PM Masahiko Sawada wrote:
>
> On Tue, Feb 26, 2019 at 1:35 PM Haribabu Kommi
> wrote:
> >
> > On Thu, Feb 14, 2019 at 9:17 PM Masahiko Sawada
> > wrote:
> >>
> >> Thank you. Attached the rebased patch.
> >
> >
> > I ran some performance tests to compare the
On Fri, Mar 15, 2019 at 3:25 PM Amit Kapila wrote:
>
> I have committed the latest version of this patch. I think we can
> wait for a day or two see if there is any complain from buildfarm or
> in general and then we can close this CF entry.
>
Closed this CF entry.
--
With Regards,
Amit
On 2019/03/15 2:56, Robert Haas wrote:
> On Thu, Mar 14, 2019 at 1:16 PM Tom Lane wrote:
>> Actually, now that I've absorbed a bit more about 898e5e329,
>> I don't like very much about it at all. I think having it
>> try to hang onto pointers into the relcache is a completely
>> wrongheaded
On 2019/03/15 1:02, Robert Haas wrote:
> On Thu, Mar 14, 2019 at 3:13 AM Amit Langote
> wrote:
>> I'm curious why DestroyPartitionDirectory doesn't do
>> hash_destroy(pdir->pdir_hash)?
>
> What would be the point? It's more efficient to let context teardown
> take care of it.
Yeah, I only
On Thu, Mar 14, 2019 at 09:04:41AM +0900, Michael Paquier wrote:
> Thanks for confirming, Mythun. I'll think about the logic of this
> patch for a couple of days in the background, then I'll try to commit
> it likely at the beginning of next week.
Committed. I have spent extra time polishing
On Saturday, March 16, 2019 5:40 PM (GMT+9), Fabien COELHO wrote:
> > Fabien, I was wondering whether you can apply TCP_USER_TIMEOUT patch
> > and continue discussion about 'socket_timeout'?
> I can apply nothing, I'm just a small-time reviewer.
> Committers on the thread are Michaël-san and
Thanks for looking at this.
On Mon, 18 Mar 2019 at 10:08, Tom Lane wrote:
> I looked at this for a little bit. I'm on board with the basic idea
> of assigning integer indexes to the ECs and keeping bitmapsets of
> relevant EC indexes in RelOptInfos. However ... man, is that
> delete_eclass()
From: mikalaike...@ibagroup.eu [mailto:mikalaike...@ibagroup.eu]
> Based on your comment it seems to me that 'socket_timeout' should be
> connected with statement_timeout. I mean that end-user should wait
> statement_timeout + 'socket_timeout' for returning control. It looks much
> more safer for
Hi,
Given a Portal, or an _SPI_plan, is there a practical way to tell whether
it came from a query with FOR UPDATE or FOR SHARE?
Regards,
-Chap
On Fri, Mar 15, 2019 at 6:20 AM, Imai, Yoshikazu wrote:
> Upon committing this, we have to care this patch break backwards
> compatibility, but I haven't seen any complaints so far. If there are
> no objections, I will set this patch to ready for committer.
Jose had set this to ready for
Hi Ram,
Thanks for doing this; I've been overestimating my ability to get to things
over the last couple of weeks.
I've looked at the patch and have made one minor change. I had moved all
the imports up to the top, to keep them in one place (and I think some had
originally been used only by the
On Sat, Mar 16, 2019 at 10:55 PM, Euler Taveira wrote:
> > Is there no need to rewrite the Description in the Doc to state we should
> specify either -d or -f option?
> > (and also it might be better to write if -l option is given, neither
> > -d nor -f option isn't necessarily needed.)
> >
> I
On Sun, Mar 17, 2019 at 12:01:31PM +0100, Magnus Hagander wrote:
> LGTM.
Okay, committed.
--
Michael
signature.asc
Description: PGP signature
On Tue, Oct 02, 2018 at 10:53:40AM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Mon, Oct 01, 2018 at 09:32:10PM -0400, Tom Lane wrote:
> >> FWIW, my problem with this patch is that I remain unconvinced of the basic
> >> correctness of the transform (specifically the unique-ification
I wrote:
> Thomas Munro writes:
>> This was an intentional change in TLS1.3, reducing round trips by
>> verifying the client certificate later.
> Ugh. So probably we can reproduce it elsewhere if we use cutting-edge
> OpenSSL versions.
I installed OpenSSL 1.1.1a on my Mac laptop. I got
On 17.03.2019 21:29, Jonathan S. Katz wrote:
On 3/17/19 1:14 PM, Alexander Korotkov wrote:
On Sun, Mar 17, 2019 at 8:06 PM Jonathan S. Katz wrote:
On 3/17/19 1:02 PM, Alexander Korotkov wrote:
Thank you for the explanation. Is it jsonb_ops or jsonb_path_ops?
I just used "USING gin(col)"
Thomas Munro writes:
> On Sun, Mar 17, 2019 at 2:00 AM Thomas Munro wrote:
>> I opened a bug report with OpenSSL, let's see what they say:
>> https://github.com/openssl/openssl/issues/8500
> This was an intentional change in TLS1.3, reducing round trips by
> verifying the client certificate
On Sun, Mar 17, 2019 at 2:00 AM Thomas Munro wrote:
> On Wed, Mar 6, 2019 at 9:21 AM Tom Lane wrote:
> > Yeah, I've still been unable to reproduce even with the sleep idea,
> > so eelpout is definitely looking like a special snowflake from here.
> > In any case, there seems little doubt that
On 03/17/19 15:06, Tom Lane wrote:
> The error message issue is indeed a concern, but I don't see why it's
> complicated if you agree that
>
>> If the query asked for CONTENT, any error result should be one you could get
>> when parsing as CONTENT.
>
> That just requires us to save the first
David Rowley writes:
> [ eclass_indexes_v3.patch ]
I looked at this for a little bit. I'm on board with the basic idea
of assigning integer indexes to the ECs and keeping bitmapsets of
relevant EC indexes in RelOptInfos. However ... man, is that
delete_eclass() thing ugly. And slow, and
> "Tom" == Tom Lane writes:
Tom> Yeah, it seems like mostly a lack-of-round-tuits problem.
Tom> Updating the aggregate's dependencies correctly might be a bit
Tom> tricky, but it can't be any worse than the corresponding problem
Tom> for functions...
I was worried about that myself but
I wrote:
> The cause of this error is that RequestCheckpoint will give up and fail
> after just 2 seconds, which evidently is not long enough on slow or
> heavily loaded machines. Since there isn't any good reason why the
> checkpointer wouldn't be running, I'm inclined to swing a large hammer
>
Chapman Flack writes:
> On 03/17/19 13:16, Tom Lane wrote:
>> Do we need a pre-scan at all?
> Without it, we double the time to a failure result in every case that
> should actually fail, as well as in this one corner case that we want to
> see succeed, and the question you posed earlier about
On 3/17/19 1:14 PM, Alexander Korotkov wrote:
> On Sun, Mar 17, 2019 at 8:06 PM Jonathan S. Katz wrote:
>> On 3/17/19 1:02 PM, Alexander Korotkov wrote:
>>>
>>> Thank you for the explanation. Is it jsonb_ops or jsonb_path_ops?
>>
>> I just used "USING gin(col)" so jsonb_ops.
>
> I see. So,
On 03/17/19 13:16, Tom Lane wrote:
> Chapman Flack writes:
>> What I was doing in the patch is the reverse: parsing with the expectation
>> of CONTENT to see if a DTD gets tripped over. It isn't allowed for an
>> element to precede a DTD, so that approach can be expected to fail fast
>> if the
You have one error at the end of update_controlfile(), where close()
could issue a frontend-like error for the backend, calling exit() on the
way. That's not good. (No need to send a new patch, I'll fix it
myself.)
Indeed. I meant to merge the "if (close(fd))", but ended merging the error
Chapman Flack writes:
> What I was doing in the patch is the reverse: parsing with the expectation
> of CONTENT to see if a DTD gets tripped over. It isn't allowed for an
> element to precede a DTD, so that approach can be expected to fail fast
> if the other branch needs to be taken.
Ah, right.
On Sun, Mar 17, 2019 at 8:06 PM Jonathan S. Katz wrote:
> On 3/17/19 1:02 PM, Alexander Korotkov wrote:
> >
> > Thank you for the explanation. Is it jsonb_ops or jsonb_path_ops?
>
> I just used "USING gin(col)" so jsonb_ops.
I see. So, jsonb_ops extracts from this query only existence of
On 03/17/19 11:45, Tom Lane wrote:
> Chapman Flack writes:
>> On 03/16/19 17:21, Tom Lane wrote:
>>> (1) always try to parse as document. If successful, we're done.
>>> (2) otherwise, if allowed by xmloption, try to parse using our
>
>> What I don't like about that is that (a) the input could
On 3/17/19 1:02 PM, Alexander Korotkov wrote:
>
> Thank you for the explanation. Is it jsonb_ops or jsonb_path_ops?
I just used "USING gin(col)" so jsonb_ops.
Thanks,
Jonathan
signature.asc
Description: OpenPGP digital signature
On Sun, Mar 17, 2019 at 8:00 PM Jonathan S. Katz wrote:
> On 3/17/19 12:55 PM, Alexander Korotkov wrote:
> >
> >> However, when I did something a little more complex, like the below:
> >>
> >> SELECT count(*)
> >> FROM news_feed
> >> WHERE data @? '$.length ? (@ < 150)';
> >>
> >> SELECT count(*)
On 3/17/19 12:55 PM, Alexander Korotkov wrote:
>
>> However, when I did something a little more complex, like the below:
>>
>> SELECT count(*)
>> FROM news_feed
>> WHERE data @? '$.length ? (@ < 150)';
>>
>> SELECT count(*)
>> FROM news_feed
>> WHERE data @? '$.content ? (@ like_regex "^Start")';
Hi!
On Sun, Mar 17, 2019 at 7:46 PM Jonathan S. Katz wrote:
> Like Pavel, I did some basic testing of the patch (on current HEAD
> 4178d8b91c) trying out various JSON path expressions, and yes, it all
> worked. I had a brief scare while testing on 4178d8b91c where initdb was
> failing on the
On 3/17/19 3:13 AM, Alexander Korotkov wrote:
> On Sat, Mar 16, 2019 at 9:39 PM Pavel Stehule wrote:
>> so 16. 3. 2019 v 10:36 odesílatel Alexander Korotkov
>> napsal:
>>>
>>> On Thu, Mar 14, 2019 at 12:07 PM Alexander Korotkov
>>> wrote:
On Sun, Mar 10, 2019 at 1:51 PM Alexander Korotkov
On Sun, Mar 17, 2019 at 6:03 PM Tom Lane wrote:
> Andrew Dunstan writes:
> > Why are we installing the jsonpath_gram.h file? It's not going to be
> > used by anything else, is it? TBH, I'm not sure I see why we're
> > installing the scanner.h file either.
>
> As near as I can see,
Chapman Flack writes:
> On 03/16/19 17:21, Tom Lane wrote:
>> Hm, so, maybe just
>>
>> (1) always try to parse as document. If successful, we're done.
>>
>> (2) otherwise, if allowed by xmloption, try to parse using our
>> current logic for the CONTENT case.
> What I don't like about that is
Andrew Dunstan writes:
> Why are we installing the jsonpath_gram.h file? It's not going to be
> used by anything else, is it? TBH, I'm not sure I see why we're
> installing the scanner.h file either.
As near as I can see, jsonpath_gram.h and jsonpath_scanner.h exist only
for communication
Many of us have faced character encoding issues because we are not in control
of our input sources and made the common assumption that UTF-8 covers
everything.
In my lab, as an example, some of our social media posts have included ZawGyi
Burmese character sets rather than Unicode Burmese.
Michael Paquier writes:
> On Sun, Mar 17, 2019 at 07:35:16AM +, Andrew Gierth wrote:
>> I took a bash at actually writing it and didn't see any obvious problems
>> (I'll post the patch in a bit). Is there some reason (other than
>> shortage of round tuits) why this might not be a good idea,
On 3/17/19 4:03 AM, Alexander Korotkov wrote:
> On Sat, Mar 16, 2019 at 9:12 PM Tom Lane wrote:
>> I wrote:
>>> Good point. I also see jsonpath_gram.h left behind after maintainer-clean:
>> Oh, and of potentially more significance: after maintainer-clean and
>> re-configure, make fails with
>>
Hi,
On 3/17/19 12:47 PM, Dean Rasheed wrote:
> On Sat, 16 Mar 2019 at 23:44, Tomas Vondra
> wrote:
>>
>>> 28). I just spotted the 1MB limit on the serialised MCV list size. I
>>> think this is going to be too limiting. For example, if the stats
>>> target is at its maximum of 1, that only
On 3/17/19 1:14 PM, Dean Rasheed wrote:
> On Sat, 16 Mar 2019 at 23:44, Tomas Vondra
> wrote:
>>>
>>> 16). This regression test fails for me:
>>>
>>> @@ -654,11 +654,11 @@
>>> -- check change of unrelated column type does not reset the MCV statistics
>>> ALTER TABLE mcv_lists ALTER COLUMN d
Hi;
Attached is my second attempt at the pg_rewind change which allows one to
include only a minimal set. To my understanding, all past feedback has
been addressed.
The current patch does not change default behavior at present. It does add
a --data-only flag which allows pg_rewind to only
Hello
> If we don't have this for SET NOT NULL then we should either add it or
> remove the one from ATTACH PARTITION.
I proposed to lower report level to debug1 in a separate thread:
https://www.postgresql.org/message-id/4859321552643736%40myt5-02b80404fd9e.qloud-c.yandex.net
Possible better
On Sun, Mar 17, 2019 at 12:44:39PM +0100, Fabien COELHO wrote:
> I could remove the two "catalog/" includes from pg_resetwal, I assume that
> you meant these ones.
Not exactly. What I meant is that if you try to call directly
fsync_fname and fsync_parent_path from file_utils.h, then you get into
On Sat, 16 Mar 2019 at 23:44, Tomas Vondra wrote:
> >
> > 16). This regression test fails for me:
> >
> > @@ -654,11 +654,11 @@
> > -- check change of unrelated column type does not reset the MCV statistics
> > ALTER TABLE mcv_lists ALTER COLUMN d TYPE VARCHAR(64);
> > SELECT * FROM
On Sat, 16 Mar 2019 at 23:44, Tomas Vondra wrote:
>
> > 28). I just spotted the 1MB limit on the serialised MCV list size. I
> > think this is going to be too limiting. For example, if the stats
> > target is at its maximum of 1, that only leaves around 100 bytes
> > for each item's values,
Michaël-san,
The issue here is that trying to embed directly the fsync routines
from file_utils.c into pg_resetwal.c messes up the inclusions because
pg_resetwal.c includes backend-side includes, which themselves touch
fd.h :(
In short your approach avoids some extra mess with the include
On Thu, 14 Mar 2019 at 06:24, Robert Haas wrote:
>
> On Wed, Mar 13, 2019 at 1:09 PM Tom Lane wrote:
> > Sergei Kornilov writes:
> > >> Ugh, I guess so. Or how about changing the message itself to use
> > >> INFO, like we already do in QueuePartitionConstraintValidation?
> >
> > > Fine for me.
On Sun, Mar 17, 2019 at 6:47 AM Michael Paquier wrote:
> On Sat, Mar 16, 2019 at 09:18:34AM +0100, Fabien COELHO wrote:
> > I think it would be better to adapt the checksum computation, but this is
> > indeed non trivial because of the way the BLCKSZ constant is hardwired
> into
> > type
On Sun, Mar 17, 2019 at 10:10 AM Michael Paquier
wrote:
> On Sat, Mar 16, 2019 at 11:18:17AM +0100, Magnus Hagander wrote:
> > BLCKSZ is very much an internal term. The exposed name through
> pg_settings
> > is block_size, so I think the original was better. Combining that one
> with
> > yours
On Sat, 16 Mar 2019, Euler Taveira wrote:
I think the former one looks like pretty, but which one is preffered?
I don't have a style preference but decided to change to your
suggestion. New version attached.
Again, the patch compiles and works as expected.
--
José Arthur Benetasso
diately after
> > bms_is_member() in the source, to match the header.
>
> I think I've already done the renames in the last patch I submitted (are
> you looking at an older version of the code, perhaps?). I've moved it
> right after bms_is_member - good idea.
>
Ah OK, I was on the 2019031
On Sat, Mar 16, 2019 at 10:47 PM Mark G wrote:
> While looking over the new jsonpath stuff I noticed the keyword table
> wasn't declared const. Shouldn't the table and the actual keyword
> strings both be declared const? Perhaps something like the attached
> (untested) patch.
Looks good to me.
On Sun, Mar 17, 2019 at 10:01:20AM +0100, Fabien COELHO wrote:
> The implementation basically removes a lot of copy paste and calls the new
> update_controlfile function instead. I like removing useless code:-)
Yes, I spent something like 10 minutes looking at that code yesterday
and I agree that
On Sun, Mar 17, 2019 at 07:35:16AM +, Andrew Gierth wrote:
> I took a bash at actually writing it and didn't see any obvious problems
> (I'll post the patch in a bit). Is there some reason (other than
> shortage of round tuits) why this might not be a good idea, or why it
> hasn't been done
On Sat, Mar 16, 2019 at 11:18:17AM +0100, Magnus Hagander wrote:
> BLCKSZ is very much an internal term. The exposed name through pg_settings
> is block_size, so I think the original was better. Combining that one with
> yours into "initialized with block size %d" etc, makes it a lot nicer.
Yes,
I'm not sure that prefixing the two lines with the comment line is very
elegant, I'd suggest to put spaces, and would still try to shorten the
second sentence, maybe:
I suggest to keep two lines, and only prefix the first one.
As you feel. For me the shorter the better, though, if the
Bonjour Michaël-san,
Yes, that would be nice, for now I have focused. For pg_resetwal yes
we could do it easily. Would you like to send a patch?
Here is a proposal for "pg_resetwal".
The implementation basically removes a lot of copy paste and calls the
new update_controlfile function
On Sun, Mar 17, 2019 at 09:17:02AM +0100, Fabien COELHO wrote:
> I'm not sure that prefixing the two lines with the comment line is very
> elegant, I'd suggest to put spaces, and would still try to shorten the
> second sentence, maybe:
I suggest to keep two lines, and only prefix the first one.
Something like "%s: database folder is incompatible" for the first
line sounds kind of better per the feedback gathered. And then on the
second line:
"The database cluster was initialized with block size %u, but
pg_checksums was compiled with block size %u."
Ok. "%s" progname instead of
On Sat, Mar 16, 2019 at 9:12 PM Tom Lane wrote:
> I wrote:
> > Good point. I also see jsonpath_gram.h left behind after maintainer-clean:
>
> Oh, and of potentially more significance: after maintainer-clean and
> re-configure, make fails with
>
> In file included from jsonpath_gram.y:24:
>
So some PostGIS people were griping (on irc) about how the lack of
CREATE OR REPLACE AGGREGATE made their life difficult for updates. It
struck me that aggregates have acquired a relatively large number of new
attributes in recent years, almost all of which are applicable at
execution time rather
On Sat, Mar 16, 2019 at 9:39 PM Pavel Stehule wrote:
> so 16. 3. 2019 v 10:36 odesílatel Alexander Korotkov
> napsal:
>>
>> On Thu, Mar 14, 2019 at 12:07 PM Alexander Korotkov
>> wrote:
>> > On Sun, Mar 10, 2019 at 1:51 PM Alexander Korotkov
>> > wrote:
>> > > On Wed, Mar 6, 2019 at 12:40 AM
74 matches
Mail list logo
