On 15/09/10 09:19, Simon Riggs wrote:
On Wed, 2010-09-15 at 10:33 +0900, Fujii Masao wrote:
On Wed, Sep 15, 2010 at 12:14 AM, Simon Riggs wrote:
Like latches, nice one.
The way the loop in WalSender now happens it won't send any outstanding
WAL if a shutdown is requested while it is waiting.
On Wed, Sep 15, 2010 at 3:19 PM, Simon Riggs wrote:
> For SIGUSR2, you're right.
>
> However, if the following clause is ever invoked, then the loop does
> have problems and we leave when not caught up.
>
> if (!PostmasterIsAlive(true))
> exit(1);
In normal shutdown case, that clause is no
On Wed, 2010-09-15 at 10:33 +0900, Fujii Masao wrote:
> On Wed, Sep 15, 2010 at 12:14 AM, Simon Riggs wrote:
> >
> > Like latches, nice one.
> >
> > The way the loop in WalSender now happens it won't send any outstanding
> > WAL if a shutdown is requested while it is waiting.
> >
> > That probably
Hello.
This is a proposal patch for SQL/MED for 9.1.
At the prev. CF, this patch had so many features to make it hard
to review all of them. So I devided it into smaller parts:
(1) foreign table DDL support (this proposal):
- support for foreign table DDL syntax (CREATE/ALTER FOREIGN TABLE)
2010/9/15 Tom Lane :
> Hitoshi Harada writes:
>> 2010/9/15 Tom Lane :
>>> Why is it so difficult to do this correctly?
>
>> Because INSERT INTO ... (SELECT|VALUES) is already a collection of
>> kludge (as comments say). It was possible to parse the two WITHs
>> separately, but it results in ambigu
Hitoshi Harada writes:
> 2010/9/15 Tom Lane :
>> Why is it so difficult to do this correctly?
> Because INSERT INTO ... (SELECT|VALUES) is already a collection of
> kludge (as comments say). It was possible to parse the two WITHs
> separately, but it results in ambiguous naming issue;
> parseWith
2010/9/13 Teodor Sigaev :
> [updated patch]
I realize I'm repeating myself, but... this patch needs
documentation. It's not optional.
It seems to me that you need to do something about AMOPSTRATEGY.
Hence the five-key syscaches patches I wrote that is sitting in queue.
And also LookupOpClassIn
Fujii Masao writes:
> In HEAD, OwnLatch can elog during holding the spinlock WalSnd->mutex.
> This seems to be unsafe
Even if it were safe, holding a spinlock through non-straight-line code
is a complete violation of the spinlock coding rules re the length of
time you're supposed to hold the lock
Here is a patch for basic JSON support. It adds only those features:
* Add "json" data type, that is binary-compatible with text.
* Syntax checking on text to JSON conversion.
* json_pretty() -- print JSON tree with indentation.
We have "JSON datatype (WIP) 01" item:
https://commitfest.pos
Robert Haas writes:
> One other thought: should we add some of these queries that have
> exposed bugs in join removal to the regression tests?
I did.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
Hi,
In HEAD, OwnLatch can elog during holding the spinlock WalSnd->mutex.
This seems to be unsafe because that elog would cause the walsender
to exit without releasing the spinlock. Because of the spinlock being
held, subsequent walsender would get stuck. I wonder if OwnLatch really
needs to be pr
On Tue, Sep 14, 2010 at 8:44 PM, Robert Haas wrote:
> On Tue, Sep 14, 2010 at 7:26 PM, Tom Lane wrote:
>> I wrote:
>>> I think that it's probably sufficient to make remove_rel_from_query run
>>> through the rel's joininfo list looking for pseudoconstant quals, and
>>> push those back into the joi
On Tue, Sep 14, 2010 at 2:59 PM, Markus Wanner wrote:
> On 09/14/2010 08:41 PM, Robert Haas wrote:
>>
>> To avoid consuming system resources forever if they're not being used.
>
> Well, what timeout would you choose. And how would you justify it compared
> to the amounts of system resources consum
On Wed, Sep 15, 2010 at 12:14 AM, Simon Riggs wrote:
>
> Like latches, nice one.
>
> The way the loop in WalSender now happens it won't send any outstanding
> WAL if a shutdown is requested while it is waiting.
>
> That probably needs to change and we'd do similarly in other procs.
Really? ISTM t
2010/9/15 Tom Lane :
> Marko Tiikkaja writes:
>> On 2010-09-14 10:51 PM, Tom Lane wrote:
>>> My recollection is that whether a CTE is marked RECURSIVE or not affects
>>> its scope of visibility, so that confusing the two cases can result in
>>> flat-out incorrect parser behavior.
>
>> The worst I
2010/9/15 Marko Tiikkaja :
> On 2010-09-14 10:51 PM, Tom Lane wrote:
>> My recollection is that whether a CTE is marked RECURSIVE or not affects
>> its scope of visibility, so that confusing the two cases can result in
>> flat-out incorrect parser behavior.
>
> The worst I can think of is:
>
> CREA
On Tue, Sep 14, 2010 at 7:26 PM, Tom Lane wrote:
> I wrote:
>> I think that it's probably sufficient to make remove_rel_from_query run
>> through the rel's joininfo list looking for pseudoconstant quals, and
>> push those back into the joininfo lists with a reduced join list. I
>> wonder though i
I wrote:
> I think that it's probably sufficient to make remove_rel_from_query run
> through the rel's joininfo list looking for pseudoconstant quals, and
> push those back into the joininfo lists with a reduced join list. I
> wonder though if there's a better way, or if there are related bugs
> t
Marko Tiikkaja writes:
> On 2010-09-14 10:51 PM, Tom Lane wrote:
>> My recollection is that whether a CTE is marked RECURSIVE or not affects
>> its scope of visibility, so that confusing the two cases can result in
>> flat-out incorrect parser behavior.
> The worst I can think of is:
> CREATE TA
On Tue, Sep 14, 2010 at 4:28 PM, Marko Tiikkaja
wrote:
> On 2010-09-14 10:51 PM, Tom Lane wrote:
>>
>> Hitoshi Harada writes:
>>>
>>> 2010/9/15 Marko Tiikkaja:
In the email you referred to, Tom was concerned about the case where
these
WITH lists have different RECURSIVE declar
Hello,
> Can you run oprofile on the older kernel, so that we can compare and see
> where the time is spent?
> Looks like over 7% of the time is spent in s_lock, which suggests some change
> in behavior in context switching or something like that, but let's see what
> the old profile looks like
Hi,
I saw the slides at:
http://www.sai.msu.su/~megera/postgres/talks/2009.pdf
describing the phrase search algebra for the proposed tsquery $
operator, and the wiki at:
http://www.sai.msu.su/~megera/wiki/2009-08-12
Has there been progress on this front? Has the patch
phrase_search-0.7.gz mention
I've been thinking about these points, and reconsidered somewhat.
Heikki Linnakangas wrote:
> Should add a citation to Cahill's work this is based on.
> Preferably with a hyperlink.
I've been thinking that this should be mentioned in both the README
and the source code.
> A short descriptio
On 14 September 2010 21:36, David E. Wheeler wrote:
> On Sep 14, 2010, at 10:48 AM, Simon Riggs wrote:
>
>> I will post my patch on this thread when it is available.
>
> Sounds awesome Simon, I look forward to seeing the discussion!
>
> Best,
>
> David
Excellent! :) I actually understand how tha
On Fri, Sep 10, 2010 at 11:52:20AM +0900, Fujii Masao wrote:
> On Fri, Sep 3, 2010 at 3:42 PM, Fujii Masao wrote:
> > Here is the proposed detailed design:
> >
> > standbys.conf
> > =
> > # This is not initialized by initdb, so users need to create it under
> > $PGDATA.
> > * The t
Heikki Linnakangas wrote:
> Great work! A year ago I thought it would be impossible to have a
> true serializable mode in PostgreSQL because of the way we do
> MVCC, and now we have a patch.
>
> At a quick read-through, the code looks very tidy and clear now.
> Some comments:
>
> Should add a
On Sep 14, 2010, at 10:48 AM, Simon Riggs wrote:
> I will post my patch on this thread when it is available.
Sounds awesome Simon, I look forward to seeing the discussion!
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 2010-09-14 10:51 PM, Tom Lane wrote:
Hitoshi Harada writes:
2010/9/15 Marko Tiikkaja:
In the email you referred to, Tom was concerned about the case where these
WITH lists have different RECURSIVE declarations. This patch makes both
RECURSIVE if either of them is. I can think of cases whe
Hitoshi Harada writes:
> 2010/9/15 Marko Tiikkaja :
>> In the email you referred to, Tom was concerned about the case where these
>> WITH lists have different RECURSIVE declarations. This patch makes both
>> RECURSIVE if either of them is. I can think of cases where that might lead
>> to surpris
On 14/09/10 19:34, Kevin Grittner wrote:
Attached is the latest Serializable Snapshot Isolation (SSI) patch.
Great work! A year ago I thought it would be impossible to have a true
serializable mode in PostgreSQL because of the way we do MVCC, and now
we have a patch.
At a quick read-through
On 09/14/2010 08:41 PM, Robert Haas wrote:
To avoid consuming system resources forever if they're not being used.
Well, what timeout would you choose. And how would you justify it
compared to the amounts of system resources consumed by an idle process
sitting there and waiting for a job?
I'
I dug into the 9.0 bug reported here:
http://archives.postgresql.org/pgsql-sql/2010-09/msg00035.php
What is happening is that the planner recognizes that the query is
unsatisfiable, because m.ttype is equated to two different constant
values. This results in generating a constant-false RestrictIn
2010/9/15 Marko Tiikkaja :
> On 2010-09-13 4:15 PM +0300, Hitoshi Harada wrote:
>>
>> 1. WITH clause atop INSERT
>> Although the previous discussion got the consensus that we forbid WITH
>> atop INSERT, it seems to me that it can be allowed. I managed to do it
>> by treating the top WITH clause (of
On Tue, Sep 14, 2010 at 2:26 PM, Markus Wanner wrote:
> On 09/14/2010 08:06 PM, Robert Haas wrote:
>> One idea I had was to have autovacuum workers stick around for a
>> period of time after finishing their work. When we need to autovacuum
>> a database, first check whether there's an existing wo
On Tue, Sep 14, 2010 at 1:56 PM, Alvaro Herrera
wrote:
> Excerpts from Tom Lane's message of mar sep 14 13:46:17 -0400 2010:
>> Alvaro Herrera writes:
>> > I think we've had enough problems with the current design of forking a
>> > new autovac process every once in a while, that I'd like to have
On 09/14/2010 08:06 PM, Robert Haas wrote:
One idea I had was to have autovacuum workers stick around for a
period of time after finishing their work. When we need to autovacuum
a database, first check whether there's an existing worker that we can
use, and if so use him. If not, start a new on
Hi,
I'm glad discussion on this begins.
On 09/14/2010 07:55 PM, Tom Lane wrote:
So there is a minimum of one avworker per database?
Nope, you can set that to 0. You don't *need* to keep idle workers around.
That's a guaranteed
nonstarter. There are many people with thousands of databases,
I'm working on a patch to implement synchronous replication for
PostgreSQL, with user-controlled durability specified on the master. The
design also provides high throughput by allowing concurrent processes to
handle the WAL stream. The proposal requires only 3 new parameters and
takes into accoun
Markus Wanner writes:
> On 09/14/2010 07:46 PM, Tom Lane wrote:
>> That seems like a fairly large can of worms to open: we have never tried
>> to make backends switch from one database to another, and I don't think
>> I'd want to start such a project with autovac.
> They don't. Even with bgworker
Hi,
On 09/14/2010 07:46 PM, Tom Lane wrote:
Alvaro Herrera writes:
I think we've had enough problems with the current design of forking a
new autovac process every once in a while, that I'd like to have them as
permanent processes instead, waiting for orders from the autovac
launcher. From th
Excerpts from Tom Lane's message of mar sep 14 13:46:17 -0400 2010:
> Alvaro Herrera writes:
> > I think we've had enough problems with the current design of forking a
> > new autovac process every once in a while, that I'd like to have them as
> > permanent processes instead, waiting for orders f
Alvaro Herrera writes:
> I think we've had enough problems with the current design of forking a
> new autovac process every once in a while, that I'd like to have them as
> permanent processes instead, waiting for orders from the autovac
> launcher. From that POV, bgworkers would make sense.
Tha
Excerpts from Markus Wanner's message of mar sep 14 12:56:59 -0400 2010:
> What bugs me a bit is that I didn't really get much feedback regarding
> the *bgworker* portion of code. Especially as that's the part I'm most
> interested in feedback.
I think we've had enough problems with the current
Alvaro Herrera writes:
> I think there's hardly much of interest in that branch, so it doesn't
> make sense to waste too much effort on it. However, why would we delete
> it? Just keep it with the manufactured tag and all -- so it is there,
> even if the history is not all that clean. This _is_
Excerpts from Tom Lane's message of mar sep 14 12:45:28 -0400 2010:
> > I want a good, clean, complete history in git, but ancient partial
> > branches are below my threshold for caring. But if you feel it's
> > useful, we can keep the tag - I don't care enough to argue about it.
>
> ... but hav
On 09/14/2010 06:26 PM, Robert Haas wrote:
As a matter of project management, I am inclined to think that until
we've hammered out this issue, there's not a whole lot useful that can
be done on any of the BG worker patches. So I am wondering if we
should set those to Returned with Feedback or bu
Robert Haas writes:
> On Tue, Sep 14, 2010 at 12:23 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> We're not planning to delete the CVS repository, are we?
>>
>> Not in the short term, but I'd like to think that the git repository
>> will contain everything of conceivable interest.
> Hmm, OK.
On Tue, Sep 14, 2010 at 12:23 PM, Tom Lane wrote:
> Robert Haas writes:
>> We're not planning to delete the CVS repository, are we?
>
> Not in the short term, but I'd like to think that the git repository
> will contain everything of conceivable interest.
Hmm, OK. That's never really been one o
On Mon, Aug 30, 2010 at 11:30 AM, Markus Wanner wrote:
> On 08/30/2010 04:52 PM, Tom Lane wrote:
>> Let me just point out that awhile back we got a *measurable* performance
>> boost by eliminating a single indirect fetch from the buffer addressing
>> code path.
>
> I'll take a look a that, thanks.
Robert Haas writes:
> We're not planning to delete the CVS repository, are we?
Not in the short term, but I'd like to think that the git repository
will contain everything of conceivable interest.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
On Tue, Sep 14, 2010 at 12:01 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Sep 14, 2010 at 10:19 AM, Tom Lane wrote:
>>> * One that creates the partial branch ecpg_big_bison. I think we have
>>> to live with this too. I don't want to drop the branch altogether,
>>> as that would repres
Excerpts from Dimitri Fontaine's message of mar sep 14 11:10:50 -0400 2010:
> Tom Lane writes:
> > PS: This attachment is text/x-patch instead of text/plain ... does
> > it come through as an attachment for you, Robert?
>
> From my MUA, I can say that it's not so much a problem of MIME type than
Robert Haas writes:
> On Tue, Sep 14, 2010 at 10:19 AM, Tom Lane wrote:
>> * One that creates the partial branch ecpg_big_bison. I think we have
>> to live with this too. I don't want to drop the branch altogether,
>> as that would represent a loss of development history. The only other
>> alt
Robert Haas writes:
> Incidentally, with respect to timing, do we want to press on with this
> conversion now or wait until after the CommitFest is done?
I'd kind of like to do it before we start the commitfest. These
repository patches will go stale if we wait too long, and a month
is probably
On 2010-09-13 4:15 PM +0300, Hitoshi Harada wrote:
1. WITH clause atop INSERT
Although the previous discussion got the consensus that we forbid WITH
atop INSERT, it seems to me that it can be allowed. I managed to do it
by treating the top WITH clause (of INSERT) as if the one of SELECT
(or VALUE
On Tue, Sep 14, 2010 at 10:19 AM, Tom Lane wrote:
> * Four that create the partial tags SUPPORT, MANUAL_1_0, creation, and
> Release-1-6-0. I think we agreed that we can just drop these tags and
> allow their manufactured commits to be garbage-collected.
+1.
> * Two that create the tags Release
Like latches, nice one.
The way the loop in WalSender now happens it won't send any outstanding
WAL if a shutdown is requested while it is waiting.
That probably needs to change and we'd do similarly in other procs.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Development, 24x7 Su
Tom Lane writes:
> PS: This attachment is text/x-patch instead of text/plain ... does
> it come through as an attachment for you, Robert?
>From my MUA, I can say that it's not so much a problem of MIME type than
the Content-Disposition, yours are always inline.
http://www.gnus.org/manual/emacs
On Tue, Sep 14, 2010 at 05:35:23PM +0900, Fujii Masao wrote:
> On Tue, Sep 14, 2010 at 5:06 PM, Heikki Linnakangas
> wrote:
> > Committed with some extra comments. I also backpatched this to 9.0.
>
> Thanks! I marked the patch as committed on CF.
Thanks!
Cheers,
David (Commitfest Cat Herd of th
Heikki Linnakangas writes:
> It just occurred to me that the Windows latch implementation goes
> through a lot of trouble to dynamically assign the shared Windows event
> handles to the latches in OwnLatch, but there's really no reason why
> they can't be statically assigned in InitSharedLatch
On Tue, Sep 14, 2010 at 5:51 PM, Heikki Linnakangas
wrote:
> On 14/09/10 05:02, Fujii Masao wrote:
>>
>> + /*
>> + * Walreceiver sets this latch every time new WAL has been
>> received and
>> + * fsync'd to disk, allowing startup process to wait for new WAL
>> to
>> + *
On 14/09/10 16:02, Fujii Masao wrote:
Hi,
In 9.1dev, wal_sender_delay in *milliseconds* is given
to WaitLatchOrSocket as *microseconds* timeout. This is
obviously wrong. The attached patch fixes this problem.
Thanks, fixed.
I was just wondering earlier this morning why walsender process was
Hi,
In 9.1dev, wal_sender_delay in *milliseconds* is given
to WaitLatchOrSocket as *microseconds* timeout. This is
obviously wrong. The attached patch fixes this problem.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
wal_sender_delay_v1.pat
It just occurred to me that the Windows latch implementation goes
through a lot of trouble to dynamically assign the shared Windows event
handles to the latches in OwnLatch, but there's really no reason why
they can't be statically assigned in InitSharedLatch instead. We have to
allocate the sa
On 14/09/10 05:02, Fujii Masao wrote:
+ /*
+* Walreceiver sets this latch every time new WAL has been received and
+* fsync'd to disk, allowing startup process to wait for new WAL to
+* arrive.
+*/
+ Latch receivedLatch;
I think that this lat
On Tue, Sep 14, 2010 at 5:06 PM, Heikki Linnakangas
wrote:
> Committed with some extra comments. I also backpatched this to 9.0.
Thanks! I marked the patch as committed on CF.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql
On 14/09/10 03:55, Fujii Masao wrote:
On Tue, Sep 14, 2010 at 12:10 AM, Heikki Linnakangas
wrote:
Yet another idea: Check in pg_ctl if recovery.conf is also present. If it
is, assume we're in recovery and don't print that warning. That would be
dead simple. I would even consider backpatching i
On 14/09/10 03:39, Fujii Masao wrote:
On Tue, Sep 14, 2010 at 12:35 AM, Heikki Linnakangas
wrote:
Hmm, looking at this more closely, I'm a bit confused. We already rename
away backup_label at the beginning of recovery. Under what circumstances do
we have a problem? This starts to seem like a c
68 matches
Mail list logo
