Re: Copy function for logical replication slots

On Sat, Feb 16, 2019 at 12:34 PM Andres Freund wrote: > > Hi, > Thank you for your comment. > On 2019-01-15 10:56:04 +0900, Masahiko Sawada wrote: > > > + pg_copy_physical_replication_slot > > + > > + > > pg_copy_physical_replication_slot(src_slot_name > > name, dst_slot

Re: Problems with plan estimates in postgres_fdw

(2019/02/15 21:46), Antonin Houska wrote: ok, I understand now. I assume that the patch https://www.postgresql.org/message-id/5C66A056.60007%40lab.ntt.co.jp obsoletes the code snippet we discussed above. Sorry, I don't understand this. Could you elaborate on that? Best regards, Etsuro Fujit

SimpleLruTruncate() mutual exclusion

I'm forking this thread from https://postgr.es/m/flat/20190202083822.gc32...@gust.leadboat.com, which reported a race condition involving the "apparent wraparound" safety check in SimpleLruTruncate(): On Wed, Feb 13, 2019 at 11:26:23PM -0800, Noah Misch wrote: > 1. The result of the test is valid

Re: Problems with plan estimates in postgres_fdw

(2019/02/15 21:19), Etsuro Fujita wrote: So, here is an updated patch. If there are no objections from you or anyone else, I'll commit the patch as a preliminary one for what's proposed in this thread. Pushed, after fiddling with the commit message a bit. Best regards, Etsuro Fujita

RE: [PROPOSAL]a new data type 'bytea' for ECPG

Meskes-san I attach a new patch. - ECPGset_desc and ecpg_build_params are changed. - implement Idea-2. - get if(is_binary)-block out from main flow to new functions (set_desc_attr, store_input_from_desc). Regards Ryo Matsumura ecpg_bytea_v1_4.patch Description: ecpg_bytea_v1_4.patch

Re: Control your disk usage in PG: Introduction to Disk Quota Extension

Hi Andres On Sat, Feb 16, 2019 at 12:53 PM Andres Freund wrote: > Hi, > On 2019-01-30 10:26:52 +0800, Hubert Zhang wrote: > > Hi Michael, Robert > > For you question about the hook position, I want to explain more about > the > > background why we want to introduce these hooks. > > We wrote a di

PGAdmin 4 don't refresh server info after restarting

Hello, We've noticed that pgadmin 3.x / 4.x doesn't refresh server info like server version after restarting. It makes people confused. For example, 1. PgAdmin was rinning 2. We upgraded postgres from 11.1 to 11.2 3. PgAdmin was restarted 4. We continued to see 11.1 5. We must push "Disconnect fro

Re: ON SELECT rule on a table without columns

On Sun, Feb 17, 2019 at 11:10 PM Tom Lane wrote: > > Ashutosh Sharma writes: > > [ allow-create-view-on-table-without-columns-v3.patch ] > > Pushed. I revised the test cases a bit --- notably, I wanted to be > sure we exercised pg_dump's createDummyViewAsClause for this, especially > after notic

RE: Prevent extension creation in temporary schemas

Dear Michael, I seem this patch is enough, but could you explain the reason you drop initial proposal more detail? I'm not sure why extensions contained by temporary schemas are acceptable. > Anything depending on a temporary object will be dropped per > dependency links once the session is over

Re: 2019-03 CF Summary / Review - Tranche #2

On Mon, 18 Feb 2019 at 15:50, Amit Langote wrote: > On 2019/02/18 11:13, Tsunakawa, Takayuki wrote: > > From: Andres Freund [mailto:and...@anarazel.de] > >> - Speed up planning with partitions > >> > >> NR: Important feature, but based on a skim of the discussion this > >> doesn't seem ready f

Re: [Patch] checksumming-related buglets in pg_verify_checksums/pg_basebackup TAP tests

On Thu, Feb 14, 2019 at 03:07:56PM +0100, Michael Banck wrote: > This also revealed a second bug in the pg_basebackup test suite where > the offset for the corruption in the second file was wrong, so it > actually never got corrupted, and the tests only passed due to the above > twice than expected

Re: Remove Deprecated Exclusive Backup Mode

On 2/16/19 5:57 AM, Andres Freund wrote: On 2019-01-05 13:19:20 -0500, Stephen Frost wrote: Greetings, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: On 12/12/2018 05:31, Robert Haas wrote: Most of the features I've been involved in removing have been deprecated for 5+ years. T

RE: Protect syscache from bloating with negative cache entries

From: Tomas Vondra [mailto:tomas.von...@2ndquadrant.com] > I think "catalog_cache_..." is fine. If we end up with a similar > patchfor relcache, we can probably call it "relation_cache_". Agreed, those are not too long or too short, and they are sufficiently descriptive. Regards Takayuki Tsunak

RE: [Bug Fix] ECPG: could not use some CREATE TABLE AS syntax

Hi, Meskes-san, Thanks for your response! > I beg to disagree, or I don't understand. Why would ecpg's changes to > the statement be wrong nowadays? I might confuse you, but it does not mean that it is wrong to reject CREATE TABLE AS ... INTO ... syntax in ECPG. My goal is to accept syntax

Re: make installcheck-world in a clean environment

On Thu, Feb 14, 2019 at 11:40:29AM -0800, Andres Freund wrote: > I'm confused. I don't see the patch as ready, given the discussion, nor > does > https://commitfest.postgresql.org/22/1672/ > contain a record of it ever being set to RFC? Did you intend to reply to > a different thread? Indeed, the

Re: pg_basebackup ignores the existing data directory permissions

On Fri, Feb 15, 2019 at 09:24:15AM +0900, Kyotaro HORIGUCHI wrote: > I disagree that pg_basebackup rejects directories other than > specific permissions, since it is just a binary backup tool, > which is not exclusive to making replication-standby. It ought to > be runnable and actually runnable by

Re: Incorrect visibility test function assigned to snapshot

On Fri, Feb 15, 2019 at 01:01:29PM +0100, Antonin Houska wrote: > As for the bug fix, I think the additional assignment does not make things > worse because SnapBuildInitialSnapshot() already does overwrite some fields: > "xip" and "xnt". Ah, right. I somewhat missed that. Let's move on with mer

Re: restrict pg_stat_ssl to superuser?

On Fri, Feb 15, 2019 at 02:04:59PM +0100, Peter Eisentraut wrote: > We could remove default privileges from pg_stat_get_activity(). Would > that be a problem? I don't think so, still I am wondering about the impact that this could have for monitoring tools calling it directly as we document it..

Re: [PATCH] pg_hba.conf : new auth option : clientcert=verify-full

On Fri, Feb 15, 2019 at 08:03:24PM -0800, Andres Freund wrote: > I see you've marked the patch as needs review - but as the patch > previously was marked as ready-for-committer, and I assume nothing > substantial has changed, I think RFC might still be the accurate state? Yes, RFC sounds good to m

Re: automatically assigning catalog toast oids

On Sat, Feb 16, 2019 at 04:50:51PM +0100, John Naylor wrote: > I just noticed a small typo in transam.h. Patch attached. Thanks, fixed. -- Michael signature.asc Description: PGP signature

Re: 2019-03 CF Summary / Review - Tranche #2

(2019/02/16 14:45), Andres Freund wrote: - postgres_fdw: Perform UPPERREL_ORDERED and UPPERREL_FINAL steps remotely WOA: This is a nontrivial change, and the design and review only started in late December. It's probably not realistic to target v12. Andres: punt to v13 I also thin

Re: BUG #15548: Unaccent does not remove combining diacritical characters

On Sun, Feb 17, 2019 at 12:45:39PM +0530, Ramanarayana wrote: > The patch I submitted was tested both in python 2 and 3 and it worked for > me.The single line of code > added in the patch runs only in python 3. I dont think it can break > python2. Would like to see the error you got in python 2 G

Re: Progress reporting for pg_verify_checksums

On Sun, Feb 17, 2019 at 09:00:29PM +0100, Michael Banck wrote: > Well, pg_rewind is also using kB, so should I switch it back to that? I am not sure which one is better, sorry :) There is an argument for switching pg_rewind to use MB as well. I don't expect pg_rewind to transfer gigs of data, bu

