Re: [HACKERS] disposition of remaining patches

2012-04-10 Thread Andrew Dunstan



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 through it :-(

cheers

andrerw

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] disposition of remaining patches

2012-04-10 Thread Tom Lane
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, and the others are clearly not ready.

I put the buffer I/O timing units issue on the open-items list
yesterday:
http://wiki.postgresql.org/wiki/PostgreSQL_9.2_Open_Items
and I encourage people to start using that to track must-fix-for-9.2
items.

We should at this point be focusing our efforts on getting a beta out.
Some but perhaps not all of the open items have to be resolved before
beta1, and we definitely need at least draft-quality release notes
so beta testers know what to test.  Any other must-do tasks out there?

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] disposition of remaining patches

2012-04-10 Thread Michael Meskes
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 dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at googlemail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] disposition of remaining patches

2012-04-10 Thread Alvaro Herrera

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, 9.3.

I intend to commit this today, unless someone is still unhappy with the
choice of syntax.

-- 
Álvaro Herrera alvhe...@commandprompt.com
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] disposition of remaining patches

2011-02-26 Thread Josh Berkus

 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 Amazon EC2.

Well, let's comprehensively address replication in a cloud environment
for 9.2.  You can start a wiki page.

-- 
  -- Josh Berkus
 PostgreSQL Experts Inc.
 http://www.pgexperts.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] disposition of remaining patches

2011-02-25 Thread Daniel Farina
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 already shown up.  And
 Jaime keeps kicking the tires too.  What Simon was hoping is that a week of
 others looking at this would produce enough feedback that it might be
 possible to sweep the remaining issues up soon after he's back.  It looks to
 me like that's about when everything else that's still open will probably
 settle too.

Besides some of the fixable issues, I am going to have to echo
Robert's sentiments about a few kinks that go beyond mechanism in the
syncrep patch: in particular, it will *almost* solve the use case I
was hoping to solve: a way to cleanly perform planned switchovers
between machines with minimal downtime and no lost data. But there are
a couple of holes I have thought of so far:

1. The 2-safe methodology supported is not really compatible with
performing planned-HA-switchover of a cluster with its own syncrep
guarantees on top of that. For example:

Server A syncreps to Server B

Now I want to provision server A-prime, which will eventually take the
place of A.

Server A syncreps to Server B
Server A syncreps to Server A-prime

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.

2. The unprivileged user can disable syncrep, in any situation. This
flexibility is *great*, but you don't really want people to do it when
one is performing the switchover. Rather, in a magical world we'd hope
that disabling syncrep would just result in not having to
synchronously commit to B (but, in this case, still synchronously
commit to A-prime)

In other words, to my mind, you can use syncrep as-is to provide
2-safe durability xor a scheduled switchover: as soon as someone wants
both, I think they'll have some trouble. I do want both, though.

-- 
fdr

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] disposition of remaining patches

2011-02-25 Thread Robert Haas
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 the last update,
 so we may see one more larger report on top of what's already shown up.  And
 Jaime keeps kicking the tires too.  What Simon was hoping is that a week of
 others looking at this would produce enough feedback that it might be
 possible to sweep the remaining issues up soon after he's back.  It looks to
 me like that's about when everything else that's still open will probably
 settle too.

 Besides some of the fixable issues, I am going to have to echo
 Robert's sentiments about a few kinks that go beyond mechanism in the
 syncrep patch: in particular, it will *almost* solve the use case I
 was hoping to solve: a way to cleanly perform planned switchovers
 between machines with minimal downtime and no lost data. But there are
 a couple of holes I have thought of so far:

Well, just because the patch doesn't solve every use case isn't a
reason not to go forward with it - we can always add more options
later - but I have to admit that I'm kind of alarmed about the number
of bugs reported so far.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] disposition of remaining patches

2011-02-25 Thread marcin mank
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` up, replicating from A
- shutdown B (now A nad A` are synchronous)
now real quick:
- shut down A
- shut down A`
-change configuration
-start up A`
-start up B

Doesn`t this work?

Greetings
Marcin

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] disposition of remaining patches

2011-02-25 Thread Daniel Farina
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
 guarantee at any point that A-prime can become the leader, and feed B.


 - start A` up, replicating from A
 - shutdown B (now A nad A` are synchronous)
 now real quick:
 - shut down A
 - shut down A`
 -change configuration
 -start up A`
 -start up B

 Doesn`t this work?

This dance does work, but it would be very nice to not have to take
the standby ('B' in my case) offline.

-- 
fdr

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] disposition of remaining patches

