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

Magnus Hagander wrote: > 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

Re: [HACKERS] PATCH: index-only scans with partial indexes

I have applied this patch to our working branch and during several weeks we ran various tests and benchmarks. We have not noticed any problems or performance degradation. And at some queries this patch cause very significant increase of performance - ten times: With this patch: postgres=# ex

Re: [HACKERS] Re: PATCH: Split stats file per database WAS: autovacuum stress-testing our system

On Mon, Feb 01, 2016 at 07:03:45PM +0100, Tomas Vondra wrote: > On 12/22/2015 03:49 PM, Noah Misch wrote: > >On Mon, Feb 18, 2013 at 06:19:12PM -0300, Alvaro Herrera wrote: > >>I have pushed it now. Further testing, of course, is always welcome. > > > >While investigating stats.sql buildfarm failu

Re: [HACKERS] WAL Re-Writes

On Mon, Feb 1, 2016 at 8:05 PM, Jim Nasby wrote: > On 1/31/16 3:26 PM, Jan Wieck wrote: > >> On 01/27/2016 08:30 AM, Amit Kapila wrote: >> >>> operation. Now why OS couldn't find the corresponding block in >>> memory is that, while closing the WAL file, we use >>> POSIX_FADV_DONTNEED if wal_leve

Re: [HACKERS] Raising the checkpoint_timeout limit

On Tue, Feb 2, 2016 at 10:58 PM, Tom Lane wrote: > I've gotta go with the "paternalism" side of the argument here. Suppose > you configure your system to checkpoint once a year --- what is going to > happen when the year is up? Or when you try to shut it down? You *will* > regret such a setting

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

On Mon, Feb 1, 2016 at 7:24 PM, David Steele wrote: > On 2/1/16 5:25 PM, Alvaro Herrera wrote: >> David Steele wrote: > >>> 2) There would be two different ways to suppress client messages but I was >>> hoping to only have one. >> >> I think they are two different things actually. > > Fair enough

Re: [HACKERS] Raising the checkpoint_timeout limit

Noah Misch writes: > On Tue, Feb 02, 2016 at 12:24:50PM +0100, Andres Freund wrote: >> On 2016-02-01 23:16:16 -0500, Noah Misch wrote: >>> In general, I favor having limits reflect fundamental system limitations >>> rather than paternalism. Therefore, I would allow INT_MAX (68 years). >> I gener

[HACKERS] Incorrect formula for SysV IPC parameters

Hello, I found that the formulas to calculate SEMMNI and SEMMNS are incorrect in 9.2 and later. http://www.postgresql.org/docs/9.5/static/kernel-resources.html All of them say that the same thing as following, | SEMMNI Maximum number of semaphore identifiers (i.e., sets) | | at least ceil((m

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

On 2016/02/03 3:31, Alvaro Herrera wrote: Etsuro Fujita wrote: Done. Attached is an updated version of the patch. Pushed, thanks. Thank you! 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 document

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

> > > I don't see how. There really is no declaration in there for a > variable called server. > Absolutely correct. My only guess is that it was from failing to make clean after a checkout/re-checkout. A good reason to have even boring regression tests. Regression tests added. diff --git a/cont

Re: [HACKERS] pglogical - logical replication contrib module

On 01/26/2016 10:43 AM, Craig Ringer wrote: On 23 January 2016 at 11:17, Steve Singer > wrote: ** Schema changes involving rewriting big tables Sometimes you have a DDL change on a large table that will involve a table rewrite and the best way of deploy

Re: [HACKERS] Raising the checkpoint_timeout limit

On Tue, Feb 2, 2016 at 8:09 PM, Noah Misch wrote: > 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 b

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

On Tue, Feb 2, 2016 at 10:27 PM, Amit Kapila wrote: > So, let's leave adding any additional column, but Alexander has brought up > a good point about storing the wait_type and actual wait_event > information into four bytes. Currently I have stored wait_type (aka > classId) > in first byte and th

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

On Tue, Feb 2, 2016 at 10:09 PM, Robert Haas wrote: > > 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 deter

Re: [HACKERS] PostgreSQL Auditing

On Tue, Feb 2, 2016 at 8:25 PM, Curtis Ruck wrote: > Additionally Robert, given your professional status, you are by no means an > unbiased contributor in this discussion. Your stance on this matter shows > that you don't necessarily want the open source solution to succeed in the > commercial/co

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

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] [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] 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] 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] 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] 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] 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 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] 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] 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] 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] 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

[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] [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

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.

> > > 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] 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] 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] 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] 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] [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 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] 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 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] 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] 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] 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] 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] 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

[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

[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

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

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] 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)

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] 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] 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] 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

[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] 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

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] 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] 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 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] 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] 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] 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] 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] 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] 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] 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-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] 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] 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 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] 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] [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] 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] 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] 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] 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] 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] 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] 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] [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] [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] 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] 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]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]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] 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] 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] [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] [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] 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] [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] [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] 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] 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] [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] 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] 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-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] 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

  1   2   >