Re: allow online change primary_conninfo

On Mon, Feb 18, 2019 at 12:06:05AM +0300, Sergei Kornilov wrote: > Ok. This was not mentioned before Michael response > yesterday. restore_command is much faster compared to database > restart [...] The startup process would not switch back to streaming with archiving enabled until it has consumed

Re: 2019-03 CF Summary / Review - Tranche #2

Hi, On 2019/02/18 11:13, Tsunakawa, Takayuki wrote: > From: Andres Freund [mailto:and...@anarazel.de] >> - Speed up planning with partitions >> >> NR: Important feature, but based on a skim of the discussion this >> doesn't seem ready for v12. >> >> Andres: punt to v13 > >> - Speed up trans

Re: Actual Cost

On Feb 17, 2019, at 11:05 AM, Donald Dong wrote: > > On Feb 17, 2019, at 10:56 AM, Tom Lane wrote: >> Perhaps, but refactoring to get that seems impractically invasive & >> expensive, since e.g. index AM cost estimate functions would have to >> be redefined, plus we'd have to carry around some k

RE: libpq debug log

On February 14, 2019 6:16 PM +, Andres Freund wrote: > Hi, > On 2018-11-28 23:20:03 +0100, Peter Eisentraut wrote: > > This does not excite me. It seems mostly redundant with using tcpdump. > I think the one counter-argument to this is that using tcpdump in real-world > scenarios has become

