Tom Lane wrote:
I'd accept a mechanism to enforce a timeout at the lock level if you
could show me a convincing use-case for lock timeouts instead of
statement timeouts, but I don't believe there is one. I think this
proposal is a solution in search of a problem.
I think statement_timeout
This wasn't encountered in my original patch because
pg_tablespace_aclmask() had this test reasonably early on:
+ if(tbloid == DEFAULTTBLSPC)
+ return (mask);
I guess that might have been a bit presumptuous but a similar thing
happens if you don't specify a tablespace:
tablespaceId
Gaetano Mendola wrote:
Tom Lane wrote:
Gaetano Mendola [EMAIL PROTECTED] writes:
I think a warning is missing if I create a table without OIDS that
inherits from a table with oids:
don't you think a warning shall to be raised here ?
Nope ... this is not different from the behavior for merging
On Mon, 28 Jun 2004, Satoshi Nagayasu wrote:
If I set statement_timeout to 1000 to detect a lock timeout,
I can't run a query which takes over 1 sec.
If a lock wait is occured, I want to detect it immediately,
but I still want to run a long-running query.
Why is it important what it is
Gavin Sherry [EMAIL PROTECTED] writes:
Chris KL just raised an issue on IRC:
test= create table test (a int4) tablespace pg_default;
ERROR: permission denied for tablespace pg_default
This is not a bug. If you don't have tablespace permissions, you don't
get to specify where your table goes
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
That way, an admin can force users to NOT use the default tablespace if
they wish, even though the users have CREATE table rights on the schema.
I think the above statement is nonsensical. Perhaps you are confusing
the notions of default
BTW, it occurs to me that there's a bug in the current implementation of
CREATE DATABASE when you change the database's default tablespace.
The CREATE DATABASE code assumes that it can physically copy all content
of the old-database's-default-tablespace into the
new-database's-default-tablespace,
Dear Tom,
BTW, it occurs to me that there's a bug in the current implementation of
CREATE DATABASE when you change the database's default tablespace.
[...]
Now, when looking at the new database's reltablespace column, it will
appear that that table is in the old database's default
Fabien COELHO [EMAIL PROTECTED] writes:
It's more a fix-me later approach, but it does not look that bad, IMHO.
It seems a bit risky to me. The worst possible consequence of the
ownership stuff not happening is that objects have wrong ownership
(and even there it's not so much wrong as we
I have set returning function written in 'c', declared as:
CREATE OR REPLACE FUNCTION check_view (text,text) RETURNS setof pg_attribute
AS '/usr/local/pgsql/lib/libplpq.so','check_view' LANGUAGE 'c'
WITH (isstrict);
When I call this function from psql :
SELECT attrelid,attnum FROM
On Mon, 2004-06-28 at 02:16, Satoshi Nagayasu wrote:
Tom Lane wrote:
I'd accept a mechanism to enforce a timeout at the lock level if you
could show me a convincing use-case for lock timeouts instead of
statement timeouts, but I don't believe there is one. I think this
proposal is a
Darko Prenosil [EMAIL PROTECTED] writes:
Anyone knows what I'm doing wrong ?
Well, when you didn't show us the text of the function, no.
However, a reasonable bet would be that you used SPI inside the function
and did not use it correctly, leaving the SPI state corrupted when
control got back
Here is the source, but now when You mentioned SPI state, I see that I put
SPI_finish stupidly after SRF_RETURN_NEXT(funcctx, result);
Could that be my problem ?
Regards !
PG_FUNCTION_INFO_V1(check_view);
Datum
check_view(PG_FUNCTION_ARGS)
{
FuncCallContext *funcctx;
MemoryContext oldcontext;
Robert Treat wrote:
I think statement_timeout and lock_timeout are different.
If I set statement_timeout to 1000 to detect a lock timeout,
I can't run a query which takes over 1 sec.
If a lock wait is occured, I want to detect it immediately,
but I still want to run a long-running query.
How
Dennis Bjorklund wrote:
If I set statement_timeout to 1000 to detect a lock timeout,
I can't run a query which takes over 1 sec.
If a lock wait is occured, I want to detect it immediately,
but I still want to run a long-running query.
Why is it important what it is that makes your query not
Would anyone else think that dumping:
SET client_min_messages TO warning;
In pg_dumps would be cool?
It would mean that while restoring a dump you can actually see the wood
for the trees when trying to see ERRORs and WARNINGs the the massive
spam of messages you get while restoring.
Chris
As part of my testing, I noticed this bug. My database has a
search_path set in the database vars. It dumps lik ethis:
DROP DATABASE usa;
CREATE DATABASE usa WITH TEMPLATE = template0 OWNER = usadmin ENCODING =
'LATIN1';
ALTER DATABASE usa SET search_path TO 'public, contrib';
Notice the
17 matches
Mail list logo
