Re: [HACKERS] silent data loss with ext4 / all current versions

On Tue, Feb 2, 2016 at 1:07 AM, Andres Freund wrote: > On 2016-01-25 16:30:47 +0900, Michael Paquier wrote: >> diff --git a/src/backend/access/transam/xlog.c >> b/src/backend/access/transam/xlog.c >> index a2846c4..b124f90 100644 >> --- a/src/backend/access/transam/xlog.c >> +++ b/src/backend/acc

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

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 mailto:d.iva...@postgrespro.ru>> wrote: This patch was originally developed by Teodor Sigaev and Oleg Bartunov in 2009

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

> KaiGai-san, > > On 2016/02/01 10:38, Kouhei Kaigai wrote: > > As an aside, background of my motivation is the slide below: > > http://www.slideshare.net/kaigai/sqlgpussd-english > > (LT slides in JPUG conference last Dec) > > > > I'm under investigation of SSD-to-GPU direct feature on top of > >

Re: [HACKERS] PostgreSQL Audit Extension

On 02/01/2016 08:23 PM, Robert Haas wrote: It also appears to me that if we did want to do that, it would need quite a lot of additional cleanup. I haven't dug in enough to have a list of specific issues, but it does look to me like there would be quite a bit. Maybe that'd be worth doing if th

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

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 the tuple so I'm >> actually in favor of just breaking backward c

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

KaiGai-san, On 2016/02/01 10:38, Kouhei Kaigai wrote: > As an aside, background of my motivation is the slide below: > http://www.slideshare.net/kaigai/sqlgpussd-english > (LT slides in JPUG conference last Dec) > > I'm under investigation of SSD-to-GPU direct feature on top of > the custom-scan

Re: [HACKERS] PostgreSQL Auditing

On Tue, Feb 02, 2016 at 01:05:46AM +, Curtis Ruck wrote: > So Auditing, it seems that some people want auditing (myself, David Steele, > 2nd quadrant, and probably others). I personally love postgresql, but > until it can meet my annoying compliance requirements, I can't leverage it > fully as

Re: [HACKERS] Raising the checkpoint_timeout limit

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 inconvenient. > >> I'm not sure what'd actually be a good upper lim

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

> On 1/31/16 7:38 PM, Kouhei Kaigai wrote: > > I'm under investigation of SSD-to-GPU direct feature on top of > > the custom-scan interface. It intends to load a bunch of data > > blocks on NVMe-SSD to GPU RAM using P2P DMA, prior to the data > > loading onto CPU/RAM, to preprocess the data to be f

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

On Mon, Feb 1, 2016 at 6:48 PM, Robert Haas wrote: > More when I have a bit more time to look at this... 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 a

Re: [HACKERS] Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby

On Sat, Jan 30, 2016 at 7:38 PM, Michael Paquier wrote: > > On Fri, Jan 29, 2016 at 9:13 PM, Michael Paquier wrote: > > Well, to put it short, I am just trying to find a way to make the > > backend skip unnecessary checkpoints on an idle system, which results > > in the following WAL pattern if sy

Re: [HACKERS] extend pgbench expressions with functions

On Tue, Feb 2, 2016 at 1:35 PM, Michael Paquier wrote: > And now there are patches. Well, nobody has complained about that until now > except me... So we could live without patching back-branches, but it don't > think it hurts much to fix those holes. Meh, s/it don't/I don't/ -- Michael --

Re: [HACKERS] extend pgbench expressions with functions

On Tue, Feb 2, 2016 at 1:24 PM, Robert Haas wrote: > On Mon, Feb 1, 2016 at 9:46 PM, Michael Paquier > wrote: > > On Mon, Feb 1, 2016 at 10:34 PM, Robert Haas > wrote: > >> On Sat, Jan 30, 2016 at 7:36 AM, Michael Paquier > >> wrote: > >>> On Fri, Jan 29, 2016 at 11:21 PM, Fabien COELHO > wro

Re: [HACKERS] extend pgbench expressions with functions

On Mon, Feb 1, 2016 at 9:46 PM, Michael Paquier wrote: > On Mon, Feb 1, 2016 at 10:34 PM, Robert Haas wrote: >> On Sat, Jan 30, 2016 at 7:36 AM, Michael Paquier >> wrote: >>> On Fri, Jan 29, 2016 at 11:21 PM, Fabien COELHO wrote: +/* overflow check (needed for INT64_MIN) */ >>>

