I am installing postgresql using homebrew on OSX. I am getting strange
compilation errors. Googling did not help me in getting any lead to the
resolution. When I compile it on a standalone basis (without using brew) I
still get the same error. Compiling 9.1beta1 source package also gave me the
same
On Jun 8, 2011, at 9:13 AM, Robert Creager wrote:I've renamed /opt/local so it's not picked up, and change HEAD to build every 6 hours. Won't prove it doesn't happen though... If it appears to work for a bit, I can move /opt/local back and see what happens.Gack. ccache is in /opt/local/bin... I
On Jun 7, 2011, at 11:32 PM, Tom Lane wrote:
>
> But I tried "make installcheck" in plperl quite a few times with no
> problems. (And yes, I tried some assorted settings of PERL_HASH_SEED,
> as well as none at all.)
>
> At this point I'm thinking that the perl you've got in /opt/local must
> b
The attached patch adds contrib/sepgsql a cache mechanism for access
control decision of SELinux. It shall reduce the total number of
system call invocations to improve the performance on its access
controls.
In the current implementation, the sepgsql always raises a query to
SELinux in-kernel. Ho
On Wed, Jun 8, 2011 at 20:22, Tom Lane wrote:
> Is this really necessary now that we know about "GROUP BY primary key"?
You're right. I was just looking for something easy to hack on and
didn't put much thought into usefulness.
I'll try to do better next time. :)
Regards,
Marti
--
Sent via pgs
While testing this, I noticed another serious bug in the OldSerXidSLRU
handling: we never set the dirty-flag on any page. I believe the reason
we haven't bumped into this in testing before is that when a new page is
initialized, it's marked as dirty, so everything goes smoothly when we
modify r
On Wed, Jun 8, 2011 at 6:43 PM, Joshua Berkus wrote:
> Simon,
>
>> The point I have made is that I disagree with a feature freeze date
>> fixed ahead of time without regard to the content of the forthcoming
>> release. I've not said I disagree with feature freezes altogether,
>> which would be utt
On Thu, Jun 9, 2011 at 11:50 AM, Pavan Deolasee wrote:
>
>
>
> Ah, I see. Would there will be benefits if we can do some special handling
> for cases where we know that ANALYZE is running outside a transaction block
> and that its not going to invoke any user-defined functions ? If user is
> runni
Hi hackers,
At first I've posted to pgsql-docs but there is no reply at present.
http://archives.postgresql.org/pgsql-docs/2011-06/msg6.php
So I post revised patch to pgsql-hackers, because the patch is for
documents under development for 9.1 beta2. Please let me know if this
was wrong l
Hello list,
A little while ago time ago I posted about how my ... exciting
backup procedure caused occasional problems starting due to clog not
being big enough.
(http://archives.postgresql.org/pgsql-hackers/2011-04/msg01148.php) I
recently had a reproduction and a little bit of luck, and I t
Oops, subject was incorrect. It should be [v9.2], not [v9.1]
2011/6/9 Kohei KaiGai :
> The attached patch adds contrib/sepgsql a cache mechanism for access
> control decision of SELinux. It shall reduce the total number of
> system call invocations to improve the performance on its access
> contro
While reviewing the SLRU code in predicate.c again, I remembered this
old thread:
http://archives.postgresql.org/pgsql-hackers/2010-12/msg02374.php
SLRU has a limit of 64k segment files, because the files are named using
four hex digits like "00CE". Kevin's math shows that that's just enough
On Thu, Jun 9, 2011 at 12:39 AM, Jeevan Chalke
wrote:
>> It's a problem, but without an efficient algorithm for Unicode case
>> folding, any fix we attempt to implement seems like it'll just be
>> moving the problem around.
>
> Agree.
>
> I read on other mail thread that str_tolower() is a wide-c
Dan Ports wrote:
> On Wed, Jun 08, 2011 at 09:17:04PM -0500, Kevin Grittner wrote:
>> A patch is attached which just covers the predicate lock
>> acquisition, where a snapshot is available without too much pain.
>> There are two functions which acquire predicate locks where a
>> snapshot was not
Heikki Linnakangas wrote:
> While testing this, I noticed another serious bug in the
> OldSerXidSLRU handling: we never set the dirty-flag on any page.
Arg. I never noticed that there was such a thing, although in
retrospect I should have suspected it and gone hunting for it.
> I believe th
On Wed, Jun 8, 2011 at 12:34, Radosław Smogura wrote:
> After compilation I got big list of differences about binaries and other
> files. You may see it in patch.
Hmm. Does this really affect just cygwin, and not also mingw? I know
msvc builds out-of-tree, but mingw doesn't, iirc? WHere do the EX
On Thu, Jun 9, 2011 at 7:46 AM, Heikki Linnakangas
wrote:
> While reviewing the SLRU code in predicate.c again, I remembered this old
> thread:
>
> http://archives.postgresql.org/pgsql-hackers/2010-12/msg02374.php
>
> SLRU has a limit of 64k segment files, because the files are named using
> four
On Thu, Jun 9, 2011 at 5:09 AM, Simon Riggs wrote:
> I have asked that we maintain the Reasonableness we have always had
> about how the feature freeze date was applied. An example of such
> reasonableness is that if a feature is a few days late and it is
> important, then it would still go into t
On Thu, Jun 9, 2011 at 2:13 PM, Robert Haas wrote:
> On Thu, Jun 9, 2011 at 5:09 AM, Simon Riggs wrote:
>> I have asked that we maintain the Reasonableness we have always had
>> about how the feature freeze date was applied. An example of such
>> reasonableness is that if a feature is a few days
>
> Can we make this the last post on this topic please?
>
+1 :)
Thanks,
Pavan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, 9 Jun 2011 14:12:59 +0200, Magnus Hagander wrote:
On Wed, Jun 8, 2011 at 12:34, Radosław Smogura
wrote:
After compilation I got big list of differences about binaries and
other
files. You may see it in patch.
Hmm. Does this really affect just cygwin, and not also mingw? I know
msvc b
On 06/09/2011 08:12 AM, Magnus Hagander wrote:
On Wed, Jun 8, 2011 at 12:34, Radosław Smogura wrote:
After compilation I got big list of differences about binaries and other
files. You may see it in patch.
Hmm. Does this really affect just cygwin, and not also mingw?
Yes, indeed.
I know
On Thu, 9 Jun 2011 14:12:59 +0200, Magnus Hagander wrote:
On Wed, Jun 8, 2011 at 12:34, Radosław Smogura
wrote:
After compilation I got big list of differences about binaries and
other
files. You may see it in patch.
Hmm. Does this really affect just cygwin, and not also mingw? I know
msvc b
=?UTF-8?Q?Rados=C5=82aw_Smogura?= writes:
> On Thu, 9 Jun 2011 14:12:59 +0200, Magnus Hagander wrote:
>> What's "nbproject"?
> Just configuration from some editor. It looks like any move in project
> creates this entry in .gitignore
If you've got random third-party tools that clutter the sou
On Thu, Jun 9, 2011 at 2:59 AM, Bhavin Kamani wrote:
> I am installing postgresql using homebrew on OSX. I am getting strange
> compilation errors. Googling did not help me in getting any lead to the
> resolution. When I compile it on a standalone basis (without using brew) I
> still get the same
Heikki Linnakangas writes:
> It's awfully late in the release cycle, but how about we add another
> digit to the filenames used by SLRU, to up the limit?
It's way too late for that kind of thing, unless you are saying that SSI
in and of itself is going to cause a release slip. (Which I'm gettin
Robert Haas writes:
> But now that I re-think about it, I guess what I'm confused about is
> this code here:
> if (ch >= 'A' && ch <= 'Z')
> ch += 'a' - 'A';
> else if (IS_HIGHBIT_SET(ch) && isupper(ch))
> ch = tolowe
On Thu, Jun 9, 2011 at 10:07 AM, Tom Lane wrote:
> Robert Haas writes:
>> But now that I re-think about it, I guess what I'm confused about is
>> this code here:
>
>> if (ch >= 'A' && ch <= 'Z')
>> ch += 'a' - 'A';
>> else if (IS_HIGHBIT_SET
Robert Haas writes:
> On Thu, Jun 9, 2011 at 10:07 AM, Tom Lane wrote:
>> We are relying on isupper() to not return true
>> when presented with a character fragment in a multibyte locale.
> Based on Jeevan's original message, it seems like that's not always
> the case, at least on Windows.
Hmm.
On Thu, Jun 9, 2011 at 10:03 AM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> It's awfully late in the release cycle, but how about we add another
>> digit to the filenames used by SLRU, to up the limit?
>
> It's way too late for that kind of thing, unless you are saying that SSI
> in and of i
Excerpts from Robert Haas's message of mié jun 08 23:24:34 -0400 2011:
> I did a brief literature search for papers on breaking the
> WAL-serialization bottleneck today and hit upon this:
>
> Aether: A Scalable Approach to Logging, Ryan Johnson, Ippokratis Pandis, et
> al.
> http://infoscience.ep
On Thu, Jun 9, 2011 at 15:40, Andrew Dunstan wrote:
>
>
> On 06/09/2011 08:12 AM, Magnus Hagander wrote:
>>
>> On Wed, Jun 8, 2011 at 12:34, Radosław Smogura
>> wrote:
>>>
>>> After compilation I got big list of differences about binaries and other
>>> files. You may see it in patch.
>>
>> Hmm. D
On Thu, Jun 9, 2011 at 10:15 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jun 9, 2011 at 10:07 AM, Tom Lane wrote:
>>> We are relying on isupper() to not return true
>>> when presented with a character fragment in a multibyte locale.
>
>> Based on Jeevan's original message, it seems like
On Thu, Jun 9, 2011 at 15:40, Radosław Smogura wrote:
> On Thu, 9 Jun 2011 14:12:59 +0200, Magnus Hagander wrote:
>>
>> On Wed, Jun 8, 2011 at 12:34, Radosław Smogura
>> wrote:
>>>
>>> After compilation I got big list of differences about binaries and other
>>> files. You may see it in patch.
>>
Robert Haas writes:
> So, speaking of that, aren't we supposed to wrap beta2 any minute now?
Yes. I'm expecting to do it this evening.
> There are two open items listed on the open items page as blockers for beta2:
> - error in information_schema.element_types view definition (bug 5926)
> - mo
On Thu, Jun 9, 2011 at 16:27, Tom Lane wrote:
> Robert Haas writes:
>> So, speaking of that, aren't we supposed to wrap beta2 any minute now?
>
> Yes. I'm expecting to do it this evening.
>
>> There are two open items listed on the open items page as blockers for beta2:
>
>> - error in informati
On Thu, Jun 9, 2011 at 10:22 AM, Alvaro Herrera
wrote:
>> 1. Subdivide XLOG insertion into three operations: (1) allocate space
>> in the log buffer, (2) copy the log records into the allocated space,
>> and (3) release the space to the buffer manager for eventual write to
>> disk. AIUI, WALInser
On Thu, Jun 9, 2011 at 2:28 AM, Hitoshi Harada wrote:
> BTW, as I changed title and design from the previous post, should I
> throw away the old commit fest entry and make the new one?
Nah, just edit the existing entry and change the title.
Also add a link to the new patch, of course.
--
Rober
Excerpts from Robert Haas's message of jue jun 09 10:28:39 -0400 2011:
> On Thu, Jun 9, 2011 at 10:22 AM, Alvaro Herrera
> wrote:
> >> 1. Subdivide XLOG insertion into three operations: (1) allocate space
> >> in the log buffer, (2) copy the log records into the allocated space,
> >> and (3) relea
On Thu, Jun 9, 2011 at 2:20 AM, Pavan Deolasee wrote:
> Ah, I see. Would there will be benefits if we can do some special handling
> for cases where we know that ANALYZE is running outside a transaction block
> and that its not going to invoke any user-defined functions ?
We'd have to distinguish
Robert Haas wrote:
> Tom Lane wrote:
> aren't we supposed to wrap beta2 any minute now?
>
> There are two open items listed on the open items page as blockers
> for beta2:
>
> - error in information_schema.element_types view definition (bug
> 5926)
> - more SSI loose ends
>
> We really oug
Robert Haas writes:
> On Thu, Jun 9, 2011 at 10:15 AM, Tom Lane wrote:
>> If we need to work around brain-dead isupper() tests, maybe the best
>> thing is to implement two versions of the loop:
>>
>>if (encoding is single byte)
>>... loop as it stands ...
>>else
>
I believe I have found a bug in libpq COPY handling with non-blocking
SSL connections. The bug manifests itself by dropping the connection
in PGputCopyData() with "server closed the connection unexpectedly"
message. The connection drop only occurs with nonblocking connections -
blocking connections
On 06/09/2011 10:25 AM, Magnus Hagander wrote:
Based on this list, a global exclude for "*.exe" and "lib*dll.def"
seems reasonable. Andrew, does that seem right to you as well?
That plus an entry in src/backend/.gitignore for "/postgres.def".
cheers
andrew
--
Sent via pgsql-hackers mail
Excerpts from Heikki Linnakangas's message of jue jun 09 04:56:41 -0400 2011:
> Fortunately the fix is very simple, we just need to set the page_dirty
> flag whenever we modify an slru page. But clearly this slru stuff needs
> more testing. It's pretty hard to write good repeatable test cases fo
"Kevin Grittner" writes:
> The other pending patch relates to the false positives serialization
> failures and funny-looking pg_lock entries from not ignoring
> non-MVCC snapshots in SSI. I don't think Dan had any problem with
> the patch I offered, but I wasn't sure what to do about two
> functi
>
> I am wondering if we shouldn't be asking ourselves a different
> question: why is ANALYZE running long enough on your tables for this
> to become an issue? How long is it taking?
>
The log file attached in the first post has the details; it's taking around 5
mins for the accounts table w
On Thu, Jun 9, 2011 at 10:34 AM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of jue jun 09 10:28:39 -0400 2011:
>> On Thu, Jun 9, 2011 at 10:22 AM, Alvaro Herrera
>> wrote:
>> >> 1. Subdivide XLOG insertion into three operations: (1) allocate space
>> >> in the log buffer, (2) cop
On Thu, Jun 9, 2011 at 10:52 AM, Pavan Deolasee
wrote:
>> I am wondering if we shouldn't be asking ourselves a different
>> question: why is ANALYZE running long enough on your tables for this
>> to become an issue? How long is it taking?
>
> The log file attached in the first post has the detail
On Thu, Jun 9, 2011 at 10:38 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jun 9, 2011 at 10:15 AM, Tom Lane wrote:
>>> If we need to work around brain-dead isupper() tests, maybe the best
>>> thing is to implement two versions of the loop:
>>>
>>> if (encoding is single byte)
>>>
Robert Haas writes:
> On Thu, Jun 9, 2011 at 10:52 AM, Pavan Deolasee
> wrote:
>>> I am wondering if we shouldn't be asking ourselves a different
>>> question: why is ANALYZE running long enough on your tables for this
>>> to become an issue? How long is it taking?
>> The log file attached in t
On 09-Jun-2011, at 8:29 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jun 9, 2011 at 10:52 AM, Pavan Deolasee
>> wrote:
I am wondering if we shouldn't be asking ourselves a different
question: why is ANALYZE running long enough on your tables for this
to become an issue?
On Thu, Jun 9, 2011 at 10:37 AM, Kevin Grittner
wrote:
> There is this pending patch, without which there are infrequent
> conditions under which the users could get a LOG level message and
> accumulate files in pg_serial:
>
> http://archives.postgresql.org/message-id/4dee7be402250003e...@gw.w
Alvaro Herrera wrote:
> Excerpts from Heikki Linnakangas's message of jue jun 09 04:56:41
-0400 2011:
>
>> Fortunately the fix is very simple, we just need to set the
>> page_dirty flag whenever we modify an slru page. But clearly this
>> slru stuff needs more testing. It's pretty hard to write g
Excerpts from Robert Haas's message of jue jun 09 10:55:45 -0400 2011:
> On Thu, Jun 9, 2011 at 10:34 AM, Alvaro Herrera
> wrote:
> > Slower than sleeping? Consider that this doesn't need to be done for
> > each record insertion, only when you need to flush (maybe more than
> > that, but I think
Hello Greg, hello All,
This is my first post at Hackers, so sorry if I am been a noob here, but I
am pretty confused about
how to create the extension pg_buffercache.
First of all, I was trying to create using the old method by calling the
pg_buffercache--1.0.sql directly.
Then I discover the cha
On Thu, Jun 9, 2011 at 3:59 AM, Kohei KaiGai wrote:
> The only modification by this patch to the core routine is a new
> syscache for pg_seclabel system catalog. The SECLABELOID enables to
> reference security label of the object using syscache interface.
I believe we decided against that previou
On Thu, Jun 9, 2011 at 11:13 AM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of jue jun 09 10:55:45 -0400 2011:
>> On Thu, Jun 9, 2011 at 10:34 AM, Alvaro Herrera
>> wrote:
>
>> > Slower than sleeping? Consider that this doesn't need to be done for
>> > each record insertion, onl
Robert Haas writes:
> On Thu, Jun 9, 2011 at 10:15 AM, Tom Lane wrote:
>> If we need to work around brain-dead isupper() tests, maybe the best
>> thing is to implement two versions of the loop:
>>if (encoding is single byte)
> That seems like a clear improvement. It's a long way from pe
On Thu, Jun 9, 2011 at 11:17 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jun 9, 2011 at 10:15 AM, Tom Lane wrote:
>>> If we need to work around brain-dead isupper() tests, maybe the best
>>> thing is to implement two versions of the loop:
>>> if (encoding is single byte)
>
>> Tha
On 09.06.2011 17:46, Tom Lane wrote:
"Kevin Grittner" writes:
The other pending patch relates to the false positives serialization
failures and funny-looking pg_lock entries from not ignoring
non-MVCC snapshots in SSI. I don't think Dan had any problem with
the patch I offered, but I wasn't su
Robert Haas writes:
> One other problem I'm realizing: didn't Peter ask Bruce to revert the
> change to make pg_upgrade ignore case differences in locale names, on
> the grounds that it was not safe?
There was a hypothesis that it wasn't safe, but no very clear evidence
either way. And we did ha
Magnus Hagander Thursday 09 of June 2011 16:25:07
> On Thu, Jun 9, 2011 at 15:40, Radosław Smogura
wrote:
> > On Thu, 9 Jun 2011 14:12:59 +0200, Magnus Hagander wrote:
> >> On Wed, Jun 8, 2011 at 12:34, Radosław Smogura
> >>
> >> wrote:
> >>> After compilation I got big list of differences abo
On 09.06.2011 15:50, Robert Haas wrote:
On Thu, Jun 9, 2011 at 7:46 AM, Heikki Linnakangas
wrote:
While reviewing the SLRU code in predicate.c again, I remembered this old
thread:
http://archives.postgresql.org/pgsql-hackers/2010-12/msg02374.php
SLRU has a limit of 64k segment files, because
Vinicius Abrahao wrote:
This is my first post at Hackers, so sorry if I am been a noob here,
but I am pretty confused about
how to create the extension pg_buffercache.
This list is for talking about development of new features, normally on
the latest development version of the software (right
Robert Haas wrote:
Well, if there are more tables that need vacuuming than there are
workers available at any given time, there will be a delay. We
probably don't keep track of that delay at present, but we could.
There are at least four interesting numbers to collect each time
autovacuum
Please do not piggyback on an unrelated thread to ask a question.
Start a new thread.
Vinicius Abrahao writes:
> postgres=# CREATE EXTENSION pg_buffercache SCHEMA pg_catalog;
> ERROR: syntax error at or near "NO"
This looks like a syntax error in the pg_buffercache--1.0.sql file ...
have you ta
Can someone explain why pg_stat_activity has a column named procpid and
not simply pid? 'pid' is that pg_locks uses, and 'procpid' is redundant
(proc-process-id). A mistake?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It'
2011/6/9 Robert Haas :
> On Thu, Jun 9, 2011 at 2:28 AM, Hitoshi Harada wrote:
>> BTW, as I changed title and design from the previous post, should I
>> throw away the old commit fest entry and make the new one?
>
> Nah, just edit the existing entry and change the title.
>
> Also add a link to the
Robert Haas wrote:
> Kevin Grittner wrote:
>> There is this pending patch, without which there are infrequent
>> conditions under which the users could get a LOG level message
>> and accumulate files in pg_serial:
>>
http://archives.postgresql.org/message-id/4dee7be402250003e...@gw.wicour
On Jun2, 2011, at 01:34 , Florian Pflug wrote:
> On Jun2, 2011, at 00:02 , Noah Misch wrote:
>> On Wed, Jun 01, 2011 at 06:16:21PM +0200, Florian Pflug wrote:
>>> Anyway, I'll try to come up with a patch that replaces
>>> xmlSetGenericErrorFunc() with xmlSetStructuredErrorFunc().
>>
>> Sounds sen
On Thu, Jun 9, 2011 at 16:40, Andrew Dunstan wrote:
>
>
> On 06/09/2011 10:25 AM, Magnus Hagander wrote:
>>
>> Based on this list, a global exclude for "*.exe" and "lib*dll.def"
>> seems reasonable. Andrew, does that seem right to you as well?
>
>
> That plus an entry in src/backend/.gitignore for
Heikki Linnakangas writes:
> On 09.06.2011 15:50, Robert Haas wrote:
>> And I would guess that there's a lot more interest in raising BLCKSZ
>> than lowering it. It might not be a bad idea to adopt the fix you
>> propose anyway, but it doesn't seem urgent.
> I guess we could fix pg_subtrans by n
Excerpts from Tom Lane's message of mié jun 08 21:50:22 -0400 2011:
> Robert Haas writes:
> > I think it'd be really useful to expose some more data in this area
> > though. One random idea is - remember the time at which a table was
> > first observed to need vacuuming. Clear the timestamp when
Bruce Momjian writes:
> Can someone explain why pg_stat_activity has a column named procpid and
> not simply pid? 'pid' is that pg_locks uses, and 'procpid' is redundant
> (proc-process-id). A mistake?
Mistake or not, it's about half a dozen releases too late to change it.
* Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
> The only modification by this patch to the core routine is a new
> syscache for pg_seclabel system catalog. The SECLABELOID enables to
> reference security label of the object using syscache interface.
Perhaps I'm missing it, but.. why is this necessar
On Wed, Jun 8, 2011 at 11:30 PM, Merlin Moncure wrote:
> The heap pages that have been marked this way may or may not have to
> be off limits from the backend other than the one that did the
> marking, and if they have to be off limits logically, there may be no
> realistic path to make them so.
2011/6/9 Robert Haas :
> On Thu, Jun 9, 2011 at 3:59 AM, Kohei KaiGai wrote:
>> The only modification by this patch to the core routine is a new
>> syscache for pg_seclabel system catalog. The SECLABELOID enables to
>> reference security label of the object using syscache interface.
>
> I believe
On Thu, Jun 9, 2011 at 11:54 AM, Bruce Momjian wrote:
> Can someone explain why pg_stat_activity has a column named procpid and
> not simply pid? 'pid' is that pg_locks uses, and 'procpid' is redundant
> (proc-process-id). A mistake?
Well, we refer to the slots that backends use as "procs" (rea
Alvaro Herrera writes:
> In any case, given the "rebalancing" feature of vacuum_cost_delay (which
> increases the delay the more workers there are), the only "solution" to
> the problem of falling behind is reducing the delay parameter. If you
> just add more workers, they start working more slow
Robert Haas writes:
> [ lots of interesting stuff about WAL optimization snipped ]
> ... Second, they aren't really using locks, unless you count
> bus locks - they appear to have implemented most or all of it via
> CAS-based lock-free algorithms, which is probably well-justified
> optimization e
2011/6/9 Stephen Frost :
> * Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
>> The only modification by this patch to the core routine is a new
>> syscache for pg_seclabel system catalog. The SECLABELOID enables to
>> reference security label of the object using syscache interface.
>
> Perhaps I'm missi
Excerpts from Tom Lane's message of jue jun 09 09:42:02 -0400 2011:
> =?UTF-8?Q?Rados=C5=82aw_Smogura?= writes:
> > On Thu, 9 Jun 2011 14:12:59 +0200, Magnus Hagander wrote:
> >> What's "nbproject"?
>
> > Just configuration from some editor. It looks like any move in project
> > creates this
On Mon, May 23, 2011 at 16:49, MauMau wrote:
> From: "Kevin Grittner"
>>
>> "MauMau" wrote:
>>>
>>> Make pg_ctl's -s option suppress informational event logging.
>>
>> This will ultimately be up to a committer (and I'm not one), but to
>> me it seems reasonable to back-patch if it is addressed t
On Thu, Jun 9, 2011 at 12:25 PM, Alvaro Herrera
wrote:
> Excerpts from Tom Lane's message of mié jun 08 21:50:22 -0400 2011:
>> Robert Haas writes:
>> > I think it'd be really useful to expose some more data in this area
>> > though. One random idea is - remember the time at which a table was
>>
Alvaro Herrera writes:
> I agree with that, though the *dll.def files are ours and probably
> deserve a global .gitignore entry.
Agreed, and that's done.
> As for executables, I think the local .gitignore files in each subdir
> should be tweaked so that they catch the .exe extension, so
> src/ba
Robert Haas wrote:
> On Wed, Jun 1, 2011 at 7:07 PM, Tom Lane wrote:
> > Alvaro Herrera writes:
> >> Excerpts from Robert Haas's message of mi? jun 01 18:22:56 -0400 2011:
> >>> ISTM that it would be useful to run postgres in a mode where it
> >>> doesn't actually try to start up the database, bu
Andrew Dunstan wrote:
>
>
> On 06/08/2011 02:29 PM, Tom Lane wrote:
> > Should we consider doing $SUBJECT? Given the plan to branch off 9.1
> > after we make the beta release, I think it's now or never for a second
> > pgindent run for 9.1.
> >
> >
>
> OK, I have made sure
Bruce Momjian writes:
> Andrew Dunstan wrote:
>> On 06/08/2011 02:29 PM, Tom Lane wrote:
>>> Should we consider doing $SUBJECT? Given the plan to branch off 9.1
>>> after we make the beta release, I think it's now or never for a second
>>> pgindent run for 9.1.
>> OK, I have made sure the list o
On Thu, Jun 9, 2011 at 12:52 PM, Tom Lane wrote:
> Robert Haas writes:
>> [ lots of interesting stuff about WAL optimization snipped ]
>
>> ... Second, they aren't really using locks, unless you count
>> bus locks - they appear to have implemented most or all of it via
>> CAS-based lock-free algo
Tom Lane wrote:
> Bruce Momjian writes:
> > Andrew Dunstan wrote:
> >> On 06/08/2011 02:29 PM, Tom Lane wrote:
> >>> Should we consider doing $SUBJECT? Given the plan to branch off 9.1
> >>> after we make the beta release, I think it's now or never for a second
> >>> pgindent run for 9.1.
>
> >>
Excerpts from Tom Lane's message of jue jun 09 12:57:46 -0400 2011:
> Alvaro Herrera writes:
> > I agree with that, though the *dll.def files are ours and probably
> > deserve a global .gitignore entry.
>
> Agreed, and that's done.
Oh, I see ... I haven't gotten the commit message yet.
--
Álva
On Thu, Jun 9, 2011 at 12:39 PM, Kohei KaiGai wrote:
> 2011/6/9 Robert Haas :
>> On Thu, Jun 9, 2011 at 3:59 AM, Kohei KaiGai wrote:
>>> The only modification by this patch to the core routine is a new
>>> syscache for pg_seclabel system catalog. The SECLABELOID enables to
>>> reference security
On Thu, Jun 9, 2011 at 12:54 PM, Kohei KaiGai wrote:
> 2011/6/9 Stephen Frost :
>> * Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
>>> The only modification by this patch to the core routine is a new
>>> syscache for pg_seclabel system catalog. The SECLABELOID enables to
>>> reference security label o
Robert Haas wrote:
> On Thu, Jun 9, 2011 at 11:54 AM, Bruce Momjian wrote:
> > Can someone explain why pg_stat_activity has a column named procpid and
> > not simply pid? ?'pid' is that pg_locks uses, and 'procpid' is redundant
> > (proc-process-id). ?A mistake?
>
> Well, we refer to the slots th
Robert Haas writes:
> On Thu, Jun 9, 2011 at 11:17 AM, Tom Lane wrote:
>> Hmm ... while the above is easy enough to do in the backend, where we
>> can look at pg_database_encoding_max_length, we have also got instances
>> of this coding pattern in src/port/pgstrcasecmp.c. It's a lot less
>> obvi
Hi,
on shdepReassignOwned() we have this message, which is obviously wrong
we are not dropping objects just reassigning them...
"""
ereport(ERROR,
(errcode(ERRCODE_DEPENDENT_OBJECTS_STILL_EXIST),
errmsg("cannot drop objects owned
by %s bec
On Thu, Jun 09, 2011 at 07:06:18AM -0500, Kevin Grittner wrote:
> Sounds reasonable, but why did you pass the snapshot to the
> PredicateLockPage() call but not the PredicateLockRelation() call?
> Oversight?
Yep, just an oversight; long day yesterday. I'll fix the patch shortly
(unless you can ge
On 08.06.2011 22:40, Kevin Grittner wrote:
Heikki Linnakangas wrote:
On 08.06.2011 03:28, Kevin Grittner wrote:
We had a report of the subject message during testing a while
back and attempted to address the issue. It can result in a LOG
< level message and the accumulation of files in the
On 09.06.2011 19:24, Tom Lane wrote:
(BTW, while I've not looked at the SLRU code in several years, I'm quite
unconvinced that this is only a matter of filename lengths.)
I don't see anything but the filename length needing adjustment. In
fact, when I hacked predicate.c to ignore the issue and
1 - 100 of 156 matches
Mail list logo
