(2010/08/16 11:50), Robert Haas wrote:
> On Fri, Aug 6, 2010 at 11:15 PM, KaiGai Kohei wrote:
>> [brief review]
>
> OK, here's an updated patch:
>
> 1. I fixed the typo Alvaro spotted.
>
> 2. I haven't done anything about moving the definition of
> ObjectAddress elsewhere, as Alvaro suggested,
On Sun, Aug 15, 2010 at 11:03 PM, Tom Lane wrote:
> Charles Pritchard writes:
>> I'd originally sent this to Joseph Adams, as he has been working on
>> adding a JSON datatype.
>> I've suggested supporting BSON, as there are many client implementations
>> available,
>
> I knew there would be a lot
On 08/15/2010 11:03 PM, Tom Lane wrote:
Charles Pritchard writes:
I'd originally sent this to Joseph Adams, as he has been working on
adding a JSON datatype.
I've suggested supporting BSON, as there are many client implementations
available,
I knew there would be a lot of critters crawling o
Charles Pritchard writes:
> I'd originally sent this to Joseph Adams, as he has been working on
> adding a JSON datatype.
> I've suggested supporting BSON, as there are many client implementations
> available,
I knew there would be a lot of critters crawling out as soon as we
turned over this r
(2010/08/15 9:55), Robert Haas wrote:
> 2010/8/14 KaiGai Kohei:
>> (2010/08/15 9:16), Stephen Frost wrote:
>>> * KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
Yep, rte->requiredPerms of inherited relations are cleared on the
expand_inherited_rtentry() since the v9.0, so we cannot know what
>>
Robert Haas writes:
> On Sun, Aug 15, 2010 at 9:25 PM, Tom Lane wrote:
>> ... and PANIC is absolutely, entirely, 100% unacceptable here. I don't
>> think you understand the context. We've already written the truncate
>> action to WAL (as we must: WAL before data change). If we PANIC, that
>> m
On Sun, Aug 15, 2010 at 10:20 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Aug 15, 2010 at 7:49 PM, Tom Lane wrote:
>>> FWIW, I *don't* like this version, specifically because it fails to
>>> utilize the pg_wchar datatype. The function in question is neither big
>>> enough nor mutable e
Robert Haas writes:
> On Sun, Aug 15, 2010 at 7:49 PM, Tom Lane wrote:
>> FWIW, I *don't* like this version, specifically because it fails to
>> utilize the pg_wchar datatype. The function in question is neither big
>> enough nor mutable enough that it's urgent to not duplicate it between
>> the
On Sun, Aug 15, 2010 at 9:25 PM, Tom Lane wrote:
> Robert Haas writes:
>> Oh, sorry. I was thinking we were talking about complete truncation
>> rather than partial truncation. I'm still pretty unhappy with the
>> proposed fix, though, because it gives up performance in a broad range
>> of case
I'd originally sent this to Joseph Adams, as he has been working on
adding a JSON datatype.
I've suggested supporting BSON, as there are many client implementations
available,
and the format is more efficient than xml and json trees for some use cases.
http://bsonspec.org/
On 8/15/10 11:27 AM,
Robert Haas writes:
> Oh, sorry. I was thinking we were talking about complete truncation
> rather than partial truncation. I'm still pretty unhappy with the
> proposed fix, though, because it gives up performance in a broad range
> of cases to cater to an extremely narrow failure case.
It does
On Sun, Aug 15, 2010 at 7:49 PM, Tom Lane wrote:
> Joseph Adams writes:
>> I've attached another patch that moves utf8_to_unicode to src/port per
>> Robert Haas's suggestion.
>
>> This patch itself is not quite as elegant as the first one because it
>> puts platform-independent code that "belongs
On Sun, Aug 15, 2010 at 5:39 PM, Tom Lane wrote:
>> Could we avoid this
>> altogether by allocating a new relfilenode on truncate?
>
> Then we'd have to copy all the data we *didn't* truncate, which is
> hardly likely to be a win.
Oh, sorry. I was thinking we were talking about complete truncati
Heikki Linnakangas writes:
> One approach is to handle the conversion from unknown to the right data
> type transparently in the backend. Attached patch adds a
> coerce-param-hook for fixed params that returns a CoerceViaIO node to
> convert the param to the right type at runtime. That's quite
Joseph Adams writes:
> I've attached another patch that moves utf8_to_unicode to src/port per
> Robert Haas's suggestion.
> This patch itself is not quite as elegant as the first one because it
> puts platform-independent code that "belongs" in wchar.c into src/port
> . It also uses unsigned int
I wrote:
> Robert Haas writes:
>> Could we avoid this
>> altogether by allocating a new relfilenode on truncate?
> Then we'd have to copy all the data we *didn't* truncate, which is
> hardly likely to be a win.
There is one thing we could do pretty easily. AFAICS there are
presently just two us
Greg Stark writes:
> On Sun, Aug 15, 2010 at 9:48 PM, Heikki Linnakangas
> wrote:
>> On 15/08/10 21:58, Tom Lane wrote:
>>> Does anyone have an opinion whether it's likely that any third-party
>>> code is calling DropRelFileNodeBuffers directly?
>>
>> I doubt it. External modules shouldn't be mo
Robert Haas writes:
> I really hate this solution, because writing out data that we're about
> to throw away just in case we can't actually throw it away seems like
> a real waste from a performance standpoint.
We went around on this already in the pgsql-bugs thread. I don't much
like it either,
Robert Haas writes:
> 2010/8/11 Boszormenyi Zoltan :
>> Shouldn't it at least be documented in more depth? Say, get_bit(, N)
>> provides the Nth bit (0-based) counting from the leftmost bit?
>> I would certainly appreciate a warning spelled out about this
>> so if you convert a number to bitstring
On Sun, Aug 15, 2010 at 9:48 PM, Heikki Linnakangas
wrote:
> On 15/08/10 21:58, Tom Lane wrote:
>>
>> Does anyone have an opinion whether it's likely that any third-party
>> code is calling DropRelFileNodeBuffers directly?
>
> I doubt it. External modules shouldn't be modifying relations at such a
On Sun, Aug 15, 2010 at 2:58 PM, Tom Lane wrote:
> In the discussion of bug #5599 we pretty much agreed to do this:
>> Seems like we need to think harder about recovering from a truncate
>> failure. A few random ideas:
>> 1. Write the dirty buffers before dropping them. Kind of ugly from a
>> pe
Robert Haas writes:
> On Sun, Aug 15, 2010 at 3:22 PM, Tom Lane wrote:
>> I'm not sure that we have any non-relation objects that are both complex
>> enough and changeable enough for there to be an observable bug here,
>> but it seems like a risk factor going forward. It seems to me both safe
>>
On Sun, Aug 15, 2010 at 3:22 PM, Tom Lane wrote:
> Robert Haas writes:
>> It seems suspicious to me that LockSharedObject() calls
>> AcceptInvalidationMessges() and LockDatabaseObject() does not. Since
>> the only caller of LockSharedObject() at present is
>> AcquireDeletionLock(), I'm not sure
On 15/08/10 21:58, Tom Lane wrote:
Does anyone have an opinion whether it's likely that any third-party
code is calling DropRelFileNodeBuffers directly?
I doubt it. External modules shouldn't be modifying relations at such a
low level.
--
Heikki Linnakangas
EnterpriseDB http://www.ente
Peter Eisentraut writes:
> Thinking about SQL assertions (check constraints that are independent of
> one particular table), do you think it would be reasonable to implement
> those on top of constraint triggers? On creation you'd hook up a
> trigger to each of the affected tables. And the trigg
On Sun, Aug 15, 2010 at 03:41:09PM -0400, Tom Lane wrote:
> Andres Freund writes:
> > On Friday 06 August 2010 20:23:15 Tom Lane wrote:
> >> I'd be willing to consider a "half assert" mode that turns off some of
> >> the most expensive checks, but AtEOXact_Buffers is hardly the only thing
> >> tha
Andres Freund writes:
> On Friday 06 August 2010 20:23:15 Tom Lane wrote:
>> I'd be willing to consider a "half assert" mode that turns off some of
>> the most expensive checks, but AtEOXact_Buffers is hardly the only thing
>> that ought to be in that list. The CLOBBER_FREED_MEMORY and memory
>>
Robert Haas writes:
> It seems suspicious to me that LockSharedObject() calls
> AcceptInvalidationMessges() and LockDatabaseObject() does not. Since
> the only caller of LockSharedObject() at present is
> AcquireDeletionLock(), I'm not sure there's an observable bug here at
> the moment, but then
In the discussion of bug #5599 we pretty much agreed to do this:
> Seems like we need to think harder about recovering from a truncate
> failure. A few random ideas:
> 1. Write the dirty buffers before dropping them. Kind of ugly from a
> performance viewpoint, but simple and safe.
I looked at m
James William Pye writes:
> On Aug 14, 2010, at 9:08 AM, Tom Lane wrote:
>> Just to clarify, you're recommending something like
>>
>> proc->me = PyCObject_FromVoidPtr(proc, NULL);
>> +if (proc->me == NULL)
>> +elog(ERROR, "could not create PyCObject fo
We (Marko, David Fetter and I) discussed on IRC about design of
writeable CTEs. It does and will contain not only syntax but also
miscellaneous specifications, general rules and restrictions. I hope
this will help the patch reviews and stop dangerous design at the
early stage. If you find something
2010/7/13 Marko Tiikkaja :
> On 7/12/10 9:34 PM +0300, Tom Lane wrote:
>>
>> Marko Tiikkaja writes:
>>>
>>> ... So what I'm now thinking of is making the planner plan that as a
>>> single
>>> Query, and make the planner expand it into multiple PlannedStmts if
>>> necessary. This would break the e
On 15/08/10 10:31, Boxuan Zhai wrote:
On Sun, Aug 15, 2010 at 4:05 AM, Heikki Linnakangas<
heikki.linnakan...@enterprisedb.com> wrote:
Thanks. I went through this, fixing all the spurious end-of-line whitespace
first with "git apply --whitespace=fix", and then manually fixing comment
and whites
On Sun, Aug 15, 2010 at 4:05 AM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> On 11/08/10 11:11, Boxuan Zhai wrote:
>
>> The new patch is done. I named it as merge_v102. (1 means it is the
>> non-inheritance merge command, 02 means this is the second time of fixing
>> reporte
34 matches
Mail list logo