Re: [HACKERS] PostgreSQL Audit Extension

On Sun, Jan 31, 2016 at 5:19 PM, Alvaro Herrera wrote: > Joshua D. Drake wrote: >> On 01/31/2016 05:07 AM, Alvaro Herrera wrote: >> >David Steele wrote: >> >>The attached patch implements audit logging for PostgreSQL as an >> >>extension. I believe I have addressed the concerns that were raised a

Re: [HACKERS] Raising the checkpoint_timeout limit

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 inconvenient. > 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 Audit Extension

On Mon, Feb 01, 2016 at 09:59:01PM +0100, Alvaro Herrera wrote: > Anyway I think the tests here are massive I would not want to see fewer tests. When I reviewed a previous incarnation of pgaudit, the tests saved me hours of writing my own. > and the code is not; Nah; the patch size category is

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

On Mon, Feb 1, 2016 at 8:21 PM, Dmitry Ivanov wrote: > This patch was originally developed by Teodor Sigaev and Oleg Bartunov in > 2009, so all credit goes to them. Any feedback is welcome. > This is not a small patch: 28 files changed, 2441 insertions(+), 380 deletions(-) And the last CF of 9.6

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

On Mon, Feb 1, 2016 at 11:28 PM, Fujii Masao wrote: > [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 cases like "I want to have two synchrono

Re: [HACKERS] Template for commit messages

On Mon, Feb 01, 2016 at 01:55:23PM +0200, Heikki Linnakangas wrote: > On 01/02/16 13:36, Andres Freund wrote: > >On 2016-01-28 06:03:02 -0500, Bruce Momjian wrote: > >>Reported-by: > >>Bug: > >>Author: > >>Reviewed-by: > >>Tested-by: > >>Backpatch-through: > > > >I personall

Re: [HACKERS] Several problems in tab-completions for SET/RESET

On Mon, Feb 1, 2016 at 10:22 PM, Fujii Masao wrote: > Pushed. Thanks! > OK. And attached is the promised patch for ALTER FUNCTION. -- Michael diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c index 5f27120..3369a3d 100644 --- a/src/bin/psql/tab-complete.c +++ b/src/bin/psql

Re: [HACKERS] extend pgbench expressions with functions

On Mon, Feb 1, 2016 at 10:34 PM, Robert Haas wrote: > On Sat, Jan 30, 2016 at 7:36 AM, Michael Paquier > wrote: >> On Fri, Jan 29, 2016 at 11:21 PM, Fabien COELHO wrote: >>> +/* overflow check (needed for INT64_MIN) */ >>> +if (lval != 0 && (*retval < 0 == lval < 0)) >>>

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

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" functionality is there to abstract >> rewrites of pages being copied; yo

Re: [HACKERS] PostgreSQL Audit Extension

On 2/1/16 4:19 PM, Tom Lane wrote: > Alvaro Herrera writes: >> Anyway I think the tests here are >> massive and the code is not; perhaps people get the mistaken impression >> that this is a huge amount of code which scares them. Perhaps you could >> split it up in (1) code and (2) tests, wh

Re: [HACKERS] PostgreSQL Audit Extension

[I pulled this back in from the other thread that got started. This happened because my email to pgsql-hackers bounced but was also sent to Alvaro who replied to that message not the later one that went through to hackers.] On 2/1/16 3:59 PM, Alvaro Herrera wrote: > Anyway, what would *you* do wi

[HACKERS] Ununsed member in printQueryOpt

I found the following code in src/bin/psql/print.h:155 (master 1d0c3b3f8a) boolquote; /* quote all values as much as possible */ That code was there since: commit a45195a191eec367a4f305bb71ab541d17a3b9f9 Author: Bruce Momjian Date: Thu Nov 4 21:56:02 1999 + Maj

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Pavel Stehule wrote: > 1. maybe we can decrease name to shorter "crossview" ?? I am happy with > crosstabview too, just crossview is correct too, and shorter I'm in favor of keeping crosstabview. It's more explicit, only 3 characters longer and we have tab completion anyway. > 2. Column

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

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 and it's been moved to the next CF you have to manually go to that CF and

Re: [HACKERS] "using previous checkpoint record at" maybe not the greatest idea?

On Mon, Feb 1, 2016 at 5:48 PM, Andres Freund wrote: > On 2016-02-01 17:29:39 -0700, David G. Johnston wrote: > > ​Learning by reading here... > > > > http://www.postgresql.org/docs/current/static/wal-internals.html > > """ > > ​After a checkpoint has been made and the log flushed, the checkpoint

Re: [HACKERS] statistics for shared catalogs not updated when autovacuum is off

On 2/1/16 7:20 PM, Peter Eisentraut wrote: That's probably right. Even with autovacuum on, the statistics for shared catalogs do not appear as updated right away. That is, if you run VACUUM and then look at pg_stat_sys_tables right away, you will see the stats for shared catalogs to be slightly

Re: [HACKERS] Raising the checkpoint_timeout limit

On 01-02-2016 21:13, Andres Freund wrote: > is there any reason for the rather arbitrary and low checkpoint_timeout > limit? > AFAICS the only reason is to run recover quickly. This setting is the same value since day 1. > A high timeout has the advantage that the total amount of full page > writ

Re: [HACKERS] Raising the checkpoint_timeout limit

On 2/1/16 6:13 PM, 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 idea in general. The only reason I can see for the 1 hour limit is to try and preve

Re: [HACKERS] statistics for shared catalogs not updated when autovacuum is off

On 2/1/16 9:49 AM, Jim Nasby wrote: > On 1/30/16 5:05 PM, Peter Eisentraut wrote: >> When autovacuum is off, the statistics in pg_stat_sys_tables for shared >> catalogs (e.g., pg_authid, pg_database) never update. So seq_scan >> doesn't update when you read the table, last_analyze doesn't update w

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

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" functionality is there to abstract rewrites of pages being copied; your patch is circumventing it and AFAICS it makes the interface more complica

Re: [HACKERS] WIP: Access method extendability

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, failed Spec compliant: not tested Documentation:not tested There are currently no docs or unit tests. I suspect this patch is st

[HACKERS] PostgreSQL Auditing

So Auditing, it seems that some people want auditing (myself, David Steele, 2nd quadrant, and probably others). I personally love postgresql, but until it can meet my annoying compliance requirements, I can't leverage it fully as my organization spends more time on meeting compliance, than actuall

Re: [HACKERS] silent data loss with ext4 / all current versions

On 2016-02-02 09:56:40 +0900, Michael Paquier wrote: > And there is no actual risk of data loss Huh? - Andres -- 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] silent data loss with ext4 / all current versions

