Re: [HACKERS] POC: Cache data in GetSnapshotData()

On Thu, Mar 10, 2016 at 1:04 PM, Mithun Cy wrote: > > > On Thu, Mar 3, 2016 at 11:50 PM, Robert Haas > wrote: > >What if you apply both this and Amit's clog control log patch(es)? Maybe > the combination of the two helps substantially more than either >one alone. > > > I did the above tests alo

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

Hi Vinayak, Thanks for the quick review! On 2016/03/10 16:22, poku...@pm.nttdata.co.jp wrote: >> On 2016/03/10 14:29, Amit Langote wrote: >> Updated patches attached. > In 0002- [ snip ] > I think we need to use datid instead of datname. > Robert added datid in pg_stat_get_progress_info() and

Re: [HACKERS] Is there a way around function search_path killing SQL function inlining?

-Original Message- > From: Andreas Karlsson [mailto:andr...@proxel.se] > Sent: Tuesday, March 08, 2016 10:43 PM > To: Regina Obe ; 'Robert Haas' > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Is there a way around function search_path killing SQL > function inlining? > H

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

Hi Amit, Thank you for updating the patch. > -Original Message- > From: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp] > Sent: Thursday, March 10, 2016 5:09 PM > To: SPS ポクレ ヴィナヤック(三技術) ; > robertmh...@gmail.com > Cc: horiguchi.kyot...@lab.ntt.co.jp; amitlangot...@gmail.com; pgsql- >

[HACKERS] utils/misc: Simplify search of end of argv in save_ps_display_args()

Hello, Attached patch provides trivial simplification of the search of end of the argv[] area by replacing for() loop with calculation based on argc. diff --git a/src/backend/utils/misc/ps_status.c b/src/backend/utils/misc/ps_status.c index 892a810..d8f2105 100644 --- a/src/backend/utils/misc/ps_s

[HACKERS] Floating point timestamps

Hi, Is the plan to remove support for floating point timestamps at some stage? If so, what is that waiting on, and would it provide sufficient warning if (say) 9.6 were documented as the last major release to support that build option? Thanks! -- Thomas Munro http://www.enterprisedb.com --

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

On 10 March 2016 at 06:27, Michael Paquier wrote: > On Thu, Mar 10, 2016 at 1:29 AM, David Steele wrote: > > On 1/8/16 9:34 AM, Alvaro Herrera wrote: > >> Simon Riggs wrote: > >>> > >>> On 8 January 2016 at 13:36, Alvaro Herrera > >>> wrote: > > I would agree except for the observatio

Re: [HACKERS] Relation extension scalability

On Thu, Mar 10, 2016 at 7:55 AM, Petr Jelinek wrote: Thanks for the comments.. > Hmm, why did you remove the comment above the call to > UnlockRelationForExtension? While re factoring I lose this comment.. Fixed it > It still seems relevant, maybe with some minor modification? > > Also there

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

> 10 марта 2016 г., в 11:50, Simon Riggs написал(а): > > On 10 March 2016 at 06:27, Michael Paquier > wrote: > On Thu, Mar 10, 2016 at 1:29 AM, David Steele > wrote: > > On 1/8/16 9:34 AM, Alvaro Herrera wrote: > >> Simon Riggs wrot

[HACKERS] Small patch for pgstat.c: fix comment + pgindent

Hello I noticed: http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=b6fb6471f6afaf649e52f38269fd8c5c60647669 ... that comments for procedures pgstat_progress_update_param and pgstat_progress_end_command are identical. Here is a patch that fixes this. Also one empty line added afte

Re: [HACKERS] Small patch for pgstat.c: fix comment + pgindent

Hi, Thanks for the report. On 2016/03/10 18:05, Aleksander Alekseev wrote: > Hello > > I noticed: > > http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=b6fb6471f6afaf649e52f38269fd8c5c60647669 > > ... that comments for procedures pgstat_progress_update_param and > pgstat_progr

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

On Thu, Mar 10, 2016 at 10:00 AM, Vladimir Borodin wrote: > Let’s do immediately after you will send a new version of your patch? Or > even better after testing your patch? Don’t get me wrong, but rejecting my > patch without tangible work on your patch may lead to forgiving about the > problem be

Re: [HACKERS] Explain [Analyze] produces parallel scan for select Into table statements.