RE: 2019-03 CF Summary / Review - Tranche #2

From: Andres Freund [mailto:and...@anarazel.de] > - Protect syscache from bloating with negative cache entries > > WOA: I think unless the feature is drastically scaled down in scope, > there's no chance to get anything into v12. > > Andres: punt to v13, unless a smaller chunk can be split

Re: Reaping Temp tables to avoid XID wraparound

On Sun, Feb 17, 2019 at 05:47:09PM +0100, Magnus Hagander wrote: > We could I guess add a field specifically for temp_namespace_xid or such. > The question is if it's worth the overhead to do that. That would mean an extra 4 bytes in PGPROC, which is something we could live with, still the use-cas

Re: [PATCH] xlogreader: do not read a file block twice

On Fri, Feb 15, 2019 at 08:06:16AM +0900, Michael Paquier wrote: > Thanks, I see what you have done. I cannot comment if your shortcut > is actually fully correct based on my knowledge of this code, but > things cannot be in the best conditions without having the WAL reader > handle properly the l

RE: speeding up planning with partitions

Amit-san Sorry for my late reply. I had another work to do. On Fri, Feb 8, 2019 at 9:13 AM, Amit Langote wrote: > On 2019/02/08 13:44, Imai, Yoshikazu wrote: > > 3. > > 0001: line 1919-1920 > > > > - case CONSTRAINT_EXCLUSION_ON: > > - break; /

Re: REL_11_STABLE: dsm.c - cannot unpin a segment that is not pinned

On Mon, Feb 18, 2019 at 10:26 AM Thomas Munro wrote: > 1. "dsa_allocate could not find %zu free pages": freepage.c, fixed in > 7215efdc. > 2. "dsa_area could not attach to segment": dsm.c, fixed in 6c0fb941. > 3. "cannot unpin a segment that is not pinned": dsm.c, fixed in 0b55aaac. > > That r

Re: Optimze usage of immutable functions as relation

Andres Freund writes: > Given this I think the appropriate state of the CF entry would have been > waiting-for-author, not needs review. Or alternatively > returned-with-feedback or rejected. I'm a bit confused as to why the > patch was moved to the next CF twice? We have this review from Antoni

