2011/7/22 Jim Nasby :
> On Jul 19, 2011, at 10:51 PM, Pavel Stehule wrote:
>>> If you mean that such checks would be done automatically, no, they
>>> shouldn't be. Consider a function that creates a table and then uses
>>> it, or even just depends on using a table that doesn't yet exist when
>>> y
On Thu, Jul 21, 2011 at 9:19 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jul 21, 2011 at 6:43 PM, Noah Misch wrote:
>>> On Wed, Jul 20, 2011 at 09:46:33PM -0400, Robert Haas wrote:
SIGetDataEntries() can pretty easily be made lock-free. The only real
changes that seem to be a
We've had several complaints about that tab-completion bug in the
Apple-supplied version of libedit, most recently here:
http://archives.postgresql.org/pgsql-bugs/2011-06/msg00119.php
I had a bug filed with Apple about that, and today I got some auto-mail
indicating they'd fixed that bug as of OS
Robert Haas writes:
> On Thu, Jul 21, 2011 at 6:43 PM, Noah Misch wrote:
>> On Wed, Jul 20, 2011 at 09:46:33PM -0400, Robert Haas wrote:
>>> SIGetDataEntries() can pretty easily be made lock-free. The only real
>>> changes that seem to be are needed are (1) to use a 64-bit counter, so
>>> you ne
On Sun, Jul 17, 2011 at 10:54 AM, Josh Kupershmidt wrote:
> On Sat, Jul 16, 2011 at 12:49 PM, Tom Lane wrote:
>> After a bit of review of the archives, the somebody was me:
>> http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=b7d67954456f15762c04e5269b64adc88dcd0860
>>
>> and this
On Thu, Jul 21, 2011 at 6:43 PM, Noah Misch wrote:
> On Wed, Jul 20, 2011 at 09:46:33PM -0400, Robert Haas wrote:
>> Profiling this combination of patches reveals that there is still some
>> pretty ugly spinlock contention on sinval's msgNumLock. And it occurs
>> to me that on x86, we really don'
On Thu, Jul 21, 2011 at 6:44 PM, Dan Ports wrote:
> If you're suggesting that hardware memory barriers aren't going to be
> needed to implement lock-free code on x86, that isn't true. Because a
> read can be reordered with respect to a write to a different memory
> location, you can still have pro
On Thu, Jul 21, 2011 at 6:22 PM, Florian Pflug wrote:
> On Jul21, 2011, at 21:15 , Robert Haas wrote:
>> On Thu, Jul 21, 2011 at 2:50 PM, Tom Lane wrote:
>>> Robert Haas writes:
... On these machines, you need to issue an explicit memory barrier
instruction at each sequence point, or j
On Jul18, 2011, at 04:36 , Robert Haas wrote:
> On Fri, Jul 8, 2011 at 6:02 AM, Florian Pflug wrote:
>>> I don't want to fiddle with your git repo, but if you attach a patch
>>> that applies to the master branch I'll give it a spin if I have time.
>>
>> Patch attached.
>>
>> Beware that it needs
On Jul 21, 2011, at 5:30 PM, Christopher Browne wrote:
> - I'd commend capturing NOW() in a timestamptz field. That gives you:
> 1. What time the DB server thought it was, in terms of UT1
> 2. What timezone it thought was tied to that connection.
Except that it doesn't, and that's exactly the p
On Jul21, 2011, at 03:46 , Robert Haas wrote:
> Profiling this combination of patches reveals that there is still some
> pretty ugly spinlock contention on sinval's msgNumLock. And it occurs
> to me that on x86, we really don't need this lock ... or
> SInvalReadLock ... or a per-backend mutex. Th
On Wed, Jul 20, 2011 at 09:46:33PM -0400, Robert Haas wrote:
> Profiling this combination of patches reveals that there is still some
> pretty ugly spinlock contention on sinval's msgNumLock. And it occurs
> to me that on x86, we really don't need this lock ... or
> SInvalReadLock ... or a per-bac
On Thu, Jul 21, 2011 at 02:31:15PM -0400, Robert Haas wrote:
> 1. Machines with strong memory ordering. On this category of machines
> (which include x86), the CPU basically does not perform loads or
> stores out of order. On some of these machines, it is apparently
> possible for there to be som
On Thu, Jul 21, 2011 at 5:48 PM, Jim Nasby wrote:
> On Jul 19, 2011, at 4:06 PM, Josh Berkus wrote:
>>> I have my doubts about that, and I hope not. These details haven't been
>>> discussed at all; I only started this thread to get community approval
>>> on cataloguing the TZs.
>>
>> I am strongl
On Jul21, 2011, at 21:15 , Robert Haas wrote:
> On Thu, Jul 21, 2011 at 2:50 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> ... On these machines, you need to issue an explicit memory barrier
>>> instruction at each sequence point, or just acquire and release a
>>> spinlock.
>>
>> Right, and the
On Thu, Jul 21, 2011 at 4:54 PM, Noah Misch wrote:
> On Wed, Jul 20, 2011 at 09:46:33PM -0400, Robert Haas wrote:
>> For the last week or so, in between various other tasks, I've been
>> trying to understand why performance drops off when you run pgbench -n
>> -S -c $CLIENTS -j $CLIENTS -T $A_FEW_
On Jul 19, 2011, at 10:51 PM, Pavel Stehule wrote:
>> If you mean that such checks would be done automatically, no, they
>> shouldn't be. Consider a function that creates a table and then uses
>> it, or even just depends on using a table that doesn't yet exist when
>> you do CREATE FUNCTION.
>
>
Jim Nasby writes:
> On Jul 19, 2011, at 11:22 AM, Ian Caulfield wrote:
>> There was an earlier point made that if someone puts eg 5pm local time
>> two years in the future into the database, and then the DST boundary
>> gets moved subsequently, some applications would like the value to
>> still sa
On Jul 19, 2011, at 4:06 PM, Josh Berkus wrote:
>> I have my doubts about that, and I hope not. These details haven't been
>> discussed at all; I only started this thread to get community approval
>> on cataloguing the TZs.
>
> I am strongly in favor of having a *timezone* data type and some syst
On Jul 21, 2011, at 2:39 PM, Jim Nasby wrote:
>> CREATE OR REPLACE FUNCTION is_timezone(
>> tz CITEXT
>> ) RETURNS BOOLEAN LANGUAGE plpgsql STABLE AS $$
> ...
>> CREATE DOMAIN timezone AS CITEXT CHECK ( is_timezone( VALUE ) );
>
> Storing giant globs of text with every timestamp field is really
On Jul 19, 2011, at 11:22 AM, Ian Caulfield wrote:
> On 19 July 2011 17:11, Kevin Grittner wrote:
>> Tom Lane wrote:
>>> "Kevin Grittner" writes:
Josh Berkus wrote:
> The timestamp and the timezone in which that timestamp was
> entered are two separate pieces of data and *ought* to
On Jul 19, 2011, at 4:20 PM, David E. Wheeler wrote:
> On Jul 19, 2011, at 2:06 PM, Josh Berkus wrote:
>
>> I am strongly in favor of having a *timezone* data type and some system
>> whereby we can uniquely identify timezones in the Zic database.
>
> CREATE OR REPLACE FUNCTION is_timezone(
>t
I started thinking more about this --- we already allow multiple
processes to write to a single file when running Postgres as a backend
on Windows. I think it is these open() flags that make it possible:
(FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE),
However, we are n
On Wed, Jul 20, 2011 at 09:46:33PM -0400, Robert Haas wrote:
> For the last week or so, in between various other tasks, I've been
> trying to understand why performance drops off when you run pgbench -n
> -S -c $CLIENTS -j $CLIENTS -T $A_FEW_MINUTES at very high client
> counts. The answer, in a w
On Thu, Jul 21, 2011 at 4:01 PM, Robert Haas wrote:
>
>
> I think we are better off doing only equality comparisons and dodging
> this problem altogether.
>
>
Fair enough.
>
> Just-plain-dead line pointers would have lp_off = 0. Dead-vacuumed
> line pointers would have lp_off != 0. The first
On Thu, Jul 21, 2011 at 3:53 PM, Tom Lane wrote:
> Robert Haas writes:
>> I think the real challenge is going to be testing. If anyone has a
>> machine with weak memory ordering they can give me access to, that
>> would be really helpful for flushing the bugs out of this stuff.
>
> There are mul
On Thu, Jul 21, 2011 at 12:51 PM, Pavan Deolasee
wrote:
> The way we force the subsequent vacuum to also look at the pages scanned and
> pruned by previous failed vacuum, all the pages that have dead-vacuum line
> pointers would have a new stamp once the vacuum finishes successfully and
> the pg_c
2011/7/21 Robert Haas :
> On Thu, Jul 21, 2011 at 3:25 PM, Yeb Havinga wrote:
>> Is it possible to only include the syscache on --enable-selinux
>> configurations? It would imply physical data incompatibility with standard
>> configurations, but that's also true for e.g. the block size.
>
> Not re
Robert Haas writes:
> I think the real challenge is going to be testing. If anyone has a
> machine with weak memory ordering they can give me access to, that
> would be really helpful for flushing the bugs out of this stuff.
There are multi-CPU PPCen in the buildfarm, or at least there were last
2011/7/21 Yeb Havinga :
>
>> Is it possible to only include the syscache on --enable-selinux
>> configurations? It would imply physical data incompatibility with standard
>> configurations, but that's also true for e.g. the block size.
>>
>> Also, the tests I did with varying bucket sizes suggested
Is it possible to only include the syscache on --enable-selinux
configurations? It would imply physical data incompatibility with
standard configurations, but that's also true for e.g. the block size.
Also, the tests I did with varying bucket sizes suggested that
decreasing the syscache to 2
On Thu, Jul 21, 2011 at 3:25 PM, Yeb Havinga wrote:
> Is it possible to only include the syscache on --enable-selinux
> configurations? It would imply physical data incompatibility with standard
> configurations, but that's also true for e.g. the block size.
Not really. SECURITY LABEL is suppose
On Thu, Jul 21, 2011 at 8:25 PM, Robert Haas wrote:
> On Thu, Jul 21, 2011 at 3:22 PM, Dave Page wrote:
>> On Thu, Jul 21, 2011 at 8:15 PM, Robert Haas wrote:
>>> I think the real challenge is going to be testing. If anyone has a
>>> machine with weak memory ordering they can give me access to,
On Thu, Jul 21, 2011 at 3:22 PM, Dave Page wrote:
> On Thu, Jul 21, 2011 at 8:15 PM, Robert Haas wrote:
>> I think the real challenge is going to be testing. If anyone has a
>> machine with weak memory ordering they can give me access to, that
>> would be really helpful for flushing the bugs out
On 2011-07-21 15:03, Robert Haas wrote:
On Thu, Jul 21, 2011 at 4:00 AM, Yeb Havinga wrote:
Besides that I have to admit having problems understanding why the 5MB cache
for pg_seclabel is a problem; it's memory consumption is lineair only to the
size of the underlying database. (in contrast wi
On Thu, Jul 21, 2011 at 8:15 PM, Robert Haas wrote:
>
> I think the real challenge is going to be testing. If anyone has a
> machine with weak memory ordering they can give me access to, that
> would be really helpful for flushing the bugs out of this stuff.
> Getting it to work on x86 is not the
On Thu, Jul 21, 2011 at 2:50 PM, Tom Lane wrote:
> Robert Haas writes:
>> ... On these machines, you need to issue an explicit memory barrier
>> instruction at each sequence point, or just acquire and release a
>> spinlock.
>
> Right, and the reason that a spinlock fixes it is that we have memory
"Albe Laurenz" writes:
> I wrote a FDW for Oracle to a) learn some server coding
> and b) see how well the FDW API works for me.
> I came up with three questions/experiences:
> 1) GetUserMapping throws an error if there is no
>user mapping for the user (or PUBLIC).
>I think that it would
Robert Haas writes:
> ... On these machines, you need to issue an explicit memory barrier
> instruction at each sequence point, or just acquire and release a
> spinlock.
Right, and the reason that a spinlock fixes it is that we have memory
barrier instructions built into the spinlock code sequenc
On Thu, Jul 21, 2011 at 12:16 PM, Kevin Grittner
wrote:
> Very impressive! Those numbers definitely justify some #ifdef code
> to provide alternatives for weak memory ordering machines versus
> others. With the number of CPUs climbing as it is, this is very
> important work!
Thanks. I'm not th
On 07/21/2011 11:13 AM, Tom Lane wrote:
"Joshua D. Drake" writes:
So I am looking intently on what it is going to take to get the URI
patch done for psql [1] and was digging around the web and have a URI
parser library. It is under the New BSD license and is strictly RFC RFC
3986 [2] compliant
On 07/21/2011 11:13 AM, Tom Lane wrote:
"Joshua D. Drake" writes:
So I am looking intently on what it is going to take to get the URI
patch done for psql [1] and was digging around the web and have a URI
parser library. It is under the New BSD license and is strictly RFC RFC
3986 [2] compliant
"Joshua D. Drake" writes:
> So I am looking intently on what it is going to take to get the URI
> patch done for psql [1] and was digging around the web and have a URI
> parser library. It is under the New BSD license and is strictly RFC RFC
> 3986 [2] compliant .
Surely we do not need a whol
On 21 July 2011 18:43, Joshua D. Drake wrote:
> So I am looking intently on what it is going to take to get the URI patch
> done for psql [1] and was digging around the web and have a URI parser
> library. It is under the New BSD license and is strictly RFC RFC 3986 [2]
> compliant .
>
> Now I ha
Excerpts from Simon Riggs's message of jue jul 21 13:30:25 -0400 2011:
> I think I'll just revert it though. Subtransactions need a lot of
> tuning but this isn't high enough up my list to be worth the work.
If it works and is sane, why would you revert it?
--
Álvaro Herrera
The PostgreSQL Com
On Thu, Jul 21, 2011 at 12:19 PM, Tom Lane wrote:
> Robert Haas writes:
>> So I finally got around to taking a look at this patch, and I guess my
>> basic feeling is that I like it. The existing code is pretty weird
>> and inconsistent: the logic in PQsetvalue() basically does the same
>> thing
Hey,
So I am looking intently on what it is going to take to get the URI
patch done for psql [1] and was digging around the web and have a URI
parser library. It is under the New BSD license and is strictly RFC RFC
3986 [2] compliant .
Now I have not dug into the code but the parser is used
On Thu, Jul 21, 2011 at 5:56 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> Instead of leaving the locks dangling to an already-destroyed resource
>> owner, how about assigning all locks directly to the top-level resource
>> owner in one sweep? That'd still be much better than the old way of
Heikki Linnakangas writes:
> Instead of leaving the locks dangling to an already-destroyed resource
> owner, how about assigning all locks directly to the top-level resource
> owner in one sweep? That'd still be much better than the old way of
> recursively reassigning them up the subtransactio
On Thu, Jul 21, 2011 at 12:17 PM, Robert Haas wrote:
> On Thu, Jul 14, 2011 at 12:43 PM, Heikki Linnakangas
> > I think you can sidestep that
> > if you check that the page's vacuum LSN <= vacuum LSN in pg_class,
> instead
> > of equality.
>
> I don't think that works, because the point of storin
On Thu, Jul 21, 2011 at 11:51 AM, Robert Haas wrote:
> On Tue, Jul 12, 2011 at 4:47 PM, Pavan Deolasee
> wrote:
> > Comments ?
>
> I was going to spend some time reviewing this, but I see that (1) it
> has bit-rotted slightly - there is a failing hunk in pg_class.h and
> (2) some of the comments
Robert Haas writes:
> So I finally got around to taking a look at this patch, and I guess my
> basic feeling is that I like it. The existing code is pretty weird
> and inconsistent: the logic in PQsetvalue() basically does the same
> thing as the logic in pqAddTuple(), but incompatibly and less
>
On Thu, Jul 14, 2011 at 12:43 PM, Heikki Linnakangas
wrote:
> How does this interact with the visibility map? If you set the visibility
> map bit after vacuuming indexes, a subsequent vacuum will not visit the
> page. The second vacuum will update relindxvacxlogid/off, but it will not
> clean up t
Robert Haas wrote:
> SIGetDataEntries(). I believe we need to bite the bullet and
> rewrite this using a lock-free algorithm, using memory barriers on
> processors with weak memory ordering.
> [32 processors; 80 clients]
> On unpatched master
> tps = 132518.586371 (including connections es
On Wed, Jul 20, 2011 at 10:28 PM, Robert Haas wrote:
> On Mon, Jul 18, 2011 at 6:38 AM, Pavel Golub wrote:
>> Hello, Merlin.
>>
>> I hope it's OK that I've added Andrew's patch to CommitFest:
>> https://commitfest.postgresql.org/action/patch_view?id=606
>>
>> I did this becuase beta3 already rele
Robert Haas wrote:
> http://wiki.postgresql.org/wiki/PostgreSQL_9.1_Open_Items is
> looking pretty barren at the moment. Are there things that should
> be listed there?
I don't know of any. The non-blocking item about paring down Dan's
latest isolation test case to a size which can be commit
On Tue, Jul 12, 2011 at 4:47 PM, Pavan Deolasee
wrote:
> Comments ?
I was going to spend some time reviewing this, but I see that (1) it
has bit-rotted slightly - there is a failing hunk in pg_class.h and
(2) some of the comments downthread seem to suggest that you're
thinking about whether to re
On Thu, 2011-07-21 at 15:31 +0200, Jan Urbański wrote:
> On 21/07/11 15:27, Sushant Sinha wrote:
> > I am using plpythonu on postgres 9.0.2. One of my python functions was
> > throwing a TypeError exception. However, I only see the exception in the
> > database and not the stack trace. It becomes
On 21/07/11 15:27, Sushant Sinha wrote:
> I am using plpythonu on postgres 9.0.2. One of my python functions was
> throwing a TypeError exception. However, I only see the exception in the
> database and not the stack trace. It becomes difficult to debug if the
> stack trace is absent in Python.
>
On 21 July 2011 14:27, Sushant Sinha wrote:
> I am using plpythonu on postgres 9.0.2. One of my python functions was
> throwing a TypeError exception. However, I only see the exception in the
> database and not the stack trace. It becomes difficult to debug if the
> stack trace is absent in Python
I am using plpythonu on postgres 9.0.2. One of my python functions was
throwing a TypeError exception. However, I only see the exception in the
database and not the stack trace. It becomes difficult to debug if the
stack trace is absent in Python.
logdb=# select get_words(forminput) from fi;
On Thu, Jul 21, 2011 at 4:00 AM, Yeb Havinga wrote:
> Is there a way to dump syscache statistics like there is for
> MemoryContext..Stats (something - gdb helped me there)?
I don't know of one.
> Besides that I have to admit having problems understanding why the 5MB cache
> for pg_seclabel is a
All,
9.1beta3 was tagged on July 7th and announced July 12th. In the
interest of avoiding institutional inertia, should we try to set a
tentative date for a next beta or, if we don't end up fixing too many
bugs in the meanwhile, perhaps a release candidate?
Obviously we want to give people some
On Thu, Jul 21, 2011 at 6:16 AM, Kohei Kaigai wrote:
> How about an idea that allows to launch environment checker (typically shell
> scripts) prior
> to regression tests?
>
> The following stuffs should be preconfigured to run sepgsql's regression test.
> - SELinux must be run and configured to
On Thu, 2011-07-21 at 00:21 +0200, Florian Pflug wrote:
> There's a small additional concern, though, which is that there's an
> XPath 2.0 spec out there, and it modifies the type system and data model
> rather heavily. So before we go adding functions, it'd probably be wise
> to check that we're n
How about an idea that allows to launch environment checker (typically shell
scripts) prior
to regression tests?
The following stuffs should be preconfigured to run sepgsql's regression test.
- SELinux must be run and configured to enforcing mode.
- The sepgsql-regtest policy module must be loade
On 2011-07-21 00:08, Robert Haas wrote:
On Wed, Jul 20, 2011 at 4:48 PM, Tom Lane wrote:
Kohei Kaigai writes:
I'd like to have a discussion about syscache towards next commit-fest.
The issues may be:
- Initial bucket allocation on most cases never be referenced.
- Reclaim cache entries on
Heikki Linnakangas wrote:
>> 2) If I decide to close remote database connections after
>> use, I would like to do so where reasonable.
>> I would like to keep the connection open between query
>> planning and query execution and close it when the
>> scan is done.
>> The exceptio
68 matches
Mail list logo
