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

Andres Freund writes: > - Inline Common Table Expressions > NR: I think it's likely that Tom will commit this soon, we're mostly > debating syntax and similar things at this point (and man, I'm looking > forward to this). Unless there are a bunch of votes real soon against the [NOT] MATERI

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

On Fri, Feb 15, 2019 at 9:45 PM Andres Freund wrote: > - Make nbtree keys unique by appending heap TID, suffix truncation > > NR: Important, seemingly carefully worked on feature. But it's > *complicated* stuff, and there's only been a bit of design review by > Heikki. The author's a committ

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

Hi > - block level PRAGMA > > NR: My reading of this thread is that the proposal is closer to being > rejected than merged. > > Andres: reject or punt? > > This patch is very simple and has strong sense for users of plpgsql_checks. For first moment, only plpgsql_check's users can get some

Re: Too rigorous assert in reorderbuffer.c

Alvaro Herrera writes: > Thanks for checking! I also run it on all branches, everything passes. > Pushed now. I'm sorry to bother you with this again, but due to new test our internal buildfarm revealed that ajacent assert on cmin is also lie. You see, we can't assume cmin is stable because th

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

Hi, On 2019-02-14 12:37:52 -0800, Andres Freund wrote: > - pg_stat_statements should notice FOR UPDATE clauses > > NR: This seems like to get in, given how sipmle it is. Some quibbles > about the appropriate approach aside. > > > Ok, my flight's about to land. So that's it for this round. -

Re: Conflict handling for COPY FROM

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 feature more than necessary? - Andres

Re: chained transactions

Hi, On 2019-01-02 16:02:21 +0100, Peter Eisentraut wrote: > +++ b/src/backend/access/transam/xact.c > @@ -189,6 +189,7 @@ typedef struct TransactionStateData > boolstartedInRecovery; /* did we start in recovery? */ > booldidLogXid; /* has xid b

Re: SQL/JSON: functions

Hi, On 2018-12-05 02:01:19 +0300, Nikita Glukhov wrote: > + if (!PG_ARGISNULL(1) && > + strncmp("any", VARDATA(type), VARSIZE_ANY_EXHDR(type))) > + { > + JsonLexContext *lex; > + JsonTokenType tok; > + > + lex = makeJsonLexContext(json, fals

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

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 diskquota extension > [ ...] > On Tue

Re: [PATCH v20] GSSAPI encryption support

Hi, On 2018-12-18 14:12:46 -0500, Robbie Harwood wrote: > From 6915ae2507bf7910c5eecfbd0b84805531c16a07 Mon Sep 17 00:00:00 2001 > From: Robbie Harwood > Date: Thu, 10 May 2018 16:12:03 -0400 > Subject: [PATCH] libpq GSSAPI encryption support > > On both the frontend and backend, prepare for GSS

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

On Sat, Feb 16, 2019 at 3:38 PM Justin Pryzby wrote: > I saw this error once last week while stress testing to reproduce earlier > bugs, > but tentatively thought it was a downstream symptom of those bugs (since > fixed), and now wanted to check that #15585 and others were no longer > reproducibl

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

Hi, On 2019-02-06 15:19:56 +, Timmer, Marius wrote: > On Mon, Jan 04, 2019 at 03:06, Michael Paquier wrote: > > I have moved the patch to next CF, waiting on author as the latest > > patch does not apply. Could it be rebased? > The patch is rebased and applies now. I see you've marked the p

Re: Remove Deprecated Exclusive Backup Mode

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. The first release where t

Re: allow online change primary_conninfo

Hi, On 2019-02-03 15:33:38 +0300, Sergei Kornilov wrote: > +/* > + * Actual processing SIGHUP signal > + */ > +static void > +ProcessWalRcvSigHup(void) > +{ > + ProcessConfigFile(PGC_SIGHUP); > + > + /* > + * If primary_conninfo has been changed while walreceiver is running, > +

Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line

Hi, On 2019-02-08 18:30:18 +0300, Alexey Kondratov wrote: > From 99c6d94f37a797400d41545a271ff111b92e9361 Mon Sep 17 00:00:00 2001 > From: Alexey Kondratov > Date: Fri, 21 Dec 2018 14:00:30 +0300 > Subject: [PATCH] pg_rewind: options to use restore_command from > postgresql.conf or command line.

Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line

Hi, On 2018-11-07 12:58:11 +0300, Alexey Kondratov wrote: > On 30.10.2018 06:01, Michael Paquier wrote: > > - Reusing the GUC parser is something I would avoid as well. Not worth > > the complexity. > > Yes, I don't like it either. I will try to make guc-file.l frontend safe. It sounds like a s

Re: Copy function for logical replication slots

Hi, 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_name , > temporary > bool) > + > + > +(slot_name name, > lsn pg_lsn) > +

Re: Channel binding

On Sat, Feb 16, 2019 at 10:12:19AM +0900, Michael Paquier wrote: > On Fri, Feb 15, 2019 at 04:17:07PM -0500, Bruce Momjian wrote: > > We removed channel binding from PG 11 in August of 2018 because we were > > concerned about downgrade attacks. Are there any plans to enable it for > > PG 12? > >

Re: [HACKERS] Restricting maximum keep segments by repslots

Hi, On 2019-01-30 10:42:04 +0900, Kyotaro HORIGUCHI wrote: > From 270aff9b08ced425b4c4e23b53193285eb2359a6 Mon Sep 17 00:00:00 2001 > From: Kyotaro Horiguchi > Date: Thu, 21 Dec 2017 21:20:20 +0900 > Subject: [PATCH 1/6] Add WAL relief vent for replication slots > > Adds a capability to limit th

Re: Reviving the "Stopping logical replication protocol" patch from Vladimir Gordichuk

Hi, On 2018-12-03 06:38:43 -0500, Dave Cramer wrote: > From 4d023cfc1fed0b5852b4da1aad6a32549b03ce26 Mon Sep 17 00:00:00 2001 > From: Dave Cramer > Date: Fri, 30 Nov 2018 18:23:49 -0500 > Subject: [PATCH 1/5] Respect client initiated CopyDone in walsender > > --- > src/backend/replication/walse

Re: Refactoring the checkpointer's fsync request queue

Hi, On 2019-02-13 18:40:05 +1300, Thomas Munro wrote: > Thanks! And sorry for not replying sooner -- I got distracted by > FOSDEM (and the associated 20 thousand miles of travel). On that trip > I had a chance to discuss this patch with Andres Freund in person, and > he opined that it might be b

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

I saw this error once last week while stress testing to reproduce earlier bugs, but tentatively thought it was a downstream symptom of those bugs (since fixed), and now wanted to check that #15585 and others were no longer reproducible. Unfortunately I got this error while running same test case [

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

On Fri, Feb 15, 2019 at 2:08 AM Andres Freund wrote: > > Hi, > > - Avoid creation of the free space map for small tables > > NR: the majority of this patch has been committed, > This is a correct assessment. > I assume the > remaining pieces will too. > Yes, I am busy these days with someth

Re: Compressed TOAST Slicing

Hi Stephen, On 2018-12-06 12:54:18 -0800, Paul Ramsey wrote: > On Sun, Dec 2, 2018 at 7:03 AM Rafia Sabih > wrote: > > > > The idea looks good and believing your performance evaluation it seems > > like a practical one too. > > Thank you kindly for the review! > > > A comment explaining how th

Re: Delay locking partitions during INSERT and UPDATE

Hi, On 2019-01-31 13:46:33 -0500, Robert Haas wrote: > I have reviewed this patch and I am in favor of it. I think it likely > needs minor rebasing because of the heap_open -> table_open renaming. > I also agree that it's worth taking some deadlock risk for the rather > massive performance gain,

Re: Patch for SortSupport implementation on inet/cdir

Hi Brandur, On 2019-02-09 20:12:53 +1300, Edmund Horner wrote: > I had a look at this. Your V2 patch applies cleanly, and the code was > straightforward and well commented. I appreciate the big comment at the > top of network_abbrev_convert explaining how you encode the data. I've marked the C

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

On 2/16/19 1:48 AM, Benjamin Manes wrote: > Hi, > > I was not involved with Andrey and his team's work, which looks like a > very promising first pass. I can try to clarify a few minor details. > > What is CAR? Did you mean ARC, perhaps? > > > CAR is the Clock variants of ARC: CAR: Clock wi

Re: Optimze usage of immutable functions as relation

On 2018-11-08 15:08:03 +0100, Antonin Houska wrote: > Aleksandr Parfenov wrote: > > > I fixed a typo and some comments. Please find new version attached. > > I've checked this verstion too. > > * is_simple_stable_function() > > instead of fetching HeapTuple from the syscache manually, you migh

Re: Channel binding

On Fri, Feb 15, 2019 at 04:17:07PM -0500, Bruce Momjian wrote: > We removed channel binding from PG 11 in August of 2018 because we were > concerned about downgrade attacks. Are there any plans to enable it for > PG 12? The original implementation of channel binding for SCRAM has included support

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

On 2/16/19 12:51 AM, Peter Geoghegan wrote: > On Fri, Feb 15, 2019 at 3:30 PM Tomas Vondra > wrote: >> That TPS chart looks a bit ... wild. How come the master jumps so much >> up and down? That's a bit suspicious, IMHO. > > Somebody should write a patch to make buffer eviction completely > ra

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

On Fri, Feb 15, 2019 at 3:30 PM Tomas Vondra wrote: > That TPS chart looks a bit ... wild. How come the master jumps so much > up and down? That's a bit suspicious, IMHO. Somebody should write a patch to make buffer eviction completely random, without aiming to get it committed. That isn't as bad

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

Hi, On 2/13/19 3:37 PM, Andrey Borodin wrote: > Hi, hackers! > > We have held education project at Sirius edu center (Sochi, Russia) > with mentors from Yandex. The group of 5 students was working on > improving the shared buffers eviction algorithm: Andrey Chausov, Yuriy > Skakovskiy, Ivan Edi

Re: Early WIP/PoC for inlining CTEs

On 2/14/19 8:22 PM, Merlin Moncure wrote: > On Thu, Feb 14, 2019 at 10:02 AM Alvaro Herrera > wrote: >> >> On 2019-Feb-14, Peter Eisentraut wrote: >> >>> On 14/02/2019 16:11, Tom Lane wrote: ... so, have we beaten this topic to death yet? Can we make a decision? Personally, I'd be

Channel binding

We removed channel binding from PG 11 in August of 2018 because we were concerned about downgrade attacks. Are there any plans to enable it for PG 12? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. A

Re: propagating replica identity to partitions

On 2019-Feb-07, Dmitry Dolgov wrote: > Could there be a race condition somewhere? The idea and the code looks > reasonable, but when I'm testing ALTER TABLE ... REPLICA IDENTITY with this > patch and concurrent partition creation, I've got the following error on > ATTACH > PARTITION: > > ERROR:

Re: WAL insert delay settings

On 2/15/19 7:41 PM, Andres Freund wrote: > Hi, > > On 2019-02-15 08:50:03 -0500, Stephen Frost wrote: >> * Andres Freund (and...@anarazel.de) wrote: >>> On 2019-02-14 11:02:24 -0500, Stephen Frost wrote: On Thu, Feb 14, 2019 at 10:15 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>

Re: shared-memory based stats collector

On 2019-Feb-15, Andres Freund wrote: > It's fine to do such renames, just do them as separate patches. It's > hard enough to review changes this big... Talk about moving the whole file to another subdir ... -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24

Re: WAL insert delay settings

Hi, On 2019-02-15 08:50:03 -0500, Stephen Frost wrote: > * Andres Freund (and...@anarazel.de) wrote: > > On 2019-02-14 11:02:24 -0500, Stephen Frost wrote: > > > On Thu, Feb 14, 2019 at 10:15 Peter Eisentraut < > > > peter.eisentr...@2ndquadrant.com> wrote: > > > > On 14/02/2019 11:03, Tomas Vondr

Re: Copy function for logical replication slots

Hi, On 15/01/2019 02:56, Masahiko Sawada wrote: > On Tue, Nov 27, 2018 at 3:46 AM Petr Jelinek > wrote: >>> + >>> + /* >>> +* The requested wal lsn is no longer available. We don't >>> want to retry >>> +* it, so raise an error. >>> +

Re: shared-memory based stats collector

Hi, On 2019-02-15 17:29:00 +0900, Kyotaro HORIGUCHI wrote: > At Thu, 7 Feb 2019 13:10:08 -0800, Andres Freund wrote > in <20190207211008.nc3axviivmcoa...@alap3.anarazel.de> > > Hi, > > > > On 2018-11-12 20:10:42 +0900, Kyotaro HORIGUCHI wrote: > > > diff --git a/src/backend/access/transam/xlog.

Re: Using POPCNT and other advanced bit manipulation instructions

Hi, On 2019-02-14 16:45:38 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2019-02-14 15:47:13 -0300, Alvaro Herrera wrote: > >> Hah, I just realized you have to add -mlzcnt in order for these builtins > >> to use the lzcnt instructions. It goes from something like > >> > >> bsrq %r

Re: Using POPCNT and other advanced bit manipulation instructions

Alvaro Herrera writes: > Here's a final version that I intend to push shortly, to have time > before EOB today to handle any fallout. I think this is likely to result in a lot of complaints about rightmost_one_pos[] being unreferenced, in non-HAVE__BUILTIN_CTZ builds. Probably that has to be an

Re: House style for DocBook documentation?

On 2019-01-26 09:31, Peter Eisentraut wrote: > On 25/01/2019 15:37, Chapman Flack wrote: >>> External links already create footnotes in the PDF output. Is that >>> different from what you are saying? >> That might, only, indicate that I was just thinking aloud in email and >> had not gone and chec

Re: explain plans with information about (modified) gucs

On 2019-02-15 17:10:28 +0100, Tomas Vondra wrote: > True. So you agree printing the values as text (as the patch currently > does) seems enough? I guess I'm fine with that. I do agree, yes.

Re: Reporting script runtimes in pg_regress

John Naylor writes: > On 2/15/19, Peter Eisentraut wrote: >> We should also strive to align "FAILED" properly. This is currently >> quite unreadable: >> >> int4 ... ok (128 ms) >> int8 ... FAILED (153 ms) >> oid ... ok (16

Re: Commit Fest 2019-01 is now closed

On 2019-02-10 20:30, Magnus Hagander wrote: > On Fri, Feb 8, 2019 at 2:12 PM Peter Eisentraut > > wrote: > > On 08/02/2019 12:27, Magnus Hagander wrote: > > I'd be more than happy for somebody with morge knowledge of such > matters > > than

Re: Using POPCNT and other advanced bit manipulation instructions

Here's a final version that I intend to push shortly, to have time before EOB today to handle any fallout. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >From 085650a174ff080f578bb289d3707173aaf4f07b Mon Sep 17

Re: Reporting script runtimes in pg_regress

Peter Eisentraut writes: > If we're going to keep this, should we enable the prove --timer option as > well? As far as that goes: I've found that in some of my older Perl installations, prove doesn't recognize the --timer switch. So turning that on would require a configuration probe of some sor

Re: explain plans with information about (modified) gucs

On 2/14/19 8:55 PM, Andres Freund wrote: > Hi, > > On 2019-01-15 02:39:49 +0100, Tomas Vondra wrote: >> >> >> On 1/14/19 11:13 PM, Alvaro Herrera wrote: >>> On 2019-Jan-14, Tomas Vondra wrote: >>> The one slightly annoying issue is that currently all the options are formatted as text,

Re: Protect syscache from bloating with negative cache entries

On 2/14/19 4:49 PM, 'Bruce Momjian' wrote: > On Thu, Feb 14, 2019 at 01:31:49AM +, Tsunakawa, Takayuki wrote: >> From: Bruce Momjian [mailto:br...@momjian.us] That being said, having a "minimal size" threshold before starting with the time-based eviction may be a good idea. >>> >>>

Re: Using POPCNT and other advanced bit manipulation instructions

On 2019-Feb-15, Tom Lane wrote: > Alvaro Herrera writes: > > Ah, I understand it now: > > https://stackoverflow.com/questions/25683690/confusion-about-bsr-and-lzcnt/43443701#43443701 > > if you call LZCNT/TZCNT on a CPU that doesn't support it, it won't raise > > SIGILL or anything ... it'll just

Re: Reporting script runtimes in pg_regress

On 2/15/19, Peter Eisentraut wrote: > We should also strive to align "FAILED" properly. This is currently > quite unreadable: > > int4 ... ok (128 ms) > int8 ... FAILED (153 ms) > oid ... ok (163 ms) > fl

Re: Protect syscache from bloating with negative cache entries

On 2/14/19 3:46 PM, Bruce Momjian wrote: > On Thu, Feb 14, 2019 at 12:40:10AM -0800, Andres Freund wrote: >> Hi, >> >> On 2019-02-13 15:31:14 +0900, Kyotaro HORIGUCHI wrote: >>> Instead, I added an accounting(?) interface function. >>> >>> | MemoryContextGettConsumption(MemoryContext cxt); >>> >

Re: Using POPCNT and other advanced bit manipulation instructions

Alvaro Herrera writes: > I noticed in Compiler Explorer that some (ancient?) Power cpus > implement instruction "popcntb", and GCC support for those uses > -mpopcntb switch enabling __builtin_popcount() to use it. I added the > switch to configure.in but I'm not sure how well that will work ...

Re: Protect syscache from bloating with negative cache entries

On 2/13/19 1:23 AM, Tsunakawa, Takayuki wrote: > From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp] >> I'm at a loss how call syscache for users. I think it is "catalog >> cache". The most basic component is called catcache, which is >> covered by the syscache layer, both of then

Re: libpq compression

On 15.02.2019 18:26, Tomas Vondra wrote: On 2/15/19 3:03 PM, Konstantin Knizhnik wrote: On 15.02.2019 15:42, Peter Eisentraut wrote: On 2018-06-19 09:54, Konstantin Knizhnik wrote: The main drawback of streaming compression is that you can not decompress some particular message without d

Re: libpq compression

On 2/15/19 3:03 PM, Konstantin Knizhnik wrote: > > > On 15.02.2019 15:42, Peter Eisentraut wrote: >> On 2018-06-19 09:54, Konstantin Knizhnik wrote: >>> The main drawback of streaming compression is that you can not >>> decompress some particular message without decompression of all previous

Re: Using POPCNT and other advanced bit manipulation instructions

Alvaro Herrera writes: > Ah, I understand it now: > https://stackoverflow.com/questions/25683690/confusion-about-bsr-and-lzcnt/43443701#43443701 > if you call LZCNT/TZCNT on a CPU that doesn't support it, it won't raise > SIGILL or anything ... it'll just silently compute the wrong result. > That'

Re: [HACKERS] Time to change pg_regress diffs to unified by default?

Re: Andrew Gierth 2019-02-15 <874l95m8w7@news-spur.riddles.org.uk> > Also while we're tweaking regression test output, would it be possible > to have some indicator of whether a test passed because a variant file > in the resultmap was ignored in favor of the standard result? > > The current s

Re: query logging of prepared statements

Sigh, resending to -hackers for real. On Fri, Feb 08, 2019 at 07:29:53AM -0600, Justin Pryzby wrote: > A couple months ago, I implemented prepared statements for PyGreSQL. While > updating our application in advance of their release with that feature, I > noticed that our query logs were several

Re: Reporting script runtimes in pg_regress

Peter Eisentraut writes: > On 2019-02-15 14:32, Peter Eisentraut wrote: >> test event_trigger... ok 128 ms >> test fast_default ... ok 173 ms >> test stats... ok 637 ms That looks reasonable, although on machines where test ru

Re: Using POPCNT and other advanced bit manipulation instructions

On 2019-Feb-14, Tom Lane wrote: > Then the correct test to see if we want to build pg_popcount.c (BTW, > please pick a less generic name for that) and the choose function > is whether we have *both* HAVE__BUILTIN_POPCOUNT and nonempty > CFLAGS_POPCNT. I used pg_bitutils_sse42.c to host the specia

Re: [HACKERS] Time to change pg_regress diffs to unified by default?

> "Peter" == Peter Eisentraut writes: Peter> (This might be one of those rare times where one hopes for a Peter> buildfarm failure for verification. :-) ) Also while we're tweaking regression test output, would it be possible to have some indicator of whether a test passed because a varian

Re: Log a sample of transactions

On 2/14/19 9:14 PM, Andres Freund wrote: Hi, Hello Andres, On 2019-01-26 11:44:58 +0100, Adrien NAYRAT wrote: + + log_transaction_sample_rate (real) + + log_transaction_sample_rate configuration parameter + + + + + Set the fraction o

Re: Using POPCNT and other advanced bit manipulation instructions

On 2019-Feb-15, Alvaro Herrera wrote: > On 2019-Feb-15, Kyotaro HORIGUCHI wrote: > > And even worse lzcntx is accidentially "fallback"s to bsrx on > > unsupported CPUs, which leads to bogus results. > > __builtin_clzll(8) = 3, which should be 60. > > I'm not sure I understand this point. Are yo

Re: Reporting script runtimes in pg_regress

On 2019-02-15 14:32, Peter Eisentraut wrote: > identity ... ok 238 ms > partition_join ... ok 429 ms > partition_prune ... ok 786 ms > reloptions ... ok 94 ms > hash_part

Re: Using POPCNT and other advanced bit manipulation instructions

On 2019-Feb-15, Kyotaro HORIGUCHI wrote: > I understand that the behavior of __builtin_c[tl]z(0) is > undefined from the reason, they convert to bs[rf]. So if we use > these builtins, additional check is required. > > https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html Okay -- the functions c

Re: Regarding participating in GSOC 2019 with PostgreSQL

Greetings, * Abhishek Agrawal (aagrawal...@gmail.com) wrote: > I am interested in doing GSOC with PostgreSQL if you guys are applying for it > this year. If anyone could direct me to proper links or some channel to > prepare for the same then it will be really helpful. I have some questions > l

Re: [PATCH][PROPOSAL] Add enum releation option type

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:not tested I believe this patch simplifies infrastructure. As non native speaker, I'm ok

Re: [HACKERS] Time to change pg_regress diffs to unified by default?

On 2019-01-03 11:20, Daniel Gustafsson wrote: >> On 3 Jan 2019, at 10:39, Christoph Berg wrote: >> >> Re: Peter Eisentraut 2019-01-02 >> <70440c81-37bb-76dd-e48b-b5a9550d5...@2ndquadrant.com> > >>> While we're considering the pg_regress output, what do you think about >>> replacing the ==...

Re: libpq compression

On 15.02.2019 15:42, Peter Eisentraut wrote: On 2018-06-19 09:54, Konstantin Knizhnik wrote: The main drawback of streaming compression is that you can not decompress some particular message without decompression of all previous messages. It seems this would have an adverse effect on protocol

Re: log bind parameter values on error

Hello Anders and Peter, Thanks for your messages. Please see the new patch version attached. > Have you analyzed how invasive it'd be to delay that till we actually > can safely start a [sub]transaction to do that logging? Probably too > expensive, but it seems like something that ought to be an

Re: WAL insert delay settings

Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2019-02-14 11:02:24 -0500, Stephen Frost wrote: > > On Thu, Feb 14, 2019 at 10:15 Peter Eisentraut < > > peter.eisentr...@2ndquadrant.com> wrote: > > > On 14/02/2019 11:03, Tomas Vondra wrote: > > > > But if you add extra sleep() calls so

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

Higuchi-san, > I found some "CREATE TABLE ... AS ... " syntaxes could not be used in > ECPG. > ... > [Investigation] > In my investigation, parse.pl ignore type CreateAsStmt of gram.y and > CreateAsStmt is defined in ecpg.trailer. ECPG use ecpg.trailer's > CreateAsStmt. However, ecpg.trailer lack

Re: Reporting script runtimes in pg_regress

On 2019-02-11 15:30, Tom Lane wrote: > Peter Eisentraut writes: >> Now that I see this in action, it makes the actual test results harder >> to identify flying by. I understand the desire to collect this timing >> data, but that is a special use case and not relevant to the normal use >> of the t

Re: restrict pg_stat_ssl to superuser?

On 2019-02-12 07:40, Michael Paquier wrote: > On Thu, Feb 07, 2019 at 09:30:38AM +0100, Peter Eisentraut wrote: >> If so, is there anything in that view that should be made available to >> non-superusers? If not, then we could perhaps do this via a simple >> permission change instead of going the

Re: Problems with plan estimates in postgres_fdw

Etsuro Fujita wrote: > (2019/02/12 18:03), Antonin Houska wrote: > > Etsuro Fujita wrote: > >> (2019/02/08 2:04), Antonin Houska wrote: > >>> > >>> And maybe related problem: why should FDW care about the effect of > >>> apply_scanjoin_target_to_paths() like you claim to do here? > >>> > >>> /

Re: libpq compression

On 2018-06-19 09:54, Konstantin Knizhnik wrote: > The main drawback of streaming compression is that you can not > decompress some particular message without decompression of all previous > messages. It seems this would have an adverse effect on protocol-aware connection proxies: They would have t

RE: Protect syscache from bloating with negative cache entries

>From: Ideriha, Takeshi [mailto:ideriha.take...@jp.fujitsu.com] >>About the new global-size based evicition(2), cache entry creation >>becomes slow after the total size reached to the limit since every one >>new entry evicts one or more old (= >>not-recently-used) entries. Because of not needing k

Re: Problems with plan estimates in postgres_fdw

(2019/02/14 18:44), Etsuro Fujita wrote: (2019/02/12 20:43), Antonin Houska wrote: Etsuro Fujita wrote: Here are my review comments: root->upper_targets[UPPERREL_FINAL] = final_target; + root->upper_targets[UPPERREL_ORDERED] = final_target; root->upper_targets[UPPERREL_WINDOW] = sort_input_tar

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

Matsumura-san, > I agree that the special route is ugly, but I cannot remove them > completely. > I try to implement Idea-2. In same time, I try to move if(bytea) > blocks to > new function for readability. > > e.g. move the following to new function set_data_attr(). I don't think this will help

Re: Incorrect visibility test function assigned to snapshot

Michael Paquier wrote: > On Fri, Feb 08, 2019 at 11:59:05AM +0100, Antonin Houska wrote: > > Sorry, I forgot. Patch is below and I'm going to add an entry to the > > next CF. > > > @@ -615,6 +615,8 @@ SnapBuildInitialSnapshot(SnapBuild *builder) > > > > TransactionIdAdvance(xid); >

postgres_fdw: another oddity in costing aggregate pushdown paths

As mentioned in the near thread, I think there is another oversight in the cost estimation for aggregate pushdown paths in postgres_fdw, IIUC. When costing an aggregate pushdown path using local statistics, we re-use the estimated costs of implementing the underlying scan/join relation, cached in

Re: Problems with plan estimates in postgres_fdw

(2019/02/12 18:03), Antonin Houska wrote: Etsuro Fujita wrote: (2019/02/08 2:04), Antonin Houska wrote: Some comments on coding: 0001-postgres_fdw-Perform-UPPERREL_ORDERED-step-remotely-v3.patch - * I'm not sure if UPPERREL_ORDE

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

On Thu, Feb 14, 2019 at 12:37:52PM -0800, Andres Freund wrote: > - Adding a TAP test checking data consistency on standby with > minRecoveryPoint > > NR: Seems like it ought to be committable, Andrew Gierth did provide > some feedback. I am rather happy of the shape of the test, and was jus

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

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 until the release had > happened. OK, committed

Re: INSTALL file

On 14/02/2019 20:13, Andres Freund wrote: > On 2019-02-04 11:02:44 +0900, Michael Paquier wrote: >> +1. I have just looked at the patch, and my take is that listing all >> the ways to build Postgres directly in the README is just a >> duplication of what we already have in the documentation. So I