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

On Tue, Feb 2, 2016 at 11:42 AM, Masahiko Sawada wrote: > On Tue, Feb 2, 2016 at 10:15 AM, Jim Nasby wrote: >> On 2/1/16 4:59 PM, Alvaro Herrera wrote: >>> >>> Masahiko Sawada wrote: >>> Attached updated version patch. Please review it. >>> >>> >>> In pg_upgrade, the "page convert" func

Re: [HACKERS] [PATCH] Phrase search ported to 9.6

On Tue, Feb 2, 2016 at 10:18 AM, Andreas Joseph Krogh wrote: > På tirsdag 02. februar 2016 kl. 04:22:57, skrev Michael Paquier < > michael.paqu...@gmail.com>: > > > > On Mon, Feb 1, 2016 at 8:21 PM, Dmitry Ivanov > wrote: >> >> This patch was originally developed by Teodor Sigaev and Oleg Bartun

Re: [HACKERS] [PATCH] Phrase search ported to 9.6

På tirsdag 02. februar 2016 kl. 09:20:06, skrev Oleg Bartunov < obartu...@gmail.com >:     On Tue, Feb 2, 2016 at 10:18 AM, Andreas Joseph Krogh mailto:andr...@visena.com>> wrote: På tirsdag 02. februar 2016 kl. 04:22:57, skrev Michael Paquier mailto:michael.paqu...@gma

Re: [HACKERS] pgbench - allow backslash-continuations in custom scripts

Hello, thank you, Febien, Micael. # Though I have made almost no activity in the last month... At Tue, 26 Jan 2016 13:53:33 +0100 (CET), Fabien COELHO wrote in > > Hello Kyotaro-san, > > > Thank you very much Michael but the CF app doesn't allow me to > > regsiter new one. Filling the Descri

Re: [HACKERS] PostgreSQL Auditing

On Tue, Feb 2, 2016 at 1:05 AM, Curtis Ruck wrote: > or pay > EnterpriseDB for their 2 year old version that doesn't have all the > cool/modern jsonb support. Just for the record, anyone who pays for our "2 year old version that doesn't have all the cool/modern jsonb support" is also entitled to

[HACKERS] get current log file

