ring the pg_proc entry for a function, so the new code
didn't fit. Ultimately, ExecAlterExtensionContentsStmt() was the closest
match, so that's where I did it.
Comments welcome. I'll add this patch to the CF.
-- Abhijit
>From 9835f0990a015431393d608c8710d9effe301c9d Mon Sep 17 00:00:0
At 2016-02-29 19:56:07 -0600, jim.na...@bluetreble.com wrote:
>
> I don't see why this would be limited to just functions. […] Am I
> missing something?
No, you are not missing anything. The specific problem I was trying to
solve involved a function, so I sketched out a solution for functions.
Onc
At 2016-03-10 08:35:43 +0100, michael.paqu...@gmail.com wrote:
>
> > I guess the easiest fix would be to shell out to initdb -s?
>
> What do you mean? I am not sure what initdb has to do with that as we
> have no need for it in pg_rewind.
initdb -S/--sync-only fsyncs everything in the data direct
At 2016-03-19 17:46:25 -0300, alvhe...@2ndquadrant.com wrote:
>
> I don't think the first patch is acceptable standalone -- we need both
> things together.
OK.
> But in reality, pg_depend handling is mixed up with other changes all
> over the place.
Yes, I noticed that. :-/
> Anyway I think thi
At 2016-03-21 13:04:33 +0300, a.korot...@postgrespro.ru wrote:
>
> I'm not sure why we want to make new dependency type by ALTER FUNCTION
> command, not ALTER EXTENSION?
It's a matter of semantics. It means something very different than what
an 'e' dependency means. The extension doesn't own the f
red.
-- Abhijit
>From 722f23b75369f035f094753e47663c50580b052c Mon Sep 17 00:00:00 2001
From: Abhijit Menon-Sen
Date: Tue, 1 Mar 2016 06:44:28 +0530
Subject: =?UTF-8?q?Add=20DEPENDENCY=5FAUTO=5FEXTENSION/ALTER=20FUNCTION=20?=
=?UTF-8?q?=E2=80=A6=20DEPENDS=20ON=20EXTENSION=20=E2=80=A6?=
MIME-V
At 2016-03-21 15:43:09 -0400, robertmh...@gmail.com wrote:
>
> I also think we should allow a function to depend on multiple
> extensions, as Alvaro mentions downthread.
I'm working on an updated patch, will post shortly.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
Hi.
I implemented "ALTER FUNCTION … DEPENDS ON EXTENSION" using a new node
(AlterObjectDependsStmt), and tried to add "ALTER TRIGGER … DEPENDS ON
EXTENSION" (partly because I wanted to make sure the code could support
multiple object types, partly because it's convenient in this particular
use cas
At 2016-03-24 12:31:16 -0300, alvhe...@2ndquadrant.com wrote:
>
> In other words I think the conclusion here is that we must use
> qualified_name in the new production rather than switching the old
> production to any_name.
Makes sense.
> I think I would like to see code implement both alternativ
At 2016-03-24 22:48:51 +0530, a...@2ndquadrant.com wrote:
>
> > I think I would like to see code implement both alternatives to see
> > which one is least ugly. Maybe a third idea will manifest itself
> > upon seeing those.
>
> Here's the first one. ExecAlterObjectDependsStmt() looks like this:
Hi.
I'm looking at an extension that creates some triggers (on user tables)
dynamically (i.e., not during CREATE EXTENSION, but afterwards). The
author has two problems with it:
* «DROP EXTENSION ext» won't work without adding CASCADE, which is an
(admittedly relatively minor) inconvenience to
I'm sorry, it wasn't clear from my earlier post that the triggers are
dependent on a function provided by the extension.
So when you do CREATE EXTENSION foo, it creates foo_somefunc() that
RETURNS TRIGGER. Later, a trigger is created (somehow; in this case it
is by some other function in the exten
Right, here's another try.
The extension does trigger-based DML auditing. You install it using
CREATE EXTENSION and then call one of its functions to enable auditing
for a particular table. That function will create a customised trigger
function based on the table's columns and a trigger that uses
At 2016-01-16 12:18:53 -0500, robertmh...@gmail.com wrote:
>
> This seems like one manifestation of the more general problem that we
> don't have any real idea what objects a function definition depends
> on.
Yes.
I'm proposing to address a part of that problem by allowing extension
dependencies
At 2016-02-22 07:45:37 +, e...@xs4all.nl wrote:
>
> I think what's needed is:
>
> use 5.008_008;
That is meant to fail if the code is run on a version of Perl older than
5.8.8, not fail if the code uses language features not present in 5.8.8.
It is little help for those trying to maintain ba
s of the original patch). Rather than trying
to untangle that right now, I'm posting what I have as-is, and I'll post
an updated version tomorrow.
-- Abhijit
commit 999c0c2632f0d4c20d20b9ac30cd258305f74bac
Author: Abhijit Menon-Sen
Date: Wed Aug 31 22:18:07 2016 +05
At 2016-09-01 15:51:11 +0900, michael.paqu...@gmail.com wrote:
>
> - (errmsg("starting point-in-time recovery to XID %u",
> - recoveryTargetXid)));
> User loses information if those logs are removed.
Agreed. I'm revising the patch right now, and I decide
At 2016-09-04 07:02:01 +0100, si...@2ndquadrant.com wrote:
>
> > By the way, what has been committed does not include the patch
> > adding the parsing context in case of an error as wanted upthread.
> > Perhaps that's not worth adding now as there is the GUC refactoring
> > potentially happening fo
ed order (which would also
break the current last-mention-wins behaviour).
Thoughts? (I've added Fujii to the Cc: list, in case he has any
comments, since this is based on his earlier patch.)
-- Abhijit
commit c20d735648f5ea867fda5afc499a63d3877536a3
Author: Abhijit Menon-Sen
Date: Thu Sep 1 0
At 2016-09-06 14:40:54 +0900, michael.paqu...@gmail.com wrote:
>
> my best advice here is to make all those recovery_target_* parameters
> PGC_POSTMASTER so as they are loaded only once when the server starts,
> and then we define the recovery target type used in the startup
> process instead of tr
At 2016-09-06 10:56:53 +0200, p...@2ndquadrant.com wrote:
>
> So +1 on the recovery_target = 'xid:xxx' idea.
OK, I'll make it work that way. New patch in a couple of days.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
htt
another update very soon.
>From 231ccefbc99c07f00560f4e88a961db186db704e Mon Sep 17 00:00:00 2001
From: Abhijit Menon-Sen
Date: Mon, 31 Oct 2016 11:32:51 +0530
Subject: Convert recovery.conf settings to GUCs
Based on unite_recoveryconf_postgresqlconf_v3.patch by Fujii Masao.
---
co
At 2016-11-04 10:35:05 +, si...@2ndquadrant.com wrote:
>
> Since the "lots of parameters" approach is almost exactly what we have
> now, I think we should do that first, get this patch committed and
> then sit back and discuss an improved API and see what downsides it
> introduces.
Thanks, I a
At 2014-06-12 16:08:05 -0700, shreesha1...@gmail.com wrote:
>
> I need to initialize the db as the root and start the database server.
Why?
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/
At 2014-06-10 18:04:13 +0900, furu...@pm.nttdata.co.jp wrote:
>
> The function works fine. It is a good to the learning of PostgreSQL.
Thanks for having a look.
> pg_xlogdump.c: In function ‘XLogDumpStatsRow’:
> pg_xlogdump.c:851: warning: format ‘%20llu’ expects type ‘long long unsigned
> int’,
nbtxlog.c:btree_xlog_vacuum() contains the following comment:
* XXX we don't actually need to read the block, we just need to
* confirm it is unpinned. If we had a special call into the
* buffer manager we could optimise this so that if the block is
* not in shared_buffers we c
At 2014-06-13 13:39:58 +0200, and...@2ndquadrant.com wrote:
>
> > void (*rm_desc) (StringInfo buf, uint8 xl_info, char *rec);
> > void (*rm_desc) (StringInfo buf, XLogRecord *record);
> >
> > […]
>
> +1. I've found this annoying in the past.
I like it too. I was just moving some code from pg_xlo
Hi.
There are 92 outstanding patches in this CommitFest, and 63 of them do
not have any reviewer. Those are very large numbers, so I hope everyone
will pitch in to keep things moving along.
There's quite a variety of patches available for review this time, and
any level of feedback about them is
(Cc: to pgsql-bugs dropped.)
At 2014-03-17 18:24:55 +1100, kommi.harib...@gmail.com wrote:
>
> *** a/doc/src/sgml/xfunc.sgml
> --- b/doc/src/sgml/xfunc.sgml
> ***
> *** 153,159 SELECT clean_emp();
> --- 153,186
> (\) (assuming escape string syntax) in the body of
>
Hi.
Just a few minor comments about your patch:
At 2014-06-13 11:46:21 +0530, amit.kapil...@gmail.com wrote:
>
> + Notes
> +
> +
> +This command will not allow to set parameters that are disallowed or
> +excluded in postgresql.conf. It also disallows to set configuration
> +paramet
At 2014-05-30 16:04:33 +0700, the.ap...@gmail.com wrote:
>
> While developing some XML processing queries, i stumbled on an old bug
> mentioned in http://wiki.postgresql.org/wiki/Todo#XML: Fix Nested or
> repeated xpath() that apparently mess up namespaces.
Thanks for the patch, and welcome to Pos
At 2014-06-13 10:29:24 -0400, t...@sss.pgh.pa.us wrote:
>
> I wonder whether we should just get rid of log_disconnections as a
> separate variable, instead logging disconnections when log_connections
> is set.
I like that idea.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
At 2014-06-17 09:49:35 +0530, amit.kapil...@gmail.com wrote:
>
> By above do you mean that the patch should allow GUC_NOT_IN_SAMPLE or
> something else, if earlier then I have removed it as per comment from
> Fujji-san.
Yes, what you've done in v3 of the patch is what I meant. I've marked
this as
At 2014-06-13 20:07:29 +0530, rahilasye...@gmail.com wrote:
>
> Patch named Support-for-lz4-and-snappy adds support for LZ4 and Snappy
> in PostgreSQL.
I haven't looked at this in any detail yet, but I note that the patch
creates src/common/lz4/.travis.yml, which it shouldn't.
I have a few prelim
At 2014-06-17 23:26:37 +0900, maumau...@gmail.com wrote:
>
> Hello,
>
> As I proposed before in the thread below, I've implemented a simple
> command for reliable WAL archiving. I would appreciate it if you
> could review and test the patch.
Please add your patch to the next CF (i.e. 2014-08), s
At 2014-06-17 08:02:59 -0700, m...@joeconway.com wrote:
>
> That first hunk refers to dblink -- I'm guessing it does not belong
> with this patch.
Yes, it's a leftover of the dblink memory leak patch that's in this CF.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
At 2014-06-17 11:32:37 -0400, br...@momjian.us wrote:
>
> > SRFs in the SELECT targetlist tend to leak memory; this is not easily
> > fixable, and nobody is likely to try hard considering the feature's on
> > the edge of deprecation anyhow.
>
> Uh, what is replacing SRFs? CTEs?
I don't think Tom
At 2014-06-17 12:47:19 -0400, alvhe...@2ndquadrant.com wrote:
>
> > > P.S. If you tag your reviews with [REVIEW] in the Subject, it'll
> > > be easier to keep track of them.
> >
> > I and, I believe, various other people hate that style, because at
> > least in Gmail, it breaks the threading. It
At 2014-06-17 15:31:33 -0300, klaussfre...@gmail.com wrote:
>
> On Tue, Jun 17, 2014 at 8:47 AM, Abhijit Menon-Sen
> wrote:
> > if (compress_backup_block = BACKUP_BLOCK_COMPRESSION_SNAPPY)
>
> You mean == right?
Of course. Thanks.
-- Abhijit
--
Sent via pgsql
At 2014-06-18 12:55:36 +0900, masao.fu...@gmail.com wrote:
>
> Also I'm thinking to backpatch this to 9.4 because this is a bugfix
> rather than new feature.
That sounds reasonable, thanks.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Thanks, I've marked this ready for committer.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
At 2014-06-18 18:10:34 +0530, rahilasye...@gmail.com wrote:
>
> palloc() is disallowed in critical sections and we are already in CS
> while executing this code. So we use malloc().
Are these allocations actually inside a critical section? It seems to me
that the critical section starts further do
At 2014-06-18 18:25:34 +0530, a...@2ndquadrant.com wrote:
>
> Are these allocations actually inside a critical section? It seems to me
> that the critical section starts further down, but perhaps I am missing
> something.
OK, I was missing that XLogInsert() itself can be called from inside a
criti
At 2014-06-18 15:33:37 +0200, dep...@gmail.com wrote:
>
> Hi,
>
> In September 2013, there was patch sent by Stas Kelvich (
> http://www.postgresql.org/message-id/9e07e159-e405-41e2-9889-a04f534fc...@gmail.com)
> that adds indexable kNN searches to cube contrib module.
>
> What is needed so that
At 2014-06-18 10:44:56 -0700, j...@agliodbs.com wrote:
>
> I'm unclear on why we would overload pg_resetxlog for this.
Because pg_resetxlog already does something very similar, so the patch
is small. If it were independent, it would have to copy quite some code
from pg_resetxlog.
> Wouldn't it b
At 2014-06-19 10:58:34 +0200, pavel.steh...@gmail.com wrote:
>
> Hello
>
> pgbouncer has idle_transaction_timeout defined some years without any
> problems, so we can take this design
>
> idle_transaction_timeout
Let's steal the name too. :-)
(I didn't realise there was precedent in pgbouncer,
At 2014-06-19 13:33:03 +0200, p...@2ndquadrant.com wrote:
>
> I think quite the opposite, it's better to say we don't support the
> obscure platform than saying that we do and have no active testing or
> proof that it indeed does and somebody finding the hard way that there
> are issues.
Yes, I st
At 2014-06-19 08:42:01 -0700, kgri...@ymail.com wrote:
>
> I'm not sure whether using the same name as pgbouncer for the same
> functionality makes it less confusing or might lead to confusion
> about which layer is disconnecting the client.
I don't think the names of the respective configuration
At 2014-06-19 17:53:17 +0200, vik.fear...@dalibo.com wrote:
>
> I much prefer with "in" but it doesn't much matter.
If you look at similar settings like statement_timeout, lock_timeout,
etc., what comes before the _timeout is a concrete *thing* that can
timeout, or that a timeout can be applied to
At 2014-06-21 23:54:58 +0200, vik.fear...@dalibo.com wrote:
>
> > I'll flip this to Waiting on Author for those changes.
>
> And back to Needs Review.
I've marked it Ready for Committer after a quick read-through.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
At 2014-06-22 19:45:08 -0700, david.g.johns...@gmail.com wrote:
>
> On Sunday, June 22, 2014, Kevin Grittner-5 [via PostgreSQL] <
> ml-node+s1045698n580830...@n5.nabble.com> wrote:
>
> > If we stick with the rule that what is to the left of _timeout is
> > what is being cancelled, the a GUC to can
Hi.
One week into the CommitFest, we now have nine committed patches, ten
ready for committer, fourteen waiting on their author, and fifty-nine
still awaiting review.
Thanks to all the people who submitted a review (and a special mention
for MauMau for reviewing the most patches so far, of which
Hi.
What's the status of this patch? Jeff, Álvaro, you're listed as
reviewers. Have you had a chance to look at the updated version
that Nick posted?
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
(I'm replying as co-author of pgaudit.)
At 2014-06-23 19:15:39 +0900, masao.fu...@gmail.com wrote:
>
> You added this into CF, but its patch has not been posted yet. Are you
> planning to make a patch?
It's a self-contained contrib module. I thought Ian had posted a
tarball, but it looks like he
At 2014-06-23 08:50:33 -0400, sfr...@snowman.net wrote:
>
> I'm not a huge fan of adding this as a contrib module
I added it to the CF because we're interested in auditing functionality
for 9.5, and as far as I can tell, there's nothing better available. At
the moment, the contrib module has the
At 2014-06-23 16:51:55 -0400, sfr...@snowman.net wrote:
>
> We can't control what gets audited through the catalog and have to
> manage that outside of PG, right?
Right. I understand now.
> Are both the connected user and the current role that the command is
> running under logged?
Yes, they are
At 2014-06-24 14:21:24 +0430, soroosh.sard...@gmail.com wrote:
>
> By the way, following code has two different output and it is weird.
I get the same output from both queries with both 9.3.4 and HEAD:
ir
---
[90,100)
[500,510)
(2 rows)
If you're reporting a problem, please ma
At 2014-06-24 12:49:17 +0200, li...@hasibether.at wrote:
>
> Is there a list of possible hooks, or maybe a little docu or overview?
The best I found was "git grep _hook_type" and then read the code to
understand when and why the hook was called.
> Especially hooks to catch Insert, Update and Dele
At 2014-06-24 14:02:11 -0400, sfr...@snowman.net wrote:
>
> Will you (collectively) be working in this direction for 9.5?
We have some time available to work on it, but not so much that I want
to write any more code without a clearer idea of what might be accepted
eventually for inclusion.
-- Abh
Hi.
I reviewed the version of this patch without log_line_prefix support,
since that seemed to be generally acceptable in followup discussion.
The patch didn't apply any more because of some changes to guc.c, but it
was trivial to regenerate (fixed patch attached).
> diff --git a/src/backend/uti
Hi.
At 2014-04-20 01:06:43 +0200, alhash...@alhashash.net wrote:
>
> To use unaccent dictionary for these languages, we need to allow empty
> targets to remove diacritics instead of replacing them.
Your patch should definitely add a test case or two to sql/unaccent.sql
and expected/unaccent.out s
At 2014-06-25 00:10:55 -0400, sfr...@snowman.net wrote:
>
> For my part, the nexts steps might be to consider how you'd migrate
> what you've provided for configuration into catalog tables
I must confess that I do not understand what needs to be migrated into
the catalog tables, or why. Of course,
At 2014-06-25 16:13:19 +0900, masao.fu...@gmail.com wrote:
>
> Categorizing this parameter to CONN_AUTH_SETTINGS looks strange to me
Oh yes. Sorry, I meant to respond to this point in my original review,
but forgot. Yes, CONN_AUTH_SETTINGS is just weird. But I couldn't find
an obviously better ans
At 2014-06-25 10:36:07 -0400, sfr...@snowman.net wrote:
>
> To me, that's ridiculous on the face of it. Other databases have had
> this kind of capability as a matter of course for decades- we are far
> behind in this area.
OK, I've done a bit more thinking, but I'm not convinced that it's so
cut
Hi.
I've attached a patch to contrib/unaccent as outlined in my review the
other day. I'm familiar with multiple languages in which modifiers are
separate characters (but not Arabic), so I decided to try a quick test
because I was curious.
I added a line containing only U+0940 (DEVANAGARI VOWEL S
Hi.
When this patch was first added to a CF, I had a quick look at it, but
left it for a proper review by someone more familiar with PL/Python
internals for precisely this reason:
> 2) You removed the comment:
> - /*
> - * We don't support arrays of row ty
At 2014-06-29 18:08:53 +0530, a...@2ndquadrant.com wrote:
>
> I think the patch is ready for committer.
That's based on my earlier quick look and the current archaeology. But
I'm not a PL/Python user, and Ronan signed up to review the patch, so I
haven't changed the status.
Ronan, did you get a c
At 2014-06-29 20:35:04 +0900, maumau...@gmail.com wrote:
>
> Thanks, I marked it as ready for committer. I hope Fujii san or
> another committer will commit this, refining English expression if
> necessary.
Since it was just a matter of editing, I went through the patch and
corrected various mino
At 2014-06-27 00:51:02 +0200, p...@2ndquadrant.com wrote:
>
> Also based on Alvaro's comment, I replaced the scanf parsing code with
> strtoul(l) function.
As far as I can tell (from the thread and a quick look at the patch),
your latest version of the patch addresses all the review comments.
Sho
So, what's the status of this patch?
There's been quite a lot of discussion (though only about the approach;
no formal code/usage review has yet been posted), but as far as I can
tell, it just tapered off without any particular consensus.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsq
Hi Vaishnavi.
In addition to Jaime's comments about the functionality, here are are
some comments about the code.
Well, they were supposed to be comments about the code, but it turns out
I have comments about the feature as well. We need to figure out what to
do about the database and user column
Hi.
We're two weeks into the CommitFest now, and things are moving along
quite nicely.
Fourteen patches have been committed, and twelve more are marked ready
for committer. But most importantly, many patches have been reviewed,
and only nine patches still lack a reviewer (and most of those have
s
At 2014-06-29 21:55:24 +0300, e...@hasegeli.com wrote:
>
> I will update the patch as returned with feedback
I don't think it's fair to mark this as returned with feedback without a
more detailed review (I think of returned with feedback as providing a
concrete direction to follow). I've set it ba
At 2014-06-30 13:55:59 +0900, horiguchi.kyot...@lab.ntt.co.jp wrote:
>
> > So we should mark this patch as "Rejected Patches"?
>
> I think so.
Done.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
At 2014-06-30 05:19:10 +, dilip.ku...@huawei.com wrote:
>
> I have started reviewing the patch..
Thanks.
> 1. Patch applied to git head cleanly.
> 2. Compiled in Linux -- Some warnings same as mentioned by furuyao
I've attached an updated version of the patch which should fix the
warnings
pt I've called the new
option --record-stats. Both options now use no_argument. This should
apply on top of the diff I posted a little while ago.
-- Abhijit
commit cc9422aa71ef0b507c634282272be3fd15c39c0b
Author: Abhijit Menon-Sen
Date: Mon Jun 30 12:15:54 2014 +0530
Introduce --r
At 2014-06-29 22:25:54 +0530, a...@2ndquadrant.com wrote:
>
> I think the really right thing to do would be to have two separate
> columns, one with "all", "sameuser", "samerole", "replication", or
> empty; and the other an array of database names.
After sleeping on it, I realised that the code wo
Hi.
I thought I'd review this patch, since pgaudit uses the
pg_event_trigger_dropped_objects function.
I went through the patch line by line, and I don't really have anything
to say about it. I notice that there are some XXX/FIXME comments in the
code, but it's not clear if those need to (or can
If I understand correctly, the design of this patch has already been
considered earlier and rejected. So I guess the patch should also be
marked rejected?
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql
At 2014-06-30 12:48:30 +0200, pavel.steh...@gmail.com wrote:
>
> +
> + Print a failed SQL commands to standard error output. This is
> + equivalent to setting the variable ECHO to
> + errors.
No "a", just "Print failed SQL commands …".
> --e.
> +-e. If set to
At 2014-06-30 16:35:45 +0500, anaeem...@gmail.com wrote:
>
> pc1dotnetpk:postgresql asif$ patch -p0 <
> > ~/core/min_max_support_for_inet_datatypes/inet_agg_v4.patch
> > can't find file to patch at input line 3
> > Perhaps you used the wrong -p or --strip option?
> > The text leading up to this was
At 2014-06-30 09:39:29 -0400, sfr...@snowman.net wrote:
>
> I certainly don't feel like it's the solution which extension authors
> are looking for and will be happy with
I don't know if there are any other extension authors involved in this
discussion, but I'm not shedding any tears over the idea
At 2014-06-30 15:19:17 -0400, t...@sss.pgh.pa.us wrote:
>
> Anyway, this raises the question of whether the current patch is
> actually a desirable way to do things, or whether it would be better
> if the unaccenting rules were like "base-char accent-char" ->
> "base-char".
It might be useful to b
At 2014-06-30 22:06:30 -0400, t...@sss.pgh.pa.us wrote:
>
> I went ahead and committed this patch, and also some further work to
> fix the multicharacter-source problem. I took it on myself to make
> the code issue warnings about misformatted lines, too.
Thanks, looks good. I found the multichara
Hi.
Do we have any consensus about what to do with these two patches?
1. Introduce a "log_replication_command" setting.
2. Change log_statement to be a list of tokens.
If I understand correctly, there weren't any strong objections to the
former, but the situation is less clear when it comes to t
At 2014-06-17 13:21:34 +0530, jeevan.cha...@enterprisedb.com wrote:
>
> Anyone has any other views ?
I guess nobody has strong feelings either way. I've marked this
(i.e. your slightly-revised patch) ready for committer.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
Hi Ronan.
Based on your review, I'm marking this as ready for committer.
> The attached patch implements this.
Your patch looks sensible enough (thanks for adding tests), but I guess
we'll let the reviewer sort out whether to commit the original or your
extended version.
Thanks.
-- Abhijit
-
At 2014-07-01 16:39:57 +0300, ma...@juffo.org wrote:
>
> > Here's a patch to make pg_xlogdump print summary statistics instead
> > of individual records.
>
> Thanks! I had a use for this feature so I backported the (first) patch
> to PostgreSQL 9.3. It's a rush job so it's ugly and may have bugs,
At 2014-06-27 16:11:21 +0200, vik.fear...@dalibo.com wrote:
>
> After a week of silence from Jov, I decided to do this myself since it
> didn't seem very hard.
>
> Many frustrating hours of trying to understand why I'm getting
> shift/reduce conflicts by the hundreds later, I've decided to give up
At 2014-07-02 04:20:31 +0300, ma...@juffo.org wrote:
>
> As far as functionality goes, it does exactly what I needed it to do;
> the output is very clear.
Good to hear.
> You might also add units (kB/MB) to the table like pg_size_pretty,
> although that would make the magnitudes harder to gauge.
Hi.
Here's a detailed mid-week update split up by category. I've left out
patches marked returned/rejected, committed, or ready for committer.
Server features
---
Lag & Lead Window Functions Can Ignore Nulls
Latest patch currently pending review by Jeff and Álvaro. No
updates
Miscellaneous
-
contrib/fastbloat - tool for quickly assessing bloat stats for a table
Pending review by Jaime.
showing index update time on EXPLAIN
Pending updated patch by Jaime.
idle_in_transaction_session_timeout
Marked as ready for committer, but as far as I can tell
Functions
-
min/max support for inet datatypes
Pending review by Muhammad Asif Naeem.
Selectivity estimation for inet operators
Dilip Kumar plans to post a review this week.
There are two "ready for committer" patches in this category.
Clients
---
Gaussian distribution pgbe
System administration
-
pg_hibernator
Nice feature, some discussion, no code reviews. Status not entirely
clear, but updated patch available.
Monitoring & control
Reducing impact of hints/cleanup for SELECTs
Pending performance review by Emanu
Security
Row-security based on Updatable security barrier views
Lots of discussion that I haven't dared to look at properly yet. I
gather there's still plenty of design-level work needed, and this
is not in any imminent danger of being committed.
Replication & Recovery
--
SQL commands
Event triggers: object creation support
Enormous patch, no reviews, no reviewers, but it's known to work
already. Does anyone want to have a look at this? (I thought it
was being reviewed, and didn't realise otherwise until a couple
of days ago. Sorry abou
Performance
---
scalable LWLocks
Generic atomics implementation
Both under active discussion.
KNN-GiST with recheck
Partial sort
Some earlier discussion, but no conclusions, and as far as I know
nobody is working on these patches at the moment.
lowering array_agg memory requi
At 2014-06-30 10:59:22 -0400, robertmh...@gmail.com wrote:
>
> That means we need some review of the patch for what it is, which
> there hasn't been much of, yet.
Regardless of the eventual fate of pgaudit, we'd certainly welcome some
review of the code.
-- Abhijit
--
Sent via pgsql-hackers ma
At 2014-07-01 21:39:27 +0900, maumau...@gmail.com wrote:
>
> Won't it be burden and a headache to maintain pgaudit code when it
> becomes obsolete in the near future?
Maybe it's a bit unfair to single out this statement to respond to,
because it seems at best tangential to your larger point, but:
Thanks for the update. I have marked the patch "returned with feedback"
and moved it to the 2014-08 CF.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
1 - 100 of 475 matches
Mail list logo
