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
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
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
--
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
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
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
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
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.
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-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,
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-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.
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-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
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 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 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 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
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
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
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
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-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
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-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
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
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
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
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
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-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
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
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
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
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 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,
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
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
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
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: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-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-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
(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
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
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
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
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-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-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 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 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-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-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 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 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
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 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
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-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 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 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 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-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 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 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-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
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
(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.
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
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
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-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’,
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/
dd it to the CF.
-- Abhijit
commit 1d687aeea278e0313071c238e6c3dc04e3e8b798
Author: Abhijit Menon-Sen
Date: Wed Jun 4 14:22:33 2014 +0530
Make 'pg_xlogdump --stats[=record]' display summary statistics
diff --git a/contrib/pg_xlogdump/pg_xlogdump.c b/contrib/pg_xlogdump/pg_xlogdump.c
index 824b
At 2014-06-03 15:06:11 +0200, vik.fear...@dalibo.com wrote:
>
> This patch implements a timeout for broken clients that idle in
> transaction.
I think this is a nice feature, but I suggest that (at the very least)
the GUC should be named "idle_transaction_timeout".
> +
> + Termina
At 2014-05-22 07:22:42 -0400, pete...@gmx.net wrote:
>
> We need a volunteer to manage the first commit fest.
I volunteer.
-- 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-05-04 11:03:56 -0400, sfr...@snowman.net wrote:
>
> Another reloption is one option, or an extension on the ACL system
> (for that piece of it), or we could make a new catalog for it (ala
> pg_seclabel), or perhaps add it on to one (pg_seclabel but rename
> it to pg_security..?).
I'll look
At 2014-05-04 08:52:42 -0400, sfr...@snowman.net wrote:
>
> This also addresses things like anonymous DO blocks and functions
> then..? With enough information to be useful for forensics?
For DML, it addresses anything that goes through InitPlan (which, via
ExecCheckRTPerms, calls the ExecutorChe
At 2014-05-02 14:22:23 -0400, sfr...@snowman.net wrote:
>
> I'm aware and I really am not convinced that pushing all of this to
> contrib modules using the hooks is the right approach- for one thing,
> it certainly doesn't seem to me that we've actually gotten a lot of
> traction from people to act
At 2014-05-02 14:04:27 -0400, sfr...@snowman.net wrote:
>
> I'd really like to see us be able to, say, log to a table and have
> more fine-grained control over what is logged, without needing an
> extension.
There were several factors we considered in our work:
1. We did the minimum possible to p
Hi.
In the past, we've had situations where "everything is hung" turned out
to be because of a script that ran manual VACUUM that was holding some
lock. It's admittedly not a huge problem, but it might be useful if a
manual VACUUM could be cancelled the way autovacuum can be.
One way to do this w
At 2014-04-02 20:10:54 -0400, robertmh...@gmail.com wrote:
>
> I think it might underestimate free space relative to tuples because
> the free space map isn't guaranteed to be completely correct. But I
> guess you knew that already...
Yes, and tuple_len is already a slight overestimate (because i
which have no visibility map).
(Just drop the attached files into contrib/fastbloat, and "make install"
should just work. Then just "create extension fastbloat".)
Questions and suggestions welcome.
-- Abhijit
/*
* contrib/fastbloat/fastbloat.c
*
* Abhijit Menon-Sen
* Portion
Hi Fabrízio.
Here are a few comments based on a quick look at your updated patch.
At 2014-02-13 22:44:56 -0200, fabriziome...@gmail.com wrote:
>
> diff --git a/doc/src/sgml/ref/alter_index.sgml
> b/doc/src/sgml/ref/alter_index.sgml
> index d210077..5e9ee9d 100644
> --- a/doc/src/sgml/ref/alter_i
At 2013-11-21 22:14:35 +0100, and...@2ndquadrant.com wrote:
>
> I'd certainly want a setting that errors out if it cannot get the
> memory using hugetables.
OK, then the current try/on/off settings are fine.
I'm better today, so I'll read the patch Heikki posted and see what more
needs to be done
At 2013-11-15 15:17:32 +0200, hlinnakan...@vmware.com wrote:
>
> I spent some time whacking this around, new patch version attached.
Thanks.
> But I'm not wedded to the idea if someone objects; a log message might
> also be reasonable: "LOG: huge TLB pages are not supported on this
> platform, bu
At 2013-10-30 11:04:36 -0400, t...@sss.pgh.pa.us wrote:
>
> > As a compromise, perhaps we can unconditionally round the size up to be
> > a multiple of 2MB? […]
>
> That sounds reasonably painless to me.
Here's a patch that does that and adds a DEBUG1 log message when we try
with MAP_HUGETLB and
At 2013-10-30 00:10:39 -0700, da...@fetter.org wrote:
>
> How about documenting that 2MB is the quantum (OK, we'll say
> "indivisible unit" or "smallest division" or something) and failing
> with a message to that effect if someone tries to set it otherwise?
I don't think you understand the proble
At 2013-10-24 19:00:28 +0200, and...@2ndquadrant.com wrote:
>
> I think we should log when we tried to use hugepages but fell back to
> plain mmap, currently it's hard to see whether they are used.
Good idea, thanks. I'll do this in the next patch I post (which will be
after we reach some consensu
At 2013-10-24 16:06:19 +0300, hlinnakan...@vmware.com wrote:
>
> Let's get rid of the rounding.
I share Andres's concern that the bug is present in various recent
kernels that are going to stick around for quite some time. Given
the rather significant performance gain, I think it's worth doing
som
At 2013-10-24 11:33:13 +0530, a...@2ndquadrant.com wrote:
>
> >From /proc/$pid/status, VmPTE was 2880kb with huge_tlb_pages=off, and
> 56kb with it turned on.
(VmPTE is the size of the process's page tables.)
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
Hi.
This is a slightly reworked version of the patch submitted by Richard
Poole last month, which was based on Christian Kruse's earlier patch.
Apart from doing various minor cleanups and documentation fixes, I also
tested this patch against HEAD on a machine with 256GB of RAM. Here's an
overview
At 2013-09-26 08:39:05 -0700, jeff.ja...@gmail.com wrote:
>
> I don't know about grottiness, but it certainly seems like it would
> deadlock like crazy.
Hi Jeff.
I don't understand the deadlock scenario you're thinking of. Could you
explain, please?
-- Abhijit
--
Sent via pgsql-hackers mailin
At 2013-09-25 19:20:17 -0300, alvhe...@2ndquadrant.com wrote:
>
> Here are some quick items while skimming this patch.
Great, that gives me plenty to work on.
At this point, I think it's appropriate to mark this patch as returned
with feedback (which I will do), since the changes needed seem fair
At 2013-09-24 09:51:00 -0700, jeff.ja...@gmail.com wrote:
>
> I get wrong answers from this index sometimes.
Thanks for the report and the test case. I'll investigate.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://
At 2013-08-19 11:47:36 +, laurenz.a...@wien.gv.at wrote:
>
> To repeat: this fixes a bug in LDAP connection parameter lookup
Hi.
I read through the patch, and it looks sensible.
I would have preferred the ldap_simple_bind_s() call in the HAVE_LIBLDAP
branch to not be inside an else {} (the i
Hi Jaime.
At 2013-09-15 23:32:11 -0500, ja...@2ndquadrant.com wrote:
>
> bitmapxlog.c:658:32: warning: ‘reln’ may be used uninitialized in this
> function [-Wuninitialized]
I added an XXX comment about this one, will investigate and fix.
Will look into the other errors as well, many thanks for t
At 2013-07-26 10:39:00 +0200, karl...@gmail.com wrote:
>
> Hello, as I can see there are more inconsistent places.
Right. This is what I was referring to in my original review. All of the
relevant sites (pre-patch) that currently do:
if (already exists)
ereport(ERROR …)
should instea
At 2013-06-12 14:29:59 -0300, fabriziome...@gmail.com wrote:
>
> The attached patch add support to "IF NOT EXISTS" to "CREATE"
> statements listed below: […]
I noticed that this patch was listed as "Needs Review" with no
reviewers, so I had a quick look.
It applies with a couple of "trailing whit
201 - 300 of 475 matches
Mail list logo
