Florian Pflug 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, but c
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 natu
>> 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 cod
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 asser
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 Developmen
On Sat, 2010-06-19 at 14:53 -0400, Robert Haas wrote:
> On Sat, Jun 19, 2010 at 2:46 PM, Greg Stark wrote:
> > On Sat, Jun 19, 2010 at 2:43 PM, 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 l
On Jun 19, 2010, at 21:13 , Tom Lane wrote:
> Robert Haas 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).
On Sat, Jun 19, 2010 at 4:55 PM, Andrew Dunstan 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 transparen
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
replicat
On Fri, Jun 18, 2010 at 12:59 PM, Andrew Dunstan wrote:
>
>
> 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 and
On 06/19/2010 09:13 PM, Tom Lane wrote:
Robert Haas 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 nons
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 t
Robert Haas 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 slave's kernel *will* e
Andrew Dunstan 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.
Well, having to
Tom Lane wrote:
Andrew Dunstan 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 lots
of people would
On Sat, Jun 19, 2010 at 2:46 PM, Greg Stark wrote:
> On Sat, Jun 19, 2010 at 2:43 PM, 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 protoc
On Sat, Jun 19, 2010 at 2:43 PM, 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, 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 th
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 non-Pos
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
s
20 matches
Mail list logo