Re: Reaping Temp tables to avoid XID wraparound

> Yeah, possibly. I think that it could be tricky though to get that at >> a global level in a cheap way. It makes also little sense to only >> show the temp namespace OID if that information is not enough. >> > > We could I guess add a field specifically for temp_namespace_xid or such. > The que

Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" test pending solution of its timing is (fwd)

Fabien COELHO writes: >> Unfortunately, there was no activity over the last few commitfests and the >> proposed patch pgbench-tap-progress-6 can't be applied anymore without >> conflicts. Fabien, what are your plans about it, could you please post a >> rebased version? > Here it is. I'm confused

Re: pg_dump multi VALUES INSERT

On Wed, 13 Feb 2019 at 19:36, Surafel Temesgen wrote: > On Mon, Feb 11, 2019 at 10:20 AM David Rowley > wrote: >> >> Reviewing pg_dump-rows-per-insert-option-v14. >> >> Also, maybe one for Fabien (because he seems keen on keeping the >> --rows-per-insert validation code) >> >> strtol() returns a

Re: Add missing CREATE TABLE IF NOT EXISTS table_name AS EXECUTE query;

On Sun, Feb 17, 2019 at 03:31:05PM +0100, Andreas Karlsson wrote: > Yeah, noticed the same thing myself while refactoring the CTAS code, but I > guess the output could be like the current output for "EXPLAIN ANALYZE > WITH NO DATA;", i.e. a top plan with "(never executed)" (see below > for an exam

Re: Ryu floating point output patch

Andrew Gierth writes: > "Andrew" == Andrew Dunstan writes: > Andrew> Would you like to reformulate this, then? > How about: > Use the specified value of extra_float_digits when dumping > floating-point data, instead of the maximum available precision. > Routine dumps made for backu

Re: Ryu floating point output patch

> "Andrew" == Andrew Dunstan writes: Tom> I think we have to document it, but it can be fairly terse perhaps. Tom> Use the specified value of extra_float_digits when dumping Tom> floating-point data, rather than pg_dump's default. Tom> I don't think we need to go into detail about when/

Re: 2019-03 CF Summary / Review - Tranche #2

James Coleman writes: >> - Prove IS NOT NULL inference for large arrays >> >> NR: No idea. > As the fairly new author of this patch, my perspective is that this > patch got quite a bit of review, albeit without a formal "yes or no" > response. FWIW, I ran out of time for that patch during the J

Re: Ryu floating point output patch

On 2/17/19 6:15 PM, Andrew Gierth wrote: >> "Tom" == Tom Lane writes: > > Andrew Dunstan writes: > >> Here's a patch without docco. How much do we actually want to > >> document this? I'm not sure it has any great value outside of > >> cross-version upgrade testing. > > Tom> I think we

Re: Ryu floating point output patch

> "Tom" == Tom Lane writes: > Andrew Dunstan writes: >> Here's a patch without docco. How much do we actually want to >> document this? I'm not sure it has any great value outside of >> cross-version upgrade testing. Tom> I think we have to document it, but it can be fairly terse perha

Re: Ryu floating point output patch

> "Tom" == Tom Lane writes: >> Obviously I'll fix the warning, but how strict do you want to be >> about the rest of the code? Tom> Well, given that we're now requiring C99 compilers, you'd think Tom> that assuming stdbool semantics would be all right. The problem on Tom> prairiedog and

Re: Ryu floating point output patch

Andrew Dunstan writes: > Here's a patch without docco. How much do we actually want to document > this? I'm not sure it has any great value outside of cross-version > upgrade testing. I think we have to document it, but it can be fairly terse perhaps. Use the specified value of extra_flo

Re: Ryu floating point output patch

On 2/17/19 12:09 PM, Andrew Gierth wrote: >> "Andrew" == Andrew Dunstan writes: > Andrew> There are all sorts of version-specific things done there. The > Andrew> code will be pretty minimal. We'll only invoke it if the target > Andrew> version is >= 12 and the source version is <= 11. > >

Re: Ryu floating point output patch

Andrew Gierth writes: > Tom> IMO, this is just awful coding, using a "bool" argument in just > Tom> one place as a boolean and in four other ones as an integer. Aside > Tom> from being cowboy coding, this has very serious risks of > Tom> misbehaving on platforms where "bool" isn't C99-like, so

Re: CPU costs of random_zipfian in pgbench

On Sun, Feb 17, 2019 at 8:09 AM Tom Lane wrote: > TBH, I think pgbench is now much too complex; it does not need more > features, especially not ones that need large caveats in the docs. > (What exactly is the point of having zipfian at all?) I agree that pgbench is too complex, given its mandate

Re: REL_11_STABLE: dsm.c - cannot unpin a segment that is not pinned

On Mon, Feb 18, 2019 at 09:26:53AM +1300, Thomas Munro wrote: > Huh. What exactly do you mean by "killing the postmaster"? If you > mean SIGKILL or something, one problem with 11 is that > gather_readnext() doesn't respond to postmaster death. I fixed that > (and every similar place) in master w

Re: Ryu floating point output patch

> "Tom" == Tom Lane writes: Tom> result[sign] = '0'; Tom> IMO, this is just awful coding, using a "bool" argument in just Tom> one place as a boolean and in four other ones as an integer. Aside Tom> from being cowboy coding, this has very serious risks of Tom> misbehaving on platforms

Re: CPU costs of random_zipfian in pgbench

On 2/17/19 5:09 PM, Tom Lane wrote: > Fabien COELHO writes: >>> I'm trying to use random_zipfian() for benchmarking of skewed data sets, >>> and I ran head-first into an issue with rather excessive CPU costs. > >> If you want skewed but not especially zipfian, use exponential which is >> quite

Re: CPU costs of random_zipfian in pgbench

On 2/17/19 6:33 PM, David Fetter wrote: > On Sun, Feb 17, 2019 at 11:09:27AM -0500, Tom Lane wrote: >> Fabien COELHO writes: I'm trying to use random_zipfian() for benchmarking of skewed data sets, and I ran head-first into an issue with rather excessive CPU costs. >> >>> If you want s

Re: Actual Cost

On Sun, Feb 17, 2019 at 11:29:56AM -0500, Jeff Janes wrote: > What would I find very useful is [...] an rusage report rather than just > wall-clock duration. Most of that's available; [pryzbyj@database ~]$ psql postgres -xtc "SET client_min_messages=log; SET log_statement_stats=on" -c 'SELECT ma

Re: Ryu floating point output patch

BTW, another minor problem with this patch: various buildfarm members are whining that prairiedog| 2019-02-17 14:25:15 | ryu_common.h:111: warning: array subscript has type 'char' This evidently is from the next-to-last line in static inline int copy_special_str(char *const result, const b

Re: REL_11_STABLE: dsm.c - cannot unpin a segment that is not pinned

On Mon, Feb 18, 2019 at 9:35 AM Justin Pryzby wrote: > On Mon, Feb 18, 2019 at 09:26:53AM +1300, Thomas Munro wrote: > > Huh. What exactly do you mean by "killing the postmaster"? If you > > mean SIGKILL or something, one problem with 11 is that > > I mean unqualified /bin/kill which is kill -TE

Re: allow online change primary_conninfo

Hi > For one, it's not ok to just let the startup process think that the > walreceiver failed - that'll make it change source of WAL to the next > available method. Something we definitely do not want, as > restore_command is very commonly slower. Ok. This was not mentioned before Michael respons

Re: REL_11_STABLE: dsm.c - cannot unpin a segment that is not pinned

On Mon, Feb 18, 2019 at 09:26:53AM +1300, Thomas Munro wrote: > On Mon, Feb 18, 2019 at 9:07 AM Justin Pryzby wrote: > > Actually... > > > > On killing the postmaster having completed this stress test, one of the > > backends was left running and didn't die on its own. It did die gracefully > > w

Re: REL_11_STABLE: dsm.c - cannot unpin a segment that is not pinned

On Mon, Feb 18, 2019 at 9:07 AM Justin Pryzby wrote: > On Sun, Feb 17, 2019 at 01:41:45PM -0600, Justin Pryzby wrote: > > On Sat, Feb 16, 2019 at 09:16:01PM +1300, Thomas Munro wrote: > > > On Sat, Feb 16, 2019 at 5:31 PM Justin Pryzby > > > wrote: > > > > Thanks, will leave it spinning overnigh

Re: REL_11_STABLE: dsm.c - cannot unpin a segment that is not pinned

On Sun, Feb 17, 2019 at 01:41:45PM -0600, Justin Pryzby wrote: > On Sat, Feb 16, 2019 at 09:16:01PM +1300, Thomas Munro wrote: > > On Sat, Feb 16, 2019 at 5:31 PM Justin Pryzby wrote: > > > Thanks, will leave it spinning overnight. > > No errors in ~36 hours (126 CPU-hrs), so that seems to work.

Re: Progress reporting for pg_verify_checksums

Hi, Am Mittwoch, den 26.12.2018, 11:14 +0900 schrieb Michael Paquier: > On Tue, Dec 25, 2018 at 07:05:30PM +0100, Fabien COELHO wrote: > > You use 1024² bytes. What about 100 bytes per MB, as the > > unit is about stored files? I haven't changed that as Ihave not been pointed to a clear proje

Re: 2019-03 CF Summary / Review - Tranche #2

> - Prove IS NOT NULL inference for large arrays > > NR: No idea. As the fairly new author of this patch, my perspective is that this patch got quite a bit of review, albeit without a formal "yes or no" response. I'm obviously interested in getting it committed, and I believe it's a fairly simp

Re: REL_11_STABLE: dsm.c - cannot unpin a segment that is not pinned

On Sat, Feb 16, 2019 at 09:16:01PM +1300, Thomas Munro wrote: > On Sat, Feb 16, 2019 at 5:31 PM Justin Pryzby wrote: > > Thanks, will leave it spinning overnight. No errors in ~36 hours (126 CPU-hrs), so that seems to work. Thanks. > > Do you know if any of the others should also be changed ? >

Re: allow online change primary_conninfo

Hi, On 2019-02-16 14:50:35 +0300, Sergei Kornilov wrote: > > I don't quite think this is the right design. IMO the startup process > > should signal the walreceiver to shut down, and the wal receiver should > > never look at the config. > > Ok, i can rewrite such way. Please check attached versio

Re: Actual Cost

On Feb 17, 2019, at 10:56 AM, Tom Lane wrote: > Perhaps, but refactoring to get that seems impractically invasive & > expensive, since e.g. index AM cost estimate functions would have to > be redefined, plus we'd have to carry around some kind of cost vector > rather than single numbers for every

Re: Actual Cost

Jeff Janes writes: > What would I find very useful is a verbosity option to get the cost > estimates expressed as a multiplier of each *_cost parameter, rather than > just as a scalar. Perhaps, but refactoring to get that seems impractically invasive & expensive, since e.g. index AM cost estimate

Re: Offline enabling/disabling of data checksums

Hi, sorry for letting this slack. First off, thanks for the review! Am Mittwoch, den 09.01.2019, 07:07 +0100 schrieb Fabien COELHO: > > I changed that to the switches -c/--verify (-c for check as -v is taken, > > should it be --check as well? I personally like verify better),  > > -d/--disable a

Re: ON SELECT rule on a table without columns

Ashutosh Sharma writes: > [ allow-create-view-on-table-without-columns-v3.patch ] Pushed. I revised the test cases a bit --- notably, I wanted to be sure we exercised pg_dump's createDummyViewAsClause for this, especially after noticing that it wasn't being tested at all before :-(

Re: CPU costs of random_zipfian in pgbench

On Sun, Feb 17, 2019 at 11:09:27AM -0500, Tom Lane wrote: > Fabien COELHO writes: > >> I'm trying to use random_zipfian() for benchmarking of skewed data sets, > >> and I ran head-first into an issue with rather excessive CPU costs. > > > If you want skewed but not especially zipfian, use expon

Re: Ryu floating point output patch

> "Andrew" == Andrew Dunstan writes: Andrew> There are all sorts of version-specific things done there. The Andrew> code will be pretty minimal. We'll only invoke it if the target Andrew> version is >= 12 and the source version is <= 11. Andrew> I can do this if we're agreed. Sure, go a

Re: Variable-length FunctionCallInfoData

On 1/26/19 11:20 PM, Andrew Dunstan wrote: > On 1/26/19 9:46 PM, Tom Lane wrote: >> Andres Freund writes: >>> The buildfarm largely seems to have had no problem with it, but handfish >>> failed: >>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=handfish&dt=2019-01-26%2022%3A57%3A19 >>>

Re: Ryu floating point output patch

On 2/17/19 11:19 AM, Andrew Gierth wrote: >> "Tom" == Tom Lane writes: > >> b) new command-line option, e.g. pg_dump --extra-float-digits=0 > > >> This is probably the safest option, IMO. Any preferences as to the > >> option name? > > Tom> I like that too, assuming that it can be made t

Re: Reaping Temp tables to avoid XID wraparound

On Thu, Feb 14, 2019 at 1:43 AM Michael Paquier wrote: > On Wed, Feb 13, 2019 at 05:48:39PM +0100, Magnus Hagander wrote: > > On Wed, Feb 13, 2019 at 2:26 AM Michael Paquier > wrote: > >> The temporary namespace OID is added to PGPROC since v11, so it could > >> be easy enough to add a system fu

Re: Ryu floating point output patch

On 2/17/19 10:56 AM, Tom Lane wrote: > Andrew Gierth writes: >> I'd been holding off responding in the hope of other opinions, but for >> what it's worth, I *really* dislike having pg_dump depend magically on >> some new environment variable. > Likewise. Sure, no problem here - that was just

Re: Actual Cost

On Sat, Feb 16, 2019 at 10:33 PM Donald Dong wrote: > On Feb 16, 2019, at 6:44 PM, Tomas Vondra wrote: > > > > On 2/17/19 3:40 AM, David Fetter wrote: > >> > >> As someone not volunteering to do any of the work, I think it'd be a > >> nice thing to have. How large an effort would you guess it wo

Re: Ryu floating point output patch

> "Tom" == Tom Lane writes: >> b) new command-line option, e.g. pg_dump --extra-float-digits=0 >> This is probably the safest option, IMO. Any preferences as to the >> option name? Tom> I like that too, assuming that it can be made to fit into the Tom> structure of the cross-version-up

Re: CPU costs of random_zipfian in pgbench

Fabien COELHO writes: >> I'm trying to use random_zipfian() for benchmarking of skewed data sets, >> and I ran head-first into an issue with rather excessive CPU costs. > If you want skewed but not especially zipfian, use exponential which is > quite cheap. Also zipfian with a > 1.0 parameter

Re: Ryu floating point output patch

Andrew Gierth writes: > I'd been holding off responding in the hope of other opinions, but for > what it's worth, I *really* dislike having pg_dump depend magically on > some new environment variable. Likewise. > b) new command-line option, e.g. pg_dump --extra-float-digits=0 > This is probably

