Re: Progress reporting for pg_verify_checksums

On Thu, Mar 14, 2019 at 11:54:17AM +0900, Kyotaro HORIGUCHI wrote: > Why this patch changes the behavior for temprary directories? It > seems like a bug fix of pg_checksums. Oops, that's a thinko from 5c995139, so fixed. Note this has no actual consequence though as PG_TEMP_FILE_PREFIX and

Re: Timeout parameters

At Thu, 14 Mar 2019 03:33:20 +, "Tsunakawa, Takayuki" wrote in <0A3221C70F24FB45833433255569204D1FBC4191@G01JPEXMBYT05> > 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

Re: Sparse bit set data structure

Hi! > 14 марта 2019 г., в 0:18, Heikki Linnakangas написал(а): > <0001-Add-SparseBitset-to-hold-a-large-set-of-64-bit-ints-.patch><0002-Andrey-Borodin-s-test_blockset-tool-adapted-for-Spar.patch> That is very interesting idea. Basically, B-tree and radix tree is a tradeoff between space and

Re: current_logfiles not following group access and instead follows log_file_mode permissions

On Tue, Mar 12, 2019 at 04:08:53PM -0400, Robert Haas wrote: > Anybody who has permission to read the log files but not the data > directory will presumably hit the directory-level permissions on > $PGDATA before the issue of the permissions on current_logfiles() per > se become relevant, except

Re: pgsql: Add support for hyperbolic functions, as well as log10().

Dean Rasheed writes: > I'm amazed that jacana's asinh() returned -0 for an input of +0. Even more amusingly, it returns NaN for acosh('infinity'), cf https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana=2019-03-14%2003%3A00%3A34 Presumably that means they calculated "infinity -

Re: Offline enabling/disabling of data checksums

On Wed, Mar 13, 2019 at 08:56:33PM +0900, Michael Paquier wrote: > On Wed, Mar 13, 2019 at 12:09:24PM +0100, Michael Banck wrote: > > The attached patch should do the above, on top of Michael's last > > patchset. > > What you are doing here looks like a good defense in itself. More thoughts on

Proposal to suppress errors thrown by to_reg*()

Hi, hackers, According to the document, "to_reg* functions return null rather than throwing an error if the name is not found", but this is not the case if the arguments to those functions are schema qualified and the caller does not have access permission of the schema even if the table (or

Re: BUG #15668: Server crash in transformPartitionRangeBounds

On Wed, Mar 13, 2019 at 03:17:47PM +0900, Amit Langote wrote: > but on HEAD, you get: > > create table foo (a int default (avg(foo.a))); > ERROR: aggregate functions are not allowed in DEFAULT expressions I actually think that what you propose here makes more sense than what HEAD does because

Re: Tid scan improvements

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

Re: Special role for subscriptions

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

Re: Tid scan improvements

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)

RE: Timeout parameters

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

Re: pgsql: Add support for hyperbolic functions, as well as log10().

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

Re: pgsql: Add support for hyperbolic functions, as well as log10().

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

Re: pgsql: Add support for hyperbolic functions, as well as log10().

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

Re: Special role for subscriptions

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

Re: Progress reporting for pg_verify_checksums

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

Re: pgsql: Add support for hyperbolic functions, as well as log10().

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 >>

Re: pgsql: Add support for hyperbolic functions, as well as log10().

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

Re: Timeout parameters

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 >

Re: pgsql: Add support for hyperbolic functions, as well as log10().

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 >>

Re: Fix handling of unlogged tables in FOR ALL TABLES publications

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

Re: pgsql: Add support for hyperbolic functions, as well as log10().

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

RE: Timeout parameters

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

Re: ToDo: show size of partitioned table

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: >> >> -

Re: Using the return value of strlcpy() and strlcat()

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

RE: Timeout parameters

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

Re: Using the return value of strlcpy() and strlcat()

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

Re: hyrax vs. RelationBuildPartitionDesc

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

Re: WIP: Avoid creation of the free space map for small tables

