Re: insensitive collations

On 09/01/2019 22:01, Daniel Verite wrote: >> I don't see anything wrong here. The collation says that both values >> are equal, so which one is returned is implementation-dependent. > Is it, but it's impractical if the product of seemingly the same GROUP BY > flip-flops between its different valid

Re: insensitive collations

On 09/01/2019 19:49, Andreas Karlsson wrote: > On 12/28/18 9:55 AM, Peter Eisentraut wrote: >> Here is an updated patch. >> >> I have updated the naming to "deterministic", as discussed. > > Maybe this is orthogonal and best handled elsewhere but have you when > working with string equality given

Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query

On Thu, Jan 10, 2019 at 2:32 PM Amit Kapila wrote: > On Wed, Jan 9, 2019 at 10:26 AM Haribabu Kommi > wrote: > > > > > > On Wed, Jan 9, 2019 at 2:25 PM Amit Kapila > wrote: > >> > >> Another minor point is that in the second statement > >> (pg_stat_statements_reset), you seem to have made it a

RE: speeding up planning with partitions

Hi Amit, On Mon, Jan 7, 2019 at 6:30 PM, Amit Langote wrote: > On 2018/12/27 20:25, Amit Langote wrote: > > Here's the v10 of the patch. I didn't get chance to do more changes > > than those described above and address Imai-san's review comments > yesterday. > > > > Have a wonderful new year! I'

Re: Fast path for empty relids in check_outerjoin_delay()

On Tue, Jan 8, 2019 at 11:29 PM Tom Lane wrote: > Richard Guo writes: > > On Fri, Jan 4, 2019 at 10:32 PM Peter Eisentraut < > > peter.eisentr...@2ndquadrant.com> wrote: > >> I think code readability and maintainability would be improved by having > >> fewer special cases and fast paths. In thi

Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0

Amit-san, (2019/01/10 10:41), Amit Langote wrote: On 2019/01/09 20:20, Etsuro Fujita wrote: I like your patch in general. I think one way to address Ashutosh's concerns would be to use the consider_partitionwise_join flag: originally, that was introduced for partitioned relations to show that

Re: Undo logs

On Wed, Jan 9, 2019 at 11:40 AM Dilip Kumar wrote: > On Tue, Jan 8, 2019 at 2:11 PM Amit Kapila > wrote: > >> >> >> 3. >> + work_txn.urec_next = uur->uur_next; >> + work_txn.urec_xidepoch = uur->uur_xidepoch; >> + work_txn.urec_progress = uur->uur_progress; >> + work_txn.urec_prevurp = uur->uur_

Re: New vacuum option to do only freezing

On Thu, Jan 10, 2019 at 5:23 AM Bossart, Nathan wrote: > > Hi, > > On 1/8/19, 7:03 PM, "Masahiko Sawada" wrote: > > Attached the updated version patch incorporated all comments I got. > > Thanks for the new patch! > > > * Instead of freezing xmax I've changed the behaviour of the new > > option (

Re: [Sender Address Forgery]Re: error message when subscription target is a partitioned table

On Tue, Jan 08, 2019 at 04:42:35PM +0900, Michael Paquier wrote: > I can see your point, though I would stick with > ERRCODE_WRONG_OBJECT_TYPE for consistency with the existing code and > because the code is intended to not work on anything else than plain > tables, at least now. Attached are my s

Re: Unified logging system for command-line programs

I think this patch is a nice improvement! On Jan 3, 2019, at 2:08 PM, Andres Freund wrote: > Or we could just add an ERROR variant that doesn't exit. Years back > I'd proposed that we make the log level a bitmask, but it could also > just be something like CALLSITE_ERROR or something roughly alon

Re: Displaying and dumping of table access methods

On Wed, Jan 9, 2019 at 10:53 PM Andres Freund wrote: > > Hi, > > On 2019-01-09 18:26:16 +0530, Amit Kapila wrote: > > On Tue, Jan 8, 2019 at 11:04 PM Andres Freund wrote: > > +1. > > > > > Don't like it > > > too much, but it seems better than the alternative. I wonder if we want > > > one for m

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

