On 07/01/2010 12:56 PM, Kevin Grittner wrote:
I just tried creating a symbolic link to the pg_log directory and
flagging the existing logs within it to 640. As a member of the
group I was able to list and view the contents of log files through
the symbolic link, even though I didn't have any aut
On 05/25/2010 01:09 PM, Mike Fowler wrote:
Why? 2.6.27 is almost 4 years old.
RHEL 5 ships with 2.6.26. I imagine that supporting it is very
desirable, regardless of its age, since that is unfortunately still the
latest version of RHEL.
-- m. tharp
--
Sent via pgsql-hackers mailing list (p
On 05/08/2010 04:07 AM, Craig Ringer wrote:
It's probably worth mentioning that people who want to turn off fsync to
gain a performance boost should instead look at a RAID controller with a
BBU so they can safely enable write-back caching, getting most of the
benefits of fsync=off safely.
Which
On 04/30/2010 01:53 PM, Robert Haas wrote:
Well, one of us is. Why would you want to retain all of your WAL logs
in pg_xlog forever?
...Robert
To create or re-synchronize SR slaves, one could change
wal_keep_segments to -1, run a backup, wait for the slaves to catch up,
and change it back
On 04/27/2010 09:59 AM, Kevin Grittner wrote:
Under what circumstances would PostgreSQL
modify a file without changing the "last modified" timestamp or the
file size?
Do all OSes have sub-second precision mtimes? Because otherwise I could
see a scenario such at this:
* File is modified
* Bac
On 04/24/2010 08:49 PM, Robert Haas wrote:
The nodeToString format as it stands is somewhat ambiguous with respect to
the type of a node member's value if one does not have access to
readfuncs.c. For example, a T_BitString called foo is serialized as ':foo
b1010' while a char * containing 'b1010'
On 04/02/2010 04:16 PM, Tom Lane wrote:
Generally speaking I'm against
exposing that data structure to clients, because there will inevitably
be griping when we change it (as we most certainly will). Your
complaints boil down to "this is hard to parse from the client side",
and that already tell
Most Esteemed Hackers:
Due to popular demand on #postgresql (by which I mean David Fetter), I
have been spending a little time making the internal SQL parser
available to clients via a C-language SQL function. The function itself
is extremely simple: just a wrapper around a call to raw_parser