Jim Nasby writes:
> Dumb question: Is this something that could be solved by having the
> postmaster track this information in it's local memory and make it available
> via a variable-sized IPC mechanism, such as a port or socket? That would
> eliminate the need to clean things up after a crash
On Feb 28, 2011, at 11:59 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Feb 27, 2011 at 8:33 PM, Joachim Wieland wrote:
>>> Remember that it's not only about saving shared memory, it's also
>>> about making sure that the snapshot reflects a state of the database
>>> that has actually exist
On 03/01/2011 05:19 PM, Jan Urbański wrote:
On 01/03/11 22:07, Andrew Dunstan wrote:
On 03/01/2011 03:53 PM, Jan Urbański wrote:
On 01/03/11 21:35, Tom Lane wrote:
Josh Berkus writes:
I'm ok with closing things as of the end of the 15 days, say
Thursday or
Friday.
It might be a good ide
On Tue, Mar 1, 2011 at 3:11 PM, Heikki Linnakangas
wrote:
> Heck, you can just put an Assert(!ImmediateInterruptOK) there, although it
> will fire in the authentication phase because of the issue with
> ClientAuthentication. You can set debug_assertions=off in postgresql.conf
> and enable it again
>
> No, the question is why is the ImmediateInterruptOK flag set. Whether
> the interrupt actually happens isn't that relevant. You could try
> setting a watchpoint on the flag variable.
>
>> But adding hold/resume interrrupts in mcxt.c (not aset.c, since we
>> want to be agnostic to the underlyi
On Tue, 2011-03-01 at 12:42 -0800, Josh Berkus wrote:
> > That response is just dodging the hard question, so whatever. Tom's
> > cleanup is not going to break things, or at least it's going to fix
> > more than it breaks on net. Sync rep, on the other hand, is going to
> > do the opposite, proba
On Mar 1, 2011, at 17:15, Hiroshi Saito wrote:
> Ooops,
> It is some trobles now.
> please see Ralf-san's comment.
Thanks, Hiroshi!
Michael Glaesemann
grzm seespotcode net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://ww
On 01/03/11 22:07, Andrew Dunstan wrote:
>
>
> On 03/01/2011 03:53 PM, Jan Urbański wrote:
>> On 01/03/11 21:35, Tom Lane wrote:
>>> Josh Berkus writes:
I'm ok with closing things as of the end of the 15 days, say
Thursday or
Friday.
>>> It might be a good idea to make a list of w
On Tue, Mar 1, 2011 at 4:58 PM, Robert Haas wrote:
>
> So where is the new patch, and the test reports from all the people
> who found problems in the last version?
>
Simon do this in his public repo here:
git://github.com/simon2ndQuadrant/postgres.git
It has been just one day from this so i exp
Excerpts from Tom Lane's message of mar mar 01 19:03:35 -0300 2011:
> Alvaro Herrera writes:
> > Strangely, we made pg_database have a toast table, and the only reason
> > for this is datacl. Should we create toast tables for the remaining
> > catalogs?
>
> As I commented on your blog, this is n
Ooops,
It is some trobles now.
please see Ralf-san's comment.
>On 01.03.11 15:49, Hiroshi Saito wrote:
>> Hi Ralf-san. Thomas-san.
>>
>> Um... cannot be accessed here.
>> http://www.ossp.org/pkg/lib/uuid/
>>
>> Are some you in a trouble?
>
>The server went down. Thanks for the hint.
>Now fixed.
On Tuesday 1. of March 2011 22:44:16 Peter Eisentraut wrote:
> On tis, 2011-03-01 at 22:22 +0100, Rumko wrote:
> > Well, wouldn't consider it ugly, but the patch (attached and available at
> > http://www.rumko.net/0001-DragonFly-BSD-support-linked.patch ) is a lot
> > shorter.
> >
> > Uses freebsd'
Alvaro Herrera writes:
> Strangely, we made pg_database have a toast table, and the only reason
> for this is datacl. Should we create toast tables for the remaining
> catalogs?
As I commented on your blog, this is nonsense. pg_database has a TOAST
table becase we thought it might need one for
On Tue, Mar 01, 2011 at 12:00:54AM +0200, Heikki Linnakangas wrote:
> On 28.02.2011 23:28, daveg wrote:
> >On Wed, Jan 12, 2011 at 10:46:14AM +0200, Heikki Linnakangas wrote:
> >>We'll likely need to go back and forth a few times with various
> >>debugging patches until we get to the heart of this.
On Mon, Feb 28, 2011 at 07:43:39PM -0600, David Christensen wrote:
>
> On Feb 28, 2011, at 3:28 PM, daveg wrote:
>
> > Anything new on this? I'm seeing at on one of my clients production boxes.
> > Also, what is the significance, ie what is the risk or damage potential if
> > this flag is set inc
On Tue, Mar 1, 2011 at 4:55 PM, Jaime Casanova wrote:
> On Tue, Mar 1, 2011 at 3:40 PM, Robert Haas wrote:
>> Sync rep, on the other hand, is going to
>> do the opposite, probably by a large margin.
>>
>
> Are you sure of that? the code is very centralized and the bugs we
> found last week weren'
On Tue, Mar 1, 2011 at 3:40 PM, Robert Haas wrote:
> Sync rep, on the other hand, is going to
> do the opposite, probably by a large margin.
>
Are you sure of that? the code is very centralized and the bugs we
found last week weren't that difficult to address, the prove for that
is that Simon fix
Hi,
Someone on IRC recently noticed that you can't grant USAGE privileges on
a table to a large number of roles. (My experiment says 2466 works,
2467 doesn't).
Of course, this is wrong and all that. I wrote a blog article about
this:
http://www.commandprompt.com/blogs/alvaro_herrera/2011/03/gra
Hi
On Tue, Mar 1, 2011 at 11:00 AM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> On 28.02.2011 23:28, daveg wrote:
>
>> On Wed, Jan 12, 2011 at 10:46:14AM +0200, Heikki Linnakangas wrote:
>>
>>> We'll likely need to go back and forth a few times with various
>>> debugging pa
On tis, 2011-03-01 at 22:22 +0100, Rumko wrote:
> Well, wouldn't consider it ugly, but the patch (attached and available at
> http://www.rumko.net/0001-DragonFly-BSD-support-linked.patch ) is a lot
> shorter.
>
> Uses freebsd's template and defines the linker in Makefile.shlib.
The piece in Mak
"David E. Wheeler" writes:
> On Mar 1, 2011, at 1:12 PM, Tom Lane wrote:
>> The question is what collation property the
>> citext type needs to have, and how we get it to have that setting during
>> an upgrade from 9.0. See
>> http://archives.postgresql.org/message-id/11548.1297983...@sss.pgh.pa.
Peter Eisentraut writes:
> On fre, 2011-02-18 at 11:45 -0500, Tom Lane wrote:
>> While testing a fix for this, I observe that pg_dump is entirely
>> broken on the subject, because it fails to dump anything at all about
>> the typcollation property when dumping a base type.
> This is now fixed.
>
On Tuesday 1. of March 2011 16:07:47 Tom Lane wrote:
> Rumko writes:
> > On Sunday 27. of February 2011 23:50:17 Peter Eisentraut wrote:
> >> It seems to me that it would be easier to just map dragonfly to the
> >> freebsd template.
> >
> > I didn't see a precedence for that kind of introduction o
On Tue, Mar 1, 2011 at 22:20, Dimitri Fontaine wrote:
> Tom Lane writes:
>> Any other "must fix" items on people's minds?
>
> I'd like it if Magnus could commit his last round of work on
> pg_basebackup to stream the WALs in a subprocess. It's been about ready
> and waiting for more tests and co
Tom Lane writes:
> Any other "must fix" items on people's minds?
I'd like it if Magnus could commit his last round of work on
pg_basebackup to stream the WALs in a subprocess. It's been about ready
and waiting for more tests and code review while I've been ill. I
should be able to get there by
On Mar 1, 2011, at 1:12 PM, Tom Lane wrote:
> Collation, not correlation.
Yeah, I'm fat-fingered today.
> The question is what collation property the
> citext type needs to have, and how we get it to have that setting during
> an upgrade from 9.0. See
> http://archives.postgresql.org/message-
"David E. Wheeler" writes:
> On Mar 1, 2011, at 12:35 PM, Tom Lane wrote:
>> * Collation-related changes still needed in contrib/citext. If we don't
>> have this done before alpha4, I'm afraid we'll have to generate a 1.1
>> update script to fix it for alpha4 users. I'd just as soon not deal
>>
On tis, 2011-03-01 at 21:10 +0100, Jan Urbański wrote:
> So you end up with a context message saying "PL/Python function %s"
> and a detail message with the saved detail (if it's present) *and* the
> traceback. The problem is that the name of the function is already in
> the traceback, so there's n
On tis, 2011-03-01 at 12:50 -0800, David E. Wheeler wrote:
> On Mar 1, 2011, at 12:35 PM, Tom Lane wrote:
>
> > * Collation-related changes still needed in contrib/citext. If we don't
> > have this done before alpha4, I'm afraid we'll have to generate a 1.1
> > update script to fix it for alpha4
On 03/01/2011 03:53 PM, Jan Urbański wrote:
On 01/03/11 21:35, Tom Lane wrote:
Josh Berkus writes:
I'm ok with closing things as of the end of the 15 days, say Thursday or
Friday.
It might be a good idea to make a list of what we have left to do before
we can wrap an alpha. Here are some t
On 01/03/11 21:35, Tom Lane wrote:
> Josh Berkus writes:
>> I'm ok with closing things as of the end of the 15 days, say Thursday or
>> Friday.
>
> It might be a good idea to make a list of what we have left to do before
> we can wrap an alpha. Here are some things on my list. Not all of them
>
On Mar 1, 2011, at 12:35 PM, Tom Lane wrote:
> * Collation-related changes still needed in contrib/citext. If we don't
> have this done before alpha4, I'm afraid we'll have to generate a 1.1
> update script to fix it for alpha4 users. I'd just as soon not deal
> with that overhead.
What needs t
On 3/1/11 12:35 PM, Tom Lane wrote:
> * Generate alpha release notes. This is at least half a day's work
> for somebody, I think, even with our fairly low standards for alpha
> release notes.
I can help with this. Possibly Selena can too.
--
-- Josh Berkus
> That response is just dodging the hard question, so whatever. Tom's
> cleanup is not going to break things, or at least it's going to fix
> more than it breaks on net. Sync rep, on the other hand, is going to
> do the opposite, probably by a large margin.
Well, we need to at least give Simon
Robert Haas writes:
> Bruce has been going through the open items for the past several weeks
> (at least) and tells me that he hasn't found very much. I'm not sure
> what your thought is on what's required to get us from here to beta,
> but I am thinking it could be done in a few weeks. With a c
On Tue, Mar 1, 2011 at 3:36 PM, Josh Berkus wrote:
>
>> That's still missing the point, which is that the code is unlikely to
>> be up to our usual standards at that point.
>
> I was talking about "when do we close the CF and start building an
> alpha", not synch rep particularly. Tom said he wan
> That's still missing the point, which is that the code is unlikely to
> be up to our usual standards at that point.
I was talking about "when do we close the CF and start building an
alpha", not synch rep particularly. Tom said he wants until Friday
anyway just for some cleanup.
--
Josh Berkus writes:
> I'm ok with closing things as of the end of the 15 days, say Thursday or
> Friday.
It might be a good idea to make a list of what we have left to do before
we can wrap an alpha. Here are some things on my list. Not all of them
are necessarily release blockers, but we need
On Tue, Mar 1, 2011 at 3:01 PM, Josh Berkus wrote:
> On 3/1/11 11:58 AM, Tom Lane wrote:
>> If we do hold up the release, I'll probably go back and reopen the
>> postgresql_fdw patch as well as btree_gist. So I won't run out of
>> things to do. But I'm not terribly satisfied with the decision-ma
On Mar 1, 2011, at 12:10 PM, Jan Urbański wrote:
> So you end up with a context message saying "PL/Python function %s" and
> a detail message with the saved detail (if it's present) *and* the
> traceback. The problem is that the name of the function is already in
> the traceback, so there's no need
On Tue, 2011-03-01 at 14:26 -0500, Robert Haas wrote:
> On Tue, Mar 1, 2011 at 2:12 PM, Josh Berkus wrote:
> >
> >>> Since we appear to be still holding the commitfest open for Sync Rep,
> >>> I guess this ought to get reviewed.
> >>
> >> Or else we should close the CommitFest and cut alpha4. Any
On Tue, Mar 1, 2011 at 2:58 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Mar 1, 2011 at 2:45 PM, Tom Lane wrote:
>>> I'd say that if there's a plausible chance that Sync Rep will be
>>> committable by the end of *this* week (and I mean Friday not Sunday),
>>> I'm willing to wait that lon
On Tue, Mar 01, 2011 at 07:07:42PM +0200, Heikki Linnakangas wrote:
> Was there test cases for any of the issues fixed by this patch that we
> should add to the suite?
Some of these issues are tricky to test, e.g. some of the code about
transferring predicate locks to a new target doesn't get exe
On 01/03/11 20:35, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>> Currently the traceback is added to the detail and the original
>> errdetail is preserved. So you'd get the detail line and the traceback
>> below it.
>
> Hm? I'm talking about plpython_error_callback() and friends,
On Tue, Mar 1, 2011 at 3:08 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Mar 1, 2011 at 2:52 PM, Josh Berkus wrote:
>>> Ideally, we want to have some binaries/packages for the "final alpha".
>>> Those broaden testing considerably.
>
>> When we have a version that needs that treatment, we
Robert Haas writes:
> On Tue, Mar 1, 2011 at 2:52 PM, Josh Berkus wrote:
>> Ideally, we want to have some binaries/packages for the "final alpha".
>> Those broaden testing considerably.
> When we have a version that needs that treatment, we can simply call
> it beta1. If it's too half-baked for
On 3/1/11 11:58 AM, Tom Lane wrote:
> If we do hold up the release, I'll probably go back and reopen the
> postgresql_fdw patch as well as btree_gist. So I won't run out of
> things to do. But I'm not terribly satisfied with the decision-making
> process here.
OK, well, we gave it an extra 15 da
Robert Haas writes:
> On Tue, Mar 1, 2011 at 2:45 PM, Tom Lane wrote:
>> I'd say that if there's a plausible chance that Sync Rep will be
>> committable by the end of *this* week (and I mean Friday not Sunday),
>> I'm willing to wait that long for it. Otherwise, it's 9.2 material.
> I am quite
On Tue, Mar 1, 2011 at 2:52 PM, Josh Berkus wrote:
> Ideally, we want to have some binaries/packages for the "final alpha".
> Those broaden testing considerably.
When we have a version that needs that treatment, we can simply call
it beta1. If it's too half-baked for that, then I don't see the p
> As I understand it, it requires only the steps described here:
>
> http://wiki.postgresql.org/wiki/Alpha_release_process
>
> That all looks pretty straightforward, assuming you can log into
> developer.postgresql.org, which I can't. I think I remember having an
> ftp account at some point, bu
Hi,
On Tuesday, March 01, 2011 11:50:42 AM Nikhil Sontakke wrote:
> >> Will try to get the call stack if needed.
> >
> > Yes, please.
> Here is the stack trace:
Thats not a stock postgres is it?
Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
On Tue, Mar 1, 2011 at 2:38 PM, Magnus Hagander wrote:
>> Frankly, I think we should be aiming to get a beta out in April, not
>> another alpha.
>
> That would be good, but in order to get there, +1 for cutting a new
> alpha even if syncrep isn't ready for it yet. That way we can at least
> get so
On Tue, Mar 1, 2011 at 2:45 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Mar 1, 2011 at 2:12 PM, Josh Berkus wrote:
>>> I think we can give Sync Rep until the 15th, given the pace of work on
>>> it. It is a major feature, and a complicated one.
>
>> Sure, but there are other features, m
On Mon, Feb 28, 2011 at 11:26 AM, Josh Berkus wrote:
>
>> does foundry support git or should I just link to a repo on github?
>
> If you prefer using git, the latter.
Ok, will do. Assign the project and I'll update stuff.
Andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
On 03/01/2011 02:15 PM, Kevin Grittner wrote:
Given that there were similar issues for other hierarchical data
types, perhaps we need something similar to tsvector, but for
hierarchical data. The extra layer of abstraction might not cost
much when used for XML compared to the possible benefi
Robert Haas writes:
> On Tue, Mar 1, 2011 at 2:12 PM, Josh Berkus wrote:
>> I think we can give Sync Rep until the 15th, given the pace of work on
>> it. It is a major feature, and a complicated one.
> Sure, but there are other features, major and minor, that we have
> postponed to 9.2. In the
On Tue, Mar 1, 2011 at 20:26, Robert Haas wrote:
> On Tue, Mar 1, 2011 at 2:12 PM, Josh Berkus wrote:
>>
Since we appear to be still holding the commitfest open for Sync Rep,
I guess this ought to get reviewed.
>>>
>>> Or else we should close the CommitFest and cut alpha4. Anyone have
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
> Currently the traceback is added to the detail and the original
> errdetail is preserved. So you'd get the detail line and the traceback
> below it.
Hm? I'm talking about plpython_error_callback() and friends, which
AFAICS you haven't changed the behavi
On Tue, Mar 1, 2011 at 2:12 PM, Josh Berkus wrote:
>
>>> Since we appear to be still holding the commitfest open for Sync Rep,
>>> I guess this ought to get reviewed.
>>
>> Or else we should close the CommitFest and cut alpha4. Anyone have an
>> opinion on which way to go?
>
> I think we can give
"Kevin Grittner" writes:
> I apparently didn't express myself very well, since you seem to have
> *completely* missed my point. I know we can do tsearch2 searches
> against XML, or JSON, or YAML, or (insert next week's new favorite
> format here). What we can't currently do efficiently is search
On 01/03/11 20:15, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>> After thinking about it more I believe that the context field should
>> keep on being a one line indication of which function the message comes
>> from (and that's how it's done in PL/pgSQL for instance), and the deta
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
> I looked into putting the tracebacks in the context field, but IMHO it
> doesn't really play out nice. PL/Python uses a errcontext callback to
> populate the context field, so the reduntant information (the name of
> the function) is always there. If that
Andrew Dunstan wrote:
> On 02/28/2011 05:28 PM, Kevin Grittner wrote:
>> Anton wrote:
>>
>>> it was actually the focal point of my considerations: whether to
>>> store plain text or 'something else'.
>
> There seems to be an almost universal assumption that storing XML
> in its native form (i.e.
>> Since we appear to be still holding the commitfest open for Sync Rep,
>> I guess this ought to get reviewed.
>
> Or else we should close the CommitFest and cut alpha4. Anyone have an
> opinion on which way to go?
I think we can give Sync Rep until the 15th, given the pace of work on
it. It
On 26.02.2011 16:58, Robert Haas wrote:
It sounds like the only thing we have definite agreement about from
all this is that apply_location should be renamed to replay_location
in pg_stat_replication, a point fairly incidental to the what this
patch is about. It seems fairly unsatisfying to just
On Tue, Mar 1, 2011 at 1:35 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Feb 28, 2011 at 2:25 PM, Tom Lane wrote:
>>> Given that it is a contrib module, I personally wouldn't object to it
>>> getting patched later, like during alpha or beta. But somebody's got
>>> to do the work, and I'
Robert Haas writes:
> On Mon, Feb 28, 2011 at 2:25 PM, Tom Lane wrote:
>> Given that it is a contrib module, I personally wouldn't object to it
>> getting patched later, like during alpha or beta. But somebody's got
>> to do the work, and I've got a dozen higher-priority problems right now.
> W
On Tue, Mar 1, 2011 at 1:15 PM, Tom Lane wrote:
> Did anybody do any performance measurements to demonstrate that this
> code has a reason to live? Because if I don't see some, I'm going
> to rip it out.
No, I have to admit I didn't do that. Might be worth doing some
before you commit the rip-o
On Tue, 2011-03-01 at 10:02 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > On Tue, 2011-03-01 at 15:51 +0900, Fujii Masao wrote:
> >> A spinlock can be used only for very short-term operation like
> >> read/write of some shared-variables. The operation on the queue
> >> is not short, so should b
So while poking at a recent example from Marc Cousin (hundreds of tables
each with 1000 attributes) I observed that a simple ANALYZE would bloat
the backend process to the tune of several hundred megabytes. I think
there is a leak in CacheMemoryContext, but haven't tracked it down yet.
But I also
I did a quick look at this patch. The major problem with it is of
course that it needs to be fixed for the recent extension-related
changes. I transposed the .sql.in changes into additions to
btree_gist--1.0.sql (attached), but haven't really sanity-checked
them beyond checking that the regressi
Heikki Linnakangas wrote:
> committed with minor changes.
Thanks!
> The ordering of the fields in PREDICATELOCKTAG was bizarre, so I
> just expanded the offsetnumber fields to an uint32, instead of
> having the padding field. I think that's a lot more readable.
I can understand that, but I
On 01.03.2011 02:03, Dan Ports wrote:
An updated patch to address this issue is attached. It fixes a couple
issues related to use of the backend-local lock table hint:
- CheckSingleTargetForConflictsIn now correctly handles the case
where a lock that's being held is not reflected in the
On fre, 2011-02-11 at 16:49 +0100, Jan Urbański wrote:
> I believe it's (b). But as we don't have time for that discussion that
> late in the release cycle, I think we need to consider it identical to (c).
As I previously mentioned, I think that there should be an SQL-level way
to tie together lan
On fre, 2011-02-18 at 11:45 -0500, Tom Lane wrote:
> While testing a fix for this, I observe that pg_dump is entirely
> broken on the subject, because it fails to dump anything at all about
> the typcollation property when dumping a base type.
This is now fixed.
> I also rather wonder
> exactly w
On Mon, Feb 28, 2011 at 4:08 PM, Michael Glaesemann
wrote:
> A couple of weeks ago when installing uuid-ossp on a new server, I noticed
> that the ossp site is gone. I haven't found anything on the web to indicate
> what happened.
>
> Anyone know?
Maybe it's time to provide our own UUID generat
On Mon, Feb 28, 2011 at 8:54 AM, Fujii Masao wrote:
> When I implemented the replication timeout patch, I found the bug on
> the HS feedback feature. When wal_receiver_status_interval is zero
> and hot_standby_feedback is enabled, walreceiver sends the feedback
> too aggressively. I think that the
It works!
Thanks Kevin and Lbrar!
:)
2011/3/1 Ibrar Ahmed :
> - export CFLAGS='-O0' may work for you.
>
>
> On Tue, Mar 1, 2011 at 8:21 PM, Kevin Grittner
> wrote:
>> hom wrote:
>>
>>> How can I do to make sure the right excute order when I debug step
>>> by step ?
>>
>> You may need to reduce
- export CFLAGS='-O0' may work for you.
On Tue, Mar 1, 2011 at 8:21 PM, Kevin Grittner
wrote:
> hom wrote:
>
>> How can I do to make sure the right excute order when I debug step
>> by step ?
>
> You may need to reduce the optimization level of your compile.
>
> -Kevin
>
> --
> Sent via pgsql-h
Nikhil Sontakke writes:
> On Tue, Mar 1, 2011 at 10:17 PM, Heikki Linnakangas
> wrote:
>> Hmm, it looks like ImmediateInterruptOK is set, while we're busy running a
>> query. How come? Can you debug that? Where does it get set?
> Ah, this is not exactly an easily reproducible problem :( You gott
hom wrote:
> How can I do to make sure the right excute order when I debug step
> by step ?
You may need to reduce the optimization level of your compile.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresq
Robert Haas writes:
> On Tue, Mar 1, 2011 at 3:21 AM, Simon Riggs wrote:
>> LWlocks are just spinlocks plus sem sleeps, so I don't see the need for
>> that in the current code. Other views welcome.
> An LWLock is a lot safer, in general, than a spinlock. A spinlock
> mustn't do anything that co
HI,
I tried to debug PostgreSQL under Redhat with Eclipse.
I follew the guide ' Working with Eclipse ', and build the DB successfully.
http://wiki.postgresql.org/wiki/Working_with_Eclipse
However, when I debug the souce code step by step, I found it run in
the wrong order.
I think the cause may
On 01.03.2011 16:40, Nikhil Sontakke wrote:
On Tue, Mar 1, 2011 at 10:17 PM, Heikki Linnakangas
wrote:
On 01.03.2011 12:50, Nikhil Sontakke wrote:
Will try to get the call stack if needed.
Yes, please.
Here is the stack trace:
Hmm, it looks like ImmediateInterruptOK is set, while we'r
Rumko writes:
> On Sunday 27. of February 2011 23:50:17 Peter Eisentraut wrote:
>> It seems to me that it would be easier to just map dragonfly to the
>> freebsd template.
> I didn't see a precedence for that kind of introduction of a new platform
> (all
> others seem to have their own template
Simon Riggs writes:
> On Tue, 2011-03-01 at 15:51 +0900, Fujii Masao wrote:
>> A spinlock can be used only for very short-term operation like
>> read/write of some shared-variables. The operation on the queue
>> is not short, so should be protected by LWLock, I think.
> There's no need to sleep w
On Tue, Mar 1, 2011 at 10:17 PM, Heikki Linnakangas
wrote:
> On 01.03.2011 12:50, Nikhil Sontakke wrote:
>>>
Will try to get the call stack if needed.
>>>
>>> Yes, please.
>>
>> Here is the stack trace:
>
> Hmm, it looks like ImmediateInterruptOK is set, while we're busy running a
> query. Ho
On 01.03.2011 12:50, Nikhil Sontakke wrote:
Will try to get the call stack if needed.
Yes, please.
Here is the stack trace:
Hmm, it looks like ImmediateInterruptOK is set, while we're busy running
a query. How come? Can you debug that? Where does it get set?
--
Heikki Linnakangas
E
On 03/01/2011 08:16 AM, Robert Haas wrote:
On Mon, Feb 28, 2011 at 6:54 PM, Andrew Dunstan wrote:
There seems to be an almost universal assumption that storing XML in its
native form (i.e. a text stream) is going to produce inefficient results.
Maybe it will, but I think it needs to be fairly
On Mon, Feb 28, 2011 at 10:32 PM, Greg Stark wrote:
> On Tue, Mar 1, 2011 at 1:43 AM, David Christensen wrote:
>> Was this cluster upgraded to 8.4.4 from 8.4.0? It sounds to me like a known
>> bug in 8.4.0 which was fixed by this commit:
>>
>
> The reproduction script described was running vacu
On Tue, Mar 1, 2011 at 3:21 AM, Simon Riggs wrote:
> On Tue, 2011-03-01 at 15:51 +0900, Fujii Masao wrote:
>> Thanks for update of the patch!
>>
>> On Tue, Mar 1, 2011 at 3:40 AM, Simon Riggs wrote:
>> >> SyncRepRemoveFromQueue seems not to be as short-term as we can
>> >> use the spinlock. Inste
On Mon, Feb 28, 2011 at 6:54 PM, Andrew Dunstan wrote:
> There seems to be an almost universal assumption that storing XML in its
> native form (i.e. a text stream) is going to produce inefficient results.
> Maybe it will, but I think it needs to be fairly convincingly demonstrated.
> And then we
On 28/02/11 19:38, Tom Lane wrote:
> Peter Eisentraut writes:
>> On mån, 2011-02-28 at 12:08 -0500, Tom Lane wrote:
>>> I'm seeing a core dump as well as multiple inconsistencies in error
>>> message spelling in the plpython regression tests on a Fedora 13 box
>>> (python 2.6.4). Several buildfar
>
>> Will try to get the call stack if needed.
>
> Yes, please.
>
Here is the stack trace:
#0 0xe410 in __kernel_vsyscall ()
#1 0xb7ee676e in __lll_mutex_lock_wait () from /lib/libc.so.6
#2 0xb7e82e41 in _L_lock_4214 () from /lib/libc.so.6
#3 0xb7e80048 in free () from /lib/libc.so.6
#4
On 2011-02-28 20:32, Simon Riggs wrote:
I have reworded it to see if that improves the explanation
Code available at git://github.com/simon2ndQuadrant/postgres.git
If a standby is removed from the list of servers then it will stop
being the synchronous standby, allowing another to take it'
On Tue, Mar 1, 2011 at 5:29 PM, Simon Riggs wrote:
>> >> What if fast shutdown is requested while RecordTransactionCommit
>> >> is waiting in SyncRepWaitForLSN? ISTM fast shutdown cannot complete
>> >> until replication has been successfully done (i.e., until at least one
>> >> synchronous standby
On Tue, Mar 1, 2011 at 4:56 PM, Simon Riggs wrote:
>> > If allow_standalone_primary = on then we sit and wait until we hit
>> > client timeout, which occurs even after last standby has gone.
>>
>> In that case, why do backends need to wait until the timeout occurs?
>> We can make those backends re
On Sunday 27. of February 2011 23:50:17 Peter Eisentraut wrote:
> On sön, 2011-02-27 at 21:19 +0100, Rumko wrote:
> > The attached patch (also available at
> > http://www.rumko.net/0001-DragonFly-BSD-support.patch ) applies cleanly
> > to the master branch and can be cherry-picked to REL9_0_STABLE
On Tue, Mar 1, 2011 at 5:21 PM, Simon Riggs wrote:
>> A spinlock can be used only for very short-term operation like
>> read/write of some shared-variables. The operation on the queue
>> is not short, so should be protected by LWLock, I think.
>
> There's no need to sleep while holding locks and t
Tom Lane writes:
> The ideal solution would likely be for the stats collector to expose its
> data structures as shared memory, but I don't think we get to do that
> under SysV shmem --- it doesn't like variable-size shmem much. Maybe
> that's another argument for looking harder into mmap or POSI
1 - 100 of 103 matches
Mail list logo