On Tue, Feb 2, 2016 at 12:49 AM, Alvaro Herrera wrote: > Michael Paquier wrote: >> On Mon, Jan 25, 2016 at 6:50 PM, Tomas Vondra >> wrote: >> > Seems OK to me. Thanks for the time and improvements! >> >> Thanks. Perhaps a committer could have a look then? I have switched >> the patch as such in t

Re: [HACKERS] silent data loss with ext4 / all current versions

On Tue, Feb 2, 2016 at 1:08 AM, Andres Freund wrote: > On 2016-02-01 16:49:46 +0100, Alvaro Herrera wrote: >> Yeah. On 9.4 there are already some conflicts, and I'm sure there will >> be more in almost each branch. Does anyone want to volunteer for >> producing per-branch versions? > >> The next

Re: [HACKERS] "using previous checkpoint record at" maybe not the greatest idea?

On 2016-02-01 17:29:39 -0700, David G. Johnston wrote: > ​Learning by reading here... > > http://www.postgresql.org/docs/current/static/wal-internals.html > """ > ​After a checkpoint has been made and the log flushed, the checkpoint's > position is saved in the file pg_control. Therefore, at the s

[HACKERS] checkpoints after database start/immediate checkpoints

Hi, Right now it takes checkpoint_timeout till we start a checkpoint, and checkpoint_timeout + checkpoint_timeout * checkpoint_completion_target till we complete the first checkpoint after shutdown/forced checkpoints. That means a) that such checkpoint will often be bigger/more heavyweight than t

Re: [HACKERS] "using previous checkpoint record at" maybe not the greatest idea?

