> 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 th
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 rem
> 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
>
"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 m
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 previousl
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 unclean
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.
Hr
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) ? "
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 on
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
ity policy 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.j
11 matches
Mail list logo