On Wed, Jan 9, 2019 at 9:00 PM John Naylor wrote: > > On Wed, Jan 9, 2019 at 7:33 AM Mithun Cy wrote: > > 2. v11-Every-other-page and v11-last-page patches improve the > > performance from base. > > 3. IMHO v11-Every-other-page would be ideal to consider it improves > > the performance and also t

Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query

On Wed, Jan 9, 2019 at 10:26 AM Haribabu Kommi wrote: > > > On Wed, Jan 9, 2019 at 2:25 PM Amit Kapila wrote: >> >> Another minor point is that in the second statement >> (pg_stat_statements_reset), you seem to have made it a two-line >> statement whereas first one looks to be a single-line state

Re: BTW, have we got a commitfest manager for the January CF?

On Wed, Jan 09, 2019 at 08:43:08PM -0500, Tom Lane wrote: > I see somebody marked the CF as in-progress, but if anyone volunteered > to be nagger-in-chief for this month, I didn't see that. I'm happy to do it. Would love to chat with recent prior CFMs, if they're willing. Best, David. -- David

Re: Early WIP/PoC for inlining CTEs

On Thu, Jan 10, 2019 at 2:28 PM Andreas Karlsson wrote: > 2. Feedback on the new syntax. I am personally fine with the current > syntax, but it was just something I just quickly hacked together to move > the patch forward and which also solved my personal uses cases. Thanks for working on this.

Re: pgsql: Use perfect hashing, instead of binary search, for keyword looku

On Wed, Jan 9, 2019 at 7:48 PM Tom Lane wrote: > Use perfect hashing, instead of binary search, for keyword lookup. > > We've been speculating for a long time that hash-based keyword lookup > ought to be faster than binary search, but up to now we hadn't found > a suitable tool for generating the

Re: BTW, have we got a commitfest manager for the January CF?

On Wed, Jan 09, 2019 at 08:43:08PM -0500, Tom Lane wrote: > I see somebody marked the CF as in-progress, but if anyone volunteered > to be nagger-in-chief for this month, I didn't see that. No volunteers as far as I know of... -- Michael signature.asc Description: PGP signature

Re: Making WAL receiver startup rely on GUC context for primary_conninfo and primary_slot_name

On Wed, Jan 09, 2019 at 05:38:53PM -0800, Donald Dong wrote: > On Jan 9, 2019, at 4:47 PM, Michael Paquier wrote: >> That's much cleaner to me to clean up the field for safety before >> starting the process. When requesting a WAL receiver to start, >> slotname and conninfo gets zeroed before doin

BTW, have we got a commitfest manager for the January CF?

I see somebody marked the CF as in-progress, but if anyone volunteered to be nagger-in-chief for this month, I didn't see that. regards, tom lane

Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0

Fujita-san, On 2019/01/09 20:20, Etsuro Fujita wrote: > (2019/01/09 9:30), Amit Langote wrote: >> So, while the patch at [1] can take care of this issue as I also mentioned >> upthread, I was trying to come up with a solution that can be back-patched >> to PG 11.  The patch I posted above is one s

Re: Making WAL receiver startup rely on GUC context for primary_conninfo and primary_slot_name

On Jan 9, 2019, at 4:47 PM, Michael Paquier wrote: > That's much cleaner to me to clean up the field for safety before > starting the process. When requesting a WAL receiver to start, > slotname and conninfo gets zeroed before doing anything, you are right > that we could do without it actually

Re: Misleading panic message in backend/access/transam/xlog.c