On Mon, Feb 1, 2016 at 4:58 PM, Andres Freund wrote: > Hi, > > currently if, when not in standby mode, we can't read a checkpoint > record, we automatically fall back to the previous checkpoint, and start > replay from there. > > Doing so without user intervention doesn't actually seem like a goo

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

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 - that was my initial reaction as well but then I thought the o

Re: [HACKERS] Trigger.sgml

> On 1/28/16 8:02 PM, Tatsuo Ishii wrote: >> I am working as a volunteer to translate docs to Japanese. I have been >> having hard time to parse the following sentence in >> doc/src/sgml/trigger.sgml. >> >> >> The possibility of s

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

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 and it's been moved to the next CF you have to manually go > to that CF and search for the patch. Agreed, I co

[HACKERS] Raising the checkpoint_timeout limit

Hi, is there any reason for the rather arbitrary and low checkpoint_timeout limit? Obviously it's not not appropriate to have a 10h timeout on all that many systems. But if the reaction to a server crashing is going to be a failover to one of several standbys anyway, setting the timeout to a high

[HACKERS] "using previous checkpoint record at" maybe not the greatest idea?

Hi, currently if, when not in standby mode, we can't read a checkpoint record, we automatically fall back to the previous checkpoint, and start replay from there. Doing so without user intervention doesn't actually seem like a good idea. While not super likely, it's entirely possible that doing s

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

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 deparseSelectSqlForJoinRel to > construct SELECT and FROM clauses for base and j

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

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 and it's been moved to the next CF you have to manually go to that CF and search for the patch. [1] https://commitfest.postgresql

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

Masahiko Sawada wrote: > Attached updated version patch. > Please review it. In pg_upgrade, the "page convert" functionality is there to abstract rewrites of pages being copied; your patch is circumventing it and AFAICS it makes the interface more complicated for no good reason. I think the real

Re: [HACKERS] Removing Functionally Dependent GROUP BY Columns

This patch got a good share of review, so it's fair to move it to the next commitfest. I marked it as ready-for-committer there which seems to be the right status. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: [HACKERS] proposal: add 'waiting for replication' to pg_stat_activity.state

Thomas Munro wrote: > Thinking of other patches in flight, I think I'd want the proposed > N-sync standbys feature to be able to explain in more detail what it's > waiting for (and likewise my causal reads proposal which does that via > the process title), though I realise that the details of how/

Re: [HACKERS] checkpointer continuous flushing

This patch got its fair share of reviewer attention this commitfest. Moving to the next one. Andres, if you want to commit ahead of time you're of course encouraged to do so. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training &

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

David Steele wrote: > On 1/11/16 6:50 PM, Alvaro Herrera wrote: > >David Steele wrote: > >>The patch creates a new counter to separate the log filtering from the > >>authentication functionality. This makes it possible to get the same > >>filtering in other parts of the code (or extensions) withou

Re: [HACKERS] snapshot too old, configured by time

Kevin Grittner wrote: > > There has been a review but no replies for more than 1 month. Returned > > with feedback? > > I do intend to post another version of the patch to tweak the > calculations again, after I can get a patch in to expand the > testing capabilities to allow an acceptable way to

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

Victor Wagner wrote: > On Fri, 22 Jan 2016 16:36:15 -0300 > Alvaro Herrera wrote: > > > You're editing the expected file for the libpq-regress thingy, but you > > haven't added any new lines to test the new capability. I think it'd > > be good to add some there. (I already said this earlier in

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

Corey Huinker wrote: > Enjoy. Didn't actually look into the patch but looks like there's progress here and this might be heading for commit. Moving to next one. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: [HACKERS] pg_hba_lookup function to get all matching pg_hba.conf entries

Haribabu Kommi wrote: > Hi, Do you have any further comments on the patch that needs to be > taken care? I do. I think the jsonb functions you added should be added to one of the json .c files instead, since they seem of general applicability. But actually, I don't think you have ever replied to

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On 2016-02-01 22:35:06 +0100, Alvaro Herrera wrote: > I know Andres is already pretty busy with the checkpoint flush patch and > I very much doubt he will be able to give this patch a lot of attention > in the short term. Moving to next CF. Yea, there's no realistic chance I'll be able to take ca

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

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 > >> 3231393151 > >> 64387339496830 > >> 12830

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