Re: Ryu floating point output patch

> "Andrew" == Andrew Dunstan writes: >> [horrible environment variable hack] >> >> We might not want to use that in more real-world cases of pg_dump use, >> but I think for this purpose it should be fine. Andrew> I haven't seen a response to this. Cross version upgrade Andrew> testing

Re: Add missing CREATE TABLE IF NOT EXISTS table_name AS EXECUTE query;

On 15/02/2019 09.14, Michael Paquier wrote: On Mon, Feb 11, 2019 at 09:53:59PM +0900, Michael Paquier wrote: Let's wait a bit more than the beginning of this week. I forgot about this week's minor release, and it is too late to do something about this report now, so we will have to wait unt OK

Re: pg_config wrongly marked as not parallel safe?

On 11/30/18 10:32 AM, Tom Lane wrote: > Joe Conway writes: >> On 11/30/18 3:30 AM, Kyotaro HORIGUCHI wrote: >>> # And returning to the topic, I vote for pg_config should be "stable". > >> And on that note, Does this change does warrant backpatching, or should >> be applied to master only? > > I

Re: Conflict handling for COPY FROM

On 2/16/19 12:24 AM, Andres Freund wrote: > Hi, > > On 2018-08-23 17:11:04 +0300, Surafel Temesgen wrote: >> COPY ... WITH ON CONFLICT LOG maximum_error, LOG FILE NAME '…'; > This doesn't seem to address Robert's point that a log file requires to > be super user only, which seems to restrict the