Hello, I find there is a new feature about getting current log file name on the TODO list (for detail please check http://www.postgresql.org/message-id/pine.gso.4.64.0811101325260.9...@westnet.com). On the other side, we finish a ticket to this requirement for our customer. If the PG

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Tue, Feb 2, 2016 at 12:43 AM, Andres Freund wrote: > On 2016-02-01 13:06:57 +0300, Alexander Korotkov wrote: > > On Mon, Feb 1, 2016 at 11:34 AM, Alexander Korotkov < > > a.korot...@postgrespro.ru> wrote: > > >> ClientBasePatch > > >> 11974419382 > > >> 8125923126395 >

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

Masahiko Sawada wrote: > I misunderstood. Sorry for noise. > I agree with adding conversion method as a pageConverter routine. \o/ > This patch doesn't change page layout actually, but pageConverter > routine checks only the page layout. > And we have to plugin named convertLayout_X_to_Y. > > I

Re: [HACKERS] Fix KNN GiST ordering type

On Mon, Feb 1, 2016 at 7:31 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > KNN GiST detects which type it should return by returning type of ordering > operator. > But it appears that type of sk_func is detected after it was replaced with > distance function. That is wrong: distance

Re: [HACKERS] get current log file

Armor wrote: > Hello, > > > I find there is a new feature about getting current log file name on the > TODO list (for detail please check > http://www.postgresql.org/message-id/pine.gso.4.64.0811101325260.9...@westnet.com). > On the other side, we finish a ticket to this requirement for ou

Re: [HACKERS] Raising the checkpoint_timeout limit

On 2 February 2016 at 05:54, Michael Paquier wrote: > On Tue, Feb 2, 2016 at 1:16 PM, Noah Misch wrote: > > On Tue, Feb 02, 2016 at 01:13:20AM +0100, Andres Freund wrote: > >> is there any reason for the rather arbitrary and low checkpoint_timeout > >> limit? > > > > Not that I know, and it is i

Re: [HACKERS] PostgreSQL Auditing

On 02/02/2016 02:05 AM, Curtis Ruck wrote: [snip] P.S., do you know what sucks, having a highly performant PostGIS database that works great, and being told to move to Oracle or SQL Server (because they have auditing). Even though they charge extra for Geospatial support (seriously?) or when

Re: [HACKERS] PostgreSQL Auditing

On 2 February 2016 at 02:05, Curtis Ruck < curtis.ruck+pgsql.hack...@gmail.com> wrote: > Just because auditing isn't sexy sharding, parallel partitioning, creative > indexing (BRIN), or hundreds of thousands of transactions a second, doesn't > make it any less of a requirement to countless organi

Re: [HACKERS] [PATCH] Phrase search ported to 9.6

Andreas Joseph Krogh wrote:   > Which seems to indicate it has received a fair amount of testing and is quite > stable. > Hopefully it integrates into the 9.6 codebase without too much risk. Yes, yes, that's all very good, but we're nearing the closure of the 9.6 development cycle and we only ha

Re: [HACKERS] [PATCH] Phrase search ported to 9.6

På tirsdag 02. februar 2016 kl. 12:04:21, skrev Alvaro Herrera < alvhe...@2ndquadrant.com >: Andreas Joseph Krogh wrote:    > Which seems to indicate it has received a fair amount of testing and is quite > stable. > Hopefully it integrates into the 9.6 codebase

Re: [HACKERS] Way to check whether a particular block is on the shared_buffer?

Kouhei Kaigai wrote: > > On 1/31/16 7:38 PM, Kouhei Kaigai wrote: > > To answer your direct question, I'm no expert, but I haven't seen any > > functions that do exactly what you want. You'd have to pull relevant > > bits from ReadBuffer_*. Or maybe a better method would just be to call > > BufTab

Re: [HACKERS] Raising the checkpoint_timeout limit

On 2016-02-01 23:16:16 -0500, Noah Misch wrote: > On Tue, Feb 02, 2016 at 01:13:20AM +0100, Andres Freund wrote: > > I'm not sure what'd actually be a good upper limit. I'd be inclined to > > even go to as high as a week or so. A lot of our settings have > > upper/lower limits that aren't a good id

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

On Tue, Feb 2, 2016 at 7:22 PM, Alvaro Herrera wrote: > Masahiko Sawada wrote: > >> I misunderstood. Sorry for noise. >> I agree with adding conversion method as a pageConverter routine. > > \o/ > >> This patch doesn't change page layout actually, but pageConverter >> routine checks only the page

Re: [HACKERS] Raising the checkpoint_timeout limit

On 2016-02-02 11:37:15 +0100, Simon Riggs wrote: > If people wish to turn off crash recovery, they can already set fsync=off. > I don't wish to see us support a setting that causes problems for people > that don't understand what checkpoints are and why everybody needs them. I don't think fsync=of

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

29.01.2016 20:43, Thom Brown: On 29 January 2016 at 16:50, Anastasia Lubennikova wrote: 29.01.2016 19:01, Thom Brown: On 29 January 2016 at 15:47, Aleksander Alekseev wrote: I tested this patch on x64 and ARM servers for a few hours today. The only problem I could find is that INSERT wor

Re: [HACKERS] Add links to commit fests to patch summary page

On Tue, Feb 2, 2016 at 2:46 AM, Jim Nasby wrote: > On 2/1/16 6:15 PM, Alvaro Herrera wrote: > >> Jim Nasby wrote: >> >>> It would be nice if the patch summary page (ie, [1]) had links to the >>> relevant entry in that CF. The specific need I see is if you look up a >>> patch >>> in the current CF

Re: [HACKERS] Way to check whether a particular block is on the shared_buffer?

> > > On 1/31/16 7:38 PM, Kouhei Kaigai wrote: > > > > To answer your direct question, I'm no expert, but I haven't seen any > > > functions that do exactly what you want. You'd have to pull relevant > > > bits from ReadBuffer_*. Or maybe a better method would just be to call > > > BufTableLookup(

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On Mon, Feb 1, 2016 at 3:47 AM, Alexander Korotkov wrote: > OK. This one looks good for me too. All right, I pushed both this and the other one as a single commit, since they were so closely related and the second only one line. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enter

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

On 2 February 2016 at 11:47, Anastasia Lubennikova wrote: > > > 29.01.2016 20:43, Thom Brown: > >> On 29 January 2016 at 16:50, Anastasia Lubennikova >> wrote: >>> >>> 29.01.2016 19:01, Thom Brown: On 29 January 2016 at 15:47, Aleksander Alekseev wrote: > > I tested this

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

Hello, At Tue, 2 Feb 2016 20:25:23 +0900, Masahiko Sawada wrote in > On Tue, Feb 2, 2016 at 7:22 PM, Alvaro Herrera > wrote: > > Masahiko Sawada wrote: > > > >> I misunderstood. Sorry for noise. > >> I agree with adding conversion method as a pageConverter routine. > > > > \o/ > > > >> This p

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On Tue, Feb 2, 2016 at 5:24 PM, Robert Haas wrote: > > On Mon, Feb 1, 2016 at 3:47 AM, Alexander Korotkov > wrote: > > OK. This one looks good for me too. > > All right, I pushed both this and the other one as a single commit, > since they were so closely related and the second only one line. >

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On Tue, Feb 2, 2016 at 2:54 PM, Robert Haas wrote: > On Mon, Feb 1, 2016 at 3:47 AM, Alexander Korotkov > wrote: > > OK. This one looks good for me too. > > All right, I pushed both this and the other one as a single commit, > since they were so closely related and the second only one line. > G

Re: [HACKERS] Add links to commit fests to patch summary page

Magnus Hagander wrote: > On Tue, Feb 2, 2016 at 2:46 AM, Jim Nasby wrote: > > > On 2/1/16 6:15 PM, Alvaro Herrera wrote: > > > >> Jim Nasby wrote: > >> > >>> It would be nice if the patch summary page (ie, [1]) had links to the > >>> relevant entry in that CF. The specific need I see is if you lo

Re: [HACKERS] Fuzzy substring searching with the pg_trgm extension

On 01.02.2016 20:12, Artur Zakirov wrote: I have changed the patch: 1 - trgm2.data was corrected, duplicates were deleted. 2 - I have added operators <<-> and <->> with GiST index supporting. A regression test will pass only with the patch http://www.postgresql.org/message-id/capphfdt19fwqxaryjk

Re: [HACKERS]WIP: Covering + unique indexes.

31.01.2016 11:04, David Rowley: On 27 January 2016 at 03:35, Anastasia Lubennikova wrote: including_columns_3.0 is the latest version of patch. And changes regarding the previous version are attached in a separate patch. Just to ease the review and debug. Hi, I've made another pass over the p

Re: [HACKERS]WIP: Covering + unique indexes.

Anastasia Lubennikova wrote: > I just write here to say that I do not disappear and I do remember about the > issue. > But I'm very very busy this week. I'll send an updated patch next week as > soon as possible. That's great to know, thanks. I moved your patch to the next commitfest. Please do

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

This patch has gotten its fair share of feedback in this fest. I moved it to the next commitfest. Please do keep working on it and reviewers that have additional comments are welcome. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA,

Re: [HACKERS] [PATCH] Phrase search ported to 9.6

On Tue, Feb 2, 2016 at 2:04 PM, Alvaro Herrera wrote: > Andreas Joseph Krogh wrote: > > > Which seems to indicate it has received a fair amount of testing and is > quite > > stable. > > Hopefully it integrates into the 9.6 codebase without too much risk. > > Yes, yes, that's all very good, but we

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On Mon, Feb 1, 2016 at 12:27 AM, Amit Kapila wrote: > Fixed. This patch doesn't build: ./xfunc.sgml:int lwlock_count = 0; Tabs appear in SGML/XML files The #define NUM_LWLOCKS 1 just seems totally unnecessary, as does int lwlock_count = 0. You're only assigning

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

Robert Haas wrote: > Overall, I think this is on the right track, but it still needs some > work to make it cleaner. We've committed a large number of patches in this item this cycle. I think it's fair to mark it as Committed. Can somebody submit a new one to the next commitfest? -- Álvaro He

Re: [HACKERS] Fwd: Core dump with nested CREATE TEMP TABLE

On Sun, Jan 31, 2016 at 11:50 AM, Tom Lane wrote: > Noah Misch writes: >> On Sat, Jan 30, 2016 at 04:28:47PM -0500, Robert Haas wrote: >>> I think I've >>> pretty much said what I have to say about this; if nothing I wrote up >>> until now swayed you, it's unlikely that anything else I say after

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

On Mon, Feb 1, 2016 at 7:10 PM, Alexander Korotkov wrote: > On Sun, Jan 31, 2016 at 6:55 AM, Amit Kapila > wrote: > >> On Thu, Jan 28, 2016 at 9:16 AM, Amit Kapila >> wrote: >> > >> > On Thu, Jan 28, 2016 at 2:12 AM, Robert Haas >> wrote: >> > > >> > > On Tue, Jan 26, 2016 at 3:10 AM, and...@a

Re: [HACKERS] proposal: PL/Pythonu - function ereport

Dne 2. 2. 2016 7:30 napsal uživatel "Catalin Iacob" : > > On Mon, Feb 1, 2016 at 5:37 PM, Pavel Stehule wrote: > > Dne 29. 1. 2016 18:09 napsal uživatel "Catalin Iacob" > > : > >> Looking at the output above, I don't see who would rely on calling > >> plpy.error with multiple arguments and getting

Re: [HACKERS] pg_lsn cast to/from int8

On Tue, Jan 26, 2016 at 4:58 PM, Craig Ringer wrote: > On 26 January 2016 at 22:07, Magnus Hagander wrote: > > >> In this case, mostly legacy compatibility. Making an app that works with >> versions that don't have pg_lsn have a nice path forward to the modern >> world. Being able to cast from p

Re: [HACKERS] Relation extension scalability

On Thu, Jan 28, 2016 at 6:23 AM, Dilip Kumar wrote: > [ new patch ] This patch contains a useless hunk and also code not in PostgreSQL style. Get pgindent set up and it will do it correctly for you, or look at the style of the surrounding code. What I'm a bit murky about is *why* this should be

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

On Mon, Feb 1, 2016 at 11:28 PM, Fujii Masao wrote: > On Mon, Feb 1, 2016 at 5:36 PM, Masahiko Sawada wrote: >> On Sun, Jan 31, 2016 at 8:58 PM, Michael Paquier >> wrote: >>> On Sun, Jan 31, 2016 at 5:28 PM, Masahiko Sawada >>> wrote: On Sun, Jan 31, 2016 at 5:18 PM, Michael Paquier

Re: [HACKERS] PostgreSQL Auditing

On 02/02/2016 02:47 AM, José Luis Tallón wrote: On 02/02/2016 02:05 AM, Curtis Ruck wrote: [snip] P.S., do you know what sucks, having a highly performant PostGIS database that works great, and being told to move to Oracle or SQL Server (because they have auditing). Even though they charge ext

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On Tue, Feb 2, 2016 at 9:04 AM, Alvaro Herrera wrote: > Robert Haas wrote: >> Overall, I think this is on the right track, but it still needs some >> work to make it cleaner. > > We've committed a large number of patches in this item this cycle. I > think it's fair to mark it as Committed. Can s

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Tue, Feb 2, 2016 at 3:48 PM, Pavel Stehule wrote: > If we decided to break compatibility, then we have to do explicitly. Thid > discussion can continue with commiter, but send path with duplicitly defined > functions has not sense for me. Currently I out of office, so I cannot to > clean it. 4.

Re: [HACKERS] Add links to commit fests to patch summary page

On Tue, Feb 2, 2016 at 1:35 PM, Alvaro Herrera wrote: > Magnus Hagander wrote: > > On Tue, Feb 2, 2016 at 2:46 AM, Jim Nasby > wrote: > > > > > On 2/1/16 6:15 PM, Alvaro Herrera wrote: > > > > > >> Jim Nasby wrote: > > >> > > >>> It would be nice if the patch summary page (ie, [1]) had links to

Re: [HACKERS] Add links to commit fests to patch summary page

Magnus Hagander wrote: > So from https://commitfest.postgresql.org/9/353/, you'd want links to > /8/353/, /7/353/, /6/353/? Right. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mail

Re: [HACKERS] Add links to commit fests to patch summary page

On Tue, Feb 2, 2016 at 4:43 PM, Alvaro Herrera wrote: > Magnus Hagander wrote: > > > So from https://commitfest.postgresql.org/9/353/, you'd want links to > > /8/353/, /7/353/, /6/353/? > > Right. > > I'm not entirely sure what I'd use that for myself, but that's trivial to implement. Thus, done

Re: [HACKERS] Relation extension scalability

On 2016-02-02 10:12:38 -0500, Robert Haas wrote: > Here's a sketch of another approach to this problem. Get rid of the > relation extension lock. Instead, have an array of, say, 256 lwlocks. > Each one protects the extension of relations where hash(relfilenode) % > 256 maps to that lock. To exte

Re: [HACKERS] Relation extension scalability

On Tue, Feb 2, 2016 at 10:49 AM, Andres Freund wrote: > I'm doubtful that anything that does the victim buffer search while > holding the extension lock will actually scale in a wide range of > scenarios. The copy scenario here probably isn't too bad because the > copy ring buffes are in use, and

Re: [HACKERS] Relation extension scalability

On 2016-01-28 16:53:08 +0530, Dilip Kumar wrote: > test_script: > > ./psql -d postgres -c "truncate table data" > ./psql -d postgres -c "checkpoint" > ./pgbench -f copy_script -T 120 -c$ -j$ postgres > > Shared Buffer48GB > Table:Unlogged Table > ench -c$ -j$ -f -M Prepared po

Re: [HACKERS] Add links to commit fests to patch summary page

On 2/2/16 6:35 AM, Alvaro Herrera wrote: what I want is the link to go to *that patch's* page in the other commitfest. That's also what I think Jim wants. +1 -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble?

Re: [HACKERS] PostgreSQL Auditing

On Tue, Feb 02, 2016 at 07:24:23AM -0800, Joshua D. Drake wrote: > PostgreSQL has auditing. It is available now, just not in core. Postgis > isn't available in core either and it seems to do just fine. I don't really buy that argument. For one, PostGIS has a pretty narrow functional use-case (spat

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

On Tue, Feb 2, 2016 at 10:05 PM, Alvaro Herrera wrote: > This patch has gotten its fair share of feedback in this fest. I moved > it to the next commitfest. Please do keep working on it and reviewers > that have additional comments are welcome. Thanks! On Tue, Feb 2, 2016 at 8:59 PM, Kyotaro H

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

On Tue, Feb 2, 2016 at 5:18 AM, Robert Haas wrote: > On Mon, Feb 1, 2016 at 8:27 AM, Ashutosh Bapat > wrote: > > Here are patches rebased on recent commit > > cc592c48c58d9c1920f8e2063756dcbcce79e4dd. Renamed original > deparseSelectSql > > as deparseSelectSqlForBaseRel and added deparseSelectSq

Re: [HACKERS] pgbench - allow backslash-continuations in custom scripts

On Thu, Jan 7, 2016 at 3:36 AM, Kyotaro HORIGUCHI wrote: > - 0001-Prepare-for-sharing-psqlscan-with-pgbench.patch > > This diff looks a bit large but most of them is cut'n-paste > work and the substantial change is rather small. > > This refactors psqlscan.l into two .l files. The additional

Re: [HACKERS] PostgreSQL Auditing

On 02/02/2016 07:31 AM, curtis.r...@gmail.com wrote: Its not available in rpm or premade binary forms in its current instantiation, not a big deal for me, but it raises the barrier to entry. If it was packaged into an RPM, what would be the process to get it added to postgresql's yum repositor

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

On Tue, Feb 2, 2016 at 11:21 AM, Ashutosh Bapat wrote: >> Why does deparseSelectStmtForRel change the order of the existing >> arguments? I have no issue with adding new arguments as required, but >> rearranging the existing argument order doesn't serve any useful >> purpose that is immediately a

Re: [HACKERS] PostgreSQL Auditing

On 02/02/2016 08:13 AM, Michael Banck wrote: On Tue, Feb 02, 2016 at 07:24:23AM -0800, Joshua D. Drake wrote: PostgreSQL has auditing. It is available now, just not in core. Postgis isn't available in core either and it seems to do just fine. I don't really buy that argument. For one, PostGIS

Re: [HACKERS] PostgreSQL Auditing

On Tue, Feb 2, 2016 at 11:13 AM, Michael Banck wrote: > On Tue, Feb 02, 2016 at 07:24:23AM -0800, Joshua D. Drake wrote: >> PostgreSQL has auditing. It is available now, just not in core. Postgis >> isn't available in core either and it seems to do just fine. > > I don't really buy that argument.

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

On Mon, Feb 1, 2016 at 8:40 AM, Alexander Korotkov wrote: > I wonder if we can use 4-byte wait_event_info more efficiently. > LWLock number in the tranche would be also useful information to expose. > Using lwlock number user can determine if there is high concurrency for > single lwlock in tranch

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

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, failed Everything looks good except for two minor issues: 1) There

Re: [HACKERS] Relation extension scalability

Andres Freund wrote: > Could you also measure how this behaves for [...] While we're proposing benchmark cases -- I remember this being an issue with toast tables getting very large values of xml which causes multiple toast pages to be extended for each new value inserted. If there are multiple

Re: [HACKERS] Tsvector editing functions

Some notices: 1 tsin in documentation doesn't look like a good name. Changed to vector similar to other places. 2 I did some editorization about freeing memory/forgotten names etc 3 It seems to me that tsvector_unnest() could be seriously optimized for large tsvectors: with current coding it

Re: [HACKERS] Tsvector editing functions

Some notices: 1 tsin in documentation doesn't look like a good name. Changed to vector similar to other places. 2 I did some editorization about freeing memory/forgotten names etc Ooops, forgot to attach -- Teodor Sigaev E-mail: teo...@sigaev.ru

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

Doh, I left that comment to myself in there. :) The corresponding structs in timestamp.c and int.c have no comment, so suggestions of what should be there are welcome. In the interim I put in this: /* state for generate_series_date(date,date,[step]) */ Extra linefeed after struct removed. Do y

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

On 2/2/16 1:01 PM, Corey Huinker wrote: > Doh, I left that comment to myself in there. :) If I had a dime for every time I've done that... > The corresponding structs in timestamp.c and int.c have no comment, so > suggestions of what should be there are welcome. In the interim I put in > this: >

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