Alexander Korotkov wrote: > Attached patch is rebased and have better comments. > Also, there is one comment which survive since original version by Andres. > > /* Add exponential backoff? Should seldomly be contended tho. */ > > > Andres, did you mean we should twice the delay with each unsucc

Re: [HACKERS] Spurious standby query cancellations

Simon Riggs wrote: > This looks good to me, apart from some WhitespaceCrime. > > Header split applied, will test and apply the main patch this week. Since the patch already appears to have a committer's attention, it's okay to move it to the next commitfest; if Simon happens to commit ahead of t

Re: [HACKERS] PostgreSQL Audit Extension

Alvaro Herrera writes: > Anyway I think the tests here are > massive and the code is not; perhaps people get the mistaken impression > that this is a huge amount of code which scares them. Perhaps you could > split it up in (1) code and (2) tests, which wouldn't achieve any > technical bene

Re: [HACKERS] WIP: Access method extendability

Alexander Korotkov wrote: > Hi! > > Patches was rebased against master. > > In the attached version of patch access methods get support of pg_dump. Thanks. This patch came in just as the commitfest was ending, so I'm moving it to the next one. -- Álvaro Herrerahttp://www.2ndQu

Re: [HACKERS] pl/pgSQL, get diagnostics and big data

On 01.02.2016 21:24, Andreas 'ads' Scherbaum wrote: Attached patch expands the row_count to 64 bit. Remembering an issue we had recently with clear text patches, attached is a gzipped version as well. Regards, -- Andreas 'ads' Scherbaum German PostgreSQL Us

Re: [HACKERS] PostgreSQL Audit Extension

David Steele wrote: > On 1/31/16 8:07 AM, Alvaro Herrera wrote: > > I'm giving > > this patch some more time by moving it to next commitfest instead. > > I was under the mistaken impression that the CF was two months long so I > appreciate getting a little more time. Yeah, sorry to disappoint bu

Re: [HACKERS] extend pgbench expressions with functions

Yet another rebase, so as to propagate the same special case checks int for / and %. -- Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml index ade1b53..ebaf4e5 100644 --- a/doc/src/sgml/ref/pgbench.sgml +++ b/doc/src/sgml/ref/pgbench.sgml @@ -796,17 +796,21 @@

[HACKERS] pl/pgSQL, get diagnostics and big data

Hello, one of our customers approached us and complained, that GET DIAGNOSTICS row_count returns invalid results if the number of rows is > 2^31. It's a bit complicated to test for this case, so I set up a separate instance with this patch, and inserted 2^32+x rows into a table. Internally,

Re: [HACKERS] PostgreSQL Audit Extension

On 1/31/16 8:07 AM, Alvaro Herrera wrote: > David Steele wrote: >> The attached patch implements audit logging for PostgreSQL as an >> extension. I believe I have addressed the concerns that were raised at >> the end of the 9.5 development cycle. > > This patch got no feedback at all during the c

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

Hi, 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 failures, mostly on animals axolotl and shearwater, I found that this pat

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

On 29.01.2016 18:58, Artur Zakirov wrote: On 29.01.2016 18:39, Alvaro Herrera wrote: Teodor Sigaev wrote: The behavior of this function is surprising to me. select substring_similarity('dog' , 'hotdogpound') ; substring_similarity -- 0.25 Substring s

Re: [HACKERS] pgbench stats per script & other stuff

Hello Michaël, Two rebase attached. - 15-e: prefix selection for -b - if (strncmp(builtin_script[i].name, name, - strlen(builtin_script[i].name)) == 0) + if (strncmp(builtin_script[i].name, name, len) == 0) I agree with Alv

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

hi I am sorry, I am writing from mobile phone and I cannot to cutting text well. Dne 29. 1. 2016 18:09 napsal uživatel "Catalin Iacob" < iacobcata...@gmail.com>: This interface is new generation of previous > > functions: info, notice, warning, error with keyword parameters interface. I > > didn'

[HACKERS] Fix KNN GiST ordering type

Hi! 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 function should always return float8. I think it is just a typo. Should be backpatched to 9

Re: [HACKERS] [PATCH] better systemd integration