Re: [Patch][WiP] Tweaked LRU for shared buffers

On 2/17/19 2:14 PM, Едигарьев, Иван Григорьевич wrote: > Hi there. I was responsible for the benchmarks, and I would be glad to > make clear that part for you. > > On Sat, 16 Feb 2019 at 02:30, Tomas Vondra > wrote: >> Interesting. Where do these numbers (5/8 and 1/8) come from? > > The first n

Re: Ryu floating point output patch

On 2/14/19 10:14 AM, Andrew Dunstan wrote: > On 2/13/19 12:09 PM, Andrew Gierth wrote: >>> "Andrew" == Andrew Gierth writes: >> Andrew> 2. How far do we need to go to support existing uses of >> Andrew>extra_float_digits? For example, do we need a way for clients to >> Andrew>requ

Re: [Patch][WiP] Tweaked LRU for shared buffers

Hi there. I was responsible for the benchmarks, and I would be glad to make clear that part for you. On Sat, 16 Feb 2019 at 02:30, Tomas Vondra wrote: > Interesting. Where do these numbers (5/8 and 1/8) come from? The first number came from MySQL realization of LRU algorithm

Re: libpq host/hostaddr/conninfo inconsistencies

I am getting error while applying patch.I think the patch needs to be redone on the latest code in master as there are some commits in master after the patch is created Possibly. Here is a v5 with a simplified text. The key point is to tell that "host" expects names, ips or directories, and

