I sent this to Bruce but forgot to cc pgsql-hackers, The patches are
likely to go into 2.6.6. People interested in extremely safe fsync
writes should also follow the IDE barrier thread and the true fsync() in
Linux on IDE thread
- Forwarded message from Yusuf Goolamabbas <[EMAIL PROTECTED]> --
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi developpers,
I would like to know information about OS virtual memory page and your
BTree node. Theoriticaly, BTree perform better if his size node is the
same that OS page (the unit of transfer between main memory and disk).
This way, it take just
Dear Tom,
> > However, I still stick with my "bad" simple idea because the simpler the
> > better, and also because of the following example:
> > ...
> > psql> SELECT count_tup('pg_shadow');
> > ERROR: syntax error at or near "FRM" at character 22
> > CONTEXT: PL/pgSQL function "count_tup" line
Tom Lane wrote:
also, is it safe to
assume that a byte sent with send() is *immediately* ready to recv()?
If not presumably you could either sleep for a very small interval
before the recv or select on the socket for a very small interval. Half
a second should be ample, I would think.
This
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> A small problem with it was reported to me a couple of days ago - user
> had firewalled off all IP6 traffic. The stats collector happily bound
> and connected to the socket, but all the packets fell in the bit bucket.
> They found it quite hard to dia
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I did wonder if we should treate "localhost" as a bit special and not
rely on the resolver for it.
I don't think so; we went in the other direction in 7.4 for pgstats.
(It used to try to bind to "127.0.0.1" and now tries "localh