2011-02-25 Thread Daniel Farina
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 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 shown up.  And
 Jaime keeps kicking the tires too.  What Simon was hoping is that a week of
 others looking at this would produce enough feedback that it might be
 possible to sweep the remaining issues up soon after he's back.  It looks to
 me like that's about when everything else that's still open will probably
 settle too.

 Besides some of the fixable issues, I am going to have to echo
 Robert's sentiments about a few kinks that go beyond mechanism in the
 syncrep patch: in particular, it will *almost* solve the use case I
 was hoping to solve: a way to cleanly perform planned switchovers
 between machines with minimal downtime and no lost data. But there are
 a couple of holes I have thought of so far:

 Well, just because the patch doesn't solve every use case isn't a
 reason not to go forward with it - we can always add more options
 later - but I have to admit that I'm kind of alarmed about the number
 of bugs reported so far.

True: the relevance of any use case to acceptance is up to some
debate. I haven't thought about how to remedy this, just thinking
aloud about a problem I would have as-is, and is important to me.  It
is true that later accretion of options can occur, but sometimes the
initial choice of semantics can make growing those easier or harder.
I haven't yet thought ahead as to how the current scheme would impact
that.

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.

-- 
fdr

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] disposition of remaining patches

2011-02-25 Thread Robert Haas
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 inspection.

I believe that the queue management logic is just totally busted and
needs to be rewritten.  I doubt there is much point in speculating
about details until that's done.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] disposition of remaining patches

2011-02-25 Thread Josh Berkus

 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 sooner.

 2. The unprivileged user can disable syncrep, in any situation. This
 flexibility is *great*, but you don't really want people to do it when
 one is performing the switchover. Rather, in a magical world we'd hope
 that disabling syncrep would just result in not having to
 synchronously commit to B (but, in this case, still synchronously
 commit to A-prime)
 
 In other words, to my mind, you can use syncrep as-is to provide
 2-safe durability xor a scheduled switchover: as soon as someone wants
 both, I think they'll have some trouble. I do want both, though.

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?

-- 
  -- Josh Berkus
 PostgreSQL Experts Inc.
 http://www.pgexperts.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] disposition of remaining patches

2011-02-25 Thread Daniel Farina
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 think that's something we said months ago is going to be a 9.2
 feature, no sooner.

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.

 2. The unprivileged user can disable syncrep, in any situation. This
 flexibility is *great*, but you don't really want people to do it when
 one is performing the switchover. Rather, in a magical world we'd hope
 that disabling syncrep would just result in not having to
 synchronously commit to B (but, in this case, still synchronously
 commit to A-prime)

 In other words, to my mind, you can use syncrep as-is to provide
 2-safe durability xor a scheduled switchover: as soon as someone wants
 both, I think they'll have some trouble. I do want both, though.

 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?

The user may have their own level of durability guarantee they want to
attain (that's why machine B is syncrepped in my example), but when
doing the switchover I think an override to enable a smooth handoff
(meaning: everything syncrepped) would be best.  What I want to avoid
is an ack from COMMIT from the primary (machine A), and then, post
switchover, the data isn't there on machine A-Prime (or B, provided
it was able to follow successfully at all, as in the current case it
might get ahead of A-prime in the WAL).

-- 
fdr

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] disposition of remaining patches

2011-02-25 Thread Josh Berkus
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 durability guarantee they want to
 attain (that's why machine B is syncrepped in my example), but when
 doing the switchover I think an override to enable a smooth handoff
 (meaning: everything syncrepped) would be best.  What I want to avoid
 is an ack from COMMIT from the primary (machine A), and then, post
 switchover, the data isn't there on machine A-Prime (or B, provided
 it was able to follow successfully at all, as in the current case it
 might get ahead of A-prime in the WAL).

Yeah, when I think about your use case, I can understand why it's an
issue.  It would be nice to have a superuser setting (or similar) which
could override user preferances and make all transactions synchrep
temporarily.  I'm not sure that's going to be reasonable to do for 9.1
though.

-- 
  -- Josh Berkus
 PostgreSQL Experts Inc.
 http://www.pgexperts.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] disposition of remaining patches

2011-02-25 Thread Daniel Farina
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 case is through n-safe durability.

