On Wed, Apr 9, 2014 at 9:20 PM, Robert Haas wrote:
> On Wed, Apr 9, 2014 at 7:41 AM, Amit Kapila wrote:
>> I am just not sure whether it is okay to rearrange the code and call
>> GetLastError() only if returned handle is Invalid (NULL) or try to look
>> for more info.
>
> Well, I don't know eithe
On Fri, Apr 11, 2014 at 4:42 PM, Andrew Dunstan wrote:
> On 04/11/2014 01:35 AM, Amit Kapila wrote:
>> I don't think this is a complete fix, for example what about platform
>> where
>> _CreateRestrictedToken() is not supported. For Example, the current
>> proposed fix will not work for below case
On Apr11, 2014, at 19:42 , Tom Lane wrote:
> Florian Pflug writes:
>> Yes, the idea had come up at some point during the review discussion. I
>> agree that it's only worthwhile if it works for state type internal - though
>> I think there ought to be a way to allow that. We could for example simp
Hackers,
the Slony team has been getting seldom reports of a problem with the
txid_snapshot data type.
The symptom is that a txid_snapshot on output lists the same txid
multiple times in the xip list part of the external representation. This
string is later rejected by txid_snapshot_in() whe
Yeah, I think I agree. I'm pretty happy to commit it without old-ascii
doing anything special.
It looks to me like old-ascii just isn't very useful for a single column
output (like expanded mode is implicitly). Maybe that needs to be fixed but
then it needs to be fixed for non expanded mode as wel
There were no support for wrapping and old-ascii line style in expanded
mode at all.
But now they are.
2014-04-11 21:58 GMT+04:00 Alvaro Herrera :
> Sergey Muraviov wrote:
> > I hope that I realized old-ascii logic correctly.
>
> I don't know what you changed here, but I don't think we need to
Sergey Muraviov wrote:
> I hope that I realized old-ascii logic correctly.
I don't know what you changed here, but I don't think we need to
preserve old-ascii behavior in the new code, in any way. If you're
mimicking something obsolete and the end result of the new feature is
not great, perhaps t
Florian Pflug writes:
> Yes, the idea had come up at some point during the review discussion. I
> agree that it's only worthwhile if it works for state type internal - though
> I think there ought to be a way to allow that. We could for example simply
> decree that the initfunc's first parameter m
Dean Rasheed writes:
> On 10 April 2014 19:54, Tom Lane wrote:
>> So if we go with that terminology, perhaps these names for the
>> new CREATE AGGREGATE parameters:
>>
>> initfuncapplies to plain aggregation, mutually exclusive with
>> initcond
>> msfunc (or just mfunc?) forwar
On Apr11, 2014, at 19:04 , Tom Lane wrote:
> It strikes me that your second point
>
>> 2) It allows strict aggregates whose state type and input type aren't
>> binary coercible to return NULL if all inputs were NULL without any
>> special coding. As it stands today, this doesn't work wit
Florian Pflug writes:
> On Apr11, 2014, at 17:09 , Tom Lane wrote:
>> Basically, this comes down to a design judgment call, and my judgment
>> is differing from yours. In the absence of opinions from others,
>> I'm going to do it my way.
> Ok. Are you going to do the necessary changes, or shall
I hope that I realized old-ascii logic correctly.
2014-04-11 19:10 GMT+04:00 Greg Stark :
> Looks good.
>
> It's still not doing the old-ascii column dividers but to be honest
> I'm not sure what the intended behaviour of old-ascii is. I've noticed
> old-ascii only displays the line markers for
On Apr11, 2014, at 17:09 , Tom Lane wrote:
> Basically, this comes down to a design judgment call, and my judgment
> is differing from yours. In the absence of opinions from others,
> I'm going to do it my way.
Ok. Are you going to do the necessary changes, or shall I? I'm happy to
leave it to y
Looks good.
It's still not doing the old-ascii column dividers but to be honest
I'm not sure what the intended behaviour of old-ascii is. I've noticed
old-ascii only displays the line markers for dividing lines, not the
final one. That seems pretty useless and maybe it's why we switched to
the new
Florian Pflug writes:
> Which is why I feel that having two separate sets of transition functions
> and state types solves the wrong problem. If we find a way to prevent
> transition functions from being called directly, we'll shave a few cycles
> of quite a few existing aggregates, invertible or
Hi,
VACUUM sometimes waits synchronously for a cleanup lock on a heap
page. Sometimes for a long time. Without reporting it externally.
Rather confusing ;).
Since we only take cleanup locks around vacuum, how about we report at
least in pgstat that we're waiting? At the moment, there's really no
Stephen Frost writes:
> * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
>> Am I right in thinking that the "locking gotcha" only happens if you
>> create a security_barrier view conaining a "SELECT ... FOR UPDATE"? If
>> so, that seems like rather a niche case - not that that means we
>> shouldn'
On Fri, Apr 11, 2014 at 2:12 PM, Michael Paquier
wrote:
> On Fri, Apr 11, 2014 at 9:53 PM, lkcl . wrote:
>>> section: https://wiki.postgresql.org/wiki/Materialized_Views.
> When updating a materialized view, or refreshing it, you need as well
> to be aware that an exclusive lock is taken on it du
On Fri, Apr 11, 2014 at 9:53 PM, lkcl . wrote:
> On Fri, Apr 11, 2014 at 1:26 PM, Heikki Linnakangas
> wrote:
>> On 04/11/2014 03:20 PM, lkcl . wrote:
>>>
>>> so i had an idea. there already exists the concept of indexes. there
>>> already exists the concept of "cached queries". question: woul
On Fri, Apr 11, 2014 at 1:26 PM, Heikki Linnakangas
wrote:
> On 04/11/2014 03:20 PM, lkcl . wrote:
>>
>> so i had an idea. there already exists the concept of indexes. there
>> already exists the concept of "cached queries". question: would it be
>> practical to*merge* those two concepts such
On Fri, Apr 11, 2014 at 10:03:08AM +0530, Amit Kapila wrote:
> On Fri, Apr 11, 2014 at 10:00 AM, Amit Kapila wrote:
> > On Thu, Apr 10, 2014 at 5:21 PM, Bruce Momjian wrote:
> >> On Thu, Apr 10, 2014 at 11:05:49AM +0530, Amit Kapila wrote:
> >
> >> Ah, yes, good point. This is going to require b
* Craig Ringer (cr...@2ndquadrant.com) wrote:
> > Hmm, the 'gotcha' I was referring to was the issue discussed upthread
> > around rows getting locked to be updated which didn't pass all the quals
> > (they passed the security_barrier view's, but not the user-supplied
> > ones), which could happ
On 04/11/2014 03:20 PM, lkcl . wrote:
so i had an idea. there already exists the concept of indexes. there
already exists the concept of "cached queries". question: would it be
practical to*merge* those two concepts such that specific queries
could be*updated* as new records are added, such
hi folks, please cc me direct on responses as i am subscribed on digest.
i've been asked to look at how to deal with around 7 billion records
(appx 30 columns, appx data size total 1k) and this might have to be
in a single system (i will need to Have Words with the client about
that). the data is
(Sorry if this breaks the thread history; on mobile)
> > Am I right in thinking that the "locking gotcha" only happens if you
> > create a security_barrier view conaining a "SELECT ... FOR UPDATE"? If
> > so, that seems like rather a niche case - not that that means we
> > shouldn't warn people
On 2014-04-11 07:12:50 -0400, Andrew Dunstan wrote:
>
> On 04/11/2014 01:35 AM, Amit Kapila wrote:
> >On Fri, Apr 11, 2014 at 3:14 AM, Bruce Momjian wrote:
> >>Can someone with Windows expertise comment on whether this should be
> >>applied?
> >I don't think this is a complete fix, for example wh
On 04/11/2014 01:35 AM, Amit Kapila wrote:
On Fri, Apr 11, 2014 at 3:14 AM, Bruce Momjian wrote:
Can someone with Windows expertise comment on whether this should be
applied?
I don't think this is a complete fix, for example what about platform where
_CreateRestrictedToken() is not supported.
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 11 April 2014 04:04, Stephen Frost wrote:
> > which changes it to "if a relation was changed to a subquery, it had
> > better be because it's got securityQuals that we're dealing with". My
> > general thinking here is that we'd be bette
(2014/04/09 12:03), Etsuro Fujita wrote:
(2014/04/09 1:23), Robert Haas wrote:
On Tue, Apr 8, 2014 at 5:05 AM, Etsuro Fujita
wrote:
Attached is a patch to improve the manual page for the ALTER TABLE
command.
Do we really need to add a section for "type_name" when we already
have a section fo
On 10 April 2014 22:52, Tom Lane wrote:
> Dean Rasheed writes:
>> I was imagining that firsttrans would only be passed the first value
>> to be aggregated, not any previous state, and that it would be illegal
>> to specify both an initcond and a firsttrans function.
>
>> The forward transition fu
Hello. Thank you for the attentive comments.
> I wrote:
> > I still think this stuff mostly needs to be thrown away and rewritten
> > in Path-creation style, but that's a long-term project. In the meantime
> > this seems like a relatively small increment of complexity, so maybe it's
> > worth app
On 11 April 2014 04:04, Stephen Frost wrote:
> Dean, Craig, all,
>
> * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
>> This is reflected in the change to the regression test output where,
>> in one of the tests, the ctids for the table to update are no longer
>> coming from the same table. I thi
Hi.
I've done some corrections for printing "newline" and "wrap" indicators.
Please review the attached patch.
2014-04-11 0:14 GMT+04:00 Sergey Muraviov :
> Hi.
>
> Thanks for your tests.
>
> I've fixed problem with headers, but got new one with data.
> I'll try to solve it tomorrow.
>
>
> 2014
33 matches
Mail list logo
