for Fedora core 6
selinux-policy-2.4.6-74.sepgsql.fc6.noarch.rpm
selinux-policy-targeted-2.4.6-74.sepgsql.fc6.noarch.rpm
selinux-policy-devel-2.4.6-74.sepgsql.fc6.noarch.rpm
o The security guide of Security-Enhanced PostgreSQL beta edition
sepgsql_security_guide.20070701.jp.beta.pdf (Japanese
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
To resolve this I think we need a clearer definition of the autovac
launcher's role in life. I see that it is attached to shared memory;
is it supposed to be able to execute transactions or otherwise do
anything the bgwriter might have
While poking at the vacuum-launcher issue currently under discussion,
I got annoyed again at the behavior we've known for a long while that
on some platforms pg_usleep() won't be interrupted by signals. (In
particular I see this on HPUX, though not on Linux or Darwin. Anyone
know if it happens
Heikki Linnakangas [EMAIL PROTECTED] writes:
Does this
+elog(LOG, checkpoint starting:%s%s%s%s%s%s,
+ (flags CHECKPOINT_IS_SHUTDOWN) ? shutdown : ,
+ (flags CHECKPOINT_IMMEDIATE) ? immediate : ,
+ (flags CHECKPOINT_FORCE) ? force : ,
+
On Sun, Jul 01, 2007 at 12:11:26PM -0400, Tom Lane wrote:
To me, this calls into question whether we should try to avoid using
SA_RESTART at all. The reason for doing it of course is to avoid
unexpected syscall EINTR failures as well as short read/short write
behaviors during disk I/O.
Hrm,
Hello
if I understand well, there isn't any difference between local and
global temp tables in postgresql.
I have question. Is correct implementation of global temp in Oracle or
Firebird, where content of glob.temp table is session visible and
metadata of g.t.t is persistent? Standard is
Martijn van Oosterhout [EMAIL PROTECTED] writes:
One other possiblity is using something like nanosleep():
But I don't know if that would help on your HPUX box though...
Doesn't help ... the function exists but it seems to have the identical
restarting behavior to select :-(
I had previously
Pavel Stehule [EMAIL PROTECTED] writes:
if I understand well, there isn't any difference between local and
global temp tables in postgresql.
See the archives; some time ago we determined that the correct reading
of the spec is that global/local determines visibility of temp tables
across
Actually I think the *most* important thing to work on is to get hash to
the point where its search speed actually beats btree consistently, so
that it has an excuse to live. If that is insoluble we might well end up
ripping it out entirely. (The first three TODO items for hash indexes
are
Naz Gassiep [EMAIL PROTECTED] writes:
As a result, when creating tables containing large blocks of text I wish
to index, I've been using HASH as an index method. Please can we state
in the manual that HASH index types are in a beta stage of development
or something similar, or perhaps remove
I have question. Is correct implementation of global temp in Oracle or
Firebird, where content of glob.temp table is session visible and
metadata of g.t.t is persistent?
It's correct per spec. Whether it's more useful than what we do is
highly debatable --- it forces all sessions to use the
11 matches
Mail list logo
