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
On Jun 20, 2010, at 7:18 , Tom Lane wrote:
> 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 l
I notice that if I vacuum a 1 row table I get a FSM that is 24576 bytes
in size, or 3 database blocks.
Why is it not 1 block, or better still 0 blocks for such a small table?
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
T
Greg: Thank you very much for your insightful comments on the performance of
direct io applied to postgres! That inspired me a lot.
Tom: thank you for the reference to man page!
On Fri, Jun 18, 2010 at 2:02 AM, Greg Smith wrote:
> Daniel Ng wrote:
>
>> I am trying to enable the direct IO for t
Florian Pflug wrote:
> On Jun 20, 2010, at 7:18 , Tom Lane wrote:
>> I was thinking that keepalive was on by default with a very
>> long interval, but I see this isn't so. However, if we enable
>> keepalive, then it's irrelevant to the point anyway. Nobody's
>> produced any evidence that keepali
> Ahem. That is what a natural key is for :)
Well, they have their own drawbacks that don't make them particularly
appealing to use with lookup tables to ape enums. How many lookup
tables have you seen in the wild with a natural key?
People sometimes represent things like US states as enums. This
Peter Geoghegan wrote:
> How many lookup tables have you seen in the wild with a natural
> key?
Me? Personally? A few hundred.
> People sometimes represent things like US states as enums. This is
> probably a mistake, because you cannot control or predict if
> there'll be a new US state, un
"Kevin Grittner" writes:
> Florian Pflug wrote:
>> Yeah, I agree. Just enabling keepalive should suffice for 9.0.
> +1, with configurable timeout;
Right, of course. That's already in the pending patch isn't it?
regards, tom lane
--
Sent via pgsql-hackers mailing lis
On Sun, 2010-06-20 at 11:36 -0400, Tom Lane wrote:
> "Kevin Grittner" writes:
> > Florian Pflug wrote:
> >> Yeah, I agree. Just enabling keepalive should suffice for 9.0.
>
> > +1, with configurable timeout;
>
> Right, of course. That's already in the pending patch isn't it?
Can someone tell
On one of my machines I get
LOG: could not receive test message on socket for statistics collector:
Connection refused
on startup. I noticed this testing 9.0 but when I went back to check I'm
now getting it on 8.3 as well, disabling all of my iptables rules doesn't
help.
I've done some d
>> People sometimes represent things like US states as enums. This is
>> probably a mistake, because you cannot control or predict if
>> there'll be a new US state, unlikely though that me be.
>
> More importantly, you're likely to need to associate properties with
> the state. Sales tax info, may
Steve Singer writes:
> Is using a single UDP socket structure instance for sending a message to
> yourself 'proper'? (it looks like we've been doing this in pgstat.c for
> many years without issues reported).
Why wouldn't it be?
> This machine is a 32bit powerpc running Debian linux with kerne
On 20/06/10 13:56, Simon Riggs wrote:
I notice that if I vacuum a 1 row table I get a FSM that is 24576 bytes
in size, or 3 database blocks.
Why is it not 1 block, or better still 0 blocks for such a small table?
It was just less code to write and test that way. The FSM tree is always
constan
"Joshua D. Drake" wrote:
> Can someone tell me what we are going to do about firewalls that
> impose their own rules outside of the control of the DBA?
Has anyone actually seen a firewall configured for something so
stupid as to allow *almost* all the various packets involved in using
a TCP co
On Sun, Jun 20, 2010 at 03:01:04PM -0500, Kevin Grittner wrote:
> "Joshua D. Drake" wrote:
>
> > Can someone tell me what we are going to do about firewalls that
> > impose their own rules outside of the control of the DBA?
>
> Has anyone actually seen a firewall configured for something so
>
On Sun, Jun 20, 2010 at 11:36 AM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Florian Pflug wrote:
>>> Yeah, I agree. Just enabling keepalive should suffice for 9.0.
>
>> +1, with configurable timeout;
>
> Right, of course. That's already in the pending patch isn't it?
Is this sarcasm, or is
On Sat, Jun 19, 2010 at 4:57 AM, mac_man2...@hotmail.it
wrote:
> 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
Robert Haas writes:
> On Sun, Jun 20, 2010 at 11:36 AM, Tom Lane wrote:
>> Right, of course. That's already in the pending patch isn't it?
> Is this sarcasm, or is there a pending patch I'm not aware of?
https://commitfest.postgresql.org/action/patch_view?id=281
regard
On Jun 20, 2010, at 22:01 , Kevin Grittner wrote:
> "Joshua D. Drake" wrote:
>
>> Can someone tell me what we are going to do about firewalls that
>> impose their own rules outside of the control of the DBA?
>
> Has anyone actually seen a firewall configured for something so
> stupid as to allow
On Sun, Jun 20, 2010 at 5:32 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Jun 20, 2010 at 11:36 AM, Tom Lane wrote:
>>> Right, of course. That's already in the pending patch isn't it?
>
>> Is this sarcasm, or is there a pending patch I'm not aware of?
>
> https://commitfest.postgresql.o
Robert Haas writes:
> On Sun, Jun 20, 2010 at 5:32 PM, Tom Lane wrote:
>> https://commitfest.postgresql.org/action/patch_view?id=281
> +1 for applying something along these lines, but we'll also need to
> update walreceiver to actually use one or more of these new
> parameters.
Right, but the l
On Sun, Jun 20, 2010 at 10:41 PM, Florian Pflug wrote:
> Yeah, especially since there is no such thing as a special "keepalive" packet
> in TCP. Keepalive simply sends packets with zero bytes of payload every once
> in a while if the connection is otherwise inactive. If those aren't
> acknowled
Greg Stark wrote:
> Keepalives introduce spurious disconnections in working TCP
> connections that have transient outages
It's been a while since I read up on this, so perhaps my memory has
distorted the facts over time, but I thought that under TCP, if one
side sends a packet which isn't ack'
On Jun 21, 2010, at 0:13 , Greg Stark wrote:
>> Keepalive is therefore extremely unlikely to break things - in the very
>> worst case, a (really, really stupid) firewall might decide to drop packets
>> with zero bytes of payload, causing inactive connections to abort after a
>> while. AFAIK walr
Robert, so in my example:
- tapes are stored in different files (one tape per file)
- you confirm those first blocks are garbage
- you confirm they could be rewritten with new data
This means that we can do recycle space using one tape per file. Correct?
So, in this case, why do we need to use l
On Mon, Jun 21, 2010 at 12:42 AM, Florian Pflug wrote:
> I'd buy that if all timeouts and retry counts would default to +infinity. But
> they don't, and hence sufficiently long network outages *will* cause
> connection aborts anyway. That a particular connection might survive due to
> inactivit
"mac_man2...@hotmail.it" writes:
> Robert, so in my example:
> - tapes are stored in different files (one tape per file)
> - you confirm those first blocks are garbage
> - you confirm they could be rewritten with new data
> This means that we can do recycle space using one tape per file. Correct?
This is a review for the \whoami patch (changed to \conninfo).
This review was done on the Feb 2 2010 version of the patch (rebased to
head) that reflects some of the feedback from -hackers on the initial
submission. The commitfest entry should be updated to reflect the most
recent version
On Sun, Jun 20, 2010 at 9:31 PM, Greg Stark wrote:
> On Mon, Jun 21, 2010 at 12:42 AM, Florian Pflug wrote:
>> I'd buy that if all timeouts and retry counts would default to +infinity.
>> But they don't, and hence sufficiently long network outages *will* cause
>> connection aborts anyway. That
On Sun, Jun 20, 2010 at 10:51 PM, Steve Singer wrote:
> One comment I have on the output format is that values (ie the database
> name) are enclosed in double quotes but the values being quoted can contain
> double quotes that are not being escaped. For example
>
> Connected to database: "testin
Robert Haas wrote:
> On Wed, Jun 16, 2010 at 9:56 PM, Tom Lane wrote:
>> Sorry, I've been a bit distracted by other responsibilities (libtiff
>> security issues for Red Hat, if you must know). I'll get on it shortly.
>
> What? You have other things to do besides hack on PostgreSQL? Shocking!
(2010/06/11 21:11), Stephen Frost wrote:
> * Magnus Hagander (mag...@hagander.net) wrote:
>> On Fri, Jun 11, 2010 at 14:07, Stephen Frost wrote:
>>> I definitely like the idea but I dislike requiring the user to do
>>> something to implement it. Thinking about how packagers might want to
>>> use
32 matches
Mail list logo
