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
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
Tom Lane wrote:
The problem is that both _LARGE_FILES and _LARGE_FILE_API are #defined
in this case, which makes #include unistd.h 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,
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 to
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 include
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
Jaime Casanova jcasa...@systemguards.com.ec 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
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp 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
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
+*/
is
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't
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
Hi!
On Tue, Nov 10, 2009 at 10:40 PM, Greg Smith gsm...@gregsmith.com 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
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
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)
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
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
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
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 more
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 because
Alvaro Herrera alvhe...@commandprompt.com 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
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 are
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 those
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
contributor
Tom Lane escribió:
Alvaro Herrera alvhe...@commandprompt.com 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 -
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
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
On Wed, Nov 11, 2009 at 12:45 PM, Peter Eisentraut pete...@gmx.net 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
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 maintainer.
On Wed, Nov 11, 2009 at 2:51 PM, Bruce Momjian br...@momjian.us 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
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 patches
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
Selena Deckelmann wrote:
Hi!
On Tue, Nov 10, 2009 at 10:40 PM, Greg Smith gsm...@gregsmith.com 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
On fre, 2009-10-30 at 00:49 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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
On Sun, Nov 8, 2009 at 8:52 PM, Robert Haas robertmh...@gmail.com 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
On Wed, Nov 11, 2009 at 3:57 PM, Greg Smith g...@2ndquadrant.com 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
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
On Wed, Nov 11, 2009 at 4:21 PM, Jaime Casanova
jcasa...@systemguards.com.ec 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
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
Peter Eisentraut pete...@gmx.net 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
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 this
On Wed, Nov 11, 2009 at 4:40 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Nov 11, 2009 at 4:21 PM, Jaime Casanova
jcasa...@systemguards.com.ec 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
Selena Deckelmann wrote:
On Tue, Nov 10, 2009 at 10:40 PM, Greg Smith gsm...@gregsmith.com 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
On Wed, Nov 11, 2009 at 5:06 PM, Jaime Casanova
jcasa...@systemguards.com.ec wrote:
On Wed, Nov 11, 2009 at 4:40 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Nov 11, 2009 at 4:21 PM, Jaime Casanova
jcasa...@systemguards.com.ec wrote:
why we need a full time manager at all?
why not
On Wed, Nov 11, 2009 at 5:14 PM, Greg Smith g...@2ndquadrant.com wrote:
Selena Deckelmann wrote:
On Tue, Nov 10, 2009 at 10:40 PM, Greg Smith gsm...@gregsmith.com wrote:
I was just poking around on the Wiki, and it looks like the role of the
CommitFest manager isn't very well documented
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
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
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
--
Andrew
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
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
/*
+ * 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
Tom Lane t...@sss.pgh.pa.us 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
Emmanuel Cecchet m...@asterdata.com 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
On Thu, Nov 12, 2009 at 1:04 AM, Andrew Chernow a...@esilo.com 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 /
Peter Eisentraut pete...@gmx.net 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
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
Joachim Wieland wrote:
On Thu, Nov 12, 2009 at 1:04 AM, Andrew Chernow a...@esilo.com 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?
Andrew Chernow a...@esilo.com 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
Emmanuel Cecchet m...@asterdata.com 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
Martijn == Martijn van Oosterhout klep...@svana.org 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 on
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.
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
Andrew Gierth and...@tao11.riddles.org.uk 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
On Wed, Nov 11, 2009 at 12:50 PM, Sergey Konoplev gray...@gmail.com 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
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Andrew Gierth and...@tao11.riddles.org.uk 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
Andrew Gierth and...@tao11.riddles.org.uk writes:
Tom == Tom Lane t...@sss.pgh.pa.us 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
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
On Wed, Nov 11, 2009 at 5:48 PM, A.M. age...@themactionfaction.com 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?
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,
On Wed, Nov 11, 2009 at 5:27 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Nov 11, 2009 at 5:14 PM, Greg Smith g...@2ndquadrant.com wrote:
Selena Deckelmann wrote:
On Tue, Nov 10, 2009 at 10:40 PM, Greg Smith gsm...@gregsmith.com wrote:
I was just poking around on the Wiki, and it
Fujii Masao masao.fu...@gmail.com 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.
On Nov 11, 2009, at 9:28 PM, Merlin Moncure wrote:
On Wed, Nov 11, 2009 at 5:48 PM, A.M.
age...@themactionfaction.com 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
Joachim Wieland j...@mcknight.de 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
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
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
Andrew Chernow a...@esilo.com 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
On Thu, Nov 12, 2009 at 12:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com 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
On Nov 11, 2009, at 10:43 PM, Tom Lane wrote:
Andrew Chernow a...@esilo.com 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
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
Tom == Tom Lane t...@sss.pgh.pa.us 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.
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
and if
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
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 inclined to
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 do
83 matches
Mail list logo