> [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

Re: pgsql: Add support for hyperbolic functions, as well as log10().

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

Re: pgsql: Add support for hyperbolic functions, as well as log10().

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 ... >

Re: Offline enabling/disabling of data checksums

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

Re: pg_rewind : feature to rewind promoted standby is broken!

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

Re: Making all nbtree entries unique by having heap TIDs participate in comparisons

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

Re: Offline enabling/disabling of data checksums

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"), +

Re: Inadequate executor locking of indexes

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 >

Re: REINDEX CONCURRENTLY 2.0

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.

Re: Using condition variables to wait for checkpoints

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,

Re: pgsql: Add support for hyperbolic functions, as well as log10().

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

Re: [HACKERS] Block level parallel vacuum

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

Re: hyrax vs. RelationBuildPartitionDesc

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

Re: hyrax vs. RelationBuildPartitionDesc

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

Re: hyrax vs. RelationBuildPartitionDesc

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

Re: hyrax vs. RelationBuildPartitionDesc

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

Re: hyrax vs. RelationBuildPartitionDesc

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

Re: using index or check in ALTER TABLE SET NOT NULL

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. > >

Re: hyrax vs. RelationBuildPartitionDesc

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

Re: Sparse bit set data structure

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

Re: hyrax vs. RelationBuildPartitionDesc

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

Sparse bit set data structure

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

Re: hyrax vs. RelationBuildPartitionDesc

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

Re: hyrax vs. RelationBuildPartitionDesc

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

Re: hyrax vs. RelationBuildPartitionDesc

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

Re: pg_rewind : feature to rewind promoted standby is broken!

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

Re: Compressed TOAST Slicing

> 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, >

Re: hyrax vs. RelationBuildPartitionDesc

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

Re: hyrax vs. RelationBuildPartitionDesc

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 >

Re: hyrax vs. RelationBuildPartitionDesc

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

Re: hyrax vs. RelationBuildPartitionDesc

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) >

Re: hyrax vs. RelationBuildPartitionDesc

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 it's more fragile than either of the options I

Re: Timeout parameters

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

Re: hyrax vs. RelationBuildPartitionDesc

On 2019-Mar-13, Robert Haas wrote: > On Wed, Mar 13, 2019 at 12:42 PM Alvaro Herrera > wrote: > > I remember going over this code's memory allocation strategy a bit to > > avoid the copy while not incurring potential leaks CacheMemoryContext; > > as I recall, my idea was to use two contexts, one

RE: Timeout parameters

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

Re: hyrax vs. RelationBuildPartitionDesc

I wrote: > I recall having noticed someplace where I thought the relcache partition > support was simply failing to make provisions for cleaning up a cached > structure at relcache entry drop, but I didn't have time to pursue it > right then. Let me see if I can reconstruct what I was worried

Re: hyrax vs. RelationBuildPartitionDesc

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

Re: using index or check in ALTER TABLE SET NOT NULL

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

Re: Timeout parameters

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

Re: using index or check in ALTER TABLE SET NOT NULL

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 > >

Re: using index or check in ALTER TABLE SET NOT NULL

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:

Re: hyrax vs. RelationBuildPartitionDesc

Robert Haas writes: > On Wed, Mar 13, 2019 at 12:42 PM Alvaro Herrera > wrote: >> I remember going over this code's memory allocation strategy a bit to >> avoid the copy while not incurring potential leaks CacheMemoryContext; >> as I recall, my idea was to use two contexts, one of which is

Re: Timeout parameters

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

Re: ToDo: show size of partitioned table

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

Re: using index or check in ALTER TABLE SET NOT NULL

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: >

Re: Offline enabling/disabling of data checksums

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 >

Re: Offline enabling/disabling of data checksums

On Wed, Mar 13, 2019 at 4:46 PM Michael Banck wrote: > Hi, > > Am Mittwoch, den 13.03.2019, 12:24 +0100 schrieb Magnus Hagander: > > On Wed, Mar 13, 2019 at 11:54 AM Sergei Kornilov wrote: > > > One new question from me: how about replication? > > > Case: primary+replica, we shut down primary

Re: Using the return value of strlcpy() and strlcat()

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 + buflen, name, NAMEDATALEN); > ] I don't think that's a

Re: hyrax vs. RelationBuildPartitionDesc

On Wed, Mar 13, 2019 at 12:42 PM Alvaro Herrera wrote: > I remember going over this code's memory allocation strategy a bit to > avoid the copy while not incurring potential leaks CacheMemoryContext; > as I recall, my idea was to use two contexts, one of which is temporary > and used for any

Re: using index or check in ALTER TABLE SET NOT NULL

Hi > 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:

Re: hyrax vs. RelationBuildPartitionDesc

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

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On Wed, Mar 13, 2019 at 12:20 AM Kyotaro HORIGUCHI wrote: > +Multivariate MCV (most-common values) lists are a straightforward extension > of > > "lists are *a*" is wrong? No, that's correct. Not sure exactly what your concern is, but it's probably related to the fact that the first parent

Re: GIN indexes on an = ANY(array) clause

