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

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

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

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

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

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 Herrera

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

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

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

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

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

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

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

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

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

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

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

[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

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

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)

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

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

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

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

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

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

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 >

[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

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

[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

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

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

[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

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

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

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

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

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.

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

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

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

[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

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

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

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

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

On Mon, Feb 1, 2016 at 10:26 AM, Amit Kapila wrote: > On Sat, Jan 30, 2016 at 2:15 PM, Alexander Korotkov < > a.korot...@postgrespro.ru> wrote: > > > > On Sat, Jan 30, 2016 at 10:58 AM, Amit Kapila > wrote: > >> > >> On Fri, Jan 29, 2016 at 6:47

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

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,

Re: [HACKERS] extend pgbench expressions with functions

Hello Michaël, - remove the short macros (although IMO it is a code degradation) FWIW, I like this suggestion from Robert. I'm not especially found of macros, my main reserve is that because of the length of the function names this necessarily creates lines longer than 80 columns or

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Mon, Feb 1, 2016 at 7:05 AM, Dilip Kumar wrote: > > On Sun, Jan 31, 2016 at 11:44 AM, Dilip Kumar > wrote: > >> By looking at the results with scale factor 1000 and 100 i don't see any >> reason why it will regress with scale factor 300. >> >> So

Re: [HACKERS] Proposal: Generic WAL logical messages

On 1 February 2016 at 09:45, Alexander Korotkov wrote: > On Sat, Jan 30, 2016 at 11:58 AM, Simon Riggs wrote: >> >> On 29 January 2016 at 21:11, Alexander Korotkov >> wrote: >>> >>> Should we think more about naming?

Re: [HACKERS] Template for commit messages

Joshua D. Drake wrote: > On 01/31/2016 04:34 PM, Michael Paquier wrote: > >This page would need a refresh IMO. I think it has not been touched > >for the last couple of years. > > No doubt but if we can't bother to keep that refreshed what makes us think > that a structured format in commit

[HACKERS] Copy-pasto in the ExecForeignDelete documentation

Hi, While working on FDW DML pushdown, I ran into a copy-pasto in the ExecForeignDelete documentation in fdwhandler.sgml: The data in the returned slot is used only if the DELETE query has a RETURNING clause or the foreign table has an AFTER ROW trigger. Triggers require all

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Mon, Feb 1, 2016 at 11:34 AM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Mon, Feb 1, 2016 at 7:05 AM, Dilip Kumar wrote: > >> >> On Sun, Jan 31, 2016 at 11:44 AM, Dilip Kumar >> wrote: >> >>> By looking at the results with scale

Re: [HACKERS] How can I build OSSP UUID support on Windows to avoid duplicate UUIDs?

高增琦 wrote: > : ( > > still don't know how to build ossp-uuid on windows with MSVC. > Saito san's patch doesn't fix all errors during compiling... I don't understand why you want to build that specific module on Windows. Doesn't Windows have its own UUID generator that you can access, using a

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

On Thu, Jan 28, 2016 at 1:39 PM, Michael Paquier wrote: > Hi all, > > I found a couple of typos as per the $subject. > A patch is attached. > Applied, thanks. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

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

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

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

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

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,

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

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

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

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

[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

[HACKERS] [PATCH] Phrase search ported to 9.6

Hi Hackers, Although PostgreSQL is capable of performing some FTS (full text search) queries, there's still a room for improvement. Phrase search support could become a great addition to the existing set of features. Introduction It is no secret that one can make Google search

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

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

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

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

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: [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.

Re: [HACKERS] Template for commit messages

On Mon, Feb 1, 2016 at 6:13 PM, Alvaro Herrera wrote: > Joshua D. Drake wrote: > > On 01/31/2016 04:34 PM, Michael Paquier wrote: > > > >This page would need a refresh IMO. I think it has not been touched > > >for the last couple of years. > > > > No doubt but if we

Re: [HACKERS] Template for commit messages

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 references to relevant threads. A year after

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.

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

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

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

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

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

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 > wrote: This patch was originally developed by Teodor

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

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

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

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

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

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

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

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

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

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

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

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

  1   2   >