> > > > Do you have any insight as to why the documentation test failed? > > > > In the mean time, here's the updated patch. > > I didn't pass the docs on account of the wonky comment since I consider > code comments to be part of the docs. The sgml docs build fine and look > good to me. > > Ah, u

Re: [HACKERS] Minor code improvements to create_foreignscan_plan/ExecInitForeignScan

Etsuro Fujita wrote: > Done. Attached is an updated version of the patch. Pushed, thanks. I kinda wonder why this struct member has a name that doesn't match the naming convention in the rest of the struct, and also why isn't it documented in the comment above the struct definition. But that's

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

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed Everything looks good to me. Ready for a committer to have a

[HACKERS] left, right, full sort merge join plan

Hi Hackers, I am looking for some help in creating LEFT/RIGHT/FULL sort-merge-join. Does anyone have a complete and reproducible script that would generate those plans? Can I find it in the regression test suite? If not, how do you exercise those code path for QA purposes? Thanks! -cktan

Re: [HACKERS] Patch: make behavior of all versions of the "isinf" function be similar

Vitaly Burovoy writes: > On 1/31/16, Tom Lane wrote: >> 2. POSIX:2008 only requires that "The isinf() macro shall return a >> non-zero value if and only if its argument has an infinite value." > Ok, then I'll use "is_infinite" from "float.c". Yeah, that's good. > But why functions' (in "src/po

