Re: [HACKERS] UPDATE of partition key

On 4 January 2018 at 02:52, David Rowley wrote: > I'll try to look at the tests tomorrow and also do some testing. So > far I've only read the code and the docs. There are a few more things I noticed on another pass I made today: 20. "carried" -> "carried out the" + would have identified

Re: TupleDescCopy doesn't clear atthasdef, attnotnull, attidentity

I wrote: > The reason I note this explicitly is that I don't find it to be > entirely safe. If ATTRIBUTE_FIXED_PART_SIZE were less than > sizeof(FormData_pg_attribute) due to alignment padding at the end of > the struct, I think we would get some valgrind complaints about copying > uninitialized d

RE: Libpq support to connect to standby server as priority

From: Jing Wang [mailto:jingwang...@gmail.com] > This is a proposal that let libpq support 'prefer-read' option in > target_session_attrs in pg_conn. The 'prefer-read' means the libpq will > try to connect to a 'read-only' server firstly from the multiple server > addresses. If failed to connect to

Re: pgbench - add \if support

Another rebase to try to please the patch tester. -- Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml index 1519fe7..7068063 100644 --- a/doc/src/sgml/ref/pgbench.sgml +++ b/doc/src/sgml/ref/pgbench.sgml @@ -895,6 +895,21 @@ pgbench options d + +

Re: Enhance pg_stat_wal_receiver view to display connected host

On Thu, Jan 4, 2018 at 11:53 AM, Michael Paquier wrote: > On Wed, Jan 03, 2018 at 06:48:07PM +1100, Haribabu Kommi wrote: > > On Wed, Jan 3, 2018 at 12:25 PM, Haribabu Kommi < > kommi.harib...@gmail.com> > > Last patch has undefined symbol, corrected patch attached. > Thanks for the review. +

Re: [HACKERS] pgbench more operators & functions

SQL doesn't evaluate unneeded arguments: Here is a version with some lazy evaluation for and, or & case. v23 is a rebase. -- Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml index 1519fe7..3dd492c 100644 --- a/doc/src/sgml/ref/pgbench.sgml +++ b/doc/src/sgml

Re: [HACKERS] UPDATE of partition key