How is this exposed? The simple count the number of fsyncs()
approach is not quite good enough (one has no control to make sure one
or more nodes are definitely up-to-date) unless one wants to just make
it go to *all* syncrep standys for a while. That seems like overkill;
so I imagine something else is in the thoughts. I'll search the
archives...

 The user may have their own level of durability guarantee they want to
 attain (that's why machine B is syncrepped in my example), but when
 doing the switchover I think an override to enable a smooth handoff
 (meaning: everything syncrepped) would be best.  What I want to avoid
 is an ack from COMMIT from the primary (machine A), and then, post
 switchover, the data isn't there on machine A-Prime (or B, provided
 it was able to follow successfully at all, as in the current case it
 might get ahead of A-prime in the WAL).

 Yeah, when I think about your use case, I can understand why it's an
 issue.  It would be nice to have a superuser setting (or similar) which
 could override user preferances and make all transactions synchrep
 temporarily.  I'm not sure that's going to be reasonable to do for 9.1
 though.

Agreed; I'd be happy to take any syncrep functionality, although it
wouldn't compose well as-is, I wanted to raise this so that we didn't
make any configuration decisions that got in the way of making
composition possible later.  Again, I haven't thought ahead yet,
partially because I thought there may be some existing thoughts in
play to consider.

With that, I will try to give syncrep a more structured review Real
Soon, although the late date of this is leaving me queasy as to the
odds of git-commit.

-- 
fdr

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] disposition of remaining patches

2011-02-25 Thread Jeff Davis
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 and switchover, right? At
least Slony makes such a distinction, as well.

Regards,
Jeff Davis



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] disposition of remaining patches

2011-02-25 Thread Josh Berkus
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 think that's the difference between failover and switchover, right? At
 least Slony makes such a distinction, as well.

Yeah.  Actually, what would be even simpler and more to the point would
be a command that says flush all transactions from Server A to Server
B, then fail over.

-- 
  -- Josh Berkus
 PostgreSQL Experts Inc.
 http://www.pgexperts.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] disposition of remaining patches

2011-02-25 Thread Daniel Farina
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 of their
 transaction post-failover, why should the DBA care?

 I think that's the difference between failover and switchover, right? At
 least Slony makes such a distinction, as well.

 Yeah.  Actually, what would be even simpler and more to the point would
 be a command that says flush all transactions from Server A to Server
 B, then fail over.

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 Amazon EC2.

But I digress. Such a command is unlikely to make it into 9.1; maybe
we can circle around on that in 9.2.

-- 
fdr

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] disposition of remaining patches

2011-02-23 Thread Robert Haas
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 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
 partially being held up by #2.

No change.

 2. Synchronous replication.  Splitting up this patch has allowed some
 progress to be made here, but there is a lot left to do, and I fear
 that trying to hash out the design issues at this late date is not
 going to lead to a great final product.  The proposed timeout to make
 the server boot out clients that don't seem to be responding is not
 worth committing, as it will only work when the server isn't
 generating WAL, which can't be presumed to be the normal state of
 affairs.  The patch to avoid ever letting the WAL sender status go
 backward from catchup to streaming was committed without discussion,
 and needs to be reverted for reasons discussed on that thread.  An
 updated version of the main patch has yet to be posted.

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...

 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 patch
 may be in better shape (I'm not 100% sure), but it needs the encoding
 fix patch Itagaki Takahiro recently proposed.  For this to be
 worthwhile, we presumably need to get at least one FDW committed along
 with the API patch.

The core and file_fdw patches are in; postgresql_fdw is being reworked
by the author.

 6. Writeable CTEs.  Tom said he'd look at this one.
 7. contrib/btree_gist KNN.  Needs updating as a result of the
 extensions patch.  This ball is really in Teodor and Oleg's court.

No change on these.

 8, 9, 10, 11, 12, 13, 14.  PL/python patches.  I believe Peter was
 working on these, but I haven't seen any updates in a while.

Peter committed two of these seven, leaving five to be addressed.

 15. Fix snapshot taking inconsistencies.  Tom said he'd look at this one.

No change on this one.

 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 this actively?

 17. determining client_encoding from client locale.  This is Peter's
 patch.  Peter, are you planning to commit this?

Peter committed this one.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] disposition of remaining patches

2011-02-23 Thread Alvaro Herrera
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 you working on this actively?

I am.  I'm not sure if it's still reasonable to get into 9.1, given that
it needs to be rewritten from almost completely from scratch.

-- 
Álvaro Herrera alvhe...@commandprompt.com
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] disposition of remaining patches

2011-02-23 Thread Robert Haas
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 of discussion of this one, but current status is not clear to me.
  Alvaro, are you working on this actively?

 I am.  I'm not sure if it's still reasonable to get into 9.1, given that
 it needs to be rewritten from almost completely from scratch.

