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
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 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
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 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 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 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
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 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
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 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
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 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
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 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 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 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 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 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, 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 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 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 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
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_
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 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(
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
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
(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
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
101 - 130 of 130 matches
Mail list logo