On Wed, Mar 9, 2016 at 8:18 PM, Mithun Cy wrote: > > Hi All, > > Explain [Analyze] Select Into table. produces the plan which uses parallel scans. > > Possible Fix: > > I tried to make a patch to fix this. Now in ExplainOneQuery if into clause is > > defined then parallel plans are disabled as

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Fri, Mar 4, 2016 at 3:40 AM, Masahiko Sawada wrote: > On Thu, Mar 3, 2016 at 11:30 PM, Masahiko Sawada > wrote: >> Hi, >> >> Thank you so much for reviewing this patch! >> >> All review comments regarding document and comment are fixed. >> Attached latest v14 patch. >> >>> This accepts 'abc^I

Re: [HACKERS] Optimizer questions

On Mar 10, 2016, at 1:56 AM, Tom Lane wrote: > Konstantin Knizhnik writes: >> I think that the best approach is to generate two different paths: >> original one, when projection is always done before sort and another one >> with postponed projection of non-trivial columns. Then we compare cost

Re: [HACKERS] create opclass documentation outdated

>> In create_opclass.sgml, not only do we have the list of AMs supporting >> STORAGE, but there is also a paragraph describing which AMs do what >> for input datatypes of FUNCTION members (around line 175). > > I placed BRIN together with gist/gin/spgist here, namely that the optype > defaults to t

Re: [HACKERS] Freeze avoidance of very large table.

On Wed, Mar 9, 2016 at 9:09 AM, Masahiko Sawada wrote: > * 001 patch : Incorporated the documentation suggestions and updated > logic a little. This 001 patch looks so little like what I was expecting that I decided to start over from scratch. The new version I wrote is attached here. I don't u

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

On Wed, Mar 9, 2016 at 3:30 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Mar 9, 2016 at 1:12 PM, Tom Lane wrote: >>> I hadn't been paying any attention to this thread, but I wonder whether >>> this entire approach isn't considerably inferior to what we can do now >>> with the planner pat

Re: [HACKERS] Is there a way around function search_path killing SQL function inlining?

On Thu, Mar 10, 2016 at 3:21 AM, Regina Obe wrote: > When you back up the database, it would create a backup with this line: > > SET search_path = public, pg_catalog; > --your create materialized view here > > When you restore even if your database has search_paths set, your > materialized view w

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

Hi, At Thu, 10 Mar 2016 08:21:36 +, wrote in <8e09c2fe530d4008aa0019e38c1d5...@mp-msgss-mbx007.msg.nttdata.co.jp> > > > So maybe we can add datname as separate column in > > pg_stat_progress_vacuum, I think it's not required only datid is sufficient. > > > Any comment? > > > > Why do you th

Re: [HACKERS] psql completion for ids in multibyte string

Hello, At Mon, 7 Mar 2016 12:34:15 -0500, Robert Haas wrote in > >> Fix pushed. > > > > Thank you for committing this. I can see only one commit for this > > in the repository but I believe it is the fixed one. > > It was OK in master, but the back-branches had problems. See > 369c0b090808129

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

On 10 March 2016 at 09:22, Michael Paquier wrote: > On Thu, Mar 10, 2016 at 10:00 AM, Vladimir Borodin > wrote: > > Let’s do immediately after you will send a new version of your patch? Or > > even better after testing your patch? Don’t get me wrong, but rejecting > my > > patch without tangible

Re: [HACKERS] Parallel Aggregate

On 9 March 2016 at 04:06, Robert Haas wrote: > On Mon, Mar 7, 2016 at 5:15 PM, David Rowley > wrote: >> 3. Nothing in create_grouping_paths() looks at the force_parallel_mode >> GUC. I had a quick look at this GUC and was a bit surprised to see 3 >> possible states, but no explanation of what the

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

On 2016/03/10 19:51, Robert Haas wrote: On Wed, Mar 9, 2016 at 3:30 PM, Tom Lane wrote: Robert Haas writes: Just taking a guess here, you might be thinking that instead of something like this... Update on public.ft2 -> Foreign Update on public.ft2 We could boil it all the way d

Re: [HACKERS] Reduce lock levels others reloptions in ALTER TABLE

On 1 March 2016 at 19:00, Robert Haas wrote: > On Mon, Feb 29, 2016 at 12:58 PM, Fabrízio de Royes Mello > wrote: > > Some time ago we added [1] the infrastructure to allow different lock > levels > > for relation options. > > > > So per discussion [2] the attached patch reduce lock levels down