Well, if it gets punted, I won't be too sad, since the pg_dump patch
to actually use this functionality for something useful already got
pushed off.  If you can commit something in a timely fashion that is
also high quality, great, but if not, I don't see it as a
show-stopper.  The highest priorities IMO are writeable CTEs and
synchronous replication.  I doubt that there would be majority support
for prolonging this on the basis of any other single patch, though I
might be wrong about that.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] disposition of remaining patches

2011-02-23 Thread Alvaro Herrera
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 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 this actively?
 
  I am.  I'm not sure if it's still reasonable to get into 9.1, given that
  it needs to be rewritten from almost completely from scratch.
 
 Well, if it gets punted, I won't be too sad, since the pg_dump patch
 to actually use this functionality for something useful already got
 pushed off.

Oh, I thought that patch was committed which is why I was in a bit of a
hurry.  I will mark this one returned with feedback too, then.

-- 
Álvaro Herrera alvhe...@commandprompt.com
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] disposition of remaining patches

2011-02-23 Thread Robert Haas
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 -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 you working on this actively?
 
  I am.  I'm not sure if it's still reasonable to get into 9.1, given that
  it needs to be rewritten from almost completely from scratch.

 Well, if it gets punted, I won't be too sad, since the pg_dump patch
 to actually use this functionality for something useful already got
 pushed off.

 Oh, I thought that patch was committed which is why I was in a bit of a
 hurry.  I will mark this one returned with feedback too, then.

No, the directory archive format patch was committed, but the parallel
pg_dump one got pushed off.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] disposition of remaining patches

2011-02-23 Thread Greg Smith

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 about the current 
patch, please don't hold off just because you know Simon is away for a 
bit.  We've been trying to keep that from impacting community progress 
too badly this week.


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 
shown up.  And Jaime keeps kicking the tires too.  What Simon was hoping 
is that a week of others looking at this would produce enough feedback 
that it might be possible to sweep the remaining issues up soon after 
he's back.  It looks to me like that's about when everything else that's 
still open will probably settle too.


--
Greg Smith   2ndQuadrant USg...@2ndquadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] disposition of remaining patches

2011-02-18 Thread Tom Lane
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 work.  The file_fdw patch
 may be in better shape (I'm not 100% sure), but it needs the encoding
 fix patch Itagaki Takahiro recently proposed.  For this to be
 worthwhile, we presumably need to get at least one FDW committed along
 with the API patch.

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 database encoding, it's still a pretty damn
useful feature.  We can look at whether that can be improved after we
have some kind of feature at all.

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 faster release
cycle than the core anyway.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] disposition of remaining patches

2011-02-18 Thread Josh Berkus
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
 PostgreSQL Experts Inc.
 http://www.pgexperts.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] disposition of remaining patches

2011-02-18 Thread 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 faster release
 cycle than the core anyway.

FDWs seem like perfect candidates for Extensions.  We'll eventually want
postgresql_fdw in core, but most FDWs will never be there.

-- 
  -- Josh Berkus
 PostgreSQL Experts Inc.
 http://www.pgexperts.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] disposition of remaining patches

2011-02-18 Thread Andrew Dunstan



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 work.  The file_fdw patch
may be in better shape (I'm not 100% sure), but it needs the encoding
fix patch Itagaki Takahiro recently proposed.  For this to be
worthwhile, we presumably need to get at least one FDW committed along
with the API patch.



I'm not sure it's not useful without, but it would be better with it. I 
agree we need some actual uses.


If people want more I'm prepared to put some hurried effort into making 
one just for copy to text array, since the consensus didn't seems to be 
in favor of piggybacking this onto the file_fdw. That would exercise the 
part of the new COPY API that would not otherwise not be exercised by 
file_fdw. If not, I'll eventually contribute that for 9.2.


cheers

andrew


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] disposition of remaining patches

2011-02-18 Thread Tom Lane
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, people would want to improve it on a faster release
 cycle than the core anyway.

 FDWs seem like perfect candidates for Extensions.  We'll eventually want
 postgresql_fdw in core, but most FDWs will never be there.

Yeah, agreed as to both points.  I would imagine that we'd absorb
postgresql_fdw into core late in the 9.2 devel cycle, which would still
leave quite a few months where it could be improved on a rapid release
cycle.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] disposition of remaining patches

2011-02-18 Thread Robert Haas
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 are read in the database encoding, it's still a pretty damn
 useful feature.  We can look at whether that can be improved after we
 have some kind of feature at all.

Sure.  OTOH, Itagaki Takahiro's solution wasn't a lot of code, so if
he feels reasonably confident in it, I'd like to see it committed.

 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 faster release
 cycle than the core anyway.

I think as long as we have one implementation in contrib, we're OK to release.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers