On ons, 2009-11-11 at 22:30 -0500, Emmanuel Cecchet wrote:
> On the other end, how do we, simple developers, become better to
> reach
> the status of committers? How can we endure the constant bashing
> especially in the early stages of our learning phase (especially if
> you
> are not paid to d
Fujii Masao wrote:
> The problem is that fsync needs to be issued too frequently, which would
> be harmless in asynchronous replication, but not in synchronous one.
> A transaction would have to wait for the primary's and standby's fsync
> before returning a "success" to a client.
>
> So I'm incli
Robert Haas wrote:
Here's an attempt.
http://wiki.postgresql.org/wiki/Running_a_CommitFest
Perfect, that's the sort of thing I was looking for the other day but
couldn't find anywhere. I just made a pass through better wiki-fying
that and linking it to the related pages in this area.
Two
Hi,
> True, but even I avoid patches I don't understand, and "practicing" by
> applying them could lead to a very undesirable outcome, e.g.
> instability.
>
How about having a staging server to help around novice committers?
Basically the selected new band of people can take a patch, review it
an
> "Tom" == Tom Lane writes:
Tom> I think you could probably just change it: make DISTINCT work as
Tom> per regular DISTINCT (treat null like a value, keep one copy).
Tom> All the spec-conforming aggregates are strict and would ignore
Tom> the null in the next step anyway.
>> Change it f
On Nov 11, 2009, at 10:43 PM, Tom Lane wrote:
Andrew Chernow writes:
I thought of a compromise: add the number of times a notification
was
generated (coalesced count+1) to the callback data. That would
satisfy
any backwards compatibility concerns and my use case too!
If you are suggesti
On Thu, Nov 12, 2009 at 12:03 PM, Tom Lane wrote:
> Fujii Masao writes:
>> Should the standby also have to follow the WAL rule during recovery?
>> The current patch doesn't care about the write order of the data page
>> and WAL in the standby. So, after both servers fail, restarting the
>> ex-sta
2. The payload parameter is optional. A notifying client can either call
"NOTIFY foo;" or "NOTIFY foo 'payload';". The length of the payload is
currently limited to 128 characters... Not sure if we should allow longer
payload strings...
Might be a good idea to make the max the same as the max le
Andrew Chernow writes:
>> I thought of a compromise: add the number of times a notification was
>> generated (coalesced count+1) to the callback data. That would satisfy
>> any backwards compatibility concerns and my use case too!
> If you are suggesting that the server poke data into the notif
The following email expresses my personal opinion and does not reflect
the opinion of my employers.
Bruce Momjian wrote:
I also think the bad economy is making it harder for people/companies to
devote time to community stuff when paid work is available.
Actually the bad economy should be a b
I thought of a compromise: add the number of times a notification was
generated (coalesced count+1) to the callback data. That would satisfy
any backwards compatibility concerns and my use case too!
If you are suggesting that the server poke data into the notifier's opaque
payload, I vot
Joachim Wieland writes:
> However, if for some reason we cannot write to the slru files in the
> pg_notify/
> directory we might want to roll back the current transaction but with the
> proposed patch we cannot because we have already committed...
I think this is a deal-breaker, and arguing abou
On Nov 11, 2009, at 9:28 PM, Merlin Moncure wrote:
On Wed, Nov 11, 2009 at 5:48 PM, A.M.
wrote:
At least with this new payload, I can set the payload to the
transaction ID
and be certain that all the notifications I sent are processed
(and in order
even!) but could you explain why the co
Fujii Masao writes:
> Should the standby also have to follow the WAL rule during recovery?
> The current patch doesn't care about the write order of the data page
> and WAL in the standby. So, after both servers fail, restarting the
> ex-standby by itself might corrupt the data.
Surely the receiv
On Wed, Nov 11, 2009 at 5:27 PM, Robert Haas wrote:
> On Wed, Nov 11, 2009 at 5:14 PM, Greg Smith wrote:
>> Selena Deckelmann wrote:
>>
>> On Tue, Nov 10, 2009 at 10:40 PM, Greg Smith wrote:
>>
>>
>> I was just poking around on the Wiki, and it looks like the role of the
>> CommitFest manager is
Hi,
Should the standby also have to follow the WAL rule during recovery?
The current patch doesn't care about the write order of the data page
and WAL in the standby. So, after both servers fail, restarting the
ex-standby by itself might corrupt the data.
If the standby follows the WAL rule, walr
On Wed, Nov 11, 2009 at 5:48 PM, A.M. wrote:
> At least with this new payload, I can set the payload to the transaction ID
> and be certain that all the notifications I sent are processed (and in order
> even!) but could you explain why the coalescing is still necessary?
Christmas comes early thi
Premature optimization is the root of all evil ;-). Unless you've done
some profiling and can show that this is a hot spot, making it more
complicated isn't the thing to be doing now.
I'm thinking of how our system uses/abuses notifies, and began wondering
if several thousand backends liste
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> I think you could probably just change it: make DISTINCT work as
> Tom> per regular DISTINCT (treat null like a value, keep one copy).
> Tom> All the spec-conforming aggregates are strict and would ignore
> Tom> the null in the next ste
> "Tom" == Tom Lane writes:
> Andrew Gierth writes:
>> Now the question: If the limit of one argument for DISTINCT aggs were
>> removed (which I'm considering doing as part of an update to the
>> aggregate ORDER BY patch I posted a while back), what should be the
>> behaviour of agg(dis
On Wed, Nov 11, 2009 at 12:50 PM, Sergey Konoplev wrote:
> Was this situation mentioned before and is there a solution or
> workaround? (I didn't find any) If not please give me a glue where to
> dig or what information should I provide?
I think you should use log_min_duration_statement or auto_e
Andrew Gierth writes:
> Now the question: If the limit of one argument for DISTINCT aggs were
> removed (which I'm considering doing as part of an update to the
> aggregate ORDER BY patch I posted a while back), what should be the
> behaviour of agg(distinct x,y) where one or both of x or y is nul
Quoth the comments in nodeAgg.c:
* We don't currently implement DISTINCT aggs for aggs having more
* than one argument. This isn't required for anything in the SQL
* spec, but really it ought to be implemented for
* feature-completeness. FIXME someday.
and:
* DISTINCT always suppresses nu
> We can use an INSERT trigger to route tuples into partitions even now.
> Why do you need an additional router for COPY? Also, it would be nicer
> that the router can works not only in COPY but also in INSERT.
Yeah, but performance on an insert trigger is impractical for large
volumes of data.
> "Martijn" == Martijn van Oosterhout writes:
>> Hi,
>>
>> Attached is a patch for a new listen/notify implementation.
>>
>> In a few words, the patch reimplements listen/notify as an
>> slru-based queue which works similar to the sinval
>> structure. Essentially it is a ring buffer
Emmanuel Cecchet wrote:
> If you look at the code you will see that you can do optimizations in
> the COPY code that you cannot do in the trigger.
Since the optimizations is nice, I hope it will work not only in COPY
but also in INSERT. An idea is moving the partitioning cache into
Relation ca
Andrew Chernow writes:
> + * This function is executed for every notification found in the queue in
> order
> + * to check if the current backend is listening on that channel. Not sure
> if we
> + * should further optimize this, for example convert to a sorted array and
> + * allow binary se
Joachim Wieland wrote:
On Thu, Nov 12, 2009 at 1:04 AM, Andrew Chernow wrote:
I think a bsearch would be needed. Very busy servers that make heavy use of
notifies would be quite a penalty.
In such an environment, how many relations/channels is a backend
typically listening to?
Do you have av
Hi,
I have extracted the partitioning option for COPY (removed the error
logging part) from the previous patch.
We can use an INSERT trigger to route tuples into partitions even now.
Why do you need an additional router for COPY?
Tom has already explained on the list why using a trigger w
Peter Eisentraut writes:
> Is it at all reasonable to try to create some mechanism so that
> exceptions (elog) that are caught and not rethrown do not end up in the
> log? For example, when you write code that does something like
> try
> insert
> catch unique_constraint_violation
> updat
On Thu, Nov 12, 2009 at 1:04 AM, Andrew Chernow wrote:
> I think a bsearch would be needed. Very busy servers that make heavy use of
> notifies would be quite a penalty.
In such an environment, how many relations/channels is a backend
typically listening to?
Do you have average / maximal numbers
Emmanuel Cecchet wrote:
> I have extracted the partitioning option for COPY (removed the error
> logging part) from the previous patch.
We can use an INSERT trigger to route tuples into partitions even now.
Why do you need an additional router for COPY? Also, it would be nicer
that the router
Tom Lane wrote:
> I think this is an artifact of the fact that SQL functions parse the
> whole querystring before executing any of it. Parsing of "DELETE FROM
> a" will result in acquiring ROW EXCLUSIVE lock on a, and then when the
> LOCK commands are executed, you have a lock-upgrade scenario
/*
+ * This function is executed for every notification found in the queue in
order
+ * to check if the current backend is listening on that channel. Not sure if
we
+ * should further optimize this, for example convert to a sorted array and
+ * allow binary search on it...
+ */
+ static b
On 11/11/09 12:55 PM, Greg Smith wrote:
> I seriously doubt you're going to find a new committer
> jumping right in by committing hot standby out of the gate just because
> they could do so.
>
We'd be lucky to get them to *read* the Hot Standby patch and comment on it.
--Josh Berkus
--
Sent
Robert Haas escreveu:
> I think an automatic system would probably not be too valuable
>
I have the same impression.
> It's easy to generate systems that spew out a lot of email, but the
> system doesn't really have any understanding of what is really going
> on. When I send out emails to nag pe
2. adds the possibility to specify a payload parameter, i.e. executing
in SQL
"NOTIFY foo 'payload';" and 'payload' will be delivered to any
listening
backend.
Thank you for implementing this- LISTEN/NOTIFY without a payload has
been a major problem to work around for me.
+1
--
Andre
On Nov 11, 2009, at 4:25 PM, Joachim Wieland wrote:
Hi,
Attached is a patch for a new listen/notify implementation.
In a few words, the patch reimplements listen/notify as an slru-
based queue
which works similar to the sinval structure. Essentially it is a
ring buffer on
disk with pages
On Wed, Nov 11, 2009 at 10:25:05PM +0100, Joachim Wieland wrote:
> Hi,
>
> Attached is a patch for a new listen/notify implementation.
>
> In a few words, the patch reimplements listen/notify as an slru-based queue
> which works similar to the sinval structure. Essentially it is a ring buffer
>
On Wed, Nov 11, 2009 at 5:14 PM, Greg Smith wrote:
> Selena Deckelmann wrote:
>
> On Tue, Nov 10, 2009 at 10:40 PM, Greg Smith wrote:
>
>
> I was just poking around on the Wiki, and it looks like the role of the
> CommitFest manager isn't very well documented yet.
>
>
> It's pretty straightforwar
On Wed, Nov 11, 2009 at 5:06 PM, Jaime Casanova
wrote:
> On Wed, Nov 11, 2009 at 4:40 PM, Robert Haas wrote:
>> On Wed, Nov 11, 2009 at 4:21 PM, Jaime Casanova
>> wrote:
>>> why we need a full time manager at all?
>>> why not simply use -rrreviewers to track the status of a patch? of
>>> course,
Selena Deckelmann wrote:
On Tue, Nov 10, 2009 at 10:40 PM, Greg Smith wrote:
I was just poking around on the Wiki, and it looks like the role of the
CommitFest manager isn't very well documented yet.
It's pretty straightforward. Robert has actually done a great job of
communicating ab
On Wed, Nov 11, 2009 at 4:40 PM, Robert Haas wrote:
> On Wed, Nov 11, 2009 at 4:21 PM, Jaime Casanova
> wrote:
>> why we need a full time manager at all?
>> why not simply use -rrreviewers to track the status of a patch? of
>> course, we hope the author or reviewer to change the status as
>> appr
Selena,
> I'd be happy to get together at some pre-appointed hour this weekend
> (Saturday / Sunday) to talk it over by phone / IRC. PDXPUG was already
> planning to get together to review some patches this Sunday from 3-5pm
> PST, so that is a convenient time for me.
Aren't you running OpenSQL t
Peter Eisentraut writes:
> On fre, 2009-10-30 at 00:49 -0400, Tom Lane wrote:
>> And this is a problem why exactly? It's entirely likely that
>> employee-ness can be determined just from what is visible in
>> the persons view, anyway. Not to mention tableoid.
> Yeah, tableoid is a deal-breaker.
Bruce Momjian wrote:
I also think the bad economy is making it harder for people/companies to
devote time to community stuff when paid work is available.
I think this explains away more of the recent situation than you're
giving it credit for. When everybody's fat and happy and it's easy to
On Wed, Nov 11, 2009 at 4:21 PM, Jaime Casanova
wrote:
> why we need a full time manager at all?
> why not simply use -rrreviewers to track the status of a patch? of
> course, we hope the author or reviewer to change the status as
> appropiate but we have seen many people including missing discuss
Is it at all reasonable to try to create some mechanism so that
exceptions (elog) that are caught and not rethrown do not end up in the
log? For example, when you write code that does something like
try
insert
catch unique_constraint_violation
update
end try
this will end up cluttering t
On Wed, Nov 11, 2009 at 3:57 PM, Greg Smith wrote:
> Robert Haas wrote:
>>
>> I tried to help, but I was fairly tied up with overall CommitFest
>> management and
>> did not have time for a full read-through of every patch.
>>
>
> I think it's completely unreasonable to expect the CF manager to do
On Sun, Nov 8, 2009 at 8:52 PM, Robert Haas wrote:
> The next CommitFest is scheduled to start in a week. So far, it
> doesn't look too bad, though a lot could change between now and then.
>
> I would personally prefer not to be involved in the management of the
> next CommitFest. Having done al
On fre, 2009-10-30 at 00:49 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > There is a gap in the permission scheme for inheritance setups. Say you
> > have this:
>
> > CREATE TABLE persons (...);
> > CREATE TABLE employees (...) INHERITS (persons);
>
> > GRANT SELECT ON persons TO foo;
>
Selena Deckelmann wrote:
Hi!
On Tue, Nov 10, 2009 at 10:40 PM, Greg Smith wrote:
On Sun, 8 Nov 2009, Robert Haas wrote:
I would personally prefer not to be involved in the management of the
next CommitFest. Having done all of the July CommitFest and a good
chunk of the September CommitFest,
Robert Haas wrote:
I tried to help, but I was fairly tied up with overall CommitFest management and
did not have time for a full read-through of every patch.
I think it's completely unreasonable to expect the CF manager to do any
patch review themselves. It's a hard enough job to keep going
Bruce Momjian wrote:
True, but even I avoid patches I don't understand, and "practicing" by
applying them could lead to a very undesirable outcome, e.g.
instability.
The usual type of practice here should come from applying trivial
patches, or ones that don't impact code quality. Docs patche
On Wed, Nov 11, 2009 at 2:51 PM, Bruce Momjian wrote:
> Josh Berkus wrote:
>>
>> > For example, probably only Simon and Heikki are knowledge enough to
>> > apply the HS and SR patchs --- but those patch is handled. The harder
>> > part is the other patches where there are only a small pool of peo
Boszormenyi Zoltan escribió:
> 2) 1b-cursor_name-ctxdiff.patch
>
> "name" -> "cursor_name" transition in core grammar
> and ecpg grammar. Currently it does nothing, it's a
> preparation phase. Depends on patch 1.
Applied this part too.
I cannot apply the other ones -- they belong to the ECPG ma
On Wed, Nov 11, 2009 at 12:45 PM, Peter Eisentraut wrote:
> The patches that get sent in are almost always
> either fallout from a customer/company project, or stuff that one of the
> closed-sourced forks has developed that they don't want to maintain, or
> stuff people do "at night" to make their
Rick Gigger wrote:
> Couldn't you have a policy that every patch is reviewed first by someone who
> wants to be an expert in that area, and then by someone who is currently an
> expert. Then you have the best of both worlds. The patch is reviewed by
> someone will make sure it won't cause prob
Couldn't you have a policy that every patch is reviewed first by someone who
wants to be an expert in that area, and then by someone who is currently an
expert. Then you have the best of both worlds. The patch is reviewed by
someone will make sure it won't cause problems, and the want to be ex
Tom Lane escribió:
> Alvaro Herrera writes:
> > I have applied this patch after some tinkering.
>
> Shouldn't there be a docs change in that commit?
True -- fixed.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
> True, but even I avoid patches I don't understand, and "practicing" by
> applying them could lead to a very undesirable outcome, e.g.
> instability.
Right, but being responsible for applying the patch is the only real
incentive anyone has to learn enough to understand its effects. If a
contrib
Josh Berkus wrote:
>
> > For example, probably only Simon and Heikki are knowledge enough to
> > apply the HS and SR patchs --- but those patch is handled. The harder
> > part is the other patches where there are only a small pool of people
> > knowledgeable enough to apply the patch, but many of
> For example, probably only Simon and Heikki are knowledge enough to
> apply the HS and SR patchs --- but those patch is handled. The harder
> part is the other patches where there are only a small pool of people
> knowledgeable enough to apply the patch, but many of those knowledgeable
> people
Alvaro Herrera writes:
> I have applied this patch after some tinkering.
Shouldn't there be a docs change in that commit?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.
Boszormenyi Zoltan escribió:
> I have split up (and cleaned up a little) the dynamic
> cursorname patch into smaller logical, easier-to-review
> pieces. Descriptions below.
>
> 1) 1a-unified-optfromin-fetch-ctxdiff.patch
>
> ecpg supports optional FROM/IN in FETCH and
> MOVE statements (mainly b
Josh Berkus wrote:
> Bruce,
>
> Well, I think the answer is to promote some new committers. When was
> the last time we added a committer?
>
> We have added a bunch of new reviewers and major contributors over the
> last 2 years. It's time to review their work and see who can be
> promoted to m
Bruce,
Well, I think the answer is to promote some new committers. When was
the last time we added a committer?
We have added a bunch of new reviewers and major contributors over the
last 2 years. It's time to review their work and see who can be
promoted to more responsibility for other people
>> Let's NOT start that discussion again.
>
> Bruce's comments were a useful addition to the technical discussion.
Yes, I'm just trying to avoid sidelining this into a discussion of
search_path management commands, which we already failed to come to a
consensus spec for earlier this year. Not
Peter Eisentraut wrote:
> On ons, 2009-11-11 at 10:25 -0500, Bruce Momjian wrote:
> > There is a more worrisome/sinister possibility that I didn't want to
> > mention in my first email --- that companies are hiring our most
> > experienced developers and having them work almost exclusively on
> > c
Hello community,
Second time after migration 8.3.7 --> 8.4.1 I was caught by this
problem. Migration was 8 days ago.
(note, I never seen such situation on 8.3)
Environment:
PostgreSQL 8.4.1 + patch
http://archives.postgresql.org/pgsql-committers/2009-10/msg00056.php
CentOS release 5.4 (Final)
S
On ons, 2009-11-11 at 10:25 -0500, Bruce Momjian wrote:
> There is a more worrisome/sinister possibility that I didn't want to
> mention in my first email --- that companies are hiring our most
> experienced developers and having them work almost exclusively on
> company-related or closed-source pr
Hi!
On Tue, Nov 10, 2009 at 10:40 PM, Greg Smith wrote:
> On Sun, 8 Nov 2009, Robert Haas wrote:
>
>> I would personally prefer not to be involved in the management of the
>> next CommitFest. Having done all of the July CommitFest and a good
>> chunk of the September CommitFest, I am feeling a b
Hi all,
I have extracted the partitioning option for COPY (removed the error
logging part) from the previous patch. The documentation and test suite
sample are provided as well.
More details are on the wiki page at
http://wiki.postgresql.org/wiki/Auto-partitioning_in_COPY. Ignore the
error lo
bruce wrote:
> This brings up a concern I have --- that the number of patch
> committers/managers is decreasing while our patch volume is increasing.
> Consider that Heikki is working mostly on Hot Standby and Streaming
> Replication, Alvaro isn't as involved in applying patches, Neil Conway
> isn
On Wed, 2009-11-11 at 12:35 +0200, Heikki Linnakangas wrote:
> While reading through the patch for what must be the 100th time by now,
:-)
> it occurred to me that this comment in heap_xlog_freeze:
>
> + /*
> +* Freezing tuples does not require conflict processing
> +*/
>
Itagaki Takahiro writes:
> I encountered the following log in 8.4.1 and HEAD. The deadlock occured
> on the same object (relation 17498 of database 17497). Is it reasonable?
I think this is an artifact of the fact that SQL functions parse the
whole querystring before executing any of it. Parsing
Jaime Casanova writes:
> I was using auto_explain to log plans (with analyze option on) from
> queries that take more than 500ms, something i found i little odd is
> that the duration says 779ms but actual time says 269ms (almost 3
> times lower), maybe some kind of instrumentation cleanup can exp
On Tue, 2009-11-10 at 15:11 -0500, Michael Glaesemann wrote:
> I skimmed through the documentation to get a better handle on what
> this will mean.
Thanks for this and any further corrections/additions.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (p
On Tue, 2009-11-10 at 22:00 +0200, Devrim GÜNDÜZ wrote:
> On Tue, 2009-11-10 at 20:36 +0200, Heikki Linnakangas wrote:
> > Attached is the latest and greatest patch against CVS head, taken from
> > the hs-riggs branch in my git repository.
>
> Is there a reason why recovery.conf.sample does not in
On Tue, 2009-11-10 at 20:14 -0800, Josh Berkus wrote:
> On 11/10/09 5:59 AM, Bruce Momjian wrote:
> > Simon Riggs wrote:
> >> All of this *also* applies to shared_preload_libraries. We also need to
> >> be able to specify new load libraries without editing the same darn
> >> parameter.
> >
> > And
Tom Lane wrote:
>> The problem is that both _LARGE_FILES and _LARGE_FILE_API are #defined
>> in this case, which makes #include fail.
>> Does anyone have an idea how to best fix this problem in the
>> source tree? I'm willing to implement and test.
>
> I've committed changes for this in CVS, plea
While reading through the patch for what must be the 100th time by now,
it occurred to me that this comment in heap_xlog_freeze:
+ /*
+* Freezing tuples does not require conflict processing
+*/
is plain wrong. In the master, we can freeze the xmin of a tuple that's
not yet v
Devrim GÜNDÜZ wrote:
> Is there a reason why recovery.conf.sample does not include (sample)
> entries for recovery_connections and max_standby_delay?
No, they probably should be included. I'll add them, thanks.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pg
83 matches
Mail list logo
