On 09 April 2014 21:25, Robert Haas Wrote:
Deadlock Detection:
I'm not sure how this would work out internally
In order to resolve deadlock, two member variable will be created in
the structure PROLOCK:
Bitmask for lock types currently held by autonomous
transaction.
Hello
I propose a enhancing of EXPLAIN statement about possibility get a plan of
other PostgreSQL process. With some other enhancing this technique can be
interesting for monitoring long duration queries.
Notes, comments?
Regards
Pavel Stehule
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 sergey.k.murav...@gmail.com:
Hi.
Thanks for your tests.
I've fixed problem with headers, but got new one with data.
I'll try to solve it
On 11 April 2014 04:04, Stephen Frost sfr...@snowman.net 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
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 applying.
On 10 April 2014 22:52, Tom Lane t...@sss.pgh.pa.us wrote:
Dean Rasheed dean.a.rash...@gmail.com 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
(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
fujita.ets...@lab.ntt.co.jp 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
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
On 11 April 2014 04:04, Stephen Frost sfr...@snowman.net 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
On 04/11/2014 01:35 AM, Amit Kapila wrote:
On Fri, Apr 11, 2014 at 3:14 AM, Bruce Momjian br...@momjian.us 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()
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 br...@momjian.us wrote:
Can someone with Windows expertise comment on whether this should be
applied?
I don't think this is a complete fix, for
(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 about it.
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
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
* 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 happen
On Fri, Apr 11, 2014 at 10:03:08AM +0530, Amit Kapila wrote:
On Fri, Apr 11, 2014 at 10:00 AM, Amit Kapila amit.kapil...@gmail.com wrote:
On Thu, Apr 10, 2014 at 5:21 PM, Bruce Momjian br...@momjian.us wrote:
On Thu, Apr 10, 2014 at 11:05:49AM +0530, Amit Kapila wrote:
Ah, yes, good
On Fri, Apr 11, 2014 at 1:26 PM, Heikki Linnakangas
hlinnakan...@vmware.com 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
On Fri, Apr 11, 2014 at 9:53 PM, lkcl . luke.leigh...@gmail.com wrote:
On Fri, Apr 11, 2014 at 1:26 PM, Heikki Linnakangas
hlinnakan...@vmware.com 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
On Fri, Apr 11, 2014 at 2:12 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Fri, Apr 11, 2014 at 9:53 PM, lkcl . luke.leigh...@gmail.com wrote:
section: https://wiki.postgresql.org/wiki/Materialized_Views.
When updating a materialized view, or refreshing it, you need as well
to be
Stephen Frost sfr...@snowman.net 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
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
Florian Pflug f...@phlo.org 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,
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
On Apr11, 2014, at 17:09 , Tom Lane t...@sss.pgh.pa.us 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
I hope that I realized old-ascii logic correctly.
2014-04-11 19:10 GMT+04:00 Greg Stark st...@mit.edu:
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
Florian Pflug f...@phlo.org writes:
On Apr11, 2014, at 17:09 , Tom Lane t...@sss.pgh.pa.us 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
On Apr11, 2014, at 19:04 , Tom Lane t...@sss.pgh.pa.us 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
Dean Rasheed dean.a.rash...@gmail.com writes:
On 10 April 2014 19:54, Tom Lane t...@sss.pgh.pa.us 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
Florian Pflug f...@phlo.org 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
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
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 alvhe...@2ndquadrant.com:
Sergey Muraviov wrote:
I hope that I realized old-ascii logic correctly.
I don't know what you changed here, but I
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
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()
On Apr11, 2014, at 19:42 , Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug f...@phlo.org 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.
On Fri, Apr 11, 2014 at 4:42 PM, Andrew Dunstan and...@dunslane.net 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
On Wed, Apr 9, 2014 at 9:20 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Apr 9, 2014 at 7:41 AM, Amit Kapila amit.kapil...@gmail.com 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
35 matches
Mail list logo