Re: [HACKERS] PostgreSQL Auditing

On 2/2/16 10:34 AM, Joshua D. Drake wrote: Auditing is a pretty security/enterprisey-related thing that could do with the "officially considered to of the PostgreSQL project standard and ready for production" rubber-stamp that tends to go along with most end-user/admin-oriented stuff shipped in t

Re: [HACKERS] PostgreSQL Auditing

On 2/2/16 5:00 AM, Simon Riggs wrote: Since you've written the email here, I'd ask that you join our community and use your knowledge and passion to make things happen. +1. Kudos for speaking up in the first place, but it's clear that right now the biggest thing holding Postgres back is lack o

Re: [HACKERS] Ununsed member in printQueryOpt

"Dickson S. Guedes" writes: > I found the following code in src/bin/psql/print.h:155 (master 1d0c3b3f8a) > boolquote; /* quote all values as much as possible */ > But I didn't found any other references to that "quote" and, after > removing that line, > the code still compiles

Re: [HACKERS] a raft of parallelism-related bug fixes

On Mon, Oct 19, 2015 at 12:02 PM, Robert Haas wrote: > On Sat, Oct 17, 2015 at 9:16 PM, Andrew Dunstan wrote: >> If all that is required is a #define, like CLOBBER_CACHE_ALWAYS, then no >> special buildfarm support is required - you would just add that to the >> animal's config file, more or less