Hi > index 2e7f1d7..d983a50 100644 > --- a/src/backend/postmaster/postmaster.c > +++ b/src/backend/postmaster/postmaster.c > @@ -4933,6 +4933,11 @@ sigusr1_handler(SIGNAL_ARGS) > if (XLogArchivingAlways()) > PgArchPID = pgarch_start(); > > +#ifdef USE_SYSTEMD > + if (!Ena

Re: [HACKERS] silent data loss with ext4 / all current versions

On 2016-02-01 16:49:46 +0100, Alvaro Herrera wrote: > Yeah. On 9.4 there are already some conflicts, and I'm sure there will > be more in almost each branch. Does anyone want to volunteer for > producing per-branch versions? > The next minor release is to be tagged next week and it'd be good to

Re: [HACKERS] silent data loss with ext4 / all current versions

On 2016-01-25 16:30:47 +0900, Michael Paquier wrote: > diff --git a/src/backend/access/transam/xlog.c > b/src/backend/access/transam/xlog.c > index a2846c4..b124f90 100644 > --- a/src/backend/access/transam/xlog.c > +++ b/src/backend/access/transam/xlog.c > @@ -3278,6 +3278,14 @@ InstallXLogFileSe

Re: [HACKERS] silent data loss with ext4 / all current versions

Michael Paquier wrote: > On Mon, Jan 25, 2016 at 6:50 PM, Tomas Vondra > wrote: > > Seems OK to me. Thanks for the time and improvements! > > Thanks. Perhaps a committer could have a look then? I have switched > the patch as such in the CF app. Seeing the accumulated feedback > upthread that's so

Re: [HACKERS] Template for commit messages

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 FWIW, I read the git logs quite a bit, especially after a release to gather some stats, and I *love* the commits that have some nice standard, easy to read fields (Alvaro for one does a great job at this). I don't think we need to mandate it,

Re: [HACKERS] Trigger.sgml

On 1/28/16 8:02 PM, Tatsuo Ishii wrote: I am working as a volunteer to translate docs to Japanese. I have been having hard time to parse the following sentence in doc/src/sgml/trigger.sgml. The possibility of surprising outcome

Re: [HACKERS] statistics for shared catalogs not updated when autovacuum is off

On 1/30/16 5:05 PM, Peter Eisentraut wrote: When autovacuum is off, the statistics in pg_stat_sys_tables for shared catalogs (e.g., pg_authid, pg_database) never update. So seq_scan doesn't update when you read the table, last_analyze doesn't update when you run analyze, etc. But when you shut

Re: [HACKERS] WAL Re-Writes

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_level is less than 'archive' which lead to this problem. So with this exp

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

On 1/31/16 7:38 PM, Kouhei Kaigai wrote: > I'm under investigation of SSD-to-GPU direct feature on top of > the custom-scan interface. It intends to load a bunch of data > blocks on NVMe-SSD to GPU RAM using P2P DMA, prior to the data > loading onto CPU/RAM, to preprocess the data to be filtered ou

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

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 >>> wrote: On Sun, Jan 31, 2016 at 5:08 PM, Masahiko Sawada

Re: [HACKERS] Transactions involving multiple postgres foreign servers

Alvaro Herrera wrote: > Ashutosh Bapat wrote: > > > Here's updated patch. I didn't use version numbers in file names in my > > previous patches. I am starting from this onwards. > > Um, I tried this patch and it doesn't apply at all. There's a large > number of conflicts. Please update it and r

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

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...@anarazel.de < > and...@anarazel.de> wrote: > > > > I do think there's a c

Re: [HACKERS] extend pgbench expressions with functions

On Sat, Jan 30, 2016 at 7:36 AM, Michael Paquier wrote: > On Fri, Jan 29, 2016 at 11:21 PM, Fabien COELHO wrote: >> +/* overflow check (needed for INT64_MIN) */ >> +if (lval != 0 && (*retval < 0 == lval < 0)) >> >> Why not use "if (lval == INT64_MIN)" instead of this compl

Re: [HACKERS] Several problems in tab-completions for SET/RESET