Re: [HACKERS] Identifying a message in emit_log_hook.

On 25 February 2016 at 07:42, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > Hello, > > At Wed, 17 Feb 2016 09:13:01 +, Simon Riggs > wrote in < > canp8+jlbge_ybxulgzxvce44oob8v0t93e5_inhvbde2pxk...@mail.gmail.com> > > On 17 February 2016 at 08:34, Kyotaro HORIGUCHI < > > horig

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On 9 March 2016 at 23:11, David Steele wrote: > There hasn't been any movement on this patch in a while. Will you have a > new tests ready for review soon? > I see the value in this feature, but the patch itself needs work and probably some slimming down/reality and a good spellcheck. If some

Re: [HACKERS] WAL log only necessary part of 2PC GID

On Wed, Mar 9, 2016 at 7:56 PM, Petr Jelinek wrote: > Hi, > > I wonder why you define the gidlen as uint32 when it would fit into uint8 > which in the current TwoPhaseFileHeader struct should be win of 8 bytes on > padding (on 64bit). I think that's something worth considering given that > this

[HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Windows service is not starting so there’s message in log: FATAL: "could not create shared memory segment “Global/PostgreSQL.851401618”: Permission

On Wed, Mar 9, 2016 at 5:46 PM, Haribabu Kommi wrote: > On Wed, Mar 9, 2016 at 10:06 PM, Amit Kapila wrote: > > On Wed, Mar 9, 2016 at 11:46 AM, Haribabu Kommi < kommi.harib...@gmail.com> > > wrote: > >> > >> > >> I tried replacing the random() with PostmaterRandom() for a test and it > >> worked

Re: [HACKERS] POC, WIP: OR-clause support for indexes

Hi Teodor, I've looked into v2 of the patch you sent a few days ago. Firstly, I definitely agree that being able to use OR conditions with an index is definitely a cool idea. I do however agree with David that the patch would definitely benefit from comments documenting various bits that are les

Re: [HACKERS] pam auth - add rhost item

Hi. In attchment new patch with updated documentation and with small change to coding style as you suggested. Regards. Grzegorz. On 03/09/2016 08:30 AM, Haribabu Kommi wrote: > On Tue, Mar 8, 2016 at 10:43 PM, Grzegorz Sampolski > wrote: >> Hi Hari. >> To use pam modules

Re: [HACKERS] Crash with old Windows on new CPU

On Wed, Mar 9, 2016 at 5:48 AM, Christian Ullrich wrote: > * Peter Eisentraut wrote: > > On 2/12/16 11:24 AM, Christian Ullrich wrote: >> > > Otherwise, it may be time to update the manual (15.6 Supported >>> Platforms) where it says PostgreSQL "can be expected to work on these >>> operating syst

Re: [HACKERS] Identifying a message in emit_log_hook.

Hi Simon, On 3/10/16 7:26 AM, Simon Riggs wrote: Can you add this to the CF? It was submitted before deadline. I presume you have access to do that? No problem - here it is: https://commitfest.postgresql.org/9/576/ -- -David da...@pgmasters.net -- Sent via pgsql-hackers mailing list (pgsq

[HACKERS] Small patch: fix warnings during compilation on FreeBSD

Hello I noticed that master branch of PostgreSQL currently compiles with warnings on FreeBSD 10.2 RELEASE: ``` pg_locale.c:1290:12: warning: implicit declaration of function 'wcstombs_l' is invalid in C99 [-Wimplicit-function-declaration] result = wcstombs_l(to, from, tolen, locale); pg_locale.

Re: [HACKERS] Using quicksort for every external sort run

Hi, On Mon, 2015-12-28 at 15:03 -0800, Peter Geoghegan wrote: > On Fri, Dec 18, 2015 at 11:57 AM, Peter Geoghegan wrote: > > BTW, I'm not necessarily determined to make the new special-purpose > > allocator work exactly as proposed. It seemed useful to prioritize > > simplicity, and currently so

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On Thu, Mar 10, 2016 at 6:10 AM, Kyotaro HORIGUCHI wrote: > So, I have looked into system_views.sql and picked up what > catalogs/views shows objects in such way, that is, showing both > object id and its name. > > Show by name: pg_policies, pg_rules, pg_tablespg_matviews, > pg_index

Re: [HACKERS] Freeze avoidance of very large table.

On Thu, Mar 10, 2016 at 3:27 PM, Masahiko Sawada wrote: > Thank you for reviewing! > Attached updated patch. > > > On Thu, Mar 10, 2016 at 3:37 AM, Robert Haas wrote: >> On Wed, Mar 9, 2016 at 9:09 AM, Masahiko Sawada >> wrote: Attached latest 2 patches. >>> * 000 patch : Incorporated the review

Re: [HACKERS] Crash with old Windows on new CPU

* Magnus Hagander wrote: I did notice the #ifdef's are actually different in the header and body section of the patch, which seems wrong. I used the one from the actual implementation (_M_AMD64) for the header includes as, and also merged the #ifdef's together to a single #if in each section. Pl

Re: [HACKERS] Parallel Aggregate

On Thu, Mar 10, 2016 at 6:42 AM, David Rowley wrote: > Hmm, it appears I only looked as far as the enum declaration, which I > expected to have something. Perhaps I'm just not used to looking up > the manual for things relating to code. I don't mind adding some comments there, it just didn't seem

[HACKERS] Endless loop calling PL/Python set returning functions

Hello There is a bug in implementation of set-returning functions in PL/Python. When you call the same set-returning function twice in a single query, the executor falls to infinite loop which causes OOM. Here is a simple reproduction for this issue: CREATE OR REPLACE FUNCTION func(iter int) RETU

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

On 3/9/16 7:37 PM, Petr Jelinek wrote: On 03/02/16 05:02, Robert Haas wrote: On Mon, Feb 1, 2016 at 7:24 PM, David Steele wrote: I have attached a patch that adds an ereport() macro to suppress client output for a single report call (applies cleanly on 1d0c3b3). I'll also move it to the next

Re: [HACKERS] Parallel Aggregate

On Thu, Mar 10, 2016 at 10:55 PM, Robert Haas wrote: > On Thu, Mar 10, 2016 at 6:42 AM, David Rowley > wrote: >> The one reason that I asked about force_parallel_mode was that I >> assumed there was some buildfarm member running somewhere that >> switches this on and runs the regression tests. I

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On Thu, Mar 10, 2016 at 3:08 AM, Amit Langote wrote: > Hi Vinayak, > > Thanks for the quick review! Committed 0001 earlier this morning. On 0002: + /* total_index_blks */ + current_index_blks = (BlockNumber *) palloc(nindexes * sizeof(BlockNumber)); + total_index_blks = 0; +

Re: [HACKERS] proposal: function parse_ident

select parse_ident(E'X\rXX'); I am sending updated patch - I used json function for correct escaping - the escaping behave is same. Hmm, it doesn't look so: % select parse_ident(E'_\005'); ERROR: identifier contains disallowed ch

Re: [HACKERS] utils/misc: Simplify search of end of argv in save_ps_display_args()

Alexander Kuleshov wrote: > Hello, > > Attached patch provides trivial simplification of the search of end of > the argv[] area by replacing for() loop with calculation based on > argc. Uhm. Doesn't this break the very same thing that the comment explains it's doing? -- Álvaro Herrera

Re: [HACKERS] Parallel Aggregate

On 8 March 2016 at 11:15, David Rowley wrote: > The setrefs.c parts of the patch remain completely broken. I've not > had time to look at this again yet, sorry. Ok, so again, apologies for previously sending such a broken patch. I've since managed to free up a bit of time to work on this, which n

Re: [HACKERS] Floating point timestamps

Thomas Munro writes: > Is the plan to remove support for floating point timestamps at some > stage? If so, what is that waiting on, and would it provide > sufficient warning if (say) 9.6 were documented as the last major > release to support that build option? AFAIK there is no particular plan t

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

On Thu, Mar 10, 2016 at 1:53 AM, Michael Paquier wrote: > On Wed, Mar 9, 2016 at 12:13 AM, Alvaro Herrera > wrote: >> Robert Haas wrote: >>> I'm pretty meh about the whole idea of this function, though, >>> actually, and I don't see a single clear +1 vote for this >>> functionality upthread. (Ap

[HACKERS] 2PC support for pglogical

Hi. Here is proof-of-concept version of two phase commit support for logical replication. There are some changes in core postgres, pglogical_output and pglogical extensions. I’ve used version from 2nd Quadrant repo, pglogical branch and rebased it to current head. Some notes about this patch:

Re: [HACKERS] Floating point timestamps

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Thomas Munro writes: > > Is the plan to remove support for floating point timestamps at some > > stage? If so, what is that waiting on, and would it provide > > sufficient warning if (say) 9.6 were documented as the last major > > release to support that b

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

Robert Haas wrote: > That's probably marginally enough support to proceed with this, but > I'm somewhat unenthused about putting time into it myself. Alvaro, > any chance you want to handle this one? OK, I can take it, but I have a few other things earlier in my queue so it will be a few days.

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

David Steele writes: > On 3/9/16 7:37 PM, Petr Jelinek wrote: >> Looking at the code, this adds bool hide_from_client to edata which is >> not initialized in errstart so that needs to be fixed. > I figured this would take care of it: > MemSet(edata, 0, sizeof(ErrorData)); > Since I want hide_from

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Mon, Mar 7, 2016 at 6:19 PM, Robert Haas wrote: > On Sat, Mar 5, 2016 at 7:22 AM, Dilip Kumar wrote: > > On Wed, Mar 2, 2016 at 11:05 AM, Dilip Kumar > wrote: > >> And this latest result (no regression) is on X86 but on my local > machine. > >> > >> I did not exactly saw what this new versio

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

David Steele writes: > I have attached a patch that adds an ereport() macro to suppress client > output for a single report call (applies cleanly on 1d0c3b3). I'll also > move it to the next CF. This patch fails to add the necessary documentation (see sources.sgml) regar

Re: [HACKERS] Floating point timestamps

Stephen Frost wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > Thomas Munro writes: > > > Is the plan to remove support for floating point timestamps at some > > > stage? If so, what is that waiting on, and would it provide > > > sufficient warning if (say) 9.6 were documented as the last majo

Re: [HACKERS] Patch to implement pg_current_logfile() function

On Wed, Mar 9, 2016 at 12:32 PM, Gilles Darold wrote: > I choose to allow the log collector to write his current log file name > into the lock file 'postmaster.pid'. This allow simple access to this > information through system commands, for example: > > postgres@W230ST:~$ tail -n1 /usr/local/pgql

Re: [HACKERS] Small patch: fix warnings during compilation on FreeBSD

Aleksander Alekseev writes: > I noticed that master branch of PostgreSQL currently compiles with > warnings on FreeBSD 10.2 RELEASE: > pg_locale.c:1290:12: warning: implicit declaration of function > 'wcstombs_l' is invalid in C99 [-Wimplicit-function-declaration] > The problem is that both proce

Re: [HACKERS] Patch to implement pg_current_logfile() function

Robert Haas writes: > On Wed, Mar 9, 2016 at 12:32 PM, Gilles Darold > wrote: >> I choose to allow the log collector to write his current log file name >> into the lock file 'postmaster.pid'. > Gosh, why? Piggybacking this on a file written for a specific purpose > by a different process seems

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

On 10 March 2016 at 06:53, Michael Paquier wrote: > On Wed, Mar 9, 2016 at 12:13 AM, Alvaro Herrera > wrote: > > Robert Haas wrote: > >> I'm pretty meh about the whole idea of this function, though, > >> actually, and I don't see a single clear +1 vote for this > >> functionality upthread. (Apo

Re: [HACKERS] Reworks of CustomScan serialization/deserialization

On 10/03/16 08:08, Kouhei Kaigai wrote: >> Also in RegisterCustomScanMethods + Assert(strlen(methods->CustomName) <= CUSTOM_NAME_MAX_LEN); Shouldn't this be actually "if" with ereport() considering this is public API and extensions can pass anything there? (for that matter

Re: [HACKERS] Endless loop calling PL/Python set returning functions

Alexey Grishchenko writes: > There is a bug in implementation of set-returning functions in PL/Python. > When you call the same set-returning function twice in a single query, the > executor falls to infinite loop which causes OOM. Ugh. > Another issue with calling the same set-returning functio

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

Simon Riggs wrote: > On 10 March 2016 at 06:53, Michael Paquier > wrote: > > > On Wed, Mar 9, 2016 at 12:13 AM, Alvaro Herrera > > wrote: > > > Robert Haas wrote: > > >> I'm pretty meh about the whole idea of this function, though, > > >> actually, and I don't see a single clear +1 vote for this

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Simon Riggs wrote: > > On 10 March 2016 at 06:53, Michael Paquier > > wrote: > > > > > On Wed, Mar 9, 2016 at 12:13 AM, Alvaro Herrera > > > wrote: > > > > Robert Haas wrote: > > > >> I'm pretty meh about the whole idea of this function, thoug

[HACKERS] New Windows animal, mostly ecpg trouble (was: Crash with old Windows on new CPU)

* Alvaro Herrera wrote: Magnus Hagander wrote: On Wed, Mar 9, 2016 at 4:36 PM, Christian Ullrich wrote: And apparently not a single one with VS 2013. OK, I'll see what I can do about setting some up soonish, at least with (server) 2008 and (client) 7. FWIW, I have a local build of 9.5.1 w

Re: [HACKERS] create opclass documentation outdated

Emre Hasegeli wrote: > >> In create_opclass.sgml, not only do we have the list of AMs supporting > >> STORAGE, but there is also a paragraph describing which AMs do what > >> for input datatypes of FUNCTION members (around line 175). > > > > I placed BRIN together with gist/gin/spgist here, namely

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

On Thu, Mar 10, 2016 at 10:30 AM, Simon Riggs wrote: > On 10 March 2016 at 06:53, Michael Paquier > wrote: >> >> On Wed, Mar 9, 2016 at 12:13 AM, Alvaro Herrera >> wrote: >> > Robert Haas wrote: >> >> I'm pretty meh about the whole idea of this function, though, >> >> actually, and I don't see a

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

On 10/03/16 15:08, David Steele wrote: Looking at the code, this adds bool hide_from_client to edata which is not initialized in errstart so that needs to be fixed. I figured this would take care of it: MemSet(edata, 0, sizeof(ErrorData)); Since I want hide_from_client to default to false. A

Re: [HACKERS] create opclass documentation outdated

Alvaro Herrera wrote: > Hmm, but if we ever add support for other types in inclusion as you > describe, we will need STORAGE, no? I think it's unfortunate that the > code currently uses the field where it's not really necessary, but > harmless; if people break their systems by introducing bogus o

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

On Thu, Mar 10, 2016 at 10:58 AM, Robert Haas wrote: > On Thu, Mar 10, 2016 at 10:30 AM, Simon Riggs > wrote: > > On 10 March 2016 at 06:53, Michael Paquier > > wrote: > >> > >> On Wed, Mar 9, 2016 at 12:13 AM, Alvaro Herrera > >> wrote: > >> > Robert Haas wrote: > >> >> I'm pretty meh about t

Re: [HACKERS] Freeze avoidance of very large table.

On Thu, Mar 10, 2016 at 8:51 AM, Masahiko Sawada wrote: > After some further thought, I thought that it's better to add check > logic for result of rewriting visibility map to upgrading logic rather > than regression test in order to ensure that rewriting visibility map > has been successfully don

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

Corey Huinker wrote: > New patch for Alvaro's consideration. Thanks. As I said, it will be a few days before I get to this; any further reviews in the meantime are welcome. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training &

Re: [HACKERS] unexpected result from to_tsvector

2016-03-08 0:46 GMT+03:00 Artur Zakirov : > Hello, > > On 07.03.2016 23:55, Dmitrii Golub wrote: > >> >> >> Hello, >> >> Should we added tests for this case? >> > > I think we should. I have added tests for teo...@123-stack.net and > 1...@stack.net emails. > > >> 123_reg.ro is

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

Petr Jelinek writes: > The comment above errhidefromclient says "Only log levels below ERROR > can be hidden from the client." but use of the errhidefromclient(true) > actually does hide the error message from client, client just gets > failed query without any message when used with ERROR leve

Re: [HACKERS] Explain [Analyze] produces parallel scan for select Into table statements.

On Thu, Mar 10, 2016 at 4:43 AM, Amit Kapila wrote: > There should be a white space between 0:CURSOR_OPT_PARALLEL_OK. Also I > don't see this comment is required as similar other usage doesn't have any > such comment. Fixed these two points in the attached patch. > > In general, the patch looks

Re: [HACKERS] Endless loop calling PL/Python set returning functions

I agree that passing function parameters through globals is not the best solution It works in a following way - executing custom code (in our case Python function invocation) in Python is made with PyEval_EvalCode . As an input to this C function you

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

On Thu, Mar 10, 2016 at 4:58 PM, Robert Haas wrote: > On Thu, Mar 10, 2016 at 10:30 AM, Simon Riggs wrote: >> On 10 March 2016 at 06:53, Michael Paquier >> wrote: >>> >>> On Wed, Mar 9, 2016 at 12:13 AM, Alvaro Herrera >>> wrote: >>> > Robert Haas wrote: >>> >> I'm pretty meh about the whole id

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

On Thu, Mar 10, 2016 at 8:58 AM, Robert Haas wrote: > On Thu, Mar 10, 2016 at 10:30 AM, Simon Riggs > wrote: > > On 10 March 2016 at 06:53, Michael Paquier > > wrote: > >> > >> On Wed, Mar 9, 2016 at 12:13 AM, Alvaro Herrera > >> wrote: > >> > Robert Haas wrote: > >> >> I'm pretty meh about th

Re: [HACKERS] Endless loop calling PL/Python set returning functions

Alexey Grishchenko writes: > One scenario when the problem occurs, is when you are calling the same > set-returning function in a single query twice. This way they share the > same "globals" which is not a bad thing, but when one function finishes > execution and deallocates input parameter's glob

Re: [HACKERS] Is there a way around function search_path killing SQL function inlining?

Robert Haas writes: > Hmm. The meaning of funcs.inline depends on the search_path, not just > during dump restoration but all the time. So anything uses it under a > different search_path setting than the normal one will have this kind > of problem; not just dump/restore. Yeah, I see no reason

Re: [HACKERS] Endless loop calling PL/Python set returning functions

No, my fix handles this well. In fact, with the first function call you allocate global variables representing Python function input parameters, call the function and receive iterator over the function results. Then in a series of Postgres calls to PL/Python handler you just fetch next value from

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

On Thu, Mar 10, 2016 at 9:30 AM, Michael Paquier wrote: > On Thu, Mar 10, 2016 at 4:58 PM, Robert Haas > wrote: > > On Thu, Mar 10, 2016 at 10:30 AM, Simon Riggs > wrote: > >> On 10 March 2016 at 06:53, Michael Paquier > >> wrote: > >>> > >>> On Wed, Mar 9, 2016 at 12:13 AM, Alvaro Herrera > >

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

On 10/03/16 17:07, Tom Lane wrote: Petr Jelinek writes: The comment above errhidefromclient says "Only log levels below ERROR can be hidden from the client." but use of the errhidefromclient(true) actually does hide the error message from client, client just gets failed query without any messag

Re: [HACKERS] Optimizer questions

konstantin knizhnik writes: > But right now the rule for cost estimation makes it not possible to apply > this optimization for simple expressions like this: ... > I wonder is there any advantages of earlier evaluation of such simple > expressions if them are not needed for sort? Well, as I sai

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

Hi, I've looked at this patch today, mostly to educate myself, so this probably should not count as a full review. Anyway, the patch seems in excellent shape - it'd be great if all patches (including those written by me) had this level of comments/docs. On Mon, 2016-02-29 at 16:09 -0800, Peter Ge

Re: [HACKERS] Endless loop calling PL/Python set returning functions

Alexey Grishchenko writes: > No, my fix handles this well. > In fact, with the first function call you allocate global variables > representing Python function input parameters, call the function and > receive iterator over the function results. Then in a series of Postgres > calls to PL/Python ha

Re: [HACKERS] Tsvector editing functions

Thanks! Fixed and added tests. Thank you! I did some patch cleanup/fix, but I have some doubt with function's names: 1 to_tsvector: # \df to_tsvector List of functions Schema |Name | Result data type | Argument data types | Type +--

Re: [HACKERS] WAL log only necessary part of 2PC GID

On 10/03/16 13:43, Pavan Deolasee wrote: On Wed, Mar 9, 2016 at 7:56 PM, Petr Jelinek mailto:p...@2ndquadrant.com>> wrote: Hi, I wonder why you define the gidlen as uint32 when it would fit into uint8 which in the current TwoPhaseFileHeader struct should be win of 8 bytes on pa

Re: [HACKERS] Endless loop calling PL/Python set returning functions

Tom Lane wrote: > Alexey Grishchenko > writes: > > No, my fix handles this well. > > In fact, with the first function call you allocate global variables > > representing Python function input parameters, call the function and > > receive iterator over the function results. Then in a series of Pos

[HACKERS] Adjusting the API of pull_var_clause()

Over in the "Optimizer questions" thread, it's become apparent that we need to fix pull_var_clause() to offer multiple behaviors for WindowFunc nodes that are parallel to the ones it has for Aggrefs (viz, reject, recurse, or include in result). This should've been done when window functions were i

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

removed leftover development comment On Thu, Mar 10, 2016 at 11:02 AM, Corey Huinker wrote: > On Thu, Mar 10, 2016 at 10:58 AM, Robert Haas > wrote: > >> On Thu, Mar 10, 2016 at 10:30 AM, Simon Riggs >> wrote: >> > On 10 March 2016 at 06:53, Michael Paquier >> > wrote: >> >> >> >> On Wed, Mar

Re: [HACKERS] WIP: Upper planner pathification

Hi Tom, On 2016-02-28 15:03:28 -0500, Tom Lane wrote: > diff --git a/src/include/optimizer/planmain.h > b/src/include/optimizer/planmain.h > index eaa642b..cd7338a 100644 > *** a/src/include/optimizer/planmain.h > --- b/src/include/optimizer/planmain.h > *** extern RelOptInfo *query_p

Re: [HACKERS] Relation extension scalability

On 10/03/16 09:57, Dilip Kumar wrote: On Thu, Mar 10, 2016 at 7:55 AM, Petr Jelinek mailto:p...@2ndquadrant.com>> wrote: Thanks for the comments.. Hmm, why did you remove the comment above the call to UnlockRelationForExtension? While re factoring I lose this comment.. Fixed it I

Re: [HACKERS] Using quicksort for every external sort run

On Thu, Mar 10, 2016 at 5:40 AM, Tomas Vondra wrote: > I was thinking about running some benchmarks on this patch, but the > thread is pretty huge so I want to make sure I'm not missing something > and this is indeed the most recent version. Wait 24 - 48 hours, please. Big update coming. -- Pe

Re: [HACKERS] Using quicksort for every external sort run

On Thu, Mar 10, 2016 at 1:40 PM, Tomas Vondra wrote: > I was thinking about running some benchmarks on this patch, but the > thread is pretty huge so I want to make sure I'm not missing something > and this is indeed the most recent version. I also ran some preliminary benchmarks just before FOSD

Re: [HACKERS] Freeze avoidance of very large table.

On Fri, Mar 11, 2016 at 1:03 AM, Robert Haas wrote: > This 001 patch looks so little like what I was expecting that I > decided to start over from scratch. The new version I wrote is > attached here. I don't understand why your version tinkers with the > logic for setting the all-frozen bit; I t

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

On Thu, Mar 10, 2016 at 11:33 AM, David G. Johnston wrote: > I tend to think we err toward this too much. This seems like development > concerns trumping usability. Consider that anything someone took the time > to write and polish to make committable to core was obviously genuinely > useful to

Re: [HACKERS] WIP: Upper planner pathification

Andres Freund writes: > I see that you made a lot of formerly externally visible make_* routines > static. The Citus extension (which will be open source in a few days) > uses several of these (make_agg, make_sort_from_sortclauses, make_limit > at least). > Can we please re-consider making these

Re: [HACKERS] pg_rewind just doesn't fsync *anything*?

Hi, On 2016-03-10 08:47:16 +0100, Michael Paquier wrote: > Still, I think that we had better fsync only entries that are modified > by pg_rewind, and files that got updated, and not the whole directory Why? If any files in there are dirty, they need to be fsynced. If they're not dirty, fsync's fr

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On Thu, Mar 10, 2016 at 12:18 AM, Amit Kapila wrote: > On Wed, Mar 9, 2016 at 7:17 PM, Robert Haas wrote: >> >> On Wed, Mar 9, 2016 at 8:31 AM, Amit Kapila >> wrote: >> > Thanks for the suggestion. I have updated the patch to include >> > wait_event_type information in the wait_event table. >>

Re: [HACKERS] WIP: Upper planner pathification

On 2016-03-10 13:48:31 -0500, Tom Lane wrote: > Andres Freund writes: > > I see that you made a lot of formerly externally visible make_* routines > > static. The Citus extension (which will be open source in a few days) > > uses several of these (make_agg, make_sort_from_sortclauses, make_limit >

  1   2   >