Re: [PATCHES] Display Pg buffer cache (WIP)
Tom Lane wrote: It'd be possible to dispense with the per-buffer spinlocks so long as you look only at the tag (and perhaps the TAG_VALID flag bit). The tags can't be changing while you hold the BufMappingLock. That's what I had thought at first, but this comment in buf_internals.h dissuaded me: buf_hdr_lock must be held to examine or change the tag, flags, usage_count, refcount, or wait_backend_id fields. The comment already notes this isn't true if you've got the buffer pinned; it would be worth adding another exception for holding the BufMappingLock, IMHO. I'm dubious that there's any point in recording information as transient as the refcounts and dirtybits I think it's worth recording dirty bits -- it provides an indication of the effectiveness of the bgwriter, for example. Reference counts could be done away with, although I doubt it would have a significant effect on the time spent holding the lock. -Neil ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Display Pg buffer cache (WIP)
Only two things to add: you forgot to add `cachedump.o' to the list of
OBJS in the utils/adt Makefile.
Mark Kirkwood wrote:
+typedef struct
+{
+ uint32 bufferid;
+ Oid relfilenode;
+ Oid reltablespace;
+ Oid reldatabase;
+ boolisdirty;
+ uint32 refcount;
+ BlockNumber blocknum;
+
+} CacheDumpRec;
You should probably make `isdirty' the last member of this struct, so as
to reduce alignment/padding requirements (this won't actually save any
space right now, but it might save some space if more members are added
to the struct in the future).
-Neil
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
[PATCHES] Implementation of SQLCODE and SQLERRM variables for PL/pgSQL
Hello
This is my second patch, than please will be tolerant :-). For one my
project I miss information about exception when I use EXCEPTION WITH
OTHERS THEN. I found two Oracle's varaibles SQLCODE and SQLERRM which
carry this information. With patch you can:
--
-- Test of built variables SQLERRM and SQLCODE
--
create or replace function trap_exceptions() returns void as $_$
begin
begin
raise exception 'first exception';
exception when others then
raise notice '% %', SQLCODE, SQLERRM;
end;
raise notice '% %', SQLCODE, SQLERRM;
begin
raise exception 'last exception';
exception when others then
raise notice '% %', SQLCODE, SQLERRM;
end;
return;
end; $_$ language plpgsql;
select trap_exceptions();
drop function trap_exceptions();
CREATE FUNCTION
NOTICE: P0001 first exception
NOTICE: 00 Sucessful completion
NOTICE: P0001 last exception
trap_exceptions
-
(1 row)
DROP FUNCTION
Regards,
Pavel Stehule
--
-- Test of built variables SQLERRM and SQLCODE
--
create or replace function trap_exceptions() returns void as $_$
begin
begin
raise exception 'first exception';
exception when others then
raise notice '% %', SQLCODE, SQLERRM;
end;
raise notice '% %', SQLCODE, SQLERRM;
begin
raise exception 'last exception';
exception when others then
raise notice '% %', SQLCODE, SQLERRM;
end;
return;
end; $_$ language plpgsql;
select trap_exceptions();
drop function trap_exceptions();
CREATE FUNCTION
NOTICE: P0001 first exception
NOTICE: 00 Sucessfull completation
NOTICE: P0001 last exception
trap_exceptions
-
(1 row)
DROP FUNCTION
357a358,360
int sqlcode_varno;
int sqlerrm_varno;
826a827,842
/* INICIALIZACE fooi a foot */
PLpgSQL_var *var;
var = (PLpgSQL_var *) (estate-datums[block-sqlcode_varno]);
var-isnull = false;
var-freeval = false;
var-value = DirectFunctionCall1(textin, CStringGetDatum(00));
var = (PLpgSQL_var *) (estate-datums[block-sqlerrm_varno]);
var-isnull = false;
var-freeval = false;
var-value = DirectFunctionCall1(textin, CStringGetDatum(Sucessful
completion));
931a948,966
/* unpack MAKE_SQLSTATE code */
chartbuf[12];
int ssval;
int i;
ssval = edata-sqlerrcode;
for (i = 0; i 5; i++)
{
tbuf[i] = PGUNSIXBIT(ssval);
ssval = 6;
}
tbuf[i] = '\0';
var = (PLpgSQL_var *)
(estate-datums[block-sqlcode_varno]);
var-value = DirectFunctionCall1(textin,
CStringGetDatum(tbuf));
var = (PLpgSQL_var *)
(estate-datums[block-sqlerrm_varno]);
var-value = DirectFunctionCall1(textin,
CStringGetDatum(edata-message));
88a89,93
struct
{
int sqlcode_varno;
int sqlerrm_varno;
} fict_vars;
104a110
%type fict_vars fict_vars_sect
251c257
pl_block : decl_sect K_BEGIN lno proc_sect exception_sect K_END
---
pl_block : decl_sect fict_vars_sect K_BEGIN lno proc_sect
exception_sect K_END
259c265
new-lineno = $3;
---
new-lineno = $4;
263,264c269,272
new-body = $4;
new-exceptions = $5;
---
new-body = $5;
new-exceptions = $6;
new-sqlcode_varno =
$2.sqlcode_varno;
new-sqlerrm_varno =
$2.sqlerrm_varno;
271a280,291
fict_vars_sect:
{
plpgsql_ns_setlocal(false);
PLpgSQL_variable*var;
var =
plpgsql_build_variable(strdup(sqlcode), 0,
plpgsql_build_datatype(TEXTOID, -1), true);
$$.sqlcode_varno = var-dno;
var =
plpgsql_build_variable(strdup(sqlerrm), 0,
plpgsql_build_datatype(TEXTOID, -1), true);
Re: [PATCHES] Cleaning up unreferenced table files
Heikki Linnakangas [EMAIL PROTECTED] writes: On Sat, 5 Mar 2005, Tom Lane wrote: xlog.c is a fairly random place to put that functionality. Didn't it strike any warning bells for you when you had to add so many new #includes? I'm not entirely sure where this should go, but not there. Yeah actually it did, but I forgot about it along the way. How about putting it in a file of its own in backend/catalog? There's some code that also deals with the data directories. Or straight into backend/storage. Actually, you could make some case for putting it in utils/init/ beside flatfiles.c, which has got much the same sort of issues to deal with. I think though that we ought to first consider the question of whether we *want* this functionality. On reflection I'm fairly nervous about the idea of actually deleting anything during startup --- seems like a good recipe for turning small failures into large failures. But if we're not going to delete anything then it's questionable whether we need to code it like this at all. It'd certainly be easier and safer to examine these tables after the system is up and running normally. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [HACKERS] Implementation of SQLCODE and SQLERRM variables for
I think we discussed this last year and decided that it would be a bad idea to use those names because Oracle's use of them is not exactly compatible with our error codes and messages. SQLCODE in particular is not compatible at all --- it's an integer in Oracle, isn't it? There is more incompatibilities to Oracle. SQLERRM is function on Oracle, only if you use it without parametr, returns current message error. SQLCODE is really integer. But it's only names. There is no problem change it. IIRC we had put off solving this problem until we decided what to do with RAISE. There really needs to be some changes in RAISE to allow it to raise a specific error code rather than always P0001, but exactly what is still undecided. I didn't know it. But for my work is SQLERRM more important. I have more constraints on tables and I need detect which which constraints raise exception. The possibility EXCEPTION WITH OTHERS is nice, but not too much usefull because I have not possibility get some informations about except. Some other problems with your patch: no documentation, and not in diff -c format. Plain diff patches are never acceptable because it's too risky to apply them against files that might have changed since you started working with them. Also, it's much easier to deal with one patch than with a separate diff for each file. (diff -c -r between an original and a modified directory is one good way to produce a useful patch.) I am not sure, I able create documentation - my english is poor. I will change diff's format and send patch again. Thank you Pavel ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Display Pg buffer cache (WIP)
Neil Conway wrote: Tom Lane wrote: It'd be possible to dispense with the per-buffer spinlocks so long as you look only at the tag (and perhaps the TAG_VALID flag bit). The tags can't be changing while you hold the BufMappingLock. That's what I had thought at first, but this comment in buf_internals.h dissuaded me: buf_hdr_lock must be held to examine or change the tag, flags, usage_count, refcount, or wait_backend_id fields. The comment already notes this isn't true if you've got the buffer pinned; it would be worth adding another exception for holding the BufMappingLock, IMHO. I'm dubious that there's any point in recording information as transient as the refcounts and dirtybits I think it's worth recording dirty bits -- it provides an indication of the effectiveness of the bgwriter, for example. Reference counts could be done away with, although I doubt it would have a significant effect on the time spent holding the lock. Let's suppose refcount is eliminated. I will then be examining the tag, flags and buf_id elements of the buffer. Holding the BufMappingLock prevents the tag changing, but what about the flags? In addition Tom pointed out that I am not examining the BM_TAG_VALID or BM_VALID flag bits (I am only checking if tag.blockNum equals InvalidBlockNumber). My initial thought is to handle !BM_TAG_VALID or !BM_VALID similarly to InvalidBlockNumber i.e all non buf_id fields set to NULL. Mark ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] Harmless space allocation typo
Heikki Linnakangas wrote: Here's a tiny fix for a harmless typo in catalog.c Applied, thanks. -Neil ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Faster install-sh in C
On Fri, Mar 04, 2005 at 11:20:07AM +0100, Peter Eisentraut wrote: Am Freitag, 4. März 2005 01:11 schrieb Neil Conway: Alvaro Herrera wrote: I wrote an install program in C. It's supposed to replace the config/install-sh script, limited to the functionality we need, i.e. what is in Makefiles in the Pg main source tree. The main objective of this exercise is to reduce make install execution time; a part of that is being able to install multiple files with one command. What's the status of this patch? I was playing a little with Make just before leaving, but since I'm hardly an expert I was having difficulty making it all work. Also, because I need to include bits from both the source dir and the build dir (to get get_progname from the port dir and signal handling from libpq), it was getting somewhat ugly. With a little more effort it can be made to work cleanly. I'm not convinced that this is the best approach. Apparently, PostgreSQL is about the only project that is somehow bothered by this. It would be more productive to find out why we can't use the system install and find fixes for that. Well, apparently everyone says the system install is not portable and the discussion stops there. Probably some projects need a sh install because they don't require a compiler, but we do; we won't require anything beyond what we already do to have a C install. Maybe most projects don't install a lot of files like we do, or maybe people just don't care. (Neither did I care back when installing all headers wasn't the default behaviour.) I do care now. And given that the work is mostly already done, I don't see why we couldn't use it. Anyway, if you want to speed up your installation today, just override the INSTALL variable by hand. This doesn't solve the fact that the INSTALL program is called once for each file in the include directories. -- Alvaro Herrera ([EMAIL PROTECTED]) Y una voz del caos me habló y me dijo Sonríe y sé feliz, podría ser peor. Y sonreí. Y fui feliz. Y fue peor. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
