On Sun, 2011-06-19 at 21:29 +0200, Florian Pflug wrote:
> If I'm not mistaken about this, that would imply that we also cannot
> have two range types with the same base type, the same opclass,
> but different collations. Which seems rather unfortunate... In fact,
> if that's true, maybe restricing
On Mon, Jun 20, 2011 at 1:00 AM, Peter Geoghegan wrote:
> I took another look at this this evening, and realised that my
> comments could be a little clearer.
>
> Attached revision cleans them up a bit.
Since I'm not familiar with Windows, I haven't read the code related
to Windows. But
the follo
On Mon, Jun 20, 2011 at 07:30, Greg Smith wrote:
> I applied Jeff's patch but changed this to address concerns about the
> program getting stuck running for too long in the function:
>
> #define plpgsql_loops 512
Is it OK to define the value as constant?
Also, it executes much more queries if
Greg Stark wrote:
I've always wondered what other people do to iterate quickly.
I'd have bet money you had an elisp program for this by now!
The peg utility script I use makes a reinstall as simple as:
stop
peg build
The UI for peg is still is a little rough around switching to another
proj
Excerpts from Pavel Stehule's message of dom jun 19 06:51:13 -0400 2011:
> Hello
>
> 2011/6/19 Steve Singer :
> > On 11-06-08 04:14 PM, Pavel Stehule wrote:
> > nbtinsert.c
> >
> > pg_get_indrelation is named differently than everything else in this file
> > (ie _bt...). My guess is that this fu
Hi Greg,
On Sun, Jun 19, 2011 at 11:44:35PM +0100, Greg Stark wrote:
> So I was the victim assigned to review this patch.
Thanks for doing so.
> The code is pretty much impeccable as usual from Noah. But I have
> questions about the semantics of it.
>
> Firstly this bit makes me wonder:
>
> +
On Sun, 19 Jun 2011, Pavel Stehule wrote:
Maybe there is second issue (little bit - performance - you have to
call a output function), But I agree, so this information is very
interesting and can help.
I am concerned about the performance impact of doing that. Not all
constraints are on int4
On Fri, Jun 17, 2011 at 11:34 AM, Robert Haas wrote:
> On Thu, Jun 16, 2011 at 10:10 PM, Fujii Masao wrote:
According to the above page, one purpose of time-delayed replication is to
protect against user mistakes on master. But, when an user notices his
wrong
operation on mas
On Sat, Jun 18, 2011 at 10:19 PM, Tom Lane wrote:
> Thom Brown writes:
>> On 18 June 2011 04:13, Bruce Momjian wrote:
>>> I tested on FreeBSD 7.4 and saw a 1 error return:
>
>> And on a Mac (so through Darwin 10.7.0 a BSD version too):
>
> Yeah, see yesterday's discussion on pgsql-admin. I thin
On Thu, Jun 16, 2011 at 9:00 PM, Tom Lane wrote:
> BTW, if you're hacking Postgres code and don't already have a
> "reinstall" script, you need one. Mine is basically
>
> pg_ctl stop
> cd $PGBLDROOT/src/backend
> make install-bin
> pg_ctl start
I've always wondered wh
On Fri, Jun 17, 2011 at 3:49 PM, Florian Pflug wrote:
>> The regex is always to the right of the operator.
>
> Which is something you have to remember... It's not in any
> way deducible from "foo ~ bar" alone.
Except that it's always been this way, going back to perl4 or tcl or
their predecessors
On Sat, Jun 18, 2011 at 11:57 AM, Rémi Zara wrote:
> Pika failed at the isolationCheck phase, hitting an assertion:
>
> TRAP: FailedAssertion("!(!((oldSerXidControl->tailXid) != ((TransactionId)
> 0)) || TransactionIdFollows(xid, oldSerXidControl->tailXid))", File:
> "predicate.c", Line: 991)
>
On Sun, Jun 19, 2011 at 11:04 AM, Jeff Shanab wrote:
> I am wondering If I am missing something obvious. If not, I have a
> suggestion for plpgsql.
>
> Stored procedures can accept rows.
>
> Libpq can receive rows (PQResult).
>
> Wouldn’t it be a great interface if PQResult was “bi-directional”? C
On Sun, Jun 19, 2011 at 3:32 PM, Cédric Villemain
wrote:
> 2nd, I provided the patches on the last CF, exactly to allow to go to
> the exciting part: the cost-estimates changes. (after all, we can work
> on the cost estimate, and if later we find a way to use ALTER TABLE or
> pg_class_ng, just do
On Sun, Jun 19, 2011 at 7:59 PM, Florian Pflug wrote:
> On Jun19, 2011, at 23:16 , Robert Haas wrote:
>> On Sun, Jun 19, 2011 at 5:10 PM, Florian Pflug wrote:
>>> On Jun19, 2011, at 20:40 , Robert Haas wrote:
2. Since VACUUM and ANALYZE often run together, we will be estimating
the perc
On 06/19/2011 06:15 PM, Kevin Grittner wrote:
I think the point is that if, on a fresh system, the first access to
a table is something which uses a tables scan -- like select count(*)
-- that all indexed access would then tend to be suppressed for that
table. After all, for each individual que
On Jun19, 2011, at 23:16 , Robert Haas wrote:
> On Sun, Jun 19, 2011 at 5:10 PM, Florian Pflug wrote:
>> On Jun19, 2011, at 20:40 , Robert Haas wrote:
>>> 2. Since VACUUM and ANALYZE often run together, we will be estimating
>>> the percentage of rows on all-visible pages just at the time when tha
On Jun20, 2011, at 00:56 , Andrew Dunstan wrote:
> On 06/19/2011 05:02 PM, Florian Pflug wrote:
>> The only argument against that I can see is that it poses
>> a compatibility problem if "~" remains the pattern matching
>> operator. I do believe, however, that the chance of
>> unknown ~ unknown
>
Heikki Linnakangas wrote:
> * The oldserxid code is broken for non-default BLCKSZ.
> o The warning will come either too early or too late
> o There is no safeguard against actually wrapping around the
> SLRU, just the warning
> o I'm suspicious of the OldSerXidPagePrecedesLogically() logic
> with
On 06/19/2011 05:02 PM, Florian Pflug wrote:
On Jun19, 2011, at 22:10 , Tom Lane wrote:
Andrew Dunstan writes:
On 06/19/2011 02:56 PM, Robert Haas wrote:
On Sun, Jun 19, 2011 at 9:53 AM, Florian Pflug wrote:
Amidst the discussion, Alvaro suggested that we resolve the issue
by adding a di
So I was the victim assigned to review this patch.
The code is pretty much impeccable as usual from Noah. But I have
questions about the semantics of it.
Firstly this bit makes me wonder:
+ /* Not-found is always final. */
+ if (!OidIsValid(relOid1))
+
I applied Jeff's patch but changed this to address concerns about the
program getting stuck running for too long in the function:
#define plpgsql_loops 512
This would be better named as "plpgsql_batch_size" or something similar
instead, the current name suggests it's how many loops to run wh
Greg Smith wrote:
> I'm not too concerned about the specific case you warned about
> because I don't see how sequential scan vs. index costing will be
> any different on a fresh system than it is now.
I think the point is that if, on a fresh system, the first access to
a table is something whi
On 06/19/2011 09:38 AM, Greg Stark wrote:
There's another problem which I haven't seen mentioned. Because the
access method will affect the cache there's the possibility of
feedback loops. e.g. A freshly loaded system prefers sequential scans
for a given table because without the cache the seeks
On Sun, Jun 19, 2011 at 5:10 PM, Florian Pflug wrote:
> On Jun19, 2011, at 20:40 , Robert Haas wrote:
>> 2. Since VACUUM and ANALYZE often run together, we will be estimating
>> the percentage of rows on all-visible pages just at the time when that
>> percentage is highest. This is not exactly wo
On Fri, Jun 17, 2011 at 11:41 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jun 16, 2011 at 6:54 PM, Tom Lane wrote:
>>> 4. Backend #2 visits the new, about-to-be-committed version of
>>> pgbench_accounts' pg_class row just before backend #3 commits.
>>> It sees the row as not good and ke
On Jun19, 2011, at 20:40 , Robert Haas wrote:
> 2. Since VACUUM and ANALYZE often run together, we will be estimating
> the percentage of rows on all-visible pages just at the time when that
> percentage is highest. This is not exactly wonderful, either...
Hm, doesn't autovacuum run ANALYZE quite
On Jun19, 2011, at 22:10 , Tom Lane wrote:
> Andrew Dunstan writes:
>> On 06/19/2011 02:56 PM, Robert Haas wrote:
>>> On Sun, Jun 19, 2011 at 9:53 AM, Florian Pflug wrote:
Amidst the discussion, Alvaro suggested that we resolve the issue
by adding a distinct type for patterns as opposed
On Sun, Jun 19, 2011 at 2:41 PM, Robert Haas wrote:
> On Sun, Jun 19, 2011 at 2:20 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Yikes. I think you are right. It's kind of scary that the regression
>>> tests passed with that mistake.
>>
>> Can we add a test that exposes that mistake?
>
> Not
On sön, 2011-06-19 at 08:59 -0700, David Fetter wrote:
> On Sat, Jun 18, 2011 at 10:18:50PM +, Peter Eisentraut wrote:
> > Make external_pid_file world readable
>
> Should this be back-patched?
I wasn't planning to. It's a new feature.
--
Sent via pgsql-hackers mailing list (pgsql-hacker
Andrew Dunstan writes:
> On 06/19/2011 02:56 PM, Robert Haas wrote:
>> On Sun, Jun 19, 2011 at 9:53 AM, Florian Pflug wrote:
>>> Amidst the discussion, Alvaro suggested that we resolve the issue
>>> by adding a distinct type for patterns as opposed to text. That'd
>>> allow us to make "~" it's ow
On 06/19/2011 02:56 PM, Robert Haas wrote:
On Sun, Jun 19, 2011 at 9:53 AM, Florian Pflug wrote:
Amidst the discussion, Alvaro suggested that we resolve the issue
by adding a distinct type for patterns as opposed to text. That'd
allow us to make "~" it's own commutator by defining both
text
Hey Jeff,
2011/6/19 Jeff Shanab
> I am wondering If I am missing something obvious. If not, I have a
> suggestion for plpgsql.
>
> ** **
>
> Stored procedures can accept rows.
>
> Libpq can receive rows (PQResult).
>
> ** **
>
> Wouldn’t it be a great interface if PQResult was “bi-di
I hope this hasn't been forgotten. But I cant see it has been committed
or moved
into the commitfest process?
Jesper
On 2011-03-11 16:51, Noah Misch wrote:
On Fri, Feb 11, 2011 at 02:13:22AM -0500, Noah Misch wrote:
Automated tests would go a long way toward building confidence that this pat
On Sun, Jun 19, 2011 at 02:48:58PM +0100, Greg Stark wrote:
> On Thu, Jun 16, 2011 at 6:11 AM, Tom Lane wrote:
> > (I will refrain for the moment from speculating whether we'll ever
> > have an index type that supports regexp match directly as an
> > indexable operator...)
>
> Fwiw I looked into
2011/6/19 Robert Haas :
> On Sun, Jun 19, 2011 at 9:38 AM, Greg Stark wrote:
>> On Tue, Jun 14, 2011 at 4:04 PM, Robert Haas wrote:
>>> 1. ANALYZE happens far too infrequently to believe that any data taken
>>> at ANALYZE time will still be relevant at execution time.
>>> 2. Using data gathered b
On Jun19, 2011, at 20:08 , Jeff Davis wrote:
> On Sun, 2011-06-19 at 12:24 +0200, Martijn van Oosterhout wrote:
>> Collation checking is generally done by the planner. I don't see why
>> the input function should check, the result of an input function is by
>> definition DEFAULT. It's up to the 'in
Martijn van Oosterhout writes:
> On Sun, Jun 19, 2011 at 11:56:15AM +0200, Rados??aw Smogura wrote:
>> I want to implement hugepages for shared memory, to make it transparent I
>> want
> At least in Linux they're trying to make hugepages transparent, so I'm
> wondering if this is going to make
On Jun19, 2011, at 20:56 , Robert Haas wrote:
> On Sun, Jun 19, 2011 at 9:53 AM, Florian Pflug wrote:
>> Amidst the discussion, Alvaro suggested that we resolve the issue
>> by adding a distinct type for patterns as opposed to text. That'd
>> allow us to make "~" it's own commutator by defining bo
2011/6/19 Robert Haas :
> On Sun, Jun 19, 2011 at 11:12 AM, Cédric Villemain
> wrote:
>>> Good point --- we would be making plan decisions based on the visibility
>>> map coverage. The big question is whether visibility map changes are
>>> more dynamic than the values we already plan against, lik
On Sun, Jun 19, 2011 at 9:53 AM, Florian Pflug wrote:
> Amidst the discussion, Alvaro suggested that we resolve the issue
> by adding a distinct type for patterns as opposed to text. That'd
> allow us to make "~" it's own commutator by defining both
> text ~ pattern
> and
> pattern ~ text.
That
On Sun, Jun 19, 2011 at 9:38 AM, Greg Stark wrote:
> On Tue, Jun 14, 2011 at 4:04 PM, Robert Haas wrote:
>> 1. ANALYZE happens far too infrequently to believe that any data taken
>> at ANALYZE time will still be relevant at execution time.
>> 2. Using data gathered by ANALYZE will make plans less
On Sun, Jun 19, 2011 at 2:20 PM, Tom Lane wrote:
> Robert Haas writes:
>> Yikes. I think you are right. It's kind of scary that the regression
>> tests passed with that mistake.
>
> Can we add a test that exposes that mistake?
Not sure. We'd have to figure out how to reliably tickle it.
--
On Sun, Jun 19, 2011 at 11:12 AM, Cédric Villemain
wrote:
>> Good point --- we would be making plan decisions based on the visibility
>> map coverage. The big question is whether visibility map changes are
>> more dynamic than the values we already plan against, like rows in the
>> table, table s
Robert Haas writes:
> Yikes. I think you are right. It's kind of scary that the regression
> tests passed with that mistake.
Can we add a test that exposes that mistake?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
On Sun, Jun 19, 2011 at 10:44 AM, Cédric Villemain
wrote:
> and recent stuff on VM will allow us to move forward it seems !
Yep, looks promising. The heap_hot_search_buffer refactoring patch is
related as well.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL
On Sun, Jun 19, 2011 at 2:01 PM, Jeff Davis wrote:
> On Sun, 2011-06-19 at 10:50 -0700, Jeff Davis wrote:
>> On Mon, 2011-06-06 at 14:03 -0400, Robert Haas wrote:
>> > The attached patch refactors heap_hot_search_buffer() so that
>> > index_getnext() can use it, and modifies index_getnext() to do
On Sun, 2011-06-19 at 12:24 +0200, Martijn van Oosterhout wrote:
> Collation checking is generally done by the planner. I don't see why
> the input function should check, the result of an input function is by
> definition DEFAULT. It's up to the 'in' operator to check.
>
> Note that the whole idea
On Sun, 2011-06-19 at 10:50 -0700, Jeff Davis wrote:
> On Mon, 2011-06-06 at 14:03 -0400, Robert Haas wrote:
> > The attached patch refactors heap_hot_search_buffer() so that
> > index_getnext() can use it, and modifies index_getnext() to do so.
>
> Attached is a version of the patch that applies
On Mon, 2011-06-06 at 14:03 -0400, Robert Haas wrote:
> The attached patch refactors heap_hot_search_buffer() so that
> index_getnext() can use it, and modifies index_getnext() to do so.
Attached is a version of the patch that applies cleanly to master.
Regards,
Jeff Davis
heap-hot-sear
On 6/19/2011 11:04 AM, Jeff Shanab wrote:
I am wondering If I am missing something obvious. If not, I have a suggestion
for plpgsql.
Stored procedures can accept rows.
Libpq can receive rows (PQResult).
Wouldn’t it be a great interface if PQResult was “bi-directional”? Create a
result set on t
I took another look at this this evening, and realised that my
comments could be a little clearer.
Attached revision cleans them up a bit.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
diff --git a/src/backend/access/transam/xlog
On Sun, Jun 19, 2011 at 3:25 AM, Kohei KaiGai wrote:
> 2011/6/18 Josh Kupershmidt :
> I think the v5 patch should be marked as 'Ready for Committer'
I think we still need to handle my "Still TODO" concerns noted
upthread. I don't have a lot of time this weekend due to a family
event, but I was mu
On Sat, Jun 18, 2011 at 10:18:50PM +, Peter Eisentraut wrote:
> Make external_pid_file world readable
Should this be back-patched?
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
2011/5/11 Bruce Momjian :
> Cédric Villemain wrote:
>> 2011/5/10 Kevin Grittner :
>> > Simon Riggs wrote:
>> >> The typical speed up for non-covered indexes will come when we
>> >> access a very large table (not in cache) via an index scan that is
>> >> smaller than a bitmapindex scan. Will we be
I am wondering If I am missing something obvious. If not, I have a suggestion
for plpgsql.
Stored procedures can accept rows.
Libpq can receive rows (PQResult).
Wouldn't it be a great interface if PQResult was "bi-directional"? Create a
result set on the client then call the database with a com
Robert Haas wrote:
> Kevin Grittner wrote:
>> I'm certainly open to suggestions for better wording.
> How about something like this:
>
> When the system is forced to combine multiple page-level predicate
> locks into a single relation-level predicate lock because the
> predicate lock table i
2011/5/14 Robert Haas :
> On Fri, May 13, 2011 at 6:34 PM, Cédric Villemain
> wrote:
>> If reviewers agree it is safe and benchmarks make evidences that no
>> basic performance issue are raised, then let's see if next items have
>> blockers or can be done.
>
> Sounds right to me.
and recent stuf
2011/6/17 Andrew Tipton :
> On Fri, Jun 10, 2011 at 22:16, Hitoshi Harada wrote:
>>
>> Isn't it worth adding new consistent function for those purposes? The
>> approach in the patch as stands looks kludge to me.
>
> Thanks for your review. Coming back to this patch after a few months'
> time, I h
2011/6/19 Greg Stark :
> On Tue, Jun 14, 2011 at 4:04 PM, Robert Haas wrote:
>> 1. ANALYZE happens far too infrequently to believe that any data taken
>> at ANALYZE time will still be relevant at execution time.
>> 2. Using data gathered by ANALYZE will make plans less stable, and our
>> users com
Hi
It looks like we've failed to reach an agreement on how to
proceed on the issue with missing commutators for the various
text matching operators ("~", "~~", and their case-insensitive
variants). We do seem to have agreed, however, that adding
commutators for the non-deprecated operators which l
2011/6/19 Florian Pflug :
> On Jun19, 2011, at 14:03 , Pavel Stehule wrote:
>> 2011/6/19 Florian Pflug :
>>> Speaking as someone who's wished for the feature that Pavel's patch provides
>>> many times in the past - shouldn't there also be a field containing the
>>> offending value? If we had that,
On Thu, Jun 16, 2011 at 6:11 AM, Tom Lane wrote:
> (I will refrain for
> the moment from speculating whether we'll ever have an index type that
> supports regexp match directly as an indexable operator...)
Fwiw I looked into this at one point and have some ideas if anyone is
keen to try it.
--
On Tue, Jun 14, 2011 at 4:04 PM, Robert Haas wrote:
> 1. ANALYZE happens far too infrequently to believe that any data taken
> at ANALYZE time will still be relevant at execution time.
> 2. Using data gathered by ANALYZE will make plans less stable, and our
> users complain not infrequently about
On 06/19/2011 08:00 AM, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian writes:
Perhaps we should recommend:
cd /path&& test ! -f %f&& cp %p %f
That is shorter and removes the duplicate problem.
Um ... %p is relative to the database directory.
Oh, I see now. I had thought it
On Jun19, 2011, at 14:03 , Pavel Stehule wrote:
> 2011/6/19 Florian Pflug :
>> Speaking as someone who's wished for the feature that Pavel's patch provides
>> many times in the past - shouldn't there also be a field containing the
>> offending value? If we had that, it'd finally be possible to tran
2011/6/19 Florian Pflug :
> On Jun19, 2011, at 05:10 , Steve Singer wrote:
>> On 11-06-18 06:36 PM, Steve Singer wrote:
>>> On 11-06-08 04:14 PM, Pavel Stehule wrote:
>>>
>>> Here is my review of this patch
>>>
>>> Submission Review:
>>>
>>> The patch applies cleanly agains
Tom Lane wrote:
> Bruce Momjian writes:
> > Perhaps we should recommend:
> > cd /path && test ! -f %f && cp %p %f
> > That is shorter and removes the duplicate problem.
>
> Um ... %p is relative to the database directory.
Oh, I see now. I had thought it was an absolute path, but good thing
On Jun19, 2011, at 05:10 , Steve Singer wrote:
> On 11-06-18 06:36 PM, Steve Singer wrote:
>> On 11-06-08 04:14 PM, Pavel Stehule wrote:
>>
>> Here is my review of this patch
>>
>> Submission Review:
>>
>> The patch applies cleanly against master
>> The patch does not inc
Sorry, the previous revision did not update regression test part
towards the latest one.
2011/6/19 Kohei KaiGai :
> Thanks for your review.
>
> 2011/6/19 Robert Haas :
>> On Tue, Jun 14, 2011 at 8:06 AM, Kohei KaiGai wrote:
>>> The attached patch is a preparation to rework implementation of DROP
2011/6/19 Pavel Stehule :
> 2011/6/19 Robert Haas :
>> On Sat, Jun 18, 2011 at 9:21 AM, Pavel Stehule
>> wrote:
>>> Is this profile expected?
>>
>> I've certainly seen profiles before where the catcache overhead was
>> significant. I don't think that I've seen SearchCatCache() quite this
>> high
On Sat, Jun 18, 2011 at 11:32:20PM -0400, Robert Haas wrote:
> On Sat, Jun 18, 2011 at 11:12 PM, Robert Haas wrote:
> > On Sat, Jun 18, 2011 at 11:06 PM, Noah Misch wrote:
> >> On Sat, Jun 18, 2011 at 10:57:13PM -0400, Robert Haas wrote:
> >>> On Sat, Jun 11, 2011 at 5:13 PM, Noah Misch wrote:
>
2011/6/19 Robert Haas :
> On Sat, Jun 18, 2011 at 9:21 AM, Pavel Stehule
> wrote:
>> Is this profile expected?
>
> I've certainly seen profiles before where the catcache overhead was
> significant. I don't think that I've seen SearchCatCache() quite this
> high on any of the profiling I've done,
2011/6/19 Steve Singer :
> On 11-06-18 06:36 PM, Steve Singer wrote:
>>
>> On 11-06-08 04:14 PM, Pavel Stehule wrote:
>>
>> Here is my review of this patch
>>
>> Submission Review:
>>
>> The patch applies cleanly against master
>> The patch does not include any documentatio
Hello
2011/6/19 Steve Singer :
> On 11-06-08 04:14 PM, Pavel Stehule wrote:
>>
>> Hello
>>
>> Attached patch implements a new erros's fields that describes table,
>> colums related to error. This enhanced info is limited to constraints
>> and RI.
>>
>
...
>
> I think that both the CONSTRAINT, an
On Sun, Jun 19, 2011 at 11:21:28AM +0200, Florian Pflug wrote:
> > I think rejecting it makes more sense, so a range would not be a
> > collatable type; it just happens to use collations of the subtype
> > internally.
>
> Ah, crap, I put the COLLATE in the wrong place. What I actually
> had in min
Martijn van Oosterhout Sunday 19 of June 2011 12:35:18
> On Sun, Jun 19, 2011 at 11:56:15AM +0200, Rados??aw Smogura wrote:
> > I want to implement hugepages for shared memory, to make it transparent I
> > want to do in this fashion:
> > 1. Reserve memory M of size s
> > 2. Try to allocate hugepag
On Sun, Jun 19, 2011 at 11:56:15AM +0200, Rados??aw Smogura wrote:
> I want to implement hugepages for shared memory, to make it transparent I
> want
> to do in this fashion:
> 1. Reserve memory M of size s
> 2. Try to allocate hugepage memory of as big size as possible (hs), attach at
> M.
> 3.
I want to implement hugepages for shared memory, to make it transparent I want
to do in this fashion:
1. Reserve memory M of size s
2. Try to allocate hugepage memory of as big size as possible (hs), attach at
M.
3. Allocate normal shared memory of size hs - s, and attach it at M+hs.
This souluti
On Jun19, 2011, at 00:23 , Jeff Davis wrote:
> On Sat, 2011-06-18 at 22:19 +0200, Florian Pflug wrote:
>> Yes, that seems necessary for consistency. That leaves the question
>> of what to do if someone tries to modify a textrange's collation with
>> a COLLATE clause. For example,
>>
>> For example
Thanks for your review.
2011/6/19 Robert Haas :
> On Tue, Jun 14, 2011 at 8:06 AM, Kohei KaiGai wrote:
>> The attached patch is a preparation to rework implementation of DROP
>> statement
>> using a common code. That intends to apply get_object_address() to resolve
>> name
>> of objects to be r
I think the v5 patch should be marked as 'Ready for Committer'
2011/6/18 Josh Kupershmidt :
> On Sat, Jun 18, 2011 at 10:53 AM, Kohei KaiGai wrote:
>> In addition, this pg_comments system view supports 'access method' class, but
>> we cannot set a comment on access methods using COMMENT ON statem
82 matches
Mail list logo
