On Sat, Jun 11, 2011 at 8:01 PM, Robert Haas wrote:
>
> "can't reassign objects owned by %s because this user is internal to
> the database system" ?
>
that message is not that clear... it seems to imply i can't reassign
any object from that user...
btw, i'm allowed to use ALTER TABLE to assign
Thanks for the review.
(2011/06/12 13:21), Robert Haas wrote:
> 2011/6/9 Shigeru Hanada:
>> Attached patch includes fixes for FOREIGN TABLE documents:
>
> I committed the changes to ALTER FOREIGN TABLE, but I think the
> changes to CREATE FOREIGN TABLE need more thought. The first of the
> two h
On Sun, Jun 12, 2011 at 10:56:41PM -0400, Robert Haas wrote:
> On Sun, Jun 12, 2011 at 9:23 PM, Noah Misch wrote:
> >> I haven't reviewed
> >> your patch in detail, but is there a way we can encapsulate the
> >> knowledge of the invalidation system down inside the sinval machinery,
> >> rather tha
On Mon, Jun 13, 2011 at 12:47 AM, Darren Duncan wrote:
>>> If you're referring to the case
>>> (1) Create table with text-range column and collation C1
>>> (2) Add check constraint containing RANGE_EMPTY()
>>> (3) Add data
>>> (4) Alter column to have collation C2, possibly changing
>>> th
Robert Haas wrote:
On Sun, Jun 12, 2011 at 7:53 AM, Florian Pflug wrote:
I think the collation is going to have to be baked into the type
definition, no? You can't just up and change the collation of the
column as you could for a straight text column, if that might cause
the contents of some r
On 06/11/2011 03:21 PM, Jeff Janes wrote:
I wouldn't expect IPC chatter to show up in profiling, because it
costs wall time, but not CPU time. The time spent might be attributed
to the kernel, or to pgbench, or to nothing at all.
Profilers aren't necessarily just accumulating raw CPU time
On Sun, Jun 12, 2011 at 12:17 PM, Alexander Korotkov
wrote:
> I'm worrying about perfomance of "column <@ const" estimation. It takes
> O(m*(n+m)) of time, where m - const length and n - statistics target.
> Probably, it can be too slow is some some cases.
Hmm, that doesn't sound terribly promisi
On Sun, Jun 12, 2011 at 11:44 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Jun 12, 2011 at 7:46 AM, Florian Pflug wrote:
>>> (B) There should be a way to use ANY()/ALL() with the
>>> array elements becoming the left arguments of the operator.
>
>> It seems to me that if we provided some
On Sun, Jun 12, 2011 at 7:53 AM, Florian Pflug wrote:
>> I think the collation is going to have to be baked into the type
>> definition, no? You can't just up and change the collation of the
>> column as you could for a straight text column, if that might cause
>> the contents of some rows to be
Robert Haas writes:
> On Sun, Jun 12, 2011 at 7:46 AM, Florian Pflug wrote:
>> (B) There should be a way to use ANY()/ALL() with the
>> array elements becoming the left arguments of the operator.
> It seems to me that if we provided some way of handling this, your
> first proposal would be moot;
On Sun, Jun 12, 2011 at 7:46 AM, Florian Pflug wrote:
> So I the end, I had to wrap the sub-query in a SQL-language
> function and use that in the check constraint. While this
> solved my immediate problem, the necessity of doing that
> highlights a few problems
>
> (A) "~" is an extremely bad nam
On Sun, Jun 12, 2011 at 8:40 AM, Florian Pflug wrote:
> Note that this restriction was removed in postgres 9.1 which
> is currently in beta. However, GIT indices must be re-created
> with REINDEX after upgrading from 9.0 to leverage that
> improvement.
Does pg_upgrade know about this?
--
Robert
On Sun, Jun 12, 2011 at 9:23 PM, Noah Misch wrote:
>> I haven't reviewed
>> your patch in detail, but is there a way we can encapsulate the
>> knowledge of the invalidation system down inside the sinval machinery,
>> rather than letting the heap code have to know directly about the
>> counter? Pe
On Sun, Jun 12, 2011 at 3:01 PM, Noah Misch wrote:
> I fully agree. That said, if this works on the standby, we may as well also
> use
> it opportunistically on the master, to throttle bloat.
As long as the performance cost is de minimis, I agree.
>> At any rate, if taking a cleanup lock on th
On Sun, Jun 12, 2011 at 06:20:53PM -0400, Robert Haas wrote:
> On Sun, Jun 12, 2011 at 3:18 PM, Noah Misch wrote:
> > Indeed, the original patch slowed it by about 50%. ?I improved the patch,
> > adding a global SharedInvalidMessageCounter to increment as we process
> > messages. ?If this counter
On Sun, Jun 12, 2011 at 7:59 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian writes:
>> > Did the system create the .git/config '[branch "REL9_1_STABLE"]' section
>> > for you or did you create it manually?
>>
>> git created them for me. I did no config hacking whatever, but now
>> I
On Sun, Jun 12, 2011 at 5:58 PM, Greg Stark wrote:
> On Sun, Jun 12, 2011 at 10:39 PM, Robert Haas wrote:
>> I hacked up the system to
>> report how often each lwlock spinlock exceeded spins_per_delay.
>
> I don't doubt the rest of your analysis but one thing to note, number
> of spins on a spinl
Tom Lane wrote:
> Bruce Momjian writes:
> > Did the system create the .git/config '[branch "REL9_1_STABLE"]' section
> > for you or did you create it manually?
>
> git created them for me. I did no config hacking whatever, but now
> I have:
>
> [branch "REL9_1_STABLE"]
> remote = origin
>
Bruce Momjian writes:
> Did the system create the .git/config '[branch "REL9_1_STABLE"]' section
> for you or did you create it manually?
git created them for me. I did no config hacking whatever, but now
I have:
[branch "REL9_1_STABLE"]
remote = origin
merge = refs/heads/REL9_1
Tom Lane wrote:
> Bruce Momjian writes:
> > I saw your commit that mentioned how to create a new branch. My problem
> > was with using workdir:
>
> There seems to be something rather broken with your setup, because I
> don't find it necessary to do any of that stuff; the recipe in the wiki
> pag
On Sun, Jun 12, 2011 at 3:18 PM, Noah Misch wrote:
> Indeed, the original patch slowed it by about 50%. I improved the patch,
> adding a global SharedInvalidMessageCounter to increment as we process
> messages. If this counter does not change between the RangeVarGetRelid() call
> and the post-lo
On Sun, Jun 12, 2011 at 03:57:08PM -0400, Robert Haas wrote:
> Thus far, locks taken via the fast-path mechanism are not shown in
> pg_locks. I've been mulling over what to do about that. It's a bit
> tricky to show a snapshot of the locks in a way that's guaranteed to
> be globally consistent, b
Peter Eisentraut writes:
> On lör, 2011-06-11 at 16:23 -0400, Bruce Momjian wrote:
>> Uh, I am the first one I remember complaining about this so I don't
>> see why we should break compatibility for such a low-level problem.
>
> I complain about it every day to the wall. :)
+1 !
--
Dimitri Font
On Sun, Jun 12, 2011 at 10:39 PM, Robert Haas wrote:
> I hacked up the system to
> report how often each lwlock spinlock exceeded spins_per_delay.
I don't doubt the rest of your analysis but one thing to note, number
of spins on a spinlock is not the same as the amount of time spent
waiting for i
Bruce Momjian writes:
> I saw your commit that mentioned how to create a new branch. My problem
> was with using workdir:
There seems to be something rather broken with your setup, because I
don't find it necessary to do any of that stuff; the recipe in the wiki
page works fine for me. What git
Here is a patch that applies over the "reducing the overhead of
frequent table locks" (fastlock-v3) patch and allows heavyweight VXID
locks to spring into existence only when someone wants to wait on
them. I believe there is a large benefit to be had from this
optimization, because the combination
With another round of GSoC submissions approaching, I went looking
around for some better guidance on the topic of how to follow terse
submission guidelines like "blend in with the surrounding code" or
"remove spurious whitespace". And I didn't find any. Many mature
open-source projects say t
Well process or thread, the issues are the same.
Check out the existing modules and how they use spinlocks and lwlocks to
protect shared memory data structures.
One thing to beware of is that there's no shared memory manager so all
shared data structures need to be fixed size allocated on startup
On 12.06.2011 17:59, Kevin Grittner wrote:
Heikki Linnakangas wrote:
On 10.06.2011 18:05, Kevin Grittner wrote:
Heikki Linnakangas wrote:
o There is no safeguard against actually wrapping around the
SLRU, just the warning
Any thoughts on what we should do instead? If someone holds open a
tra
On Jun12, 2011, at 19:26 , Seref Arikan wrote:
> This is actually a request for documentation guidance. I intend to
> develop an extension to postgresql. Basically I'd like to place calls
> to network using ZeroMQ, and I need to have detailed information about
> a lot of things, especially threadi
On Thu, Jan 20, 2011 at 09:48:12PM -0500, Robert Haas wrote:
> On Thu, Jan 20, 2011 at 6:19 PM, Noah Misch wrote:
> > On Thu, Jan 20, 2011 at 09:36:11PM +, Simon Riggs wrote:
> >> I agree that the DDL behaviour is wrong and should be fixed. Thank you
> >> for championing that alternative view.
On Sun, Jun 12, 2011 at 12:15:29AM -0400, Robert Haas wrote:
> On Sat, Jun 11, 2011 at 11:40 PM, Noah Misch wrote:
> > We currently achieve that wait-free by first marking the page with the next
> > available xid and then reusing it when that mark (btpo.xact) predates the
> > oldest running xid (R
Greetings,
This is actually a request for documentation guidance. I intend to
develop an extension to postgresql. Basically I'd like to place calls
to network using ZeroMQ, and I need to have detailed information about
a lot of things, especially threading issues. I need to have some
global resour
On Fri, Jun 10, 2011 at 9:03 PM, Simon Riggs wrote:
> Initial comments are that the code is well structured and I doubt
> there will be problems at the code level. Looks like a good patch.
>
I'm worrying about perfomance of "column <@ const" estimation. It takes
O(m*(n+m)) of time, where m - cons
Tom Lane wrote:
> Bruce Momjian writes:
> > Uh, I think someone needs to add this to our wiki:
>
> I did.
I saw your commit that mentioned how to create a new branch. My problem
was with using workdir:
http://wiki.postgresql.org/wiki/Committing_with_Git#Committing_Using_a_Single_Clone
> Heikki Linnakangas wrote:
> On 10.06.2011 18:05, Kevin Grittner wrote:
>> Heikki Linnakangas wrote:
>>> o There is no safeguard against actually wrapping around the
>>> SLRU, just the warning
>>
>> Any thoughts on what we should do instead? If someone holds open a
>> transaction long enough to b
Bruce Momjian writes:
> Uh, I think someone needs to add this to our wiki:
I did.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi
Next time, please post questions regarding the usage of postgres
to the -general list, not to -hackers. The purpose of -hackers is
to discuss the development of postgres proper, not the development
of applications using postgres.
On Jun12, 2011, at 13:33 , Sushant Sinha wrote:
> I am using pg_
I am using pg_trgm for spelling correction as prescribed in the
documentation. But I see that it does not work for unicode sring. The
database was initialized with utf8 encoding and the C locale.
Here is the table:
\d words
Table "public.words"
Column | Type | Modifiers
+---
On Jun12, 2011, at 04:37 , Robert Haas wrote:
> On Thu, Jun 9, 2011 at 6:26 PM, Florian Pflug wrote:
>> On Jun8, 2011, at 17:46 , Jeff Davis wrote:
>>> It looks like the type input function may be a problem, because it
>>> doesn't look like it knows what the collation is yet. In other words,
>>> P
Hi
I've recently wanted to define a check constraint on an array
column that verifies that all array entries match some regular
expression. Unfortunately, t
The most natural way of expressing such a check would be
CHECK ('' ~ ANY(field)),
but that doesn't work, because "~" expects the *value*
t
On lör, 2011-06-11 at 16:23 -0400, Bruce Momjian wrote:
> Uh, I am the first one I remember complaining about this so I don't
> see why we should break compatibility for such a low-level problem.
I complain about it every day to the wall. :)
--
Sent via pgsql-hackers mailing list (pgsql-hacker
42 matches
Mail list logo
