Looking over the remaining patches that still aren't closed in the
January CommitFest:
Foreign keys with arrays - Tom wants to commit this at the beginning
of a release cycle rather than the end, but there's no actual known
problem with it. Therefore I suggest moving it to the first 9.3
On 04/10/2012 09:40 AM, Robert Haas wrote:
parallel pg_dump - I think this one needs to get moved to the first
9.3 CommitFest. There is more work to be done there than we can
realistically do right now, but I think we can pick it up for the next
cycle.
Yeah, I'm only about 1/4 of the way
Robert Haas robertmh...@gmail.com writes:
Looking over the remaining patches that still aren't closed in the
January CommitFest:
[ all but ECPG readahead and maybe libpq URIs have to go to 9.3 ]
Yeah, I agree. I'm not comfortable with squeezing in the array foreign
keys stuff at this point,
On Tue, Apr 10, 2012 at 09:40:58AM -0400, Robert Haas wrote:
ECPG FETCH readahead - Michael Meskes is going to commit this soon;
everyone seems to agree it's ready to go.
It still needs a couple minor tweaks but I think it will be done shortly.
Michael
--
Michael Meskes
Michael at Fam-Meskes
Excerpts from Robert Haas's message of mar abr 10 10:40:58 -0300 2012:
URI connection string support for libpq - I'm unclear with Alvaro or
Peter still intend to try to slip this one in. It's simple enough
that I think that would be OK if it can be done in the next day or
two. Otherwise,
That would be nice; I'm basically abusing syncrep to this purpose. At
the same time, someone may need to be notified of such a switchover
occurring, and in event of failure, it'd be nice to bounce back to the
primary. Tangentially relevent, Virtual IP is not always an option,
such as on
On Wed, Feb 23, 2011 at 11:49 AM, Greg Smith g...@2ndquadrant.com wrote:
Robert Haas wrote:
2. Synchronous replication. Splitting up this patch has allowed some
On top of 4 listed reviewers I know Dan Farina is poking at the last update,
so we may see one more larger report on top of what's
On Fri, Feb 25, 2011 at 3:14 AM, Daniel Farina dan...@heroku.com wrote:
On Wed, Feb 23, 2011 at 11:49 AM, Greg Smith g...@2ndquadrant.com wrote:
Robert Haas wrote:
2. Synchronous replication. Splitting up this patch has allowed some
On top of 4 listed reviewers I know Dan Farina is poking at
On Fri, Feb 25, 2011 at 9:14 AM, Daniel Farina dan...@heroku.com wrote:
Right now, as it stands, the syncrep patch will be happy as soon as
the data has been fsynced to either B or A-prime; I don't think we can
guarantee at any point that A-prime can become the leader, and feed B.
- start A`
On Fri, Feb 25, 2011 at 5:25 AM, marcin mank marcin.m...@gmail.com wrote:
On Fri, Feb 25, 2011 at 9:14 AM, Daniel Farina dan...@heroku.com wrote:
Right now, as it stands, the syncrep patch will be happy as soon as
the data has been fsynced to either B or A-prime; I don't think we can
On Fri, Feb 25, 2011 at 4:43 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Feb 25, 2011 at 3:14 AM, Daniel Farina dan...@heroku.com wrote:
On Wed, Feb 23, 2011 at 11:49 AM, Greg Smith g...@2ndquadrant.com wrote:
Robert Haas wrote:
2. Synchronous replication. Splitting up this patch
On Fri, Feb 25, 2011 at 2:33 PM, Daniel Farina dan...@heroku.com wrote:
I know I got hit by a backend synchronization (in the sense of locks,
etc) bugs; do you think it is possible yours (sending SIGSTOP) could
be the same root cause? I haven't followed all the other bugs cleared
up by
Right now, as it stands, the syncrep patch will be happy as soon as
the data has been fsynced to either B or A-prime; I don't think we can
guarantee at any point that A-prime can become the leader, and feed B.
Yeah, I think that's something we said months ago is going to be a 9.2
feature, no
On Fri, Feb 25, 2011 at 3:44 PM, Josh Berkus j...@agliodbs.com wrote:
Right now, as it stands, the syncrep patch will be happy as soon as
the data has been fsynced to either B or A-prime; I don't think we can
guarantee at any point that A-prime can become the leader, and feed B.
Yeah, I
Daniel,
Ah, okay, I had missed that discussion, I also did not know it got so
specific as to address this case (are you sure?) rather than something
more general, say quorum or N-safe durability.
The way we address that case is through n-safe durability.
The user may have their own level of
On Fri, Feb 25, 2011 at 4:36 PM, Josh Berkus j...@agliodbs.com wrote:
Daniel,
Ah, okay, I had missed that discussion, I also did not know it got so
specific as to address this case (are you sure?) rather than something
more general, say quorum or N-safe durability.
The way we address that
On Fri, 2011-02-25 at 15:44 -0800, Josh Berkus wrote:
Hmmm, I don't follow this. The user can only disable syncrep for their
own transactions. If they don't care about the persistence of their
transaction post-failover, why should the DBA care?
I think that's the difference between failover
On 2/25/11 4:57 PM, Jeff Davis wrote:
On Fri, 2011-02-25 at 15:44 -0800, Josh Berkus wrote:
Hmmm, I don't follow this. The user can only disable syncrep for their
own transactions. If they don't care about the persistence of their
transaction post-failover, why should the DBA care?
I
On Fri, Feb 25, 2011 at 5:21 PM, Josh Berkus j...@agliodbs.com wrote:
On 2/25/11 4:57 PM, Jeff Davis wrote:
On Fri, 2011-02-25 at 15:44 -0800, Josh Berkus wrote:
Hmmm, I don't follow this. The user can only disable syncrep for their
own transactions. If they don't care about the persistence
On Fri, Feb 18, 2011 at 5:47 PM, Robert Haas robertmh...@gmail.com wrote:
The CommitFest application currently reflects 17 remaining patches for
CommitFest 2011-01.
Now we're down to 12. As usual, the last few patches take the longest...
1. Change pg_last_xlog_receive_location not to move
Excerpts from Robert Haas's message of mié feb 23 14:54:02 -0300 2011:
On Fri, Feb 18, 2011 at 5:47 PM, Robert Haas robertmh...@gmail.com wrote:
16. synchronized snapshots. Alvaro is working on this one.
Lots of discussion of this one, but current status is not clear to me.
Alvaro, are
On Wed, Feb 23, 2011 at 1:05 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mié feb 23 14:54:02 -0300 2011:
On Fri, Feb 18, 2011 at 5:47 PM, Robert Haas robertmh...@gmail.com wrote:
16. synchronized snapshots. Alvaro is working on this one.
Lots
Excerpts from Robert Haas's message of mié feb 23 15:14:04 -0300 2011:
On Wed, Feb 23, 2011 at 1:05 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mié feb 23 14:54:02 -0300 2011:
On Fri, Feb 18, 2011 at 5:47 PM, Robert Haas robertmh...@gmail.com
On Wed, Feb 23, 2011 at 1:34 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mié feb 23 15:14:04 -0300 2011:
On Wed, Feb 23, 2011 at 1:05 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mié feb 23 14:54:02
Robert Haas wrote:
2. Synchronous replication. Splitting up this patch has allowed some
This has gotten a bunch of review, on several different threads. I
assume Simon will publish an update when he gets back to his
keyboard...
That was the idea. If anyone has any serious concerns
The CommitFest application currently reflects 17 remaining patches for
CommitFest 2011-01.
1. Change pg_last_xlog_receive_location not to move backwards. We
don't have complete consensus on what to do here. If we can agree on
a way forward, I think we can finish this one up pretty quickly.
Robert Haas robertmh...@gmail.com writes:
3, 4, 5. SQL/MED. Tom has picked up the main FDW API patch, which I
expect means it'll go in. I am not so sure about the FDW patches,
though: in particular, based on Heikki's comments, the postgresql_fdw
patch seems to be badly in need of some more
On 2/18/11 2:47 PM, Robert Haas wrote:
The CommitFest application currently reflects 17 remaining patches for
CommitFest 2011-01.
I'm impressed, actually. This is way further along than I expected us
to be.
--
-- Josh Berkus
On 2/18/11 3:04 PM, Tom Lane wrote:
postgresql_fdw may have to live as an external project for the 9.1
cycle, unless it's in much better shape than you suggest above.
I won't feel too bad about that as long as the core support exists.
More than likely, people would want to improve it on a
On 02/18/2011 05:47 PM, Robert Haas wrote:
3, 4, 5. SQL/MED. Tom has picked up the main FDW API patch, which I
expect means it'll go in. I am not so sure about the FDW patches,
though: in particular, based on Heikki's comments, the postgresql_fdw
patch seems to be badly in need of some more
Josh Berkus j...@agliodbs.com writes:
On 2/18/11 3:04 PM, Tom Lane wrote:
postgresql_fdw may have to live as an external project for the 9.1
cycle, unless it's in much better shape than you suggest above.
I won't feel too bad about that as long as the core support exists.
More than likely,
On Fri, Feb 18, 2011 at 6:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
FWIW, my thought is to try to get the API patch committed and then do
the file_fdw patch. Maybe I'm hopelessly ASCII-centric, but I do not
see encoding considerations as a blocking factor for this. If we define
that files
32 matches
Mail list logo
