On 2019-Mar-13, Robert Haas wrote:
> RelationBuildPartitionDesc() creates basically all of the data
> structures it needs and then copies them into rel->rd_pdcxt, which has
> always seemed a bit inefficient to me. Another way to redesign this
> would be to have the function create a temporary
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. But year ago this was implemented in my patch and Tom voted
> >
On Wed, Mar 13, 2019 at 1:15 PM Tom Lane wrote:
> I'm a bit confused as to why there's an issue here at all. The usual
> plan for computed-on-demand relcache sub-structures is that we compute
> a working copy that we're going to return to the caller using the
> caller's context (which is
On Sun, Mar 10, 2019 at 1:13 PM Julien Rouhaud wrote:
>
> On Sat, Mar 9, 2019 at 7:58 PM Julien Rouhaud wrote:
> >
> > On Sat, Mar 9, 2019 at 7:50 PM Magnus Hagander wrote:
> > >
> > > On Sat, Mar 9, 2019 at 10:41 AM Julien Rouhaud wrote:
> > >>
> > >> Sorry, I have again new comments after a
On Wed, Mar 13, 2019 at 4:53 PM Julien Rouhaud wrote:
>
> On Sun, Mar 10, 2019 at 1:13 PM Julien Rouhaud wrote:
> >
> > On Sat, Mar 9, 2019 at 7:58 PM Julien Rouhaud wrote:
> > >
> > > On Sat, Mar 9, 2019 at 7:50 PM Magnus Hagander
> > > wrote:
> > > >
> > > > On Sat, Mar 9, 2019 at 10:41 AM
On Wed, Mar 13, 2019 at 2:05 AM Fabien COELHO wrote:
> Also, I do not see the downside of sending a cancel query before severing
> the connection. If it is not processed, too bad, but if it is then it is
> for the better.
If the network connection is dead, which is the situation the patch
I 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. But year ago this was implemented in my patch and Tom voted
>> against using INFO level for such purpose:
On Wed, Mar 13, 2019 at 1:25 PM Fabien COELHO wrote:
> Hmmm... ISTM that we are not talking about the same patch...
You are correct! I was talking about the patches that allow user
control of TCP_USER_TIMEOUT, which is apparently totally different
from the socket_timeout patch that you're
On Wed, Mar 13, 2019 at 1:30 PM Tom Lane wrote:
> Ah, here we are: it was rel->rd_partcheck. I'm not sure exactly how
> complicated that structure can be, but I'm pretty sure that this is
> a laughably inadequate method of cleaning it up:
>
> if (relation->rd_partcheck)
>
On Wed, Mar 13, 2019 at 11:17 AM Sergei Kornilov wrote:
> > The buildfarm thinks additional nitpicking is needed.
>
> hm. Patch was committed with debug1 level tests and many animals uses
> log_statement = 'all'. Therefore they have additional line in result: LOG:
> statement: alter table
On Wed, Mar 13, 2019 at 4:51 PM Michael Banck
wrote:
> Hi,
>
> Am Mittwoch, den 13.03.2019, 12:43 +0100 schrieb Magnus Hagander:
> > I think this is dangerous enough that it needs to be enforced and not
> > documented.
>
> Changing the cluster ID might have some other side-effects, I think
>
st 13. 3. 2019 v 8:02 odesílatel Amit Langote
napsal:
> On 2019/02/22 1:41, Pavel Stehule wrote:
> > čt 21. 2. 2019 v 0:56 odesílatel Justin Pryzby
> > napsal:
> >
> >> On Sat, Feb 16, 2019 at 10:52:35PM +0100, Pavel Stehule wrote:
> >>> I like your changes. I merged all - updated patch is
On Wed, Mar 13, 2019 at 1:19 PM Tom Lane wrote:
> Oh, and yes, I think QueuePartitionConstraintValidation's usage
> is an unacceptable abuse of INFO level. I'm surprised we haven't
> gotten complaints about it yet.
Perhaps that's because users aren't as direly opposed to informational
messages
Hello Robert,
Also, I do not see the downside of sending a cancel query before severing
the connection. If it is not processed, too bad, but if it is then it is
for the better.
If the network connection is dead, which is the situation the patch
intends to detect,
Hmmm... ISTM that we are
Hello Fabien-san.
The 2nd patch is 700 KB, I think that there is a unvoluntary file copy.
If the user reconnects, eg "\c db", the setting is lost. The
re-connection handling should probably take care of this parameter, and maybe
others.
I think your opinion is reasonable, but it seems
On Wed, Mar 13, 2019 at 2:21 PM Alvaro Herrera wrote:
> On 2019-Mar-13, Robert Haas wrote:
> > On Wed, Mar 13, 2019 at 1:38 PM Alvaro Herrera
> > wrote:
> > > A bit, yes, but not overly so, and it's less fragile that not having
> > > such a protection. Anything that allocates in
On Wed, Mar 13, 2019 at 2:26 PM Tom Lane wrote:
> OK, in that case it's definitely all the temporary data that gets created
> that is the problem. I've not examined your patch in great detail but
> it looks plausible for fixing that.
Cool.
> I think that RelationBuildPartitionDesc could use
Alvaro Herrera writes:
> You do? Unless I misunderstood, your options are:
> 1. (the patch you attached) create a temporary memory context that is
> used for everything, then at the end copy the good stuff to CacheMemCxt
> (or a sub-context thereof). This still needs to copy.
> 2. create a
> On Mar 13, 2019, at 9:32 AM, Andrey Borodin wrote:
>
>
>
>> 13 марта 2019 г., в 21:05, Paul Ramsey
>> написал(а):
>>
>> Here is a new (final?) patch ...
>>
>>
>
> This check
>
> @@ -744,6 +748,8 @@ pglz_decompress(const char *source, int32 slen, char
> *dest,
>
Robert Haas writes:
> On Wed, Mar 13, 2019 at 2:26 PM Tom Lane wrote:
>> I think that RelationBuildPartitionDesc could use some additional cleanup
>> or at least better commenting. In particular, it's neither documented nor
>> obvious to the naked eye why rel->rd_partdesc mustn't get set till
Hi,
I was reviewing Andrey Borodin's patch for GiST VACUUM [1], which
includes a new "block set" data structure, to track internal and empty
pages while vacuuming a GiST. The blockset data structure was a pretty
simple radix tree, that can hold a set of BlockNumbers.
The memory usage of the
On Wed, Mar 13, 2019 at 3:18 PM Heikki Linnakangas wrote:
> I started to consider rewriting the data structure into something more
> like B-tree. Then I remembered that I wrote a data structure pretty much
> like that last year already! We discussed that on the "Vacuum: allow
> usage of more than
On Wed, Mar 13, 2019 at 3:14 PM Tom Lane wrote:
> Yeah, but usually there's some comment pointing it out. I also wonder
> if there aren't corner-case bugs; it seems a bit bogus for example that
> rd_pdcxt is created without any thought as to whether it might be set
> already. It's not clear
Robert Haas writes:
> On Wed, Mar 13, 2019 at 3:14 PM Tom Lane wrote:
>> Meanwhile, who's going to take point on cleaning up rd_partcheck?
>> I don't really understand this code well enough to know whether that
>> can share one of the existing partitioning-related sub-contexts.
> To your
On Wed, Mar 13, 2019 at 4:18 PM Tom Lane wrote:
> Off topic for the moment, since this clearly wouldn't be back-patch
> material, but I'm starting to wonder if we should just have a context
> for each relcache entry and get rid of most or all of the retail
> cleanup logic in
On 2019-Mar-13, Robert Haas wrote:
> On Wed, Mar 13, 2019 at 1:38 PM Alvaro Herrera
> wrote:
> > A bit, yes, but not overly so, and it's less fragile that not having
> > such a protection. Anything that allocates in CacheMemoryContext needs
> > to be very careful anyway.
>
> True, but I think
Robert Haas writes:
>> Dunno if that's related to hyrax's issue, though.
> It's related in the sense that it's a leak, and any leak will tend to
> run the system out of memory more easily, but what I observed was a
> large leak into MessageContext, and that would be a leak into
>
On Wed, Mar 13, 2019 at 1:38 PM Michael Paquier wrote:
> On Tue, Mar 12, 2019 at 06:23:01PM +0900, Michael Paquier wrote:
> > And you are pointing out to the correct commit. The issue is that
> > process_target_file() has added a call to check_file_excluded(), and
> > this skips all the folders
Hi,
On Wed, Mar 13, 2019 at 01:25:11PM -0400, Robert Haas wrote:
> On Wed, Mar 13, 2019 at 1:19 PM Tom Lane wrote:
> > Oh, and yes, I think QueuePartitionConstraintValidation's usage
> > is an unacceptable abuse of INFO level. I'm surprised we haven't
> > gotten complaints about it yet.
>
>
On 2019/03/14 2:11, Pavel Stehule wrote:
> st 13. 3. 2019 v 8:02 odesílatel Amit Langote
> napsal:
>> Not a native speaker either, but I like Justin's changes. Although I
>> noticed that he missed changing one sentence to look like other similar
>> sentences.
>>
>> What Justin did:
>>
>> -
From: Robert Haas [mailto:robertmh...@gmail.com]
> The first thing I notice about the socket_timeout patch is that the
> documentation is definitely wrong:
Agreed. I suppose the description should be clearer about:
* the purpose and what situation this timeout will help: not for canceling a
On Wed, Mar 13, 2019 at 8:49 PM Tom Lane wrote:
> Meh. As I said before, we're not in the business of improving on what
> libm does --- if someone has a beef with the results, they need to take
> it to their platform's libm maintainer, not us. The point of testing
> this at all is just to
On 2019/03/13 21:03, Peter Eisentraut wrote:
> If a FOR ALL TABLES publication exists, unlogged tables are ignored
> for publishing changes. But CheckCmdReplicaIdentity() would still
> check in that case that such a table has a replica identity set before
> accepting updates. That is useless, so
Robert Haas writes:
> On Wed, Mar 13, 2019 at 8:49 PM Tom Lane wrote:
>> Meh. As I said before, we're not in the business of improving on what
>> libm does --- if someone has a beef with the results, they need to take
>> it to their platform's libm maintainer, not us. The point of testing
>>
On Wed, Mar 13, 2019 at 10:20 PM Tsunakawa, Takayuki
wrote:
> I think the purpose of socket_timeout is to avoid infinite or unduely long
> wait and return response to users, where other existing timeout parameters
> wouldn't help. For example, OS's process scheduling or paging/swapping
>
On Wed, Mar 13, 2019 at 10:39 PM Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Mar 13, 2019 at 8:49 PM Tom Lane wrote:
> >> Meh. As I said before, we're not in the business of improving on what
> >> libm does --- if someone has a beef with the results, they need to take
> >> it to their
Robert Haas writes:
> On Wed, Mar 13, 2019 at 10:39 PM Tom Lane wrote:
>> No, but that's not the hazard. I have a very fresh-in-mind example:
>> at one point while tweaking Laetitia's patch, I'd accidentally changed
>> datanh so that it called tanh not atanh. The previous set of tests did
>>
Hello.
At Wed, 13 Mar 2019 16:25:15 +0900, Michael Paquier wrote
in <20190313072515.gb2...@paquier.xyz>
> On Wed, Mar 13, 2019 at 07:22:28AM +0100, Fabien COELHO wrote:
> > Does not apply because of the renaming committed by Michaël.
> >
> > Could you rebase?
>
> This stuff touches
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Mar 11, 2019 at 10:39 PM Michael Paquier wrote:
> > On Mon, Mar 11, 2019 at 06:32:10PM -0700, Jeff Davis wrote:
> > > * Is the original idea of a special role still viable?
> >
> > In my opinion, that part may be valuable. The
On 3/13/19 5:56 PM, Tom Lane wrote:
> Michael Paquier writes:
>> On Tue, Mar 12, 2019 at 11:16:42PM -0400, Tom Lane wrote:
>>> I'm inclined to leave it as-is for a day or so and see if any
>>> other failures turn up, before deciding what to do about it.
>> Fine by me.
> Well, so far jacana is
Andrew Dunstan writes:
> Or we could possibly call the function and then turn a result of -0 into 0?
But -0 is the correct output if the input is -0. So that approach
requires distinguishing -0 from 0, which is annoyingly difficult.
regards, tom lane
At Wed, 13 Mar 2019 23:18:27 -0400, Tom Lane wrote in
<2503.1552533...@sss.pgh.pa.us>
tgl> Andrew Dunstan writes:
tgl> > Or we could possibly call the function and then turn a result of -0 into
0?
tgl>
tgl> But -0 is the correct output if the input is -0. So that approach
tgl> requires
From: Robert Haas [mailto:robertmh...@gmail.com]
> But that's not what it will do. As long as the server continues to
> dribble out protocol messages from time to time, the timeout will
> never fire no matter how much time passes. I saw a system once where
> every 8kB read took many seconds to
At Wed, 13 Mar 2019 23:03:26 -0400, Stephen Frost wrote in
<20190314030326.gq6...@tamriel.snowman.net>
> Greetings,
>
> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Mon, Mar 11, 2019 at 10:39 PM Michael Paquier
> > wrote:
> > > On Mon, Mar 11, 2019 at 06:32:10PM -0700, Jeff Davis
On Mon, 4 Feb 2019 at 18:37, Edmund Horner wrote:
> 1. v6-0001-Add-selectivity-estimate-for-CTID-system-variables.patch
I think 0001 is good to go. It's a clear improvement over what we do today.
(t1 = 1 million row table with a single int column.)
Patched:
# explain (analyze, timing off)
On Mon, 4 Feb 2019 at 18:37, Edmund Horner wrote:
> 2. v6-0002-Support-backward-scans-over-restricted-ranges-in-hea.patch
> 3. v6-0003-Support-range-quals-in-Tid-Scan.patch
> 4. v6-0004-TID-selectivity-reduce-the-density-of-the-last-page-.patch
These ones need a rebase.
--
David Rowley
On Wed, Mar 13, 2019 at 4:38 PM Robert Haas wrote:
> On Wed, Mar 13, 2019 at 4:18 PM Tom Lane wrote:
> > Off topic for the moment, since this clearly wouldn't be back-patch
> > material, but I'm starting to wonder if we should just have a context
> > for each relcache entry and get rid of most
Thanks for having a look at this.
On Wed, 13 Mar 2019 at 22:45, Amit Langote
wrote:
> I have one question about the relation between idxlockmode and
> rellockmode? From skimming the patch, it appears that they're almost
> always set to the same value. If so, why not use rellockmode for index
>
On Wed, Mar 13, 2019 at 02:43:39PM +0300, Sergei Kornilov wrote:
> Seems good. And I think we need backpath this check to pg11. similar
> to cross-version compatibility checks
+fprintf(stderr, _("%s: data directory block size %d is different to
compiled-in block size %d.\n"),
+
Hi,
On 2019-03-13 16:50:53 -0400, Robert Haas wrote:
> On Wed, Mar 13, 2019 at 4:38 PM Robert Haas wrote:
> > On Wed, Mar 13, 2019 at 4:18 PM Tom Lane wrote:
> > > Off topic for the moment, since this clearly wouldn't be back-patch
> > > material, but I'm starting to wonder if we should just
On Wed, Mar 13, 2019 at 1:56 AM Masahiko Sawada wrote:
> I don't have a strong opinion but the using a Node would be more
> suitable in the future when we add more options to vacuum. And it
> seems to me that it's unlikely to change a Node to a plain struct. So
> there is an idea of doing it now
Michael Paquier writes:
> On Tue, Mar 12, 2019 at 11:16:42PM -0400, Tom Lane wrote:
>> I'm inclined to leave it as-is for a day or so and see if any
>> other failures turn up, before deciding what to do about it.
> Fine by me.
Well, so far jacana is the only critter that's shown any problem.
I
On 2019-03-13 15:13, Sergei Kornilov wrote:
> Patch is marked as target version 12, but is inactive few weeks long. I think
> many users want this feature and patch is in good shape. We have open
> questions on this thread?
>
> Latest patch still can be aplied cleanly; it builds and pass tests.
On 2019/03/14 5:18, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Mar 13, 2019 at 3:14 PM Tom Lane wrote:
>>> Meanwhile, who's going to take point on cleaning up rd_partcheck?
>>> I don't really understand this code well enough to know whether that
>>> can share one of the existing
> [segfault problems]
This now seems spurious. I ran make distclean, git pull, reapplied the
patch (leaving out the gettimeofday() calls), and now my upgrade perf
test works with default compiler settings. Not sure what happened, but
hopefully we can move forward.
--
John Naylor
On Wed, Mar 13, 2019 at 9:51 AM Tom Lane wrote:
> ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> > [ let's convert
> > + strlcpy(buf + buflen, name, NAMEDATALEN);
> > + buflen += strlen(buf + buflen);
> > to
> > + buflen += strlcpy(buf
From: Fabien COELHO [mailto:coe...@cri.ensmp.fr]
> >> If the user reconnects, eg "\c db", the setting is lost. The
> >> re-connection handling should probably take care of this parameter, and
> maybe others.
> > I think your opinion is reasonable, but it seems not in this thread.
>
> HI think
Ashwin Agrawal writes:
> On Wed, Mar 13, 2019 at 9:51 AM Tom Lane wrote:
>> I don't think that's a safe transformation: what strlcpy returns is
>> strlen(src), which might be different from what it was actually
>> able to fit into the destination.
>> Sure, they're equivalent if no truncation
Andres Freund writes:
> On 2019-03-13 16:50:53 -0400, Robert Haas wrote:
>> On Wed, Mar 13, 2019 at 4:38 PM Robert Haas wrote:
>>> On Wed, Mar 13, 2019 at 4:18 PM Tom Lane wrote:
Off topic for the moment, since this clearly wouldn't be back-patch
material, but I'm starting to wonder
Hi,
On 2019-03-13 17:10:55 -0400, Tom Lane wrote:
> There's already a mechanism in there to suppress child contexts after
> 100 or so, which would almost inevitably kick in on the relcache if we
> did this. So I don't believe we'd have a problem with the context dumps
> getting too long --- more
On Thu, Mar 14, 2019 at 1:15 AM Robert Haas wrote:
> On Tue, Mar 12, 2019 at 7:12 PM Andres Freund wrote:
> > Having useful infrastructure is sure cool.
>
> Yay!
+1
I renamed the CVs because the names I had used before broke the
convention that variables named ckpt_* are protected by ckpt_lck,
On Thu, Mar 14, 2019 at 12:15:57AM +0530, Mithun Cy wrote:
> I have not looked into the patch but quick test show it has fixed the above
> issue.
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
On Wed, 13 Mar 2019, 21:56 Tom Lane, wrote:
>
> Of these, probably the least bad is #3, even though it might require
> a few rounds of experimentation to find the best extra_float_digits
> setting to use. I'll go try it without any roundoff, just to see
> what the raw results look like ...
>
On Tue, Mar 12, 2019 at 11:40 AM Robert Haas wrote:
> I think it's pretty clear that we have to view that as acceptable. I
> mean, we could reduce contention even further by finding a way to make
> indexes 40% larger, but I think it's clear that nobody wants that.
I found this analysis of bloat
On Wed, Mar 13, 2019 at 12:24:21PM +0100, Magnus Hagander wrote:
> Enabling or disabling the checksums offline on the master quite clearly
> requires a rebuild of the standby, there is no other way (this is one of
> the reasons for the online enabling in that patch, so I still hope we can
> get
Dean Rasheed writes:
> It's not unreasonable to expect these functions to be accurate to within
> the last 1 or 2 digits, so testing with extra_float_digits or whatever
> seems reasonable, but I think a wider variety of test inputs is required.
Meh. As I said before, we're not in the business
101 - 166 of 166 matches
Mail list logo