Re: [HACKERS] PostgreSQL Auditing

On Tue, Feb 02, 2016 at 08:28:54AM -0800, Joshua D. Drake wrote: > On 02/02/2016 07:31 AM, curtis.r...@gmail.com wrote: > >Its not available in rpm or premade binary forms in its current > >instantiation, not a big deal for me, but it raises the barrier to > >entry. > > > >If it was packaged into a

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Tue, Feb 2, 2016 at 10:39 AM, Catalin Iacob wrote: > On Tue, Feb 2, 2016 at 3:48 PM, Pavel Stehule wrote: >> If we decided to break compatibility, then we have to do explicitly. Thid >> discussion can continue with commiter, but send path with duplicitly defined >> functions has not sense for

Re: [HACKERS] PostgreSQL Auditing

On 2/2/16 4:50 PM, Michael Banck wrote: > > We are looking into packaging pgaudit for Debian. > > However, then another question comes up: Should the 2nd Quadrant or the > Crunchy Data codebase be added to the distribution? Who gets to decide? For my 2 cents I think that the version I submitted

Re: [HACKERS] [POC] FETCH limited by bytes.

On Wed, Jan 27, 2016 at 11:19 PM, Corey Huinker wrote: > The possible tests might be: > - creating a server/table with fetch_size set > - altering an existing server/table to have fetch_size set > - verifying that the value exists in pg_foreign_server.srvoptions and > pg_foreign_table.ftoptions. >

