Hi,
as a Gentoo user I had a hard time getting the documentation
compiled. Attached you will find a Patch explaining exactly this: how
to compile the documentation under Gentoo.
Best regards,
--
Christian Kruse http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Tr
Hi all
I'm having a hard time seeing any reasonable semantics for the
combination of row-security and inheritance in 9.4 that are also
practical to implement.
I'm considering just punting on inheritance for 9.4, adding checks to
prohibit inheritance from being added to a rel with row security and
Hi Tom,
On 29/01/14 20:06, Tom Lane wrote:
> Christian Kruse writes:
> > Your reasoning sounds quite logical to me. Thus I did a
> > grep -RA 3 "ereport" src/* | less
> > and looked for ereport calls with errno in it. I found quite a few,
> > attached you will find a patch addressing that issue.
Hi,
after I finally got documentation compilation working I updated the
patch to be syntactically correct. You will find it attached.
Best regards,
--
Christian Kruse http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
diff --git a/doc/src/sgml
On Tue, Jan 28, 2014 at 05:34:21PM +, Thom Brown wrote:
> Hi all,
>
> Application to Google Summer of Code 2014 can be made as of next
> Monday (3rd Feb), and then there will be a 12 day window in which to
> submit an application.
>
> I'd like to gauge interest from both mentors and students
On 01/29/2014 09:47 PM, Craig Ringer wrote:
> https://github.com/ringerc/postgres/compare/rls-9.4-upd-sb-views
>
> i.e. https://github.com/ringerc/postgres.git ,
> branch rls-9.4-upd-sb-views
>
> (subject to rebasing) or the non-rebased tag rls-9.4-upd-sb-views-v2
Pushed an update to the br
Sent from my iPad
On 28-Jan-2014, at 10:04, Kouhei Kaigai wrote:
>>> I wonder what shall be the cases when foreign table is on a server which
>> does not support *all* SQL features.
>>>
>>> Does a FDW need to have the possible inherit options mentioned in its
>> documentation for this patch?
(2014/01/27 21:52), Shigeru Hanada wrote:
> 2014-01-27 Etsuro Fujita :
>> While still reviwing this patch, I feel this patch has given enough
>> consideration to interactions with other commands, but found the following
>> incorrect? behabior:
>>
>> postgres=# CREATE TABLE product (id INTEGER, desc
(2014/01/29 17:31), Rajeev rastogi wrote:
On 28th January, Mitsumasa KONDO wrote:
By the way, latest pg_stat_statement might affect performance in
Windows system.
Because it uses fflush() system call every creating new entry in
pg_stat_statements, and it calls many fread() to warm file cache. It
(2014/01/29 16:58), Peter Geoghegan wrote:
On Tue, Jan 28, 2014 at 10:51 PM, Tom Lane wrote:
KONDO Mitsumasa writes:
By the way, latest pg_stat_statement might affect performance in Windows system.
Because it uses fflush() system call every creating new entry in
pg_stat_statements, and it cal
On Wed, Jan 29, 2014 at 07:31:29PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > I have cleaned up entab.c so I am ready to add a new option that removes
> > tabs from only comments. Would you like me to create that and provide a
> > diff at a URL? It would have to be run against all back b
David Fetter wrote:
> 2) Is there another way to solve the problem of adding a foreign
> key constraint that points at a busy table?
Add it as NOT VALID and do a later VALIDATE CONSTRAINT step, after the
patch to reduce lock levels for ALTER TABLE goes in, perhaps?
--
Álvaro Herrera
Christian Kruse writes:
> Your reasoning sounds quite logical to me. Thus I did a
> grep -RA 3 "ereport" src/* | less
> and looked for ereport calls with errno in it. I found quite a few,
> attached you will find a patch addressing that issue.
Committed. I found a couple of errors in your patch,
On 28.1.2014 08:29, Heikki Linnakangas wrote:
> On 01/28/2014 05:54 AM, Tomas Vondra wrote:
>> Then I ran those scripts on:
>>
>>* 9.3
>>* 9.4 with Heikki's patches (9.4-heikki)
>>* 9.4 with Heikki's and first patch (9.4-alex-1)
>>* 9.4 with Heikki's and both patches (9.4-alex-2)
>
On Tue, Jan 28, 2014 at 1:17 PM, Peter Eisentraut wrote:
> On 11/30/13, 6:59 AM, Haribabu kommi wrote:
> > To detect provided data and xlog directories are same or not, I reused
> the
> > Existing make_absolute_path() code as follows.
>
> I note that initdb does not detect whether the data and xlo
Bruce Momjian writes:
> I have cleaned up entab.c so I am ready to add a new option that removes
> tabs from only comments. Would you like me to create that and provide a
> diff at a URL? It would have to be run against all back branches.
If you think you can actually tell the difference reliab
On Wed, Jan 29, 2014 at 12:53:02AM -0500, Tom Lane wrote:
> Robert Haas writes:
> > If this only affects a handful of places, then sure, let's go ahead
> > and fix it. But if it's going to create a massive enough diff that
> > we've gotta think about back-patching it, then IMHO it's totally not
>
On Mon, Jan 27, 2014 at 10:54 AM, Peter Geoghegan wrote:
> On Mon, Jan 27, 2014 at 10:27 AM, Heikki Linnakangas
> wrote:
>>> I think I see some bugs in _bt_moveright(). If you examine
>>> _bt_finish_split() in detail, you'll see that it doesn't just drop the
>>> write buffer lock that the caller
Andrew Dunstan writes:
> I could live with just stddev. Not sure others would be so happy.
FWIW, I'd vote for just stddev, on the basis that min/max appear to add
more to the counter update time than stddev does; you've got
this:
+ e->counters.total_sqtime += total_time * total_tim
On 01/29/2014 02:37 PM, Merlin Moncure wrote:
> create table bar(a int, b int[]);
> postgres=# select jsonb_populate_record(null::bar, '{"a": 1, "b":
> [1,2]}'::jsonb, false);
> ERROR: cannot populate with a nested object unless use_json_as_text is true
Hmmm. What about just making any impossibly
It seems to me that the terms "physical", "logical", and "binary" are
always relative to the perspective of the component being worked on.
"Physical" often means "one level of abstraction below mine, and upon which
my work builds". "Logical" means "my work's level of abstraction". And
"Binary" m
On 01/29/2014 05:37 PM, Merlin Moncure wrote:
On Wed, Jan 29, 2014 at 3:56 PM, Andrew Dunstan wrote:
On 01/29/2014 01:03 PM, Andrew Dunstan wrote:
On 01/27/2014 10:43 PM, Andrew Dunstan wrote:
On 01/26/2014 05:42 PM, Andrew Dunstan wrote:
Here is the latest set of patches for nested hsto
On Wed, Jan 29, 2014 at 3:56 PM, Andrew Dunstan wrote:
>
> On 01/29/2014 01:03 PM, Andrew Dunstan wrote:
>>
>>
>> On 01/27/2014 10:43 PM, Andrew Dunstan wrote:
>>>
>>>
>>> On 01/26/2014 05:42 PM, Andrew Dunstan wrote:
Here is the latest set of patches for nested hstore and jsonb.
>>
Last week:
Status Summary. Needs Review: 66, Waiting on Author: 16, Ready for
Committer: 9, Committed: 20, Returned with Feedback: 2. Total: 113.
This week:
Status Summary. Needs Review: 49, Waiting on Author: 18, Ready for
Committer: 9, Committed: 33, Returned with Feedback: 3, Rejected: 1.
Tot
Christian Kruse writes:
> Your reasoning sounds quite logical to me. Thus I did a
> grep -RA 3 "ereport" src/* | less
> and looked for ereport calls with errno in it. I found quite a few,
> attached you will find a patch addressing that issue.
Excellent, thanks for doing the legwork. I'll take c
Hello
I am looking on this patch.
It is great idea, and I am sure, so we want this patch - it was requested
and proposed more time.
Some tips:
a) possibility to test only selected tests
b) possibility to verify generated file against expected file
c) detection some warnings (expected/unexpected
On 01/29/2014 04:14 PM, Peter Geoghegan wrote:
On Wed, Jan 29, 2014 at 6:06 AM, Andrew Dunstan wrote:
mportance is in the eye of the beholder. As far as I'm concerned, min and
max are of FAR less value than stddev. If stddev gets left out I'm going to
be pretty darned annoyed, especially sinc
On 01/29/2014 10:10 PM, Robert Haas wrote:
Committed with minor doc changes.
Thanks!
/Andreas
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jan 29, 2014 at 6:06 AM, Andrew Dunstan wrote:
> mportance is in the eye of the beholder. As far as I'm concerned, min and
> max are of FAR less value than stddev. If stddev gets left out I'm going to
> be pretty darned annoyed, especially since the benchmarks seem to show the
> marginal
On Wed, Jan 29, 2014 at 3:13 PM, Andreas Karlsson wrote:
> On 01/29/2014 09:01 PM, Robert Haas wrote:
>> Cool. I propose adding one parameter rather than two to
>> ExplainOnePlan() and making it of type instr_time * rather than
>> passing an instr_time and a bool. If you don't want to include th
On 29. Januar 2014 20:51:38 MEZ, Robert Haas wrote:
>On Wed, Jan 29, 2014 at 8:22 AM, Andres Freund
>wrote:
>> Hi,
>>
>> On 2014-01-29 21:59:05 +0900, Michael Paquier wrote:
>>> The undocumented GUC called xloginsert_slots has been introduced by
>>> commit 9a20a9b. It is mentioned by the commit t
On 01/29/2014 12:46 PM, Merlin Moncure wrote:
> I think the opening paragraphs contrasting json/jsonb be needs
> refinement. json is going to be slightly faster than jsonb for input
> *and* output. For example, in one application I store fairly large
> json objects containing pre-compiled static
On Wed, Jan 29, 2014 at 12:03 PM, Andrew Dunstan wrote:
> Only change in functionality is the addition of casts between jsonb and
> json.
>
> The other changes are the merge with the new json functions code, and
> rearrangement of the docs changes to make them less ugly. Essentially I
> moved the
Hi,
On 29/01/14 21:37, Christian Kruse wrote:
> […]
> attached you will find a patch addressing that issue.
Maybe we should include the patch proposed in
<20140129195930.gd31...@defunct.ch>
and do this as one (slightly bigger) patch. Attached you will find
this alternative version.
Best regard
Hi,
On 29/01/14 13:39, Tom Lane wrote:
> No, what I meant is that the ereport caller needs to save errno, rather
> than assuming that (some subset of) ereport-related subroutines will
> preserve it.
> […]
Your reasoning sounds quite logical to me. Thus I did a
grep -RA 3 "ereport" src/* | less
related to
http://www.postgresql.org/message-id/bf2827dcce55594c8d7a8f7ffd3ab7713ddb1...@szxeml508-mbx.china.huawei.com
Hello
1. I had to rebase this patch - actualised version is attached - I merged
two patches to one
2. The psql code is compiled without issues after patching
3. All regress te
Hi,
On 29/01/14 22:17, Heikki Linnakangas wrote:
> Thanks. There are more cases of that in InternalIpcMemoryCreate, they ought
> to be fixed as well. And should also grep the rest of the codebase for more
> instances of that. And this needs to be back-patched.
I'm way ahead of you ;-) Working on
On 01/29/2014 09:59 PM, Christian Kruse wrote:
Hi,
On 29/01/14 21:36, Heikki Linnakangas wrote:
[…]
Fix pushed.
You are right. Thanks. But there is another bug, see
<20140128154307.gc24...@defunct.ch>
ff. Attached you will find a patch fixing that.
Thanks. There are more cases of that in
On 01/29/2014 09:01 PM, Robert Haas wrote:
Cool. I propose adding one parameter rather than two to
ExplainOnePlan() and making it of type instr_time * rather than
passing an instr_time and a bool. If you don't want to include the
planning time, pass NULL; if you do, pass a pointer to the instr_
On 14 January 2014 08:38, Christian Kruse wrote:
> Hi,
>
> On 13/01/14 20:06, Heikki Linnakangas wrote:
>> On 12/17/2013 04:58 PM, Christian Kruse wrote:
>> >attached you will find a patch for showing the current transaction id
>> >(xid) and the xmin of a backend in pg_stat_activty and the xmin in
On 01/29/2014 11:54 AM, Robert Haas wrote:
> I agree. I find it somewhat unlikely that pg_stat_statements is
> fragile enough that these few extra counters are going to make much of
> a difference. At the same time, I find min and max a dubious value
> proposition. It seems highly likely to me t
On Wed, Jan 29, 2014 at 2:21 PM, Andreas Karlsson wrote:
> On 01/28/2014 09:39 PM, Tom Lane wrote:
>>
>> I'm for doing the measurement in ExplainOneQuery() and not printing
>> anything in code paths that don't go through there.
>
> Reading the discussion here and realizing that my last patch was w
Hi,
On 29/01/14 21:36, Heikki Linnakangas wrote:
> […]
> Fix pushed.
You are right. Thanks. But there is another bug, see
<20140128154307.gc24...@defunct.ch>
ff. Attached you will find a patch fixing that.
Best regards,
--
Christian Kruse http://www.2ndQuadrant.com/
PostgreSQ
On 29 January 2014 05:43, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jan 28, 2014 at 12:36 PM, Alvaro Herrera
>> wrote:
>>> Honestly, I would prefer that we push a patch that has been thoroughly
>>> reviewed and in which we have more confidence, so that we can push
>>> without a GUC. This
On Wed, Jan 29, 2014 at 9:06 AM, Andrew Dunstan wrote:
>> I am not opposed in principle to adding new things to the counters
>> struct in pg_stat_statements. I just think that the fact that the
>> overhead of installing the module on a busy production system is
>> currently so low is of *major* va
On Wed, Jan 29, 2014 at 8:22 AM, Andres Freund wrote:
> Hi,
>
> On 2014-01-29 21:59:05 +0900, Michael Paquier wrote:
>> The undocumented GUC called xloginsert_slots has been introduced by
>> commit 9a20a9b. It is mentioned by the commit that this parameter
>> should be removed before the release.
On Wed, Jan 29, 2014 at 4:56 AM, salah jubeh wrote:
>>I'm not particularly in favor of implementing this as client-side
>>functionality, because then it's only available to people who use that
>>particular client. Simon Riggs proposed a server-side option to the
>>DROP DATABASE command some time
2014-01-29 Vik Fearing
> On 01/29/2014 08:21 PM, Pavel Stehule wrote:
> > second question - is not this functionality too dangerous? If somebody
> > use it as scheduler, then
> >
> > a) can holds connect, session data, locks too long time
> > b) it can stop on query timeout probably much more ear
On 01/29/2014 09:18 PM, Christian Kruse wrote:
Hi,
On 29/01/14 10:11, Jeff Janes wrote:
I'm getting this warning now with gcc (GCC) 4.4.7:
Interesting. I don't get that warning. But the compiler is (formally)
right.
pg_shmem.c: In function 'PGSharedMemoryCreate':
pg_shmem.c:332: warning: 'a
On 01/29/2014 08:21 PM, Pavel Stehule wrote:
> second question - is not this functionality too dangerous? If somebody
> use it as scheduler, then
>
> a) can holds connect, session data, locks too long time
> b) it can stop on query timeout probably much more early then user expect
>
> What is expec
On 01/29/2014 10:19 AM, Simon Riggs wrote:
> No specific reason that I can recall but replication is heavily
> protected by layers of security.
>
> pg_stat_replication is a join with pg_stat_activity, so some of the
> info is open, some closed. It seems possible to relax that.
I'm all for the ide
2014-01-29 Vik Fearing
> On 01/29/2014 08:04 PM, Pavel Stehule wrote:
> > Hello
> >
> > I am looking on this patch
>
> Thank you for looking at it.
>
> > http://www.postgresql.org/message-id/525fe206.6000...@dalibo.com
> >
> > a) pg_sleep_for - no objection - it is simple and secure
>
> Okay.
>
>
On 01/28/2014 09:39 PM, Tom Lane wrote:
I'm for doing the measurement in ExplainOneQuery() and not printing
anything in code paths that don't go through there.
Reading the discussion here and realizing that my last patch was wrong I
am now in agreement with this. I have attached a patch which
Hi,
On 29/01/14 10:11, Jeff Janes wrote:
> I'm getting this warning now with gcc (GCC) 4.4.7:
Interesting. I don't get that warning. But the compiler is (formally)
right.
> pg_shmem.c: In function 'PGSharedMemoryCreate':
> pg_shmem.c:332: warning: 'allocsize' may be used uninitialized in this
>
On 01/29/2014 08:04 PM, Pavel Stehule wrote:
> Hello
>
> I am looking on this patch
Thank you for looking at it.
> http://www.postgresql.org/message-id/525fe206.6000...@dalibo.com
>
> a) pg_sleep_for - no objection - it is simple and secure
Okay.
> b) pg_sleep_until
>
> I am not sure - maybe th
On 01/29/2014 04:55 AM, Simon Riggs wrote:
> It is possible that adding this extra straw breaks the camel's back,
> but it seems unlikely to be that simple. A new feature to help
> performance problems will be of a great use to many people; complaints
> about the performance of pg_stat_statements a
Hello
I am looking on this patch
http://www.postgresql.org/message-id/525fe206.6000...@dalibo.com
a) pg_sleep_for - no objection - it is simple and secure
b) pg_sleep_until
I am not sure - maybe this implementation is too simply. I see two possible
risk where it should not work as users can ex
Hi,
On 29/01/14 14:12, Heikki Linnakangas wrote:
> The documentation is still lacking. We should explain somewhere how to set
> nr.hugepages, for example. The "Managing Kernel Resources" section ought to
> mention setting. Could I ask you to work on that, please?
Of course! Attached you will find
Esteemed hackers,
I can't be the only person to have encountered a situation where
adding a new foreign key pointing at a busy table essentially never
happens because the way things work now, creating the constraint
trigger on that busy table requires an AccessExclusive lock, or a
unicorn, whichev
Christian Kruse writes:
> Ok, so I propose the attached patch as a fix.
No, what I meant is that the ereport caller needs to save errno, rather
than assuming that (some subset of) ereport-related subroutines will
preserve it.
In general, it's unsafe to assume that any nontrivial subroutine prese
On 28 January 2014 20:14, Josh Berkus wrote:
> On 01/28/2014 12:10 PM, Tom Lane wrote:
>> Josh Berkus writes:
>>> For example, I would really like to GRANT an unpriv user access to the
>>> WAL columns in pg_stat_replication so that I can monitor replication
>>> delay without granting superuser pe
On Wed, Jan 29, 2014 at 4:12 AM, Heikki Linnakangas wrote:
> On 01/28/2014 06:11 PM, Christian Kruse wrote:
>
>> Hi,
>>
>> attached you will find a new version of the patch, ported to HEAD,
>> fixed the mentioned bug and - hopefully - dealing the the remaining
>> issues.
>>
>
> Thanks, I have com
2014-01-29 Pavel Stehule
>
>
>
> 2014-01-29 Jeevan Chalke
>
> Hi Pavel,
>>
>> Now the patch looks good to me. However when I try to restore your own
>> sql file's dump, I get following errors:
>>
>> pg_restore: [archiver (db)] could not execute query: ERROR: relation
>> "public.emp" does not ex
New patch attached with the following changes:
On Thu, Jan 23, 2014 at 11:01 AM, Steeve Lennmark wrote:
> On Thu, Jan 23, 2014 at 2:06 AM, Peter Eisentraut wrote:
>
>> I'm not totally happy with the choice of ":" as the mapping separator,
>> because that would always require escaping on Windows
2014/1/29 Ian Lawrence Barwick :
> 2014-01-29 Andrew Dunstan :
>>
>> On 01/28/2014 05:55 AM, Ian Lawrence Barwick wrote:
>>>
>>>
>>> Hi Payal
>>>
>>> Many thanks for the review, and my apologies for not getting back to
>>> you earlier.
>>>
>>> Updated version of the patch attached with suggested co
On 01/29/2014 10:21 AM, Tom Lane wrote:
Andrew Dunstan writes:
In the jsonb patch I have been working on, I have replicated all of what
I call the json processing functions, and I will shortly add analogs for
the new functions in that category json_to_record and json_to_recordset.
However I ha
Andrew Dunstan writes:
> In the jsonb patch I have been working on, I have replicated all of what
> I call the json processing functions, and I will shortly add analogs for
> the new functions in that category json_to_record and json_to_recordset.
> However I have not replicated what I call the
On Wed, Jan 29, 2014 at 9:08 AM, Andrew Dunstan wrote:
> In the jsonb patch I have been working on, I have replicated all of what I
> call the json processing functions, and I will shortly add analogs for the
> new functions in that category json_to_record and json_to_recordset.
>
> However I have
In the jsonb patch I have been working on, I have replicated all of what
I call the json processing functions, and I will shortly add analogs for
the new functions in that category json_to_record and json_to_recordset.
However I have not replicated what I call the json generation functions,
ar
On 29 January 2014 12:20, Dean Rasheed wrote:
>> @Dean: If we moved that to rewriter, would expand_security_quals() and
>> preprocess_rowmarks() also move?
>>
>
> Actually I tend to think that expand_security_quals() should remain
> where it is, regardless of where inheritance expansion happens.
On 01/29/2014 02:21 PM, Amit Kapila wrote:
On Wed, Jan 29, 2014 at 3:41 PM, Heikki Linnakangas
wrote:
For example, if the new tuple is an exact copy of the old tuple,
except for one additional byte in the beginning, the algorithm would fail to
recognize that. It would be good to add a test case
On Tue, Jan 28, 2014 at 5:58 AM, Christian Kruse
wrote:
> Hi,
>
> On 28/01/14 13:51, Heikki Linnakangas wrote:
>> Oh darn, I remembered we had already committed this, but clearly not. I'd
>> love to still get this into 9.4. The latest patch (hugepages-v5.patch) was
>> pretty much ready for commit,
On Tue, Jan 28, 2014 at 11:01 PM, salah jubeh wrote:
> Hello Sawada,
>
>>- This patch is not patched to master branch
> Sorry, My mistake
>>//new connections are not allowed
> Corrected.
>
> I hope now the patch in better state, if somthing left, I will be glad to
> fix it
> Regards
>
>
> On Tuesd
On 01/29/2014 04:01 PM, Vik Fearing wrote:
On 01/29/2014 01:12 PM, Heikki Linnakangas wrote:
The documentation is still lacking.
The documentation is indeed lacking since it breaks the build.
doc/src/sgml/config.sgml contains the line
normal allocation if that fails. With on tag.
Trivi
On 01/29/2014 02:58 AM, Peter Geoghegan wrote:
I am not opposed in principle to adding new things to the counters
struct in pg_stat_statements. I just think that the fact that the
overhead of installing the module on a busy production system is
currently so low is of *major* value, and therefo
On 01/29/2014 01:12 PM, Heikki Linnakangas wrote:
> On 01/28/2014 06:11 PM, Christian Kruse wrote:
>> Hi,
>>
>> attached you will find a new version of the patch, ported to HEAD,
>> fixed the mentioned bug and - hopefully - dealing the the remaining
>> issues.
>
> Thanks, I have committed this now.
On 01/28/2014 02:11 PM, Craig Ringer wrote:
>> > My first thought is to add a boolean flag to RangeTblEntry (similar to
>> > the "inh" flag) to say whether RLS expansion is requested for that
>> > RTE. Then set it to false on each RTE as you add new RLS quals to it's
>> > securityQuals.
> That's wh
On Wed, Jan 29, 2014 at 10:38 PM, Michael Paquier
wrote:
> On Sat, Jan 25, 2014 at 5:41 AM, Fujii Masao wrote:
>> I think that it's time to rename all the variables related to
>> pg_stat_bgwriter.
>> For example, it's better to change PgStat_GlobalStats to PgStat_Bgwriter.
>> I think that it's o
On Sat, Jan 25, 2014 at 5:41 AM, Fujii Masao wrote:
> I think that it's time to rename all the variables related to
> pg_stat_bgwriter.
> For example, it's better to change PgStat_GlobalStats to PgStat_Bgwriter.
> I think that it's okay to make this change as separate patch, though.
Please find a
2014-01-29 Christian Convey :
>
> On Mon, Jan 27, 2014 at 7:14 PM, Kouhei Kaigai wrote:
>>
>> FDW's join pushing down is one of the valuable use-cases of this
>> interface,
>> but not all. As you might know, my motivation is to implement GPU
>> acceleration
>> feature on top of this interface, tha
Hi,
On 2014-01-29 21:59:05 +0900, Michael Paquier wrote:
> The undocumented GUC called xloginsert_slots has been introduced by
> commit 9a20a9b. It is mentioned by the commit that this parameter
> should be removed before the release. Wouldn't it be a good time to
> remove this parameter soon? I i
Hi all,
The undocumented GUC called xloginsert_slots has been introduced by
commit 9a20a9b. It is mentioned by the commit that this parameter
should be removed before the release. Wouldn't it be a good time to
remove this parameter soon? I imagine that removing it before the beta
would make sense
On 29 January 2014 09:16, Magnus Hagander wrote:
> On Wed, Jan 29, 2014 at 8:58 AM, Peter Geoghegan wrote:
>>
>> I am not opposed in principle to adding new things to the counters
>> struct in pg_stat_statements. I just think that the fact that the
>> overhead of installing the module on a busy p
On 29 January 2014 06:43, Tom Lane wrote:
> Kouhei Kaigai writes:
>> Let me ask an elemental question. What is the reason why inheritance
>> expansion logic should be located on the planner stage, not on the tail
>> of rewriter?
>
> I think it's mostly historical. You would however have to think
On Jan29, 2014, at 09:59 , Dean Rasheed wrote:
> On 28 January 2014 20:16, Florian Pflug wrote:
>> On Jan27, 2014, at 23:28 , Dean Rasheed wrote:
>>> This case is explicitly forbidden, both in CREATE AGGREGATE and in the
>>> executor. To me, that seems overly restrictive --- if transfn is
>>> st
On Mon, Jan 27, 2014 at 7:14 PM, Kouhei Kaigai wrote:
> FDW's join pushing down is one of the valuable use-cases of this interface,
> but not all. As you might know, my motivation is to implement GPU
> acceleration
> feature on top of this interface, that offers alternative way to scan or
> join
While transforming the LIKE clause in transformTableLikeClause(), the
function does remap the varattnos of the constraint expression.
838│
839│ ccbin_node =
map_variable_attnos(stringToNode(ccbin),
840│
1, 0,
841│
attmap, tupleDesc->natts,
842│
&found_whole_row);
So,
On 29 January 2014 11:34, Craig Ringer wrote:
> On 01/23/2014 06:06 PM, Dean Rasheed wrote:
>> On 21 January 2014 09:18, Dean Rasheed wrote:
>>> Yes, please review the patch from 09-Jan
>>> (http://www.postgresql.org/message-id/CAEZATCUiKxOg=voovja2s6g-sixzzxg18totggp8zobq6qn...@mail.gmail.com).
On Wed, Jan 29, 2014 at 3:41 PM, Heikki Linnakangas
wrote:
> On 01/28/2014 07:01 PM, Heikki Linnakangas wrote:
>>
>> On 01/27/2014 07:03 PM, Amit Kapila wrote:
>>>
>>> I have tried to improve algorithm in another way so that we can get
>>> benefit of same chunks during find match (something simila
On 29 January 2014 11:27, Simon Riggs wrote:
> On 29 January 2014 06:43, Tom Lane wrote:
>
>> Actually though, isn't this issue mostly about inheritance of a query
>> *target* table?
>
> Exactly. IMHO updateable views on inheritance sets will have multiple
> other performance problems, so trying
On 01/28/2014 06:11 PM, Christian Kruse wrote:
Hi,
attached you will find a new version of the patch, ported to HEAD,
fixed the mentioned bug and - hopefully - dealing the the remaining
issues.
Thanks, I have committed this now.
The documentation is still lacking. We should explain somewhere
On 01/23/2014 06:06 PM, Dean Rasheed wrote:
> On 21 January 2014 09:18, Dean Rasheed wrote:
>> Yes, please review the patch from 09-Jan
>> (http://www.postgresql.org/message-id/CAEZATCUiKxOg=voovja2s6g-sixzzxg18totggp8zobq6qn...@mail.gmail.com).
>>
>
> After further testing I found a bug --- it i
On 29 January 2014 06:43, Tom Lane wrote:
> Actually though, isn't this issue mostly about inheritance of a query
> *target* table?
Exactly. IMHO updateable views on inheritance sets will have multiple
other performance problems, so trying to support them here will not
make their usage seamless.
On 01/28/2014 07:34 PM, Thom Brown wrote:
And I'd be fine with being admin again this year, unless there's
anyone else who would like to take up the mantle?
Please do, thanks!
Who would be up for mentoring this year?
I can mentor.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-ha
On 28 January 2014 21:28, Robert Haas wrote:
> On Tue, Jan 28, 2014 at 5:02 AM, Simon Riggs wrote:
>> I agree that this is being seen the wrong way around. The planner
>> contains things it should not do, and as a result we are now
>> discussing enhancing the code that is in the wrong place, whic
2014-01-29 Jeevan Chalke
> Hi Pavel,
>
> Now the patch looks good to me. However when I try to restore your own sql
> file's dump, I get following errors:
>
> pg_restore: [archiver (db)] could not execute query: ERROR: relation
> "public.emp" does not exist
> Command was: DROP TRIGGER IF EXI
Hi Pavel,
Now the patch looks good to me. However when I try to restore your own sql
file's dump, I get following errors:
pg_restore: [archiver (db)] could not execute query: ERROR: relation
"public.emp" does not exist
Command was: DROP TRIGGER IF EXISTS emp_insert_trigger ON public.emp;
pg
On 01/28/2014 07:01 PM, Heikki Linnakangas wrote:
On 01/27/2014 07:03 PM, Amit Kapila wrote:
I have tried to improve algorithm in another way so that we can get
benefit of same chunks during find match (something similar to lz).
The main change is to consider chunks at fixed boundary (4 byte)
an
Hello Robert,
>I'm not particularly in favor of implementing this as client-side
>functionality, because then it's only available to people who use that
>particular client. Simon Riggs proposed a server-side option to the
>DROP DATABASE command some time ago, and I think that might be the way
>
On 01/29/2014 03:34 PM, Kouhei Kaigai wrote:
>> Kouhei Kaigai writes:
>>> Let me ask an elemental question. What is the reason why inheritance
>>> expansion logic should be located on the planner stage, not on the
>>> tail of rewriter?
>>
>> I think it's mostly historical. You would however have
1 - 100 of 109 matches
Mail list logo
