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
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
Robert Haas 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, and the others are c
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
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
CommitFes
> 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 Fri, Feb 25, 2011 at 5:21 PM, Josh Berkus 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 of their
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?
>
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 failov
On Fri, Feb 25, 2011 at 4:36 PM, Josh Berkus 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 case is t
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
On Fri, Feb 25, 2011 at 3:44 PM, Josh Berkus 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 think that's
> 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, n
On Fri, Feb 25, 2011 at 2:33 PM, Daniel Farina 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 inspection.
I believ
On Fri, Feb 25, 2011 at 4:43 AM, Robert Haas wrote:
> On Fri, Feb 25, 2011 at 3:14 AM, Daniel Farina wrote:
>> On Wed, Feb 23, 2011 at 11:49 AM, Greg Smith wrote:
>>> Robert Haas wrote:
>
> 2. Synchronous replication. Splitting up this patch has allowed some
>>> On top of 4 listed revie
On Fri, Feb 25, 2011 at 5:25 AM, marcin mank wrote:
> On Fri, Feb 25, 2011 at 9:14 AM, Daniel Farina 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 ca
On Fri, Feb 25, 2011 at 9:14 AM, Daniel Farina 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` up, replicat
On Fri, Feb 25, 2011 at 3:14 AM, Daniel Farina wrote:
> On Wed, Feb 23, 2011 at 11:49 AM, Greg Smith 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 w
On Wed, Feb 23, 2011 at 11:49 AM, Greg Smith 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 already show
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 a
On Wed, Feb 23, 2011 at 1:34 PM, Alvaro Herrera
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
>> wrote:
>> > Excerpts from Robert Haas's message of mié feb 23 14:54:02 -0300 2011:
>> >> On Fri, Feb 18, 2011 at 5:
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
> 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 wrote:
> >
> >> > 16. synchronized snapsho
On Wed, Feb 23, 2011 at 1:05 PM, Alvaro Herrera
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 wrote:
>
>> > 16. synchronized snapshots. Alvaro is working on this one.
>>
>> Lots of discussion of this one, but curre
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 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 you working on th
On Fri, Feb 18, 2011 at 5:47 PM, Robert Haas 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 backwards. We
> don'
On Fri, Feb 18, 2011 at 6:04 PM, Tom Lane 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 are read in the d
Josh Berkus 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, people woul
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 w
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 f
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
Robert Haas 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 work. The file_fdw
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. It's
32 matches
Mail list logo