Re: [HACKERS] PostgreSQL Auditing

On Tue, Feb 2, 2016 at 5:16 PM, David Steele wrote: > This sort of confusion is one of the main reasons I pursued inclusion in > core. But that's exactly wrong. When there is not agreement on one code base over another, that's the time it is most important not to pick one of them arbitrarily pri

Re: [HACKERS] PostgreSQL Auditing

Its not available in rpm or premade binary forms in its current instantiation, not a big deal for me, but it raises the barrier to entry. If it was packaged into an RPM, what would be the process to get it added to postgresql's yum repositories? February 2 2016 10:24 AM, "Joshua D. Drake" wrot

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

On Mon, Feb 1, 2016 at 9:28 AM, Fujii Masao wrote: > So what about the following plan? > > [first version] > Add only synchronous_standby_num which specifies the number of standbys > that the master must wait for before marking sync replication as completed. > This version supports simple use case

Re: [HACKERS] proposal: PL/Pythonu - function ereport

Robert Haas wrote: > The eventual committer is likely to be much happier with this patch if > you guys have achieved consensus among yourselves on the best > approach. > > (Disclaimer: The eventual committer won't be me. I'm not a Python > guy. But we try to proceed by consensus rather than com

Re: [HACKERS] [POC] FETCH limited by bytes.

> > > postgres_fdw.c:2642:16: error: use of undeclared identifier 'server' > foreach(lc, server->options) > Odd. Compiled for me. Maybe I messed up the diff. Will get back to you on that with the tests suggested. > ^ > ../../src/includ

Re: [HACKERS] [PATCH] Phrase search ported to 9.6

On Tue, Feb 2, 2016 at 6:04 AM, Alvaro Herrera wrote: > Andreas Joseph Krogh wrote: >> Which seems to indicate it has received a fair amount of testing and is quite >> stable. >> Hopefully it integrates into the 9.6 codebase without too much risk. > > Yes, yes, that's all very good, but we're near

Re: [HACKERS] [POC] FETCH limited by bytes.

On Tue, Feb 2, 2016 at 5:57 PM, Corey Huinker wrote: >> postgres_fdw.c:2642:16: error: use of undeclared identifier 'server' >> foreach(lc, server->options) > > > Odd. Compiled for me. Maybe I messed up the diff. Will get back to you on > that with the tests suggested. I d

[HACKERS] Why is hstore_to_json_loose not like hstore_to_jsonb_loose?

hstore_to_json_loose() contains a heuristic that says that an hstore value that looks like a JSON number should be treated as a number (and hence not quoted). That logic has an oversight in it, as per bug #13906, but it's straightforward to fix. However, I noticed that hstore_to_jsonb_loose() has

Re: [HACKERS] Integer overflow in timestamp_part()

[ Please use a useful Subject: line in your posts. ] Vitaly Burovoy writes: > I've just found a little bug: extracting "epoch" from the last 30 > years before Postgres' "+Infinity" leads an integer overflow: Hmm. I do not like the proposed patch much: it looks like it's throwing away precision

Re: [HACKERS] Raising the checkpoint_timeout limit

On Tue, Feb 02, 2016 at 12:24:50PM +0100, Andres Freund wrote: > On 2016-02-01 23:16:16 -0500, Noah Misch wrote: > > On Tue, Feb 02, 2016 at 01:13:20AM +0100, Andres Freund wrote: > > > I'm not sure what'd actually be a good upper limit. I'd be inclined to > > > even go to as high as a week or so.

Re: [HACKERS] PostgreSQL Auditing

Robert, This isn't wrong. I don't see anyone else trying to submit anything in reference to auditing. Just because there have been multiple implementations in the past, based on commit histories, there have only been a few that tried getting into core or contrib (that i can find in mailing list

Re: [HACKERS] Integer overflow in timestamp_part()

On 2/2/16 6:39 PM, Tom Lane wrote: I'm inclined to think that a good solution would be to create an artificial restriction to not accept years beyond, say, 10 AD. That would leave us with a lot of daylight to not have to worry about corner-case overflows in timestamp arithmetic. I'm not sure

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

On Wed, Feb 3, 2016 at 7:33 AM, Robert Haas wrote: > On Mon, Feb 1, 2016 at 9:28 AM, Fujii Masao wrote: >> So what about the following plan? >> >> [first version] >> Add only synchronous_standby_num which specifies the number of standbys >> that the master must wait for before marking sync replic

Re: [HACKERS] PostgreSQL Auditing

On 2/2/16 7:25 PM, Curtis Ruck wrote: I'm opening to testing and evaluating to see if it meets our compliance requirements, but I am no where close to being a C developer, or having C developers that could actually provide a meaningful review. One issue along this thread already pops up, concern

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

On Tue, Feb 2, 2016 at 8:48 PM, Fujii Masao wrote: > So you disagree with only third version that I proposed, i.e., > adding some hooks for sync replication? If yes and you're OK > with the first and second versions, ISTM that we almost reached > consensus on the direction of multiple sync replica

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On 2/2/16 4:52 PM, Alvaro Herrera wrote: Robert Haas wrote: The eventual committer is likely to be much happier with this patch if you guys have achieved consensus among yourselves on the best approach. (Disclaimer: The eventual committer won't be me. I'm not a Python guy. But we try to proc

Re: [HACKERS] pglogical - logical replication contrib module

The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: tested, failed Spec compliant: not tested Documentation:tested, failed Here is some more review +- `pglogical.replication_set_add_table

Re: [HACKERS] PostgreSQL Auditing

​So, Noah's excellent response has been ignored (from what my threaded Gmail view tells me) at this point...​ On Tue, Feb 2, 2016 at 6:25 PM, Curtis Ruck < curtis.ruck+pgsql.hack...@gmail.com> wrote: > Robert, > > This isn't wrong. I don't see anyone else trying to submit anything in > reference

Re: [HACKERS] [PATCH] better systemd integration

I've committed this. Thanks for checking. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Add links to commit fests to patch summary page

On 2/2/16 9:46 AM, Magnus Hagander wrote: I'm not entirely sure what I'd use that for myself, but that's trivial to implement. Thus, done and published. FWIW, my use case was actually to go from https://commitfest.postgresql.org/8/353/ to https://commitfest.postgresql.org/9/353/, which I need

Re: [HACKERS] Integer overflow in timestamp_part()

On 2/2/16, Tom Lane wrote: > [ Please use a useful Subject: line in your posts. ] I'm so sorry, it was the first time I had forgotten to look at the "Subject" field before I pressed the "Send" button. > Vitaly Burovoy writes: >> I've just found a little bug: extracting "epoch" from the last 30

  1   2   >