Corey Huinker writes: > A client had an issue with a where that had a where clause something like > this: > WHERE 123456 = ANY(integer_array_column) > I was surprised that this didn't use the pre-existing GIN index on > integer_array_column, whereas recoding as > WHERE ARRAY[123456] <@

Re: Compressed TOAST Slicing

> 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, { *dp = dp[-off];

Re: using index or check in ALTER TABLE SET NOT NULL

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

hyrax vs. RelationBuildPartitionDesc

Hi, Amit Kapila pointed out to be that there are some buidfarm failures on hyrax which seem to have started happening around the time I committed 898e5e3290a72d288923260143930fb32036c00c. It failed like this once: 2019-03-07 19:57:40.231 EST [28073:11] DETAIL: Failed process was running: /*

Re: Compressed TOAST Slicing

On Mar 13, 2019, at 8:25 AM, Paul Ramsey wrote:On Mar 13, 2019, at 3:09 AM, Tomas Vondra wrote:On 3/13/19 3:19 AM, Michael Paquier wrote:On Tue, Mar 12, 2019 at 07:01:17PM -0700, Andres Freund wrote:I don't think this is even close to

Re: Checksum errors in pg_stat_database

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

Using the return value of strlcpy() and strlcat()

Hi hackers, Over in the "Include all columns in default names for foreign key constraints" thread[1], I noticed the patch added the following: + strlcpy(buf + buflen, name, NAMEDATALEN); + buflen += strlen(buf + buflen); Seeing as strlcpy() returns the copied length,

Re: Checksum errors in pg_stat_database

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

Re: Offline enabling/disabling of data checksums

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 there are several cloud-native 3rd party solutions that use the cluster

Re: Offline enabling/disabling of data checksums

Hi, Am Mittwoch, den 13.03.2019, 12:24 +0100 schrieb Magnus Hagander: > On Wed, Mar 13, 2019 at 11:54 AM Sergei Kornilov wrote: > > One new question from me: how about replication? > > Case: primary+replica, we shut down primary and enable checksum, and > > "started streaming WAL from primary"

Re: WIP: Avoid creation of the free space map for small tables

On Wed, Mar 13, 2019 at 7:42 PM John Naylor wrote: > > On Wed, Mar 13, 2019 at 8:18 PM Amit Kapila wrote: > > > First, I had a problem: On MacOS with their "gcc" wrapper around > > > clang, I got a segfault 11 when compiled with no debugging symbols. > > > > > > > Did you get this problem with

Re: Compressed TOAST Slicing

> On Mar 13, 2019, at 3:09 AM, Tomas Vondra > wrote: > > On 3/13/19 3:19 AM, Michael Paquier wrote: >> On Tue, Mar 12, 2019 at 07:01:17PM -0700, Andres Freund wrote: >>> I don't think this is even close to popular enough to incur the >>> maybe of a separate function / more complicated

Re: using index or check in ALTER TABLE SET NOT NULL

Hi > 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 pg_class alter column relname drop not null; and similar for

Re: Minimal logical decoding on standbys

Hi , I am getting a server crash on standby while executing pg_logical_slot_get_changes function   , please refer this scenario Master cluster( ./initdb -D master) set wal_level='hot_standby in master/postgresql.conf file start the server , connect to  psql terminal and create a physical

Re: using index or check in ALTER TABLE SET NOT NULL

Robert Haas writes: > On Tue, Mar 12, 2019 at 4:27 PM Sergei Kornilov wrote: >> Agreed, in attached new version ... > Committed with a little more nitpicking. The buildfarm thinks additional nitpicking is needed. regards, tom lane

Re: Special role for subscriptions

Hi! Thanks for comments! > Just letting the superuser decide who gets to create subscriptions > seems good enough from here. I've prepare patch with new system role, i'm not sure about name, called it "pg_subscription_users". In that patch we don't check permissions on target tables, i don't

Re: [Patch] Log10 and hyperbolic functions for SQL:2016 compliance

Thanks, Tom ! Thank you everyone for your help and patience. Cheers, Lætitia Le mar. 12 mars 2019 à 20:57, Tom Lane a écrit : > =?UTF-8?Q?L=C3=A6titia_Avrot?= writes: > > So, as you're asking that too, maybe my reasons weren't good enough. > You'll > > find enclosed a new version of the

Show a human-readable n_distinct in pg_stats view

Hi, It seems to me that since the pg_stats view is supposed to be human-readable, it would make sense to show a human-readable version of n_distinct. Currently, when the stats collector estimates that the number of distinct values is more than 10% of the total row count, what is stored in

Re: REINDEX CONCURRENTLY 2.0

Hello 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. regards, Sergei

  1   2   >