On Wed, Jan 09, 2019 at 05:09:19PM -0800, Andres Freund wrote: > IIRC we have other such errors including offset and length (and if > not we'll grow some). It should be formatted as a genetic write > error with the file name, no reference to log file, etc, even if > there's no precedent. Yeah, th

Re: Early WIP/PoC for inlining CTEs

Here is a new version of the patch with added tests, improved comments, some minor code cleanup and most importantly slightly changed logic for when we should inline. The current strategy is to always inline unless the CTE is recursive or it has side effects, i.e. it is a DML query, it contain

Re: Misleading panic message in backend/access/transam/xlog.c

On January 9, 2019 5:01:40 PM PST, Michael Paquier wrote: >On Wed, Jan 09, 2019 at 08:10:43AM -0800, Andres Freund wrote: >> I'm quite unenthused about that. If anything, I'd remove detail and >use >> the standard error message about not being able to write to a file, >and >> include the full p

Re: Misleading panic message in backend/access/transam/xlog.c

On Wed, Jan 09, 2019 at 08:10:43AM -0800, Andres Freund wrote: > I'm quite unenthused about that. If anything, I'd remove detail and use > the standard error message about not being able to write to a file, and > include the full path. Partially agreed. Those messages have been left out of 56df07

Re: Making WAL receiver startup rely on GUC context for primary_conninfo and primary_slot_name

On Wed, Jan 09, 2019 at 06:00:23AM -0800, Donald Dong wrote: > I wonder why do we need to have this addition? > > src/backend/replication/walreceiver.c > + memset(walrcv->slotname, 0, NAMEDATALEN); > + if (PrimarySlotName) > + strlcpy((char *) walrcv->slotname, PrimarySlo

Re: some minor comment fix in md.c

On Wed, Jan 09, 2019 at 08:30:53AM +, Jamison, Kirk wrote: > Here are few minor fix in md.c comments > src/backend/storage/smgr/md.c > > 1. @L174 - removed the unnecessary word "is". > - […] Note that this is breaks mdnblocks() and related functionality [...] > + […] Note that this breaks mdnb

Re: A few new options for vacuumdb

On Wed, Jan 9, 2019 at 1:33 PM Michael Paquier wrote: > > On Wed, Jan 09, 2019 at 10:33:00AM +0900, Masahiko Sawada wrote: > > Since pg_(total)_relation_size() returns 0 for parent table the > > specifying the parent table to vacuumdb with --min-relation-size > > always does nothing. Maybe we will

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

John Naylor writes: > On Wed, Jan 9, 2019 at 5:33 PM Tom Lane wrote: >> really need here. We could go with "[no-]case-insensitive", perhaps. >> Or "[no-]case-fold", which is at least a little shorter and less >> double-negative-y. > I'd be in favor of --[no-]case-fold. Yeah, I like that better

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

On Wed, Jan 9, 2019 at 5:33 PM Tom Lane wrote: > really need here. We could go with "[no-]case-insensitive", perhaps. > Or "[no-]case-fold", which is at least a little shorter and less > double-negative-y. I'd be in favor of --[no-]case-fold. On Tue, Jan 8, 2019 at 5:53 PM Tom Lane wrote: > I

Re: BUG #15446: Crash on ALTER TABLE

On 1/8/19 7:41 PM, Andrew Dunstan wrote: > On 1/8/19 4:48 PM, Dean Rasheed wrote: >> On Tue, 8 Jan 2019 at 19:34, Andrew Dunstan >> wrote: >>> Here's a patch that I think cures the problem. >>> >> Hmm, that doesn't quite work because the table might not actually be >> rewritten as a result of the

Re: [HACKERS] pgbench - allow to store select results into variables

Here are my proposed final changes. I noticed that you were allocating the prefixes for all cases even when there were no cset/gset in the command; I changed it to delay the allocation until needed. I also noticed you were skipping the Meta enum dance for no good reason; added that makes conditio

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

John Naylor writes: > On Tue, Jan 8, 2019 at 5:31 PM Tom Lane wrote: >> The length macro was readily available there so I used it. AFAIR >> that wasn't true elsewhere, though I might've missed something. >> It's pretty much just belt-and-suspenders coding anyway, since all >> those arrays are ma

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

John Naylor writes: > On Wed, Jan 9, 2019 at 2:04 PM Tom Lane wrote: >> Now the impedance mismatch about case sensitivity is handled with >> my $f = PerfectHash::generate_hash_function(\@keywords, $funcname, >> case_insensitive => !$case_sensitive); >> which is at least a little clea

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

John Naylor writes: > On Wed, Jan 9, 2019 at 2:44 PM Tom Lane wrote: >> [patch to shrink oid index] > It would help maintaining its newfound sveltness if we warned if a > higher oid was assigned, as in the attached. I used 6200 as a soft > limit, but that could be anything similiar. I think the

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

On Wed, Jan 9, 2019 at 2:44 PM Tom Lane wrote: > [patch to shrink oid index] It would help maintaining its newfound sveltness if we warned if a higher oid was assigned, as in the attached. I used 6200 as a soft limit, but that could be anything similiar. -- John Naylorhttps://ww

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

On Tue, Jan 8, 2019 at 5:31 PM Tom Lane wrote: > > John Naylor writes: > > In the committed keyword patch, I noticed that in common/keywords.c, > > the array length is defined with > > ScanKeywordCategories[SCANKEYWORDS_NUM_KEYWORDS] > > but other keyword arrays just have ...[]. Is there a reason

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

On Wed, Jan 9, 2019 at 2:04 PM Tom Lane wrote: > > I wrote: > > John Naylor writes: > >> -There is a bit of a cognitive clash between $case_sensitive in > >> gen_keywordlist.pl and $case_insensitive in PerfectHash.pm. They each > >> make sense in their own file, but might it be worth using one or

Re: insensitive collations

Peter Eisentraut wrote: > > =# select n from (values ('été' collate "myfr"), ('ete')) x(n) > > group by 1 order by 1 ; > > n > > - > > ete > > (1 row) > > > > =# select n from (values ('été' collate "myfr"), ('ete')) x(n) > > group by 1 order by 1 desc; > > n > > - >

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

On Wed, Jan 09, 2019 at 02:04:15PM -0500, Tom Lane wrote: > Also, in view of finding that the original multiplier choices failed > on the fmgr oid problem, I spent a little effort making the code > able to try more combinations of hash multipliers and seeds. It'd > be nice to have some theory rath

RE: Timeout parameters

Hello, > To wrap up, the relevant parameters work like this: > * TCP keepalive and TCP user (retransmission) timeout: for network problems > * statement_timeout: for long-running queries > * socket_timeout (or send/recv_timeout): for saturated servers Takayuki Tsunakawa, could you provide wide

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

Andres Freund writes: > On 2019-01-09 15:03:35 -0500, Tom Lane wrote: >> (Speaking of which, I've been wondering for awhile if libpq ought not >> obtain the OIDs of lo_create and friends by #including fmgroids.h >> instead of doing a runtime query on every connection. If we did that, >> we'd be f

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

Hi, On 2019-01-09 15:03:35 -0500, Tom Lane wrote: > Alvaro Herrera writes: > > On 2019-Jan-09, Tom Lane wrote: > >> We could make the index table still smaller if we wanted to reassign > >> a couple dozen high-numbered functions down to lower OIDs, but I dunno > >> if it's worth the trouble. It

Re: New vacuum option to do only freezing

Hi, On 1/8/19, 7:03 PM, "Masahiko Sawada" wrote: > Attached the updated version patch incorporated all comments I got. Thanks for the new patch! > * Instead of freezing xmax I've changed the behaviour of the new > option (DISABLE_INDEX_CLEANUP) so that it sets dead tuples as dead > instead of a

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

Alvaro Herrera writes: > On 2019-Jan-09, Tom Lane wrote: >> We could make the index table still smaller if we wanted to reassign >> a couple dozen high-numbered functions down to lower OIDs, but I dunno >> if it's worth the trouble. It certainly isn't from a performance >> standpoint, because tho

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

Andres Freund writes: > On 2019-01-09 14:44:24 -0500, Tom Lane wrote: >> /* fast lookup only possible if original oid still assigned */ >> -if (id >= FirstGenbkiObjectId) >> +if (id > fmgr_last_builtin_oid) >> return NULL; > An extern reference here will make the code a bit l

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

Hi, On 2019-01-09 14:44:24 -0500, Tom Lane wrote: > I wrote: > > Also, I fail to understand why fmgr_builtin_oid_index has 1 entries > > anyway. We could easily have fmgrtab.c expose the last actually assigned > > builtin function OID (presently 6121) and make the index array only > > that bi

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

On 2019-Jan-09, Tom Lane wrote: > We could make the index table still smaller if we wanted to reassign > a couple dozen high-numbered functions down to lower OIDs, but I dunno > if it's worth the trouble. It certainly isn't from a performance > standpoint, because those unused entry ranges will n

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

I wrote: > Also, I fail to understand why fmgr_builtin_oid_index has 1 entries > anyway. We could easily have fmgrtab.c expose the last actually assigned > builtin function OID (presently 6121) and make the index array only > that big, which just about eliminates the space advantage completely

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

I wrote: > John Naylor writes: >> -There is a bit of a cognitive clash between $case_sensitive in >> gen_keywordlist.pl and $case_insensitive in PerfectHash.pm. They each >> make sense in their own file, but might it be worth using one or the >> other? > Yeah, dunno. It seems to make sense for t

Re: insensitive collations

On 12/28/18 9:55 AM, Peter Eisentraut wrote: Here is an updated patch. I have updated the naming to "deterministic", as discussed. Maybe this is orthogonal and best handled elsewhere but have you when working with string equality given unicode normalization forms[1] any thought? I feel there

Re: A few new options for vacuumdb

On 1/8/19, 10:34 PM, "Michael Paquier" wrote: > On Wed, Jan 09, 2019 at 10:33:00AM +0900, Masahiko Sawada wrote: >> Since pg_(total)_relation_size() returns 0 for parent table the >> specifying the parent table to vacuumdb with --min-relation-size >> always does nothing. Maybe we will need to deal

Re: Displaying and dumping of table access methods

Hi, On 2019-01-09 18:26:16 +0530, Amit Kapila wrote: > On Tue, Jan 8, 2019 at 11:04 PM Andres Freund wrote: > +1. > > > Don't like it > > too much, but it seems better than the alternative. I wonder if we want > > one for multiple regression related issues, or whether one specifically > > about

Re: FETCH FIRST clause PERCENT option

On 1/9/19 4:43 PM, Surafel Temesgen wrote: > > > On Wed, Jan 9, 2019 at 5:38 PM Tomas Vondra > mailto:tomas.von...@2ndquadrant.com>> wrote: > > > It's hard to say what exactly are you doing, because you haven't shared > any code nor examples. > > > okay i attach in progress patch >

Re: Misleading panic message in backend/access/transam/xlog.c

Hi, On 2019-01-09 12:06:39 +0100, Michael Banck wrote: > there was a report in #postgresql recently about a crash on Google Cloud > SQL with the somewhat misleading message "could not write to log file" > while in fact it was the xlog/wal: > > |PANIC: could not write to log file 00010196

Re: FETCH FIRST clause PERCENT option

On Wed, Jan 9, 2019 at 5:38 PM Tomas Vondra wrote: > > It's hard to say what exactly are you doing, because you haven't shared > any code nor examples. okay i attach in progress patch regards Surafel diff --git a/doc/src/sgml/ref/select.sgml b/doc/src/sgml/ref/select.sgml index 4db8142afa..849

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

On 1/8/19 3:18 PM, Dean Rasheed wrote: > On Mon, 7 Jan 2019 at 00:45, Tomas Vondra > wrote: >> >> FWIW the main unsolved issue (at least on the MCV part) is how it >> decides which items to keep in the list. >> >> As explained in [1], in the multivariate case we can't simply look at >> the gro

Re: [HACKERS] pgbench - allow to store select results into variables

Attached v27 is the same but with an improved documentation where full examples, with and without prefix, are provided for both cset & gset. I have already made changes on top of v26. Can you please submit this as a delta patch on top of v26? Attached. -- Fabien.diff --git a/doc/src/sgml/r

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

On Wed, Jan 9, 2019 at 7:33 AM Mithun Cy wrote: > 2. v11-Every-other-page and v11-last-page patches improve the > performance from base. > 3. IMHO v11-Every-other-page would be ideal to consider it improves > the performance and also to an extent avoid expansion if space is > already available. G

Re: speeding up planning with partitions

On Wed, Jan 9, 2019 at 11:41 PM Alvaro Herrera wrote: > > From 3b86331dd5a2368adc39c9fef92f3dd09d817a08 Mon Sep 17 00:00:00 2001 > > From: amit > > Date: Wed, 7 Nov 2018 16:51:31 +0900 > > Subject: [PATCH v11 4/6] Move inheritance expansion code into its own file > > I wonder if it would make sen

Re: speeding up planning with partitions

> From 3b86331dd5a2368adc39c9fef92f3dd09d817a08 Mon Sep 17 00:00:00 2001 > From: amit > Date: Wed, 7 Nov 2018 16:51:31 +0900 > Subject: [PATCH v11 4/6] Move inheritance expansion code into its own file I wonder if it would make sense to commit 0004 ahead of the rest? To avoid carrying this huge

Re: FETCH FIRST clause PERCENT option

On 1/9/19 7:09 AM, Surafel Temesgen wrote: > > > On Sun, Jan 6, 2019 at 5:51 PM Tomas Vondra > mailto:tomas.von...@2ndquadrant.com>> wrote: > > > On 1/6/19 12:40 PM, Surafel Temesgen wrote: > > > > > > On Fri, Jan 4, 2019 at 5:27 PM Tomas Vondra > >

Re: libpq compression

On 09.01.2019 13:25, Iwata, Aya wrote: Hi, I agree with the critiques from Robbie Harwood and Michael Paquier that the way in that compression is being hooked into the existing architecture looks like a kludge. I'm not sure I know exactly how it should be done, but the current approach doesn

Re: Making WAL receiver startup rely on GUC context for primary_conninfo and primary_slot_name

Hi Michael, Thank you for the information! > On Dec 11, 2018, at 9:55 PM, Michael Paquier wrote: > > Well, the conninfo and slot name accessible to the user are the values > available only once the information of the WAL receiver in shared memory > is ready to be displayed. Relying more on the

Re: emacs configuration for new perltidy settings

On 1/8/19 8:44 PM, Noah Misch wrote: > On Tue, Jan 08, 2019 at 08:17:43AM -0500, Andrew Dunstan wrote: >> On 1/3/19 12:53 AM, Noah Misch wrote: >>> If I run perltidy on 60d9979, then run perl-mode indent, the diff between >>> the >>> perltidy run and perl-mode indent run is: >>> 129 files chang

Re: [HACKERS] pgbench - allow to store select results into variables

On 2019-Jan-09, Fabien COELHO wrote: > > Attached a v26 with I hope everything ok, but for the documentation that > > I'm unsure how to improve. > > Attached v27 is the same but with an improved documentation where full > examples, with and without prefix, are provided for both cset & gset. I ha

Re: Displaying and dumping of table access methods

On Tue, Jan 8, 2019 at 11:04 PM Andres Freund wrote: > > Hi, > > On 2019-01-08 11:30:56 +0100, Peter Eisentraut wrote: > > On 08/01/2019 00:56, Andres Freund wrote: > > > A patch at [2] adds display of a table's access method to \d+ - but that > > > means that running the tests with a different de

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

Hi John Naylor, On Tue, Jan 8, 2019 at 2:27 AM John Naylor wrote: > I've attached two patches for testing. Each one applies on top of the > current patch. Thanks for the patch, I did a quick test for both of the patches same tests as in [1], now for fillfactors 20, 70, 100 (Note for HEAP_FSM_CREA

Re: [PROPOSAL] Shared Ispell dictionaries

On 01.10.2018 12:22, Arthur Zakirov wrote: On Thu, Jun 14, 2018 at 11:40:17AM +0300, Arthur Zakirov wrote: I attached new version of the patch. The patch still applies to HEAD. I moved it to the next commitfest. Here is the rebased patch. I also updated copyright in ts_shared.h and ts_shar

Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0

Amit-san, (2019/01/09 9:30), Amit Langote wrote: (sorry about the repeated email, but my previous attempt failed due to trying to send to the -hackers and -performance lists at the same time, so trying again after removing -performance) Thanks! (Actually, I also failed to send my post to thos

Re: Misleading panic message in backend/access/transam/xlog.c

On Wed, Jan 9, 2019 at 12:06 PM Michael Banck wrote: > Hi, > > there was a report in #postgresql recently about a crash on Google Cloud > SQL with the somewhat misleading message "could not write to log file" > while in fact it was the xlog/wal: > > |PANIC: could not write to log file 000100

Re: ALTER TABLE with multiple SET NOT NULL

Hello I investigate this bug and found reason: > alter table t1 add column b float8 not null default random(), add primary > key(a); Here we call ATController (src/backend/commands/tablecmds.c) with two cmds: AT_AddColumn and AT_AddIndex Then we go to phase 2 in ATRewriteCatalogs: - succesful

Misleading panic message in backend/access/transam/xlog.c

Hi, there was a report in #postgresql recently about a crash on Google Cloud SQL with the somewhat misleading message "could not write to log file" while in fact it was the xlog/wal: |PANIC: could not write to log file 000101960054 at offset | 13279232, length 245760: Cannot allocate

Re: libpq compression

> On Wed, Jan 9, 2019 at 11:25 AM Iwata, Aya wrote: > > This thread seems to be stopped. > In last e-mail, Dmitry suggest to update the patch that implements the > function in another way, and as far as I saw, he has not updated patch yet. Yep, I'm still working on it, hopefully I can submit som

RE: libpq compression

Hi, > > I agree with the critiques from Robbie Harwood and Michael Paquier > > that the way in that compression is being hooked into the existing > > architecture looks like a kludge. I'm not sure I know exactly how it > > should be done, but the current approach doesn't look natural; it > > loo

problems with foreign keys on partitioned tables

Hi, I noticed a couple of problems with foreign keys on partitioned tables. 1. Foreign keys of partitions stop working correctly after being detached from the parent table create table pk (a int primary key); create table p (a int) partition by list (a); create table p1 partition of p for values

Re: port of INSTALL file generation to XSLT

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:tested, failed Hi! I tested this. Patch applied cleanly and INSTALL file was produced.

Re: Displaying and dumping of table access methods

> On Tue, Jan 8, 2019 at 6:34 PM Andres Freund wrote: > > On 2019-01-08 11:30:56 +0100, Peter Eisentraut wrote: > > On 08/01/2019 00:56, Andres Freund wrote: > > > A patch at [2] adds display of a table's access method to \d+ - but that > > > means that running the tests with a different default t

RE: Problem during Windows service start

Michael Paquier wrote: > You should register this patch to the next commit fest in the section for bug > fixes to not lose sight of it; Thank you for picking up my post. I registered to the next CF. > I haven't put much thoughts into what you propose here, but this status > message is not rea

some minor comment fix in md.c

Hi, Here are few minor fix in md.c comments src/backend/storage/smgr/md.c 1. @L174 - removed the unnecessary word "is". - […] Note that this is breaks mdnblocks() and related functionality [...] + […] Note that this breaks mdnblocks() and related functionality [...] 2. @L885 - grammar fix - We u

Re: additional foreign key test coverage

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: not tested Spec compliant: not tested Documentation:not tested Hi! I tested this patch and it applied cleanly and all tests passed. I h

Re: MERGE SQL statement for PG12

Hi! Looking at the commitfest as a novice contributor I was searching for patches to review without any reviewers set. And because I just spend some time and made a patch improving how REFRESH MATERIALIZED VIEW CONCURRENTLY works (does INSERTs/UPDATEs/DELETEs instead of just DELETEs/INSERTs) wh