Robert, for tracking purpose, below I have consolidated your review items on which we are yet to conclude. Let me know if you have more comments on the points which I made. -- 1. ExecUpdate() needs to revert back tcs_map value changed by ExecInsert() -- >> + /* >>

Re: [HACKERS] Pluggable storage

On Thu, Jan 4, 2018 at 10:00 AM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Wed, Jan 3, 2018 at 10:08 AM, Haribabu Kommi > wrote: > >> >> On Wed, Dec 27, 2017 at 11:33 PM, Alexander Korotkov < >> a.korot...@postgrespro.ru> wrote: >> >>> >>> Also, I appreciate that now tuple_inser

Libpq support to connect to standby server as priority

Hi Hackers, This is a proposal that let libpq support 'prefer-read' option in target_session_attrs in pg_conn. The 'prefer-read' means the libpq will try to connect to a 'read-only' server firstly from the multiple server addresses. If failed to connect to the 'read-only' server then it will try t

Re: Observations in Parallel Append

On Thu, Jan 4, 2018 at 9:06 AM, Robert Haas wrote: > On Tue, Jan 2, 2018 at 11:11 PM, Amit Kapila wrote: >> Attached, please find the patch which fixes this issue (Thanks to >> Dilip for helping me in identifying the above case and fix). I have >> also modified the comment atop function >> choos

Re: Observations in Parallel Append

On Tue, Jan 2, 2018 at 11:11 PM, Amit Kapila wrote: > Attached, please find the patch which fixes this issue (Thanks to > Dilip for helping me in identifying the above case and fix). I have > also modified the comment atop function > choose_next_subplan_for_worker() as discussed above. The chang

Re: [HACKERS] [PATCH] Generic type subscripting

Dmitry Dolgov <9erthali...@gmail.com> writes: > Another rebased version of this patch. Apologies for not having paid attention to this patch for so long. Coming back to it now, I wonder what happened to the plan to separate assignment and fetch into two different node types. I can see that that d

Re: January CommitFest is underway!

On Wed, Jan 03, 2018 at 07:38:33PM -0500, Stephen Frost wrote: > * Michael Paquier (michael.paqu...@gmail.com) wrote: > > On Wed, Jan 03, 2018 at 06:38:53PM -0500, Stephen Frost wrote: > > > The January commitfest (the second-to-last of the PG11 release cycle, > > > which likely means lots of big p

Re: LIKE foo% optimization easily defeated by OR?

On 04/01/18 12:06, Greg Stark wrote: I think I found the bug 18" from the monitor I'll just be over here with the paper bag over my head mumbling about running RESET ALL before running tests... I think Linus has patented the use of a paper bag in your situation... So you might have to pay

Re: Enhance pg_stat_wal_receiver view to display connected host

On Wed, Jan 03, 2018 at 06:48:07PM +1100, Haribabu Kommi wrote: > On Wed, Jan 3, 2018 at 12:25 PM, Haribabu Kommi > Last patch has undefined symbol, corrected patch attached. + memset(walrcv->host, 0, NAMEDATALEN); + if (host) + strlcpy((char *) walrcv->host, host, NAMED

Re: January CommitFest is underway!

Michael, * Michael Paquier (michael.paqu...@gmail.com) wrote: > On Wed, Jan 03, 2018 at 06:38:53PM -0500, Stephen Frost wrote: > > The January commitfest (the second-to-last of the PG11 release cycle, > > which likely means lots of big patches landing, since big patches > > aren't allowed to be fi

Re: January CommitFest is underway!

On Wed, Jan 03, 2018 at 06:38:53PM -0500, Stephen Frost wrote: > The January commitfest (the second-to-last of the PG11 release cycle, > which likely means lots of big patches landing, since big patches > aren't allowed to be first seen in the last commitfest before feature > freeze... ;) has offic

Re: January CommitFest is underway!

Stephen Frost writes: > The January commitfest (the second-to-last of the PG11 release cycle, > which likely means lots of big patches landing, since big patches > aren't allowed to be first seen in the last commitfest before feature > freeze... ;) has officially begun and we have a lot of work ah

Re: LIKE foo% optimization easily defeated by OR?

On Thu, Jan 4, 2018 at 2:06 AM, Greg Stark wrote: > I think I found the bug 18" from the monitor I'll just be over > here with the paper bag over my head mumbling about running RESET ALL > before running tests... > It's no problem. That sometimes happens to everybody. -- Alexander Koro

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

On 12/20/2017 02:44 AM, Mark Dilger wrote: > >> On Dec 19, 2017, at 4:31 PM, Tomas Vondra >> wrote: >> >> Hi, >> >> On 12/19/2017 08:17 PM, Mark Dilger wrote: >>> >>> I tested your latest patches on my mac os x laptop and got one test >>> failure due to the results of 'explain' coming up diffe

January CommitFest is underway!

Greetings! The January commitfest (the second-to-last of the PG11 release cycle, which likely means lots of big patches landing, since big patches aren't allowed to be first seen in the last commitfest before feature freeze... ;) has officially begun and we have a lot of work ahead of us. To the

Re: TupleDescCopy doesn't clear atthasdef, attnotnull, attidentity

Thomas Munro writes: > If there is any system where sizeof(FormData_pg_attribute) != > (offsetof(FormData_pg_attribute,attcollation) + sizeof(Oid)), won't > load_relcache_init_file() get upset? Oh, I see it would just go to > read_failed and then "do it the hard way". Right, so we needn't includ

Re: TupleDescCopy doesn't clear atthasdef, attnotnull, attidentity

On Thu, Jan 4, 2018 at 12:29 PM, Thomas Munro wrote: > If there is any system where sizeof(FormData_pg_attribute) != > (offsetof(FormData_pg_attribute,attcollation) + sizeof(Oid)), won't > load_relcache_init_file() get upset? Oh, I see it would just go to > read_failed and then "do it the hard wa

Re: TupleDescCopy doesn't clear atthasdef, attnotnull, attidentity

On Thu, Jan 4, 2018 at 12:01 PM, Tom Lane wrote: > Thomas Munro writes: >> Andrew Gierth complained off-list that TupleDescCopy() doesn't clear >> atthasdef. Yeah, that's an oversight. The function is new in commit >> cc5f81366c36 and was written by me to support "flat" (pointer-free) >> tuple

Re: CFM for January commitfest?

Ryan, * Ryan Murphy (ryanfmur...@gmail.com) wrote: > > > Yes, I have interest to help. I do not have the experience of how to do > > the > > > whole, but I believe that if I help you (you as CFM) in the future I can > > > assume this activity when necessary. > > Hi Stephen. Thanks for being the

Re: CFM for January commitfest?

> > Yes, I have interest to help. I do not have the experience of how to do > the > > whole, but I believe that if I help you (you as CFM) in the future I can > > assume this activity when necessary. Hi Stephen. Thanks for being the CFM! I'm also interested in helping. Last commitfest I revie

Re: LIKE foo% optimization easily defeated by OR?

I think I found the bug 18" from the monitor I'll just be over here with the paper bag over my head mumbling about running RESET ALL before running tests...

Re: LIKE foo% optimization easily defeated by OR?

Greg Stark writes: > On 3 January 2018 at 22:34, Alexander Korotkov > wrote: >> I've checked similar case on database with PostgreSQL mailing lists. It >> works for me. > Wow that's fascinating. I wonder why it's not kicking in for me. text vs varchar maybe? regards, t

Re: TupleDescCopy doesn't clear atthasdef, attnotnull, attidentity

Thomas Munro writes: > Andrew Gierth complained off-list that TupleDescCopy() doesn't clear > atthasdef. Yeah, that's an oversight. The function is new in commit > cc5f81366c36 and was written by me to support "flat" (pointer-free) > tuple descriptors for use in DSM. Following the example of >

Re: [HACKERS] Pluggable storage

On Wed, Jan 3, 2018 at 10:08 AM, Haribabu Kommi wrote: > > On Wed, Dec 27, 2017 at 11:33 PM, Alexander Korotkov < > a.korot...@postgrespro.ru> wrote: > >> >> Also, I appreciate that now tuple_insert() and tuple_update() methods are >> responsible for inserting index tuples. This unleash pluggabl

Re: LIKE foo% optimization easily defeated by OR?

On 3 January 2018 at 22:34, Alexander Korotkov wrote: > I've checked similar case on database with PostgreSQL mailing lists. It > works for me. Wow that's fascinating. I wonder why it's not kicking in for me. I have checked with enable_seqscan=off but I'll have to do some more investigations. I

Re: LIKE foo% optimization easily defeated by OR?

Hi, Greg! On Thu, Jan 4, 2018 at 12:57 AM, Greg Stark wrote: > Our database has a query that looks like this -- note the OR between a > simple equality qual and a LIKE qual: > > => explain SELECT 1 AS one FROM "redirect_routes" WHERE > redirect_routes.path = 'foobar' OR redirect_routes.path LI

Re: [PATCH] Comment typo in get_collation_name() comment

Alvaro Herrera writes: > The problem is that pg-hackers is now too much traffic, so unregistered > patches customarily fall through cracks. Recommendation is to register > all patches to avoid that problem. I shall keep that in mind and register even trivial patches in future if they don't get

Re: compress method for spgist - 2

On Thu, Jan 4, 2018 at 1:17 AM, Dagfinn Ilmari Mannsåker wrote: > Teodor Sigaev writes: > > >> > >> Now, this patch is ready for committer from my point of view. > > > > Thank you, pushed > > This patch added two copies of the poly_ops row to the "Built-in SP-GiST > Operator Classes" table in sp

Re: [Patch] Make block and file size for WAL and relations defined at cluster creation

Hello, 2018-01-03 21:51 GMT+01:00 Andres Freund : > Hi, > > On 2018-01-03 21:43:51 +0100, Remi Colinet wrote: > > - we may test different combinations of file and block sizes, for the > > relation and the WAL in order to have the better performances of the > server. > > Avoiding a compilation for

Re: compress method for spgist - 2

Teodor Sigaev writes: >> >> Now, this patch is ready for committer from my point of view. > > Thank you, pushed This patch added two copies of the poly_ops row to the "Built-in SP-GiST Operator Classes" table in spgist.sgml. The attached patched removes one of them. - ilmari -- - Twitter seem

Re: [PATCH] Comment typo in get_collation_name() comment

Dagfinn Ilmari Mannsåker wrote: > ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes: > > > Hi Hackers, > > > > The comment for get_collation_name() seems to have been copy-pasted from > > get_constraint_name(), but missed one s/constraint/collation/. > > > > Patch attached. > > Bump? Do I need

Re: [Patch v2] Make block and file size for WAL and relations defined at cluster creation

Remi Colinet wrote: > Hello, > > This is version 2 of the patch to make the file and block sizes for WAL and > relations, run-time configurable at initdb. I don't think this works, since we have a rule that pallocs are prohibited within critical section and I see that your patch changes some stac

Re: [PATCH] Comment typo in get_collation_name() comment

ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes: > Hi Hackers, > > The comment for get_collation_name() seems to have been copy-pasted from > get_constraint_name(), but missed one s/constraint/collation/. > > Patch attached. Bump? Do I need to add this patch to the next commitfest? I though

LIKE foo% optimization easily defeated by OR?

Our database has a query that looks like this -- note the OR between a simple equality qual and a LIKE qual: => explain SELECT 1 AS one FROM "redirect_routes" WHERE redirect_routes.path = 'foobar' OR redirect_routes.path LIKE 'foobar/%'; QUERY PLAN ---

Re: CFM for January commitfest?

Greetings Gerdan, * Gerdan Rezende dos Santos (ger...@gmail.com) wrote: > On Wed, 3 Jan 2018 at 00:53 Stephen Frost wrote: > > On the PG mailing lists, we'd prefer if you didn't top-post but instead > > respond in-line (as I'll do below). > > > > * Gerdan Rezende dos Santos (ger...@gmail.com) wro

Re: CFM for January commitfest?

All, * Stephen Frost (sfr...@snowman.net) wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > Now that the January fest has nominally started, we need somebody > > to act as CF manager. Any volunteers? > > > > (If someone already did volunteer and I missed it, my apologies.) > > With the list m

Re: [Patch] Make block and file size for WAL and relations defined at cluster creation

On Wed, Jan 3, 2018 at 3:43 PM, Remi Colinet wrote: > Justifications are: I think this is all missing the point. If varying the block size (or whatever) is beneficial, then having it configurable at initdb is clearly useful. But, as Andres says, you haven't submitted any evidence that this is t

Re: [HACKERS] Proposal: Local indexes for partitioned table

Peter Eisentraut wrote: > On 12/29/17 15:38, Alvaro Herrera wrote: > > I just realized there's a further problem in the area: when a partition > > is detached from its parent, its indexes are not made independent of the > > indexes on parent. So they can't be dropped on their own (booh!); and > >

Re: [Patch] Make block and file size for WAL and relations defined at cluster creation

Hi, On 2018-01-03 21:43:51 +0100, Remi Colinet wrote: > - we may test different combinations of file and block sizes, for the > relation and the WAL in order to have the better performances of the server. > Avoiding a compilation for each combination of values seems to make sense. That's somethin

Re: [HACKERS] Proposal: Local indexes for partitioned table

On 12/29/17 15:38, Alvaro Herrera wrote: > I just realized there's a further problem in the area: when a partition > is detached from its parent, its indexes are not made independent of the > indexes on parent. So they can't be dropped on their own (booh!); and > dropping the index on the former p

Re: AS OF queries

Maybe that a simple check of the asof_timestamp value like: asof_timestamp >= now() - time_travel_period AND asof_timestamp >= latest_table_ddl would permit to raise a warning or an error message saying that query result can not be garanteed with this asof_timestamp value. latest_table_ddl bei

Re: [Patch] Make block and file size for WAL and relations defined at cluster creation

Robert, Justifications are: - we may test different combinations of file and block sizes, for the relation and the WAL in order to have the better performances of the server. Avoiding a compilation for each combination of values seems to make sense. - the same binary can be used on the same host

Re: [HACKERS] Issues with logical replication

Alvaro Herrera wrote: > Will push this shortly after lunch. Pushed. Will you (Konstantin, Stas, Masahiko) please verify that after this commit all the problems reported with logical replication are fixed? Thanks -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Developm

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On 01/03/2018 09:06 PM, Tomas Vondra wrote: > Hi, > > attached is v4 of the patch series, with a couple of changes: > > 1) Fixes a bunch of bugs I discovered during stress testing. > > I'm not going to go into details, but the main fixes are related to > properly updating progress from the wor

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

Hi, attached is v4 of the patch series, with a couple of changes: 1) Fixes a bunch of bugs I discovered during stress testing. I'm not going to go into details, but the main fixes are related to properly updating progress from the worker, and not streaming when creating the logical replication s

Re: to_timestamp TZH and TZM format specifiers

Vik Fearing writes: > On 01/03/2018 08:39 PM, Tom Lane wrote: >> Vik Fearing writes: >>> Shouldn't this support TZS or something for seconds? >> According to the docs I cited upthread, there's no such field type >> in Oracle. > So what? Well, the function is meant to be Oracle-compatible, so w

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On 01/02/2018 04:07 PM, Peter Eisentraut wrote: > On 12/22/17 23:57, Tomas Vondra wrote: >> PART 1: adding logical_work_mem memory limit (0001) >> --- > > The documentation in this patch contains some references to later > features (streaming). Pe

Re: to_timestamp TZH and TZM format specifiers

On 01/03/2018 08:39 PM, Tom Lane wrote: > Vik Fearing writes: >> Shouldn't this support TZS or something for seconds? > > According to the docs I cited upthread, there's no such field type > in Oracle. So what? -- Vik Fearing +33 6 46 75 15 36 http://2ndQ

Re: to_timestamp TZH and TZM format specifiers

Vik Fearing writes: > Shouldn't this support TZS or something for seconds? According to the docs I cited upthread, there's no such field type in Oracle. regards, tom lane

Programmatically accessing selection predicates

Hi, In order to run some cardinality estimation experiments I'm hoping to access the raw values for selections predicates from within the calc_joinrel_size_estimate method (in costsize.c). For example, if the restriction WHERE name_attr = "example_str" appears in the query, I'd like to get the "

Re: Better testing coverage and unified coding for plpgsql loops

Alvaro Herrera writes: > Tom Lane wrote: >> I really think we should stick with the macro implementation, unless >> somebody wants to do some actual investigation to prove that a >> function implementation imposes negligible cost. > I don't really care too much about the macro-or-function side of

Re: to_timestamp TZH and TZM format specifiers

On 01/03/2018 07:03 PM, Andrew Dunstan wrote: > > This small and simple standalone patch extracted from the SQL/JSON work > would allow the user to supply a string with a time zone specified as > hh:mm thus: > > > SELECT to_timestamp('2011-12-18 11:38 -05:20', '-MM-DD HH12:MI > TZH:T

Re: Better testing coverage and unified coding for plpgsql loops

Tom Lane wrote: > I really think we should stick with the macro implementation, unless > somebody wants to do some actual investigation to prove that a > function implementation imposes negligible cost. I'm not prepared > to just assume that, especially not after the work I just did on > plpgsql

Re: to_timestamp TZH and TZM format specifiers

Andrew Dunstan writes: > On 01/03/2018 01:34 PM, Tom Lane wrote: >> BTW, I had not known this before, but according to the page I'm >> looking at >> https://docs.oracle.com/database/121/SQLRF/sql_elements004.htm#SQLRF00212 >> Oracle also supports "TZD" to mean a time zone abbreviation (their >> ex

Re: to_timestamp TZH and TZM format specifiers

On 01/03/2018 01:34 PM, Tom Lane wrote: > Andrew Dunstan writes: >> This small and simple standalone patch extracted from the SQL/JSON work >> would allow the user to supply a string with a time zone specified as >> hh:mm thus: >> SELECT to_timestamp('2011-12-18 11:38 -05:20', '-MM-DD HH

Re: Better testing coverage and unified coding for plpgsql loops

On Wed, Jan 3, 2018 at 1:53 PM, Tom Lane wrote: > I thought about this a bit harder and realized that if we make it > a function, we will have to pass "rc" by reference since the function > needs to change it in some cases. That might have no impact if the > compiler is smart enough, but I expect

Re: Better testing coverage and unified coding for plpgsql loops

Robert Haas writes: > On Tue, Jan 2, 2018 at 10:08 AM, Tom Lane wrote: >> It could be converted into a function returning bool, a la >> if (!loop_rc_processing(...)) >> break; > I prefer writing this sort of thing using a function call and > dispatching on the return value, as

Re: Better testing coverage and unified coding for plpgsql loops

On Tue, Jan 2, 2018 at 10:08 AM, Tom Lane wrote: > Alvaro Herrera writes: >> Darafei "Komяpa" Praliaskouski wrote: >>> - can this macro become a function? > >> The "exit_action" argument makes it tough. It can probably be done -- >> it seems to require contorting the one callsite that uses "goto

Re: to_timestamp TZH and TZM format specifiers

Andrew Dunstan writes: > This small and simple standalone patch extracted from the SQL/JSON work > would allow the user to supply a string with a time zone specified as > hh:mm thus: > SELECT to_timestamp('2011-12-18 11:38 -05:20', '-MM-DD HH12:MI > TZH:TZM'); > to_timest

to_timestamp TZH and TZM format specifiers

This small and simple standalone patch extracted from the SQL/JSON work would allow the user to supply a string with a time zone specified as hh:mm thus: SELECT to_timestamp('2011-12-18 11:38 -05:20', '-MM-DD HH12:MI TZH:TZM'); to_timestamp --

Re: Speeding up pg_upgrade

On Sat, Dec 9, 2017 at 08:45:14AM -0500, Stephen Frost wrote: > Bruce, > > * Bruce Momjian (br...@momjian.us) wrote: > > On Fri, Dec 8, 2017 at 12:26:55PM -0500, Stephen Frost wrote: > > > * Bruce Momjian (br...@momjian.us) wrote: > > > > I think the big problem with two-stage pg_upgrade is that

Re: [HACKERS] Issues with logical replication

Stas Kelvich wrote: > Seems that having busy loop is the best idea out of several discussed. > > I thought about small sleep at the bottom of that loop if we reached topmost > transaction, but taking into account low probability of that event may be > it is faster to do just busy wait. In other

Re: [HACKERS] eval_const_expresisions and ScalarArrayOpExpr

Dmitry Dolgov <9erthali...@gmail.com> writes: > Oh, ok - I see now, thank you. So, I think no one would object if I'll mark > this patch as ready for committer. Pushed, thanks for reviewing! regards, tom lane

Re: [HACKERS] SQL/JSON in PostgreSQL

On 01/03/2018 11:04 AM, Oleg Bartunov wrote: > > > On 3 Jan 2018 00:23, "Andrew Dunstan" > wrote: > > > > On 01/02/2018 05:04 PM, Nikita Glukhov wrote: > > > > I have removed all extra features from the patch set, they can be > > found in ou

Re: [HACKERS] list of credits for release notes

On Wed, Nov 1, 2017 at 11:24:03PM -0400, Peter Eisentraut wrote: > On 10/2/17 18:34, Bruce Momjian wrote: > > My smaller question is how will this list be generated in PG 11? From > > the commit log when the release notes are created, or some other method? > > I don't think it should be done at

Re: TODO list (was Re: Contributing with code)

On 01/03/2018 09:00 AM, Alvaro Herrera wrote: Joshua D. Drake wrote: There's already https://postgresql.uservoice.com/forums/21853-general which seems to work pretty well. Here's the list of completed items: https://postgresql.uservoice.com/forums/21853-general?status_id=124172 Well that's in

Re: TODO list (was Re: Contributing with code)

Joshua D. Drake wrote: > Heck we could go a step further and actually allow (authenticated) voting on > various features. This would provide the community the ability to more > easily interact with -hackers on various features that would be desirable. There's already https://postgresql.uservoice.

Re: TODO list (was Re: Contributing with code)

On 1/3/18 11:10, Alvaro Herrera wrote: > This text was added by [1] as saying: > > This list contains '''some known PostgreSQL bugs and feature > > requests''' and we hope it contains all such > (before this, it said "all known Pg bugs" which seemed too optimistic, > so the correction w

Re: TODO list (was Re: Contributing with code)

On 01/03/2018 07:49 AM, Jeff Janes wrote: O.k. what does it tell us though? Is it a resource issue? Is it a barrier of entry issue? Lack of ownership/ruthlessness.  While I can edit it to remove items that don't seem desirable (or comprehensible, or whatever) I'm not likely to do so, unless

Re: WIP Patch: Pgbench Serialization and deadlock errors

Hello Marina, Some comment about WIP pgbench error handling v4. Patch applies, compiles, global & local "make check" are ok. doc compiles. I'm generally okay with having such a feature, but I'd like it to be *MUCH* simpler, otherwise it is going to make pgbench unmaintainable:-( Also, ISTM

Re: TODO list (was Re: Contributing with code)

I think deleting the TODO list is a bad idea -- it contains very useful pointers to previous discussion on hard topics. Jeff Janes wrote: > On Tue, Jan 2, 2018 at 2:48 PM, Robert Haas wrote: > > It also has a note at the top saying we think it's complete, but we > > don't think that, or I don'

Re: [HACKERS] SQL/JSON in PostgreSQL

On 3 Jan 2018 00:23, "Andrew Dunstan" wrote: On 01/02/2018 05:04 PM, Nikita Glukhov wrote: > > I have removed all extra features from the patch set, they can be > found in our > github repository: > https://github.com/postgrespro/sqljson/tree/sqljson_ext. > > Now there are 10 patches which have

Re: TODO list (was Re: Contributing with code)

On Tue, Jan 2, 2018 at 6:42 PM, Joshua D. Drake wrote: > On 01/02/2018 11:17 AM, Robert Haas wrote: > >> On Sun, Dec 31, 2017 at 2:31 PM, Peter Geoghegan wrote: >> >>> On Sun, Dec 31, 2017 at 10:42 AM, Tom Lane wrote: >>> If we're not going to maintain/curate it properly, I agree it's not

Re: Do we really need to switch to per-tuple memory context in ATRewriteTable() when Table Rewrite is not happening

On Wed, Jan 3, 2018 at 8:06 PM, Andrew Gierth wrote: >> "Ashutosh" == Ashutosh Sharma writes: > > Ashutosh> Hi All, > > Ashutosh> Today while trying to understand the code for ALTER TABLE in > Ashutosh> PostgreSQL (basically the table rewrite part), I noticed that > Ashutosh> we are switc

Re: Do we really need to switch to per-tuple memory context in ATRewriteTable() when Table Rewrite is not happening

On Wed, Jan 3, 2018 at 7:25 PM, Alvaro Herrera wrote: > Ashutosh Sharma wrote: > >> I am basically talking about the following lines of code in >> ATRewriteTable() function. >> >> /* >> * Switch to per-tuple memory context and reset it for each tuple >> * produced, so we don't leak memory. >> *

Re: TODO list (was Re: Contributing with code)

On Tue, Jan 2, 2018 at 2:48 PM, Robert Haas wrote: > On Sun, Dec 31, 2017 at 2:02 PM, David G. Johnston > wrote: > > It probably needs three sub-sections. Fist the raw ideas put forth by > > people not capable of implementation but needing capabilities; these get > > moved to one of two section

Re: [HACKERS] LDAPS

On 1/2/18 14:56, Thomas Munro wrote: >> A small point on the test changes. You change the test under >> "diagnostic message", but I'm not sure why. Do the changes invalidate >> the existing test? > > Yeah. In master, I was relying on the server rejecting ldaptls=1 > requests due to lack of conf

Re: Package version in PG_VERSION and version()

On Tue, Jan 2, 2018 at 9:20 PM, Craig Ringer wrote: > Last time I tried to actually deploy packages that used --with-extra-version > a variety of tools that talk to postgres broke because they choked when > parsing the version. Including widely used ones like check_postgres. I think there's likel

tsquery pre-parser

https://caub.github.io/pg-tsquery/

Re: Do we really need to switch to per-tuple memory context in ATRewriteTable() when Table Rewrite is not happening

> "Ashutosh" == Ashutosh Sharma writes: Ashutosh> Hi All, Ashutosh> Today while trying to understand the code for ALTER TABLE in Ashutosh> PostgreSQL (basically the table rewrite part), I noticed that Ashutosh> we are switching to a per-tuple memory context even when Ashutosh> table rew

Re: Deadlock in multiple CIC.

Andres Freund wrote: > On 2017-12-26 13:31:03 -0300, Alvaro Herrera wrote: > > It's strange that this has gone undetected for so long. I wonder if > > there's an interaction with logical decoding and its historical > > snapshot stuff here. > > I can't see how - did you have a vague theory you cou

Re: Do we really need to switch to per-tuple memory context in ATRewriteTable() when Table Rewrite is not happening

Ashutosh Sharma wrote: > I am basically talking about the following lines of code in > ATRewriteTable() function. > > /* > * Switch to per-tuple memory context and reset it for each tuple > * produced, so we don't leak memory. > */ > oldCxt = MemoryContextSwitchTo(GetPerTupleMemoryContext(esta

Re: [HACKERS] UPDATE of partition key

> On 3 January 2018 at 11:42, Amit Khandekar wrote: >> [...] So it make perfect sense for >> ExecSetupPartitionTupleRouting() to palloc and return a pointer. Sorry >> for the noise. Will share the change in an upcoming patch version. >> Thanks ! > > ExecSetupPartitionTupleRouting() now returns Par

Re: [HACKERS] GnuTLS support

On 1/3/18 04:59, Michael Paquier wrote: > On Tue, Jan 02, 2018 at 10:54:29PM -0500, Peter Eisentraut wrote: >> I think the solution is that we need to require that all SSL server-side >> implementations support all channel binding types. > > That could be a stop for Windows and macos SSL implement

Re: PATCH: Configurable file mode mask

On Tue, Jan 2, 2018 at 11:43 AM, David Steele wrote: >> > I think MakeDirectory() is a good wrapper, but isn't >> MakeDirectoryPerm() sort of silly? > > There's one place in the backend (storage/ipc/ipc.c) that sets non-default > directory permissions. This function is intended to support that an

Re: CFM for January commitfest?

Hi Tom, > On Jan 2, 2018, at 7:54 PM, Tom Lane wrote: > > Now that the January fest has nominally started, we need somebody > to act as CF manager. Any volunteers? > > (If someone already did volunteer and I missed it, my apologies.) While this will not help for the immediate problem, after r

Re: [HACKERS] eval_const_expresisions and ScalarArrayOpExpr

> On 2 January 2018 at 20:52, Tom Lane wrote: > > I did find one case where the patch makes things significantly slower: > > select * from test where true is true > and true is true > and true is true > and true is true > ... (100 times altogether) Yes, indeed, I never tested this kind of con

Re: [HACKERS] UPDATE of partition key

On 20 December 2017 at 11:52, Amit Khandekar wrote: > On 14 December 2017 at 08:11, Amit Langote > wrote: >> >> Regarding ExecSetupChildParentMap(), it seems to me that it could simply >> be declared as >> >> static void ExecSetupChildParentMap(ModifyTableState *mtstate); >> >> Looking at the pl

Re: [HACKERS] GnuTLS support

On Tue, Jan 02, 2018 at 10:54:29PM -0500, Peter Eisentraut wrote: > I think the solution is that we need to require that all SSL server-side > implementations support all channel binding types. That could be a stop for Windows and macos SSL implementations then. I would think that we would benefit

Re: TODO list (was Re: Contributing with code)

On 01/03/2018 03:50 AM, David Rowley wrote: > On 3 January 2018 at 13:12, Patrick Krecker wrote: >> As a person looking to become a postgres contributor, perhaps I can >> offer some perspective on this. I think there is value in providing >> *some* starting point for new contributors in the form o

Do we really need to switch to per-tuple memory context in ATRewriteTable() when Table Rewrite is not happening

Hi All, Today while trying to understand the code for ALTER TABLE in PostgreSQL (basically the table rewrite part), I noticed that we are switching to a per-tuple memory context even when table rewrite is not required. For e.g.. consider the case where we do ADD CONSTRAINTS (NOT NULL or CHECK) usi

Re: copy_file_range is now a Linux kernel call

On 2018-01-02 23:34:47 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2018-01-02 23:08:05 -0500, Tom Lane wrote: > >> Bleah --- "rwnd" is unpronounceable and not an abbreviation we're > >> currently using anywhere. If we go that way, let's brave carpal tunnel > >> syndrome by calling it "r