One bit of feedback I keep getting from people who archive their WAL
files is that the fairly new pg_archivecleanup utility doesn't handle
the case where those archives are compressed. As the sort of users who
are concerned about compression are also often ones with giant archives
they struggl
(my last two posts seemingly did not reach the HACKERS forum, so please
let me resend the last one ;-) )
May I sum up?
o in the recent there are no efforts known to experiment with
reference types, methods, or rule inference on top of PostgreSQL --
advice that can be given mostly points to
On 08.02.2011 05:03, Robert Haas wrote:
On Mon, Feb 7, 2011 at 5:11 PM, Heikki Linnakangas
wrote:
Implement genuine serializable isolation level.
With gcc version 4.2.1 (Apple Inc. build 5664):
predicate.c: In function ‘CheckTargetForConflictsIn’:
predicate.c:3674: warning: ‘nexttargettag.l
On Mon, Feb 7, 2011 at 10:59 PM, Robert Haas wrote:
> On Fri, Feb 4, 2011 at 9:15 PM, Jaime Casanova wrote:
>> ok, i will see you're reviewed version later today
>
> This patch is still marked as "Needs Review" in the CommitFest
> application, but I'm thinking perhaps it should be changed to Read
2011/2/8 Noah Misch :
> On Mon, Feb 07, 2011 at 11:16:18PM -0500, Robert Haas wrote:
>> So
>> can we just get rid of should_be_detoasted, and have exec_eval_datum()
>> or its callers instead test:
>>
>> !var->isnull && var->datatype->typbyval && var->datatype->typlen == -1
>> && VARATT_IS_EXTENDED(
2011/2/8 Robert Haas :
> On Sun, Feb 6, 2011 at 9:10 AM, Robert Haas wrote:
>>> Suppose "foo" is toasted. As the code stands in master, it gets detoasted
>>> in
>>> text_lt(). Certainly we won't overwrite the source back in PL/pgSQL from
>>> the
>>> detoast point in text_lt().
>>
>> Right, tha
2011/2/8 Robert Haas :
> On Fri, Feb 4, 2011 at 1:54 PM, Hitoshi Harada wrote:
>> 2011/2/5 Tom Lane :
>>> Hitoshi Harada writes:
2011/2/5 Tom Lane :
> Yeah, putting backend-only stuff into that header is a nonstarter.
>>>
Do you mean you think it' all right to define
pg_cached_
On 11-02-06 11:40 AM, Jan Urbański wrote:
PFA an updated patch with documentation.
Yeah, changed them.
Those changes look fine. The tests now pass.
I've attached a new version of the patch that fixes a few typos/wording
issues I saw in the documentation. I also changed the link to the
On 11-02-07 10:37 PM, Robert Haas wrote:
- The PL/python extravaganza. I'm not really clear where we stand
with this. There are a lot of patches here.
Some of the patches have been committed a few others are ready (or
almost ready) for a committer. The table function one is the only one
On Mon, Feb 07, 2011 at 11:16:18PM -0500, Robert Haas wrote:
> So
> can we just get rid of should_be_detoasted, and have exec_eval_datum()
> or its callers instead test:
>
> !var->isnull && var->datatype->typbyval && var->datatype->typlen == -1
> && VARATT_IS_EXTENDED(var->value)
FWIW, this is wh
On Mon, Feb 7, 2011 at 10:42 PM, Joachim Wieland wrote:
>> i guess the huge amount of info is showing the patch is just for
>> debugging and will be removed before commit, right?
>
> That's right.
So how close are we to having a committable version of this? Should
we push this out to 9.2?
--
R
On Tue, Dec 28, 2010 at 9:23 PM, Karl Lehenbauer
wrote:
> On Dec 28, 2010, at 7:29 PM, Tom Lane wrote:
>> This patch appears to be changing a whole lot of stuff that in fact
>> pg_indent has never changed, so there's something wrong with the way you
>> are doing it. It looks like a bad typedef li
On Mon, Jan 24, 2011 at 2:00 AM, Fujii Masao wrote:
> On Wed, Jan 5, 2011 at 5:08 AM, Heikki Linnakangas
> wrote:
>> I finally got around to look at this. I wrote a patch to validate that the
>> TLI on xlog page header matches ThisTimeLineID during recovery, and noticed
>> quickly in testing that
On Wed, Jan 19, 2011 at 1:01 AM, Fujii Masao wrote:
> On Thu, Jan 13, 2011 at 9:08 PM, Fujii Masao wrote:
>> I did s/failover/promote. Here is the updated patch.
>
> I rebased the patch to current git master.
This patch looks fine to me. I will mark it Ready for Committer.
(Someone else please
On Sun, Feb 6, 2011 at 9:10 AM, Robert Haas wrote:
>> Suppose "foo" is toasted. As the code stands in master, it gets detoasted in
>> text_lt(). Certainly we won't overwrite the source back in PL/pgSQL from the
>> detoast point in text_lt().
>
> Right, that much seems obvious...
>
>> Pavel's opt
On Fri, Feb 4, 2011 at 1:54 PM, Hitoshi Harada wrote:
> 2011/2/5 Tom Lane :
>> Hitoshi Harada writes:
>>> 2011/2/5 Tom Lane :
Yeah, putting backend-only stuff into that header is a nonstarter.
>>
>>> Do you mean you think it' all right to define
>>> pg_cached_encoding_conversion() in pg_conv
On Fri, Feb 4, 2011 at 9:15 PM, Jaime Casanova wrote:
> ok, i will see you're reviewed version later today
This patch is still marked as "Needs Review" in the CommitFest
application, but I'm thinking perhaps it should be changed to Ready
for Committer? Are there any open issues?
--
Robert Haas
On Thu, Feb 3, 2011 at 11:00 PM, Robert Haas wrote:
> On Fri, Jan 14, 2011 at 6:15 AM, Simon Riggs wrote:
>> Patch to implement the proposed feature attached, for CFJan2011.
>>
>> 2 sub-command changes:
>>
>> ALTER TABLE foo ADD FOREIGN KEY fkoo ... NOT VALID;
>>
>> ALTER TABLE foo VALIDATE CONST
Hi Jaime,
thanks for your review!
On Sun, Feb 6, 2011 at 2:12 PM, Jaime Casanova wrote:
> code review:
>
> something i found, and is a very simple one, is this warning (there's
> a similar issue in _StartMasterParallel with the buf variable)
> """
> pg_backup_directory.c: In function ‘_EndMaster
On Fri, Feb 4, 2011 at 12:02 PM, Oleg Bartunov wrote:
> Aha,
>
> Teodor sent it to the list Dec 28, see
> http://archives.postgresql.org/message-id/4D1A1677.80300%40sigaev.ru
>
> After a month I didn't see any activity on this patch, so I I added it to
> https://commitfest.postgresql.org/action/pa
On Mon, 2011-02-07 at 11:16 -0500, Tom Lane wrote:
> Vaibhav Kaushal writes:
> > Hi,
> > I find that ExecInitExpr creates a ExprState tree (and so say the
> > comments above the function in the source). Also, it seems to decide
> > which function would get called when the expression is to be evalu
On Mon, Feb 7, 2011 at 3:57 PM, Chris Browne wrote:
> It sure looks to me like there are going to be a bunch of items that,
> based on the recognized policies, need to get deferred to 9.2, and the
> prospects for Sync Rep getting into 9.1 don't look notably good to me.
>
> It's definitely readily
Attached is an updated patch that incorporates all of the review I've
done so far on the core code. This omits the contrib changes, which
I've not looked at in any detail, and the docs changes since I've not
yet updated the docs to match today's code changes. User-visible
changes are that WITH NO
On Sat, Feb 5, 2011 at 3:34 PM, Cédric Villemain
wrote:
> Anyway, without GUC is fine too as it won't fill the /var/log itself !
> I am just not opposed to have new GUC in those areas (log && debug).
OK. Committed without a new GUC, at least for now.
--
Robert Haas
EnterpriseDB: http://www.ent
On Mon, Feb 7, 2011 at 5:11 PM, Heikki Linnakangas
wrote:
> Implement genuine serializable isolation level.
With gcc version 4.2.1 (Apple Inc. build 5664):
predicate.c: In function ‘CheckTargetForConflictsIn’:
predicate.c:3674: warning: ‘nexttargettag.locktag_field5’ may be used
uninitialized in
On Mon, Feb 7, 2011 at 11:12 AM, Tom Lane wrote:
> =?utf-8?q?Rados=C5=82aw_Smogura?= writes:
>> I'm sending small patch for textsend. It reduces unnecessary copies, and
>> memory usage for duplication of varlena data. May you look?
>
> This code will break the day that text and bytea don't have t
On Mon, Feb 7, 2011 at 4:11 PM, Simon Riggs wrote:
>> So I guess the only remaining issue is whether we should distinguish
>> the error message text, as well as the error codes. Tom was in favor
>> of that upthread, and I am too. Right now we have:
> The error text is already differentiated by
>
On 02/07/2011 11:34 AM, Andrew Dunstan wrote:
On 02/04/2011 05:49 AM, Itagaki Takahiro wrote:
Here is a demonstration to support jagged input files. It's a patch
on the latest patch. The new added API is:
bool NextLineCopyFrom(
[IN] CopyState cstate,
[OUT] char ***field
Heikki Linnakangas wrote:
> Ok, committed.
Thanks for that, and for all the suggestions along the way!
Thanks also to Joe Conway for the review and partial commit in the
first CF for this release; to Jeff Davis for the reviews, pointing
out areas which needed work; and to Anssi Kääriäinen fo
On Mon, Feb 7, 2011 at 5:23 PM, Magnus Hagander wrote:
> On Mon, Feb 7, 2011 at 23:14, Heikki Linnakangas
> wrote:
>> On 06.02.2011 20:30, Kevin Grittner wrote:
>>>
>>> "Kevin Grittner" wrote:
>>>
I'm working on it now, and hope to have it all settled down today.
>>>
>>> Done and pushed to
On Mon, Feb 7, 2011 at 23:14, Heikki Linnakangas
wrote:
> On 06.02.2011 20:30, Kevin Grittner wrote:
>>
>> "Kevin Grittner" wrote:
>>
>>> I'm working on it now, and hope to have it all settled down today.
>>
>> Done and pushed to the git repo. Branch serializable on:
>>
>> git://git.postgresql.o
On Mon, 2011-02-07 at 11:50 -0800, Josh Berkus wrote:
> >> I just spoke to my manager at EnterpriseDB and he cleared my schedule
> >> for the next two days to work on this. So I'll go hack on this now.
> >> I haven't read the patch yet so I don't know for sure how quite I'll
> >> be able to get up
On 06.02.2011 20:30, Kevin Grittner wrote:
"Kevin Grittner" wrote:
I'm working on it now, and hope to have it all settled down today.
Done and pushed to the git repo. Branch serializable on:
git://git.postgresql.org/git/users/kgrittn/postgres.git
Heikki: I'm back to not having any outstan
Kevin Grittner wrote:
There are occasional posts from those wondering why their read-only
queries are so slow after a bulk load, and why they are doing heavy
writes. (I remember when I posted about that, as a relative newbie,
and I know I've seen others.)
Sure; I created http://wiki.postgre
On Mon, 2011-02-07 at 15:25 -0500, Robert Haas wrote:
> I would certainly appreciate it if
> everyone could at least credit me with acting in good faith.
I think you are, if that helps.
--
Simon Riggs http://www.2ndQuadrant.com/books/
PostgreSQL Development, 24x7 Support, Training a
Just from curious may I ask in which direction this will go, and how this will
affect performance of text and binary format?
Actually I started to make smaller improvements, and I think about one big to
encode text (when client and server encoding are different) directly to
StringInfo, without
dp...@pgadmin.org (Dave Page) writes:
> On Mon, Feb 7, 2011 at 6:55 PM, Robert Haas wrote:
>> On Mon, Feb 7, 2011 at 12:43 PM, Tom Lane wrote:
>>> Robert Haas writes:
... Well, the current CommitFest ends in one week, ...
>>>
>>> Really? I thought the idea for the last CF of a development
Dimitri Fontaine writes:
> Tom Lane writes:
>> If you're worried about that, then it's questionable whether ALTER
>> EXTENSION SET SCHEMA makes sense at all, ever. I don't see any reason
>> to think that an extension is more fragile for this purpose than any
>> other random SQL dependencies. Al
On Wed, 2011-02-02 at 21:21 -0500, Robert Haas wrote:
> On Tue, Feb 1, 2011 at 3:17 AM, Simon Riggs wrote:
> > ERRCODE_DATABASE_DROPPED57P04 looks best
>
> So I guess the only remaining issue is whether we should distinguish
> the error message text, as well as the error codes. Tom was in
On Mon, Feb 7, 2011 at 9:46 PM, Robert Haas wrote:
> On Mon, Feb 7, 2011 at 3:34 PM, Dave Page wrote:
>> On Mon, Feb 7, 2011 at 9:25 PM, Robert Haas wrote:
>>> You're moving the bar. It DOES say that the CommitFest will end on
>>> February 15th. Now, if we want to have a discussion about chang
On Mon, Feb 7, 2011 at 3:34 PM, Dave Page wrote:
> On Mon, Feb 7, 2011 at 9:25 PM, Robert Haas wrote:
>> You're moving the bar. It DOES say that the CommitFest will end on
>> February 15th. Now, if we want to have a discussion about changing
>> that, let's have that discussion (perhaps on a thr
Hello hackers,
Just FYI, the CFP for PgEast in NYC closes in three days.
https://www.postgresqlconference.org/talk_types
Sincerely,
JD
--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engine
On Mon, Feb 7, 2011 at 3:14 PM, Dimitri Fontaine wrote:
> Robert Haas writes:
>> I'm not trying to bypass compromising, and I don't know what makes you
>> think otherwise. I am trying to ensure that the CommitFest wraps up
>
> Well, I'm too tired to allow myself posting such comments, sorry to h
On Mon, Feb 7, 2011 at 9:25 PM, Robert Haas wrote:
> You're moving the bar. It DOES say that the CommitFest will end on
> February 15th. Now, if we want to have a discussion about changing
> that, let's have that discussion (perhaps on a thread where the
> subject has something to do with the to
On Mon, 2011-02-07 at 12:24 -0800, Josh Berkus wrote:
> +1.
>
> I, for one, would vote against extending beta if Sync Rep isn't ready
> yet. There's plenty of other "big features" in 9.1, and Sync Rep will
> benefit from having additional development time given the number of
> major spec points
On Mon, Feb 7, 2011 at 3:06 PM, Dave Page wrote:
>>> Rejecting stuff because we haven't gotten round to dealing with it in
>>> such a short period of time is a damn good way to limit the number of
>>> contributions we get. I don't believe we've agreed at any point that
>>> the last commitfest shou
On 2/7/11 11:41 AM, Robert Haas wrote:
> However, I don't want to prolong
> the CommitFest indefinitely in the face of patches that the authors
> are not actively working on or can't finish in the time available, or
> where there is no consensus that the proposed change is what we want.
> I believe
Robert Haas writes:
> I'm not trying to bypass compromising, and I don't know what makes you
> think otherwise. I am trying to ensure that the CommitFest wraps up
Well, I'm too tired to allow myself posting such comments, sorry to have
left the previous mail through. More than one commit fest s
On Mon, Feb 7, 2011 at 8:59 PM, Robert Haas wrote:
> On Mon, Feb 7, 2011 at 2:56 PM, Dave Page wrote:
>> On Mon, Feb 7, 2011 at 6:55 PM, Robert Haas wrote:
>>> On Mon, Feb 7, 2011 at 12:43 PM, Tom Lane wrote:
Robert Haas writes:
> ... Well, the current CommitFest ends in one week, ...
Robert Haas wrote:
> Dave Page wrote:
>> Robert Haas wrote:
>>> Tom Lane wrote:
Robert Haas writes:
> ... Well, the current CommitFest ends in one week, ...
Really? I thought the idea for the last CF of a development
cycle was that it kept going till we'd dealt with ev
Tom Lane writes:
> If you're worried about that, then it's questionable whether ALTER
> EXTENSION SET SCHEMA makes sense at all, ever. I don't see any reason
> to think that an extension is more fragile for this purpose than any
> other random SQL dependencies. Also, an extension being relocatab
On 02/07/2011 01:39 AM, Itagaki Takahiro wrote:
file_fdw uses CopyFromErrorCallback() to give errors the proper context. The
function uses template strings like "COPY %s, line %d", where %s is the name of
the relation being copied. Presumably file_fdw and other features using this
API woul
On Mon, Feb 7, 2011 at 6:55 PM, Robert Haas wrote:
> On Mon, Feb 7, 2011 at 12:43 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> ... Well, the current CommitFest ends in one week, ...
>>
>> Really? I thought the idea for the last CF of a development cycle was
>> that it kept going till we'd dea
On Mon, Feb 7, 2011 at 2:56 PM, Dave Page wrote:
> On Mon, Feb 7, 2011 at 6:55 PM, Robert Haas wrote:
>> On Mon, Feb 7, 2011 at 12:43 PM, Tom Lane wrote:
>>> Robert Haas writes:
... Well, the current CommitFest ends in one week, ...
>>>
>>> Really? I thought the idea for the last CF of a
On Feb 7, 2011, at 10:23 AM, Tom Lane wrote:
> On reflection, the set of extensions that an extension depends on is
> obviously a property of the extension, which means it ought to be
> specified in the extension's control file, not in the CREATE EXTENSION
> command. So now I'm thinking something
>> I just spoke to my manager at EnterpriseDB and he cleared my schedule
>> for the next two days to work on this. So I'll go hack on this now.
>> I haven't read the patch yet so I don't know for sure how quite I'll
>> be able to get up to speed on it, so if someone who is more familiar
>> with t
On Mon, Feb 7, 2011 at 2:09 PM, Dimitri Fontaine wrote:
> Robert Haas writes:
>> done in the time available is another thing entirely. I do NOT want
>> to still be working on the items for this CommitFest in June - that's
>> about when I'd like to be releasing beta3.
>
> Except that's not how we
Dimitri Fontaine writes:
> That said, we should do something about ALTER EXTENSION SET SCHEMA and
> the relocatable property. I'm thinking that an extension stops being
> relocatable as soon as any of its reverse dependencies (all the tree) is
> not relocatable.
If you're worried about that, the
On Mon, 2011-02-07 at 17:59 +, Simon Riggs wrote:
> On Mon, 2011-02-07 at 12:39 -0500, Robert Haas wrote:
>
> > I just spoke to my manager at EnterpriseDB and he cleared my schedule
> > for the next two days to work on this. So I'll go hack on this now.
> > I haven't read the patch yet so I d
Robert Haas writes:
> done in the time available is another thing entirely. I do NOT want
> to still be working on the items for this CommitFest in June - that's
> about when I'd like to be releasing beta3.
Except that's not how we work here. You want to change that with
respect to the release
2011/2/7 Cédric Villemain :
> 2011/2/7 Robert Haas :
>> On Mon, Feb 7, 2011 at 10:48 AM, Bruce Momjian wrote:
>>> Robert Haas wrote:
On Sat, Feb 5, 2011 at 4:31 PM, Bruce Momjian wrote:
> Uh, in this C comment:
>
> + ? ? ? ?* or not we want to take the time to write it. ?We al
2011/2/7 Robert Haas :
> On Mon, Feb 7, 2011 at 10:48 AM, Bruce Momjian wrote:
>> Robert Haas wrote:
>>> On Sat, Feb 5, 2011 at 4:31 PM, Bruce Momjian wrote:
>>> > Uh, in this C comment:
>>> >
>>> > + ? ? ? ?* or not we want to take the time to write it. ?We allow up to
>>> > 5% of
>>> > + ? ? ?
Tom Lane writes:
> On reflection, the set of extensions that an extension depends on is
> obviously a property of the extension, which means it ought to be
> specified in the extension's control file, not in the CREATE EXTENSION
> command. So now I'm thinking something like
>
> requires = '
Greg Smith wrote:
> As a larger statement on this topic, I'm never very excited about
> redesigning here starting from any point other than "saw a
> bottleneck doing on a production system". There's a long list
> of such things already around waiting to be addressed, and I've
> never seen any g
On sön, 2011-01-30 at 14:52 -0800, Jeff Davis wrote:
> * naming issues:
> - period -> tsrange ?
> - periodtz -> tstzrange ?
> - intrange -> int4range
Have you considered a grammar approach like for arrays, so that you
would write something like
CREATE TABLE ... (
foo RANGE OF in
I wrote:
> ... So where I think we're going to end up
> is adding a clause along the line of "USING list-of-extension-names"
> to CREATE EXTENSION, storing those dependencies explicitly, and having
> the CREATE EXTENSION code set search_path to the target schema followed
> by the target schema(s) o
Dimitri Fontaine writes:
> Tom Lane writes:
>> I think we'd better add an extowner column to pg_extension.
> Agreed. There's no need to have it now but we will add it at some
> point. So if now is when that works the best for you, I'm happy to see
> that happen :)
BTW, on trying this I notic
On Mon, Feb 7, 2011 at 12:59 PM, Simon Riggs wrote:
> On Mon, 2011-02-07 at 12:39 -0500, Robert Haas wrote:
>
>> I just spoke to my manager at EnterpriseDB and he cleared my schedule
>> for the next two days to work on this. So I'll go hack on this now.
>> I haven't read the patch yet so I don't
On Mon, Feb 7, 2011 at 12:43 PM, Tom Lane wrote:
> Robert Haas writes:
>> ... Well, the current CommitFest ends in one week, ...
>
> Really? I thought the idea for the last CF of a development cycle was
> that it kept going till we'd dealt with everything. Arbitrarily
> rejecting stuff we haven
On Mon, 2011-02-07 at 12:39 -0500, Robert Haas wrote:
> I just spoke to my manager at EnterpriseDB and he cleared my schedule
> for the next two days to work on this. So I'll go hack on this now.
> I haven't read the patch yet so I don't know for sure how quite I'll
> be able to get up to speed o
"David E. Wheeler" writes:
> On Feb 7, 2011, at 9:51 AM, Tom Lane wrote:
>> Interesting point. It's all right at the moment because I tweaked
>> pg_dump_sort.c so that procedural languages are dumped before modules.
>> But maybe we should convert the PLs to modules.
> s/modules/extensions/?
Yea
"David E. Wheeler" writes:
> On Feb 7, 2011, at 8:57 AM, Tom Lane wrote:
>> Yeah, this is another approach that one could take instead of having
>> per-row flags. I'm not sure that it's better, much less so much better
>> that we should force extensions to do it that way and not the other.
>> But
On Feb 7, 2011, at 9:51 AM, Tom Lane wrote:
> Interesting point. It's all right at the moment because I tweaked
> pg_dump_sort.c so that procedural languages are dumped before modules.
> But maybe we should convert the PLs to modules.
s/modules/extensions/?
David
--
Sent via pgsql-hackers ma
On Feb 7, 2011, at 9:20 AM, Dimitri Fontaine wrote:
> Also, I didn't bite this bullet, but maybe we should provide core PLs as
> extension. Then CREATE LANGUAGE would maybe get deprecated and only
> valid when used in an extension's script — or the next patch (UPGRADE)
> will take care of create
Dimitri Fontaine writes:
> Tom Lane writes:
>> Quite aside from search path, cross-extension dependencies simply aren't
>> going to work unless pg_dump knows about them so it can load the
>> extensions in the right order. I had forgotten about the earthdistance
>> case, but given that I think we
On Feb 7, 2011, at 8:57 AM, Tom Lane wrote:
> Yeah, this is another approach that one could take instead of having
> per-row flags. I'm not sure that it's better, much less so much better
> that we should force extensions to do it that way and not the other.
> But it's definitely another argument
Robert Haas writes:
> ... Well, the current CommitFest ends in one week, ...
Really? I thought the idea for the last CF of a development cycle was
that it kept going till we'd dealt with everything. Arbitrarily
rejecting stuff we haven't dealt with doesn't seem fair.
re
Kevin Grittner wrote:
> "Kevin Grittner" wrote:
>> Jeff Davis wrote:
>>
>>> What does PredicateLockTuple do that needs a share lock? Does a
>>> pin suffice?
>>
>> If one process is reading a tuple and another is writing it
>> (e.g., UPDATE or DELETE) the concern is that we need to be able
>> t
On Mon, Feb 7, 2011 at 12:28 PM, Robert Haas wrote:
> On Mon, Feb 7, 2011 at 11:33 AM, Simon Riggs wrote:
>> On Mon, 2011-02-07 at 09:55 -0500, Robert Haas wrote:
>>> On Sun, Jan 30, 2011 at 11:44 AM, Robert Haas wrote:
>>> > Time's running short - do you have an updated patch?
>>>
>>> This patc
On Mon, Feb 7, 2011 at 11:33 AM, Simon Riggs wrote:
> On Mon, 2011-02-07 at 09:55 -0500, Robert Haas wrote:
>> On Sun, Jan 30, 2011 at 11:44 AM, Robert Haas wrote:
>> > Time's running short - do you have an updated patch?
>>
>> This patch hasn't been updated in more than three weeks. I assume
>>
Jeff Davis writes:
> Ok, but what should the parameter to CREATE TYPE ... AS RANGE be then?
>
> CREATE TYPE foo AS RANGE (
> SUBTYPE = ...
> SUBTYPE_BTREE_OPERATOR_CLASS = ...
> );
>
> is a little verbose. Ideas?
I would think
CREATE TYPE foo AS RANGE (bar) USING (btree_ops);
The USING cl
Tom Lane writes:
> No, I've hacked the code enough already that merging would be painful.
> I'll keep working on it.
I supposed so much, but got to ask :)
> Oh, duh, I'd forgotten about the OverrideSearchPath usage. So never
> mind the above claim. But I still think it'd be a good idea to ensu
peder...@ccsscorp.com ("Bill Pedersen") writes:
> I look forward to hearing from people in the PostgreSQL community as well as
> from others interested in this effort.
To a number of us, it's academically interesting, though, as we don't
have VMS systems, it's not likely to be super-easy to assist
On Mon, Feb 7, 2011 at 10:48 AM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Sat, Feb 5, 2011 at 4:31 PM, Bruce Momjian wrote:
>> > Uh, in this C comment:
>> >
>> > + ? ? ? ?* or not we want to take the time to write it. ?We allow up to 5%
>> > of
>> > + ? ? ? ?* otherwise-not-dirty pages to
On Mon, 2011-02-07 at 13:33 +0100, Dimitri Fontaine wrote:
> Hi,
>
> Jeff Davis writes:
> > * Should pg_range reference the btree opclass or the compare function
> > directly?
>
> I would say yes. We use the btree opclass in other similar situations.
Ok, but what should the parameter to CREA
Florian Pflug writes:
> We could avoid the need for a per-row "system_data" flag if we required
> extensions to split user-editable and system-provided configuration data
> into different tables. For convenient access to the configuration data,
> the extension could let the user-editable table inh
Dimitri Fontaine writes:
> Tom Lane writes:
>> I think we'd better add an extowner column to pg_extension.
> Agreed. There's no need to have it now but we will add it at some
> point. So if now is when that works the best for you, I'm happy to see
> that happen :)
> Would it help that I prep
On Sun, 2011-02-06 at 20:10 +0100, Erik Rijkers wrote:
> I was trying
> where intrange @> integer
>
> which admittedly is not in the documentation,
> but does already half work, and would be really
> convenient to have. As it stands the construct
> seems to fail after ANALYZE, when there is m
On Feb6, 2011, at 19:23 , Tom Lane wrote:
> After a bit of thought I believe that we can fix this if we are willing
> to teach pg_dump explicitly about extension configuration tables.
> The behavior we want for those is for the table schema definition to
> never be dumped (the table should always b
Tom Lane writes:
> One is ownership. Since we don't record the identity of the user who
> created an extension, there's no way for pg_dump to ensure that it's
> recreated by the same user. I think we'll regret that in future even
> if you don't think it's problematic today. In particular, I for
On 02/04/2011 05:49 AM, Itagaki Takahiro wrote:
Here is a demonstration to support jagged input files. It's a patch
on the latest patch. The new added API is:
bool NextLineCopyFrom(
[IN] CopyState cstate,
[OUT] char ***fields, [OUT] int *nfields, [OUT] Oid *tupleOid)
It j
On Mon, 2011-02-07 at 09:55 -0500, Robert Haas wrote:
> On Sun, Jan 30, 2011 at 11:44 AM, Robert Haas wrote:
> > Time's running short - do you have an updated patch?
>
> This patch hasn't been updated in more than three weeks. I assume
> this should now be marked Returned with Feedback, and we'l
Dimitri Fontaine writes:
> Tom Lane writes:
>> one I'd been thinking about a bit was OIDs of modules this one depends
>> on. The current design doesn't cope very well with modules that depend
>> on other ones.
> Or even at all. I guess here "modules" is referring to shared object
> libraries,
Robert Haas wrote:
> On Sun, Jan 30, 2011 at 11:44 AM, Robert Haas wrote:
> > Time's running short - do you have an updated patch?
>
> This patch hasn't been updated in more than three weeks. I assume
> this should now be marked Returned with Feedback, and we'll revisit
> synchronous replication
Tom Lane writes:
> one I'd been thinking about a bit was OIDs of modules this one depends
> on. The current design doesn't cope very well with modules that depend
> on other ones.
Or even at all. I guess here "modules" is referring to shared object
libraries, right? Or are you already thinking
Vaibhav Kaushal writes:
> Hi,
> I find that ExecInitExpr creates a ExprState tree (and so say the
> comments above the function in the source). Also, it seems to decide
> which function would get called when the expression is to be evaluated
> when ExecQual runs, by setting the function pointer, f
=?utf-8?q?Rados=C5=82aw_Smogura?= writes:
> I'm sending small patch for textsend. It reduces unnecessary copies, and
> memory usage for duplication of varlena data. May you look?
This code will break the day that text and bytea don't have the same
internal representation, which seems likely to b
The update on the work to push towards a bigger pgbench is that I now
have the patch running and generating databases larger than any
previously possible scale:
$ time pgbench -i -s 25000 pgbench
...
25 tuples done.
...
real258m46.350s
user14m41.970s
sys0m21.310s
$ psql -d
There are some things that the current extensions patch leaves
indeterminate during a dump and reload cycle, which strikes me
as a bad thing.
One is ownership. Since we don't record the identity of the user who
created an extension, there's no way for pg_dump to ensure that it's
recreated by the
Robert Haas wrote:
> On Sat, Feb 5, 2011 at 4:31 PM, Bruce Momjian wrote:
> > Uh, in this C comment:
> >
> > + ? ? ? ?* or not we want to take the time to write it. ?We allow up to 5%
> > of
> > + ? ? ? ?* otherwise-not-dirty pages to be written due to hint bit changes,
> >
> > 5% of what? ?5% of
1 - 100 of 130 matches
Mail list logo