Re: Actual Cost

On 2/17/19 7:45 AM, Donald Dong wrote: > On Feb 16, 2019, at 9:31 PM, Tom Lane wrote: >> >> Donald Dong writes: >>> On Feb 16, 2019, at 6:44 PM, Tomas Vondra wrote: I don't quite understand what is meant by "actual cost metric" and/or how is that different from running EXPLAIN ANALYZE.

Re: [WIP] CREATE SUBSCRIPTION with FOR TABLES clause (table filter)

Hi! > 14 февр. 2019 г., в 20:04, Evgeniy Efimkin > написал(а): > > I've made some more iterations looking for ideas how to improve the patch and found non. Code style, docs, tests, make-check worlds, bit status, everything seems OK. A little bit of copied code from dblink (there is no probl

Re: amcheck verification for GiST

Hi Peter! Sorry for the delay. Here's new version. > 1 февр. 2019 г., в 4:58, Peter Geoghegan написал(а): > > On Tue, Jan 1, 2019 at 2:11 AM Andrey Borodin wrote: >>> This isn't consistent with what you do within verify_nbtree.c, which >>> deliberately avoids ever holding more than a single bu

Re: CPU costs of random_zipfian in pgbench

Hello Tomas, I'm trying to use random_zipfian() for benchmarking of skewed data sets, and I ran head-first into an issue with rather excessive CPU costs. [...] This happens because generalizedHarmonicNumber() does this: for (i = n; i > 1; i--) ans += pow(i, -s); wher