Tom, Robert,
thank you.
Now it is clearer how space on tapes is recycled.
I tried to follow Robert's example but storing one tape per separate file.
Read in the first block of each run (hosted by separate tapes and so by
separate files) and output them into extra storage, wherever this extra
It would be nice to get beta3 out the door sooner rather than later,
but I sort of feel like we're not ready yet. In fact, we seem to be a
bit stalled. The open items list currently lists four items.
1. max_standby_delay. Tom has committed to getting this done, but has
been tied up with
On Sat, 2010-06-19 at 09:43 -0400, Robert Haas wrote:
4. Streaming Replication needs to detect death of master. We need
some sort of keep-alive, here. Whether it's at the TCP level (as
advocated by Tom Lane and others) or at the protocol level (as
advocated by Greg Stark) is something that
On Sat, Jun 19, 2010 at 2:43 PM, Robert Haas robertmh...@gmail.com wrote:
4. Streaming Replication needs to detect death of master. We need
some sort of keep-alive, here. Whether it's at the TCP level (as
advocated by Tom Lane and others) or at the protocol level (as
advocated by Greg Stark)
On Sat, Jun 19, 2010 at 2:46 PM, Greg Stark gsst...@mit.edu wrote:
On Sat, Jun 19, 2010 at 2:43 PM, Robert Haas robertmh...@gmail.com wrote:
4. Streaming Replication needs to detect death of master. We need
some sort of keep-alive, here. Whether it's at the TCP level (as
advocated by Tom
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
Insert a sort order column into pg_enum, and rearrange the values in
that whenever the user wants to add a new value in a particular place.
You give up cheap comparisons in exchange for flexibility. I think
Andrew Dunstan and...@dunslane.net writes:
Another thought: could we add a column to pg_type with a flag that's
true if the oids are in sort order? Then the comparison routines could
just look that up in the type cache and if it's true (as it often will
be) just return the oid comparison.
Robert Haas robertmh...@gmail.com writes:
Right now, if the SR master reboots unexpectedly (say, power plug pull
and restart), the slave never notices. It just sits there forever
waiting for the next byte of data from the master to arrive (which it
never will).
This is nonsense --- the
On Saturday 19 June 2010 18:05:34 Joshua D. Drake wrote:
On Sat, 2010-06-19 at 09:43 -0400, Robert Haas wrote:
4. Streaming Replication needs to detect death of master. We need
some sort of keep-alive, here. Whether it's at the TCP level (as
advocated by Tom Lane and others) or at the
On 06/19/2010 09:13 PM, Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
Right now, if the SR master reboots unexpectedly (say, power plug pull
and restart), the slave never notices. It just sits there forever
waiting for the next byte of data from the master to arrive (which it
never
On Fri, Jun 18, 2010 at 12:59 PM, Andrew Dunstan and...@dunslane.netwrote:
David E. Wheeler wrote:
On Jun 18, 2010, at 9:34 AM, Andrew Dunstan wrote:
I'd be perfectly happy to hear a reasonable alternative. Assuming we use
some integer representation, given two labels represented by n
Gurjeet Singh wrote:
This is very similar to Andrew's original suggestion of splitting 32
bits into 16+16, but managed by the machine hence no complicated
comparison algos needed on our part. Also, since this is all
transparent to the SQL interface, our dump-reload cycle or Slony
On Sat, Jun 19, 2010 at 4:55 PM, Andrew Dunstan and...@dunslane.net wrote:
Gurjeet Singh wrote:
This is very similar to Andrew's original suggestion of splitting 32 bits
into 16+16, but managed by the machine hence no complicated comparison algos
needed on our part. Also, since this is all
On Jun 19, 2010, at 21:13 , Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
Right now, if the SR master reboots unexpectedly (say, power plug pull
and restart), the slave never notices. It just sits there forever
waiting for the next byte of data from the master to arrive (which it
On Sat, 2010-06-19 at 14:53 -0400, Robert Haas wrote:
On Sat, Jun 19, 2010 at 2:46 PM, Greg Stark gsst...@mit.edu wrote:
On Sat, Jun 19, 2010 at 2:43 PM, Robert Haas robertmh...@gmail.com wrote:
4. Streaming Replication needs to detect death of master. We need
some sort of keep-alive,
On Fri, 2010-06-18 at 11:50 -0400, Andrew Dunstan wrote:
Thoughts?
enum types exist as an optimisation-by-avoidance of referential
integrity.
We're a relational database, so IMHO we should spend time performance
tuning RI.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL
Simon Riggs wrote:
On Fri, 2010-06-18 at 11:50 -0400, Andrew Dunstan wrote:
Thoughts?
enum types exist as an optimisation-by-avoidance of referential
integrity.
We're a relational database, so IMHO we should spend time performance
tuning RI.
I don't accept your initial
Thoughts?
enum types exist as an optimisation-by-avoidance of referential
integrity.
We're a relational database, so IMHO we should spend time performance
tuning RI.
I take the view that they exist as a way of representing enumerations
of application/domain values - if it's hard coded in
On Sun, 2010-06-20 at 03:42 +0100, Peter Geoghegan wrote:
Thoughts?
It's very cool to be able to write queries like SELECT * FROM payments
WHERE payment_type = 'cash', rather than having to recall time and
again what the PK of cash is within your lookup table.
Ahem. That is what a natural
Florian Pflug f...@phlo.org writes:
On Jun 19, 2010, at 21:13 , Tom Lane wrote:
This is nonsense --- the slave's kernel *will* eventually notice that
the TCP connection is dead, and tell walreceiver so. I don't doubt
that the standard TCP timeout is longer than people want to wait for
that,
20 matches
Mail list logo