On Mon, Feb 1, 2016 at 9:23 PM, Michael Paquier wrote: > On Mon, Feb 1, 2016 at 9:15 PM, Fujii Masao wrote: >> If we do that, we also should change the tab-completion for SET command >> so that "=" is suggested. But I'm afraid that which might decrease that >> tab-completion. >> >> Imagine the cas

Re: [HACKERS] Fwd: [DOCS] pgbench doc typos

On Wed, Jan 27, 2016 at 8:32 PM, Erik Rijkers wrote: > On 2016-01-27 11:06, Erik Rijkers wrote: >> >> Two trivial changes to doc/src/sgml/ref/pgbench.sgml - Here is example outputs: + Here is example output: "Here are example outputs" is better? In 9.4 document, that description was used fo

Re: [HACKERS] Template for commit messages

On Mon, Feb 1, 2016 at 1:04 PM, Andres Freund wrote: > On 2016-02-01 12:56:21 +0100, Magnus Hagander wrote: > > Let's just assume that we can fix that part. As in, we can expose either > an > > internal db id or a short hash or something, from the archives server. We > > could then have that visi

Re: [HACKERS] Comment typos in source code: s/thats/that is/

On Mon, Feb 1, 2016 at 7:44 PM, Magnus Hagander wrote: > On Thu, Jan 28, 2016 at 1:39 PM, Michael Paquier > wrote: >> I found a couple of typos as per the $subject. >> A patch is attached. > > Applied, thanks. Thanks. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq

Re: [HACKERS] Several problems in tab-completions for SET/RESET

On Mon, Feb 1, 2016 at 9:15 PM, Fujii Masao wrote: > If we do that, we also should change the tab-completion for SET command > so that "=" is suggested. But I'm afraid that which might decrease that > tab-completion. > > Imagine the case of "SET work_mem ". If "TO" and "=" are suggested, > we need

Re: [HACKERS] Template for commit messages

Andres Freund wrote: > On 2016-02-01 12:56:21 +0100, Magnus Hagander wrote: > > Let's just assume that we can fix that part. As in, we can expose either an > > internal db id or a short hash or something, from the archives server. We > > could then have that visible/linkable directly on the archive

Re: [HACKERS] Several problems in tab-completions for SET/RESET

On Mon, Feb 1, 2016 at 3:14 PM, Michael Paquier wrote: > On Mon, Feb 1, 2016 at 1:21 PM, Fujii Masao wrote: >> On Fri, Jan 29, 2016 at 1:02 PM, Michael Paquier >> wrote: >>> On Fri, Jan 29, 2016 at 11:53 AM, Fujii Masao wrote: I removed the above and added the following for that case.

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

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." > Therefore, any assumption about the sign of the result is wrong anyway, > and any patch that depends on it will be rejected, regar

Re: [HACKERS] Template for commit messages

On 2016-02-01 12:56:21 +0100, Magnus Hagander wrote: > Let's just assume that we can fix that part. As in, we can expose either an > internal db id or a short hash or something, from the archives server. We > could then have that visible/linkable directly on the archives page, and > one could copy/

Re: [HACKERS] Template for commit messages

On Mon, Feb 1, 2016 at 12:53 PM, Michael Paquier wrote: > On Mon, Feb 1, 2016 at 8:36 PM, Andres Freund wrote: > > I personally, and I realize that I'm likely alone on that, would really > > like to see references to relevant threads. A year after a commit or > > such it often starts to get hard

Re: [HACKERS] Template for commit messages

On 01/02/16 13:36, Andres Freund wrote: On 2016-01-28 06:03:02 -0500, Bruce Momjian wrote: Reported-by: Bug: Author: Reviewed-by: Tested-by: Backpatch-through: I personally, and I realize that I'm likely alone on that, would really like to see re

Re: [HACKERS] Template for commit messages

On 2016-02-01 20:53:56 +0900, Michael Paquier wrote: > Last time this was suggested though there were concerns regarding the > 72-80 character limit per line in a commit message. That seems like a misdirect. The limit is there to keep things readable, not because there's a hard technical limit. So

Re: [HACKERS] Template for commit messages

On Mon, Feb 1, 2016 at 8:36 PM, Andres Freund wrote: > I personally, and I realize that I'm likely alone on that, would really > like to see references to relevant threads. A year after a commit or > such it often starts to get hard to know which threads a commit was > about. Often it's easy enou

  1   2   >