Re: [HACKERS] [PATCHES] Dbsize backend integration
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: 03 July 2005 17:10 To: Dawid Kuroczko Cc: Andreas Pflug; Dave Page; Bruce Momjian; PostgreSQL-patches; PostgreSQL-development Subject: Re: [HACKERS] [PATCHES] Dbsize backend integration Dawid Kuroczko [EMAIL PROTECTED] writes: Oh, I think pg_dbfile_size is best so far. I think it's by far the ugliest suggestion yet :-( Why? It does exactly what it says on the tin! It might not be that nice, but it does describe what it does - and noone yet has come up with anything less ambiguous or misleading imho. Andreas's suggestion of having just one function with a bool parameter might be a workable compromise. Aside from the fact that's a change to the API that we had settled on, it doesn't solve the actual problem of needing a suitable name for a function that returns the size of a table /or/ index. pg_relation_size() or pg_table_size() can't be used for precisely the reason they were rejected for that purpose in the first place. Regards, Dave. ---(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: [HACKERS] [PATCHES] Users/Groups - Roles
Dear Tom, We probably need to think a bit harder about the meaning of CREATEROLE though. Right now it gives free license not only to create roles but to alter any property of existing roles. This seems appropriate if you think of it as a safer form of superuser, which is how I was thinking of it. It would be too powerful for Fabien's situation though. Yes. ISTM it would be a good thing to separate - sysadmin issues (create a user that can connect - pg_hba.conf) and - dbadmin issues (manage permission on data in a catalog). The first item is the current pg superuser. I envision the second item as being a property of the database (catalog) OWNER, which can do whatever he/she wants at home, but should not bother others. So there is a need for a limited 'createrole' ability (simple roles that cannot be users (?), and avoid name space collision). This is better for teaching, but also for any service provider which would host many users and databases, and would like to transfer them. If you want to delegate data access privileges to someone, it is better to have that restricted to the catalog to avoid name-space collision. The same issue arises when moving a database from one cluster to another where some role names may already be used. That is the kind of think I also need to do as a dbadmin. If one take a conceptual perspective, database access privilege management is a catalog-related task, so it seems better to have that in the catalog. So I think all points that roles are better (more useful) per-catalog than per-cluster. If you just want to claim that 'pg has roles', you can do the marketing with per-cluster roles;-) If you want them more useful, you need them per-catalog. -- Fabien. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Schedule for release 8.1
Marc G. Fournier wrote: On Mon, 4 Jul 2005, Bruce Momjian wrote: Here is a rough outline of what is coming for 8.1: o On Monday, we will collect all submitted patches. o Within the next 2-4 weeks, we will apply all patches that can be applied. o We will make sure all changes since 8.1 are working resonably well and are documented. This is the cleanup phase. All changes since 8.0, don't you mean ... ? Yea, I really meant all changes _in_ 8.1. Thanks. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] Dbsize backend integration
Dave Page dpage@vale-housing.co.uk writes: Aside from the fact that's a change to the API that we had settled on, it doesn't solve the actual problem of needing a suitable name for a function that returns the size of a table /or/ index. pg_relation_size() or pg_table_size() can't be used for precisely the reason they were rejected for that purpose in the first place. Rejected by whom? pg_relation_size is an excellent choice for that. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Dbsize backend integration
Tom Lane wrote: Dave Page dpage@vale-housing.co.uk writes: Aside from the fact that's a change to the API that we had settled on, it doesn't solve the actual problem of needing a suitable name for a function that returns the size of a table /or/ index. pg_relation_size() or pg_table_size() can't be used for precisely the reason they were rejected for that purpose in the first place. Rejected by whom? pg_relation_size is an excellent choice for that. We mostly tell people that table and relation are synonmous. Though there is a distinction, it seems error-prone to rely on that distinction in the API. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(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: [HACKERS] [PATCHES] Disable page writes when fsync off, add GUC
Stephen Frost wrote: -- Start of PGP signed section. * Bruce Momjian (pgman@candle.pha.pa.us) wrote: This patch disables page writes to WAL when fsync is off, because with no fsync guarantee, the page write recovery isn't useful. This doesn't seem quite right to me. What happens with PITR? And PITR doesn't need page writes at all because it has a full backup the file system to start with. In fact with PITR the crashed file system isn't used at all (restored from backup). In fact there is a TODO to exclude full page writes from the PITR backup of WAL. Postgres crashes? While many people seriously distrust running w/ fsync off, I'm sure there's quite a few folks which do. This also adds a full_page_writes GUC to turn off page writes to WAL. Some people might not want full_page_writes, but still might want fsync. Adding an option to not do page writes to WAL seems fine to me, but I think WAL writes should be on by default, even in the fsync=off case. If people want to turn it off, fine, for either case since we expect they understand what it means to have it turned off, but I don't think the two options should be coupled as is being proposed. That is a question I had in my mind. I added documentation that turning off fsync also disables full_page_writes, but we could decouple them and tell people to consider disableing full_pages_writes if they turn off fsync, basically suggesting they make the second change. Other opinions? -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] HEAD doesn't cope with libraries in non-default
Andrew Dunstan wrote: I was also slightly dubious about it. However, we do still need to solve the problem that the patch addressed. Buildfarm members platypus and cuckoo are currently failing because dblink is picking up the wrong libpq (and it appears that incorrect libraries are also being picked up in the ecpg libraries, although this isn't causing a buildfarm failure.) We have four pieces of information when linking a shared library: B: in-tree libraries that we might need (in case of ecpglib: libpq) A: path to those in-tree libraries D: external libraries that we might need (in case of ecpglib in my case: -lcrypt -lm) C: path to those external libraries (e.g., /usr/local/lib) On the linker command line, we need this information in one of the following two orders: A B C D A C B D The Makefile.shlib receives from the respective main makefile A B D in SHLIB_LINK and would have to insert C in the middle somewhere. Currently, the actual behavior is C A B D and the failed patch wanted to do A B D C, both of which are wrong. So either we code up some intelligence to put the C in the right position or we have to pass down A B and D separately from the main makefile. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] New warnings in plgsql/src/scan.l
I see new warnings in the generation of plpgsql's scanner: /usr/bin/flex -Pplpgsql_base_yy -o'/pg/source/00orig/src/pl/plpgsql/src/pl_scan.c' /pg/source/00orig/src/pl/plpgsql/src/scan.l /pg/source/00orig/src/pl/plpgsql/src/scan.l:198: warning, the character range [-ÿ] is ambiguous in a case-insensitive scanner /pg/source/00orig/src/pl/plpgsql/src/scan.l:198: warning, the character range [-ÿ] is ambiguous in a case-insensitive scanner /pg/source/00orig/src/pl/plpgsql/src/scan.l:320: warning, the character range [-ÿ] is ambiguous in a case-insensitive scanner I think those have to do with E'' handling changes. I remember there were similar problems in the main scanner as well some time ago, not sure about the resolution. -- Alvaro Herrera (alvherre[a]surnet.cl) I personally became interested in Linux while I was dating an English major who wouldn't know an operating system if it walked up and bit him. (Val Henson) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Use of copydir vs. cp
Right now, we use 'cp' in unix, and a copydir() function on Win32. Shouldn't we be using copydir() on all platforms so we can report errors more easily? -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Use of copydir vs. cp
On Mon, Jul 04, 2005 at 12:45:47PM -0400, Bruce Momjian wrote: Right now, we use 'cp' in unix, and a copydir() function on Win32. Shouldn't we be using copydir() on all platforms so we can report errors more easily? I agree. In fact, I didn't understand it back then when you opposed the idea of doing that. -- Alvaro Herrera (alvherre[a]surnet.cl) Jude: I wish humans laid eggs Ringlord: Why would you want humans to lay eggs? Jude: So I can eat them ---(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: [HACKERS] New warnings in plgsql/src/scan.l
Alvaro Herrera wrote: I see new warnings in the generation of plpgsql's scanner: /usr/bin/flex -Pplpgsql_base_yy -o'/pg/source/00orig/src/pl/plpgsql/src/pl_scan.c' /pg/source/00orig/src/pl/plpgsql/src/scan.l /pg/source/00orig/src/pl/plpgsql/src/scan.l:198: warning, the character range [-ÿ] is ambiguous in a case-insensitive scanner This warning has existed in one from or another ever since the latest flex version is in use. For example, 7.4 shows it as well. I don't think we have to do anything (except rewrite PL/pgSQL's parser, which is somehow planned (or hoped for) anyway). -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Use of copydir vs. cp
Bruce Momjian wrote: Right now, we use 'cp' in unix, and a copydir() function on Win32. Shouldn't we be using copydir() on all platforms so we can report errors more easily? Oops, I see Win32 CopyFile() in copydir.c. Seems copydir() would need some modifications to work on Unix. I added it to the TODO list. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Use of copydir vs. cp
Alvaro Herrera wrote: On Mon, Jul 04, 2005 at 12:45:47PM -0400, Bruce Momjian wrote: Right now, we use 'cp' in unix, and a copydir() function on Win32. Shouldn't we be using copydir() on all platforms so we can report errors more easily? I agree. In fact, I didn't understand it back then when you opposed the idea of doing that. At the time, we were trying to get Win32 in with as little code change as possible. At this point, with everything working, it is time to complete this item. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(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: [HACKERS] New warnings in plgsql/src/scan.l
On Mon, Jul 04, 2005 at 06:51:48PM +0200, Peter Eisentraut wrote: Alvaro Herrera wrote: I see new warnings in the generation of plpgsql's scanner: /usr/bin/flex -Pplpgsql_base_yy -o'/pg/source/00orig/src/pl/plpgsql/src/pl_scan.c' /pg/source/00orig/src/pl/plpgsql/src/scan.l /pg/source/00orig/src/pl/plpgsql/src/scan.l:198: warning, the character range [-ÿ] is ambiguous in a case-insensitive scanner This warning has existed in one from or another ever since the latest flex version is in use. Really? Hmm, maybe the issue is that my system upgraded itself. I see flex is at 2.5.31 ATM, not sure how to find out when it was upgraded. (But then maybe I'm wrong about those warnings being new; maybe they were usually drowned in the noise of tsort input having a loop, or something like that, that I've never cared to shut up.) -- Alvaro Herrera (alvherre[a]surnet.cl) This is a foot just waiting to be shot(Andrew Dunstan) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCHES] Dbsize backend integration
Bruce Momjian wrote: Tom Lane wrote: Dave Page dpage@vale-housing.co.uk writes: Aside from the fact that's a change to the API that we had settled on, it doesn't solve the actual problem of needing a suitable name for a function that returns the size of a table /or/ index. pg_relation_size() or pg_table_size() can't be used for precisely the reason they were rejected for that purpose in the first place. Rejected by whom? pg_relation_size is an excellent choice for that. We mostly tell people that table and relation are synonmous. Though there is a distinction, it seems error-prone to rely on that distinction in the API. I am starting to warm up to the idea of using relation as the combined total. Was that the proposal? Are we prepared to make that distinction in other places? -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Dbsize backend integration
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: 04 July 2005 14:54 To: Dave Page Cc: Dawid Kuroczko; Andreas Pflug; Bruce Momjian; PostgreSQL-patches; PostgreSQL-development Subject: Re: [HACKERS] [PATCHES] Dbsize backend integration Dave Page dpage@vale-housing.co.uk writes: Aside from the fact that's a change to the API that we had settled on, it doesn't solve the actual problem of needing a suitable name for a function that returns the size of a table /or/ index. pg_relation_size() or pg_table_size() can't be used for precisely the reason they were rejected for that purpose in the first place. Rejected by whom? pg_relation_size is an excellent choice for that. Bruce didn't like it (http://archives.postgresql.org/pgsql-hackers/2005-06/msg01410.php), and you seemed to object as well (http://archives.postgresql.org/pgsql-hackers/2005-06/msg01247.php) Personally I'm beyond caring much now as the amount of time spent trying to name these simple functions is wildly disproportionate the the effort take to actually code them. I think we just need to agree there is no perfect name and rely on the comments and docs to guide people. I think the current names work OK, and Bruce and Dawid at least agree! Regards, Dave. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] [PATCH] pgcrypto: pgp_encrypt v3
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- Marko Kreen wrote: Well, I needed to decide, whether it is realistic to implement PGP public-key encryption someday, because then I better rename the function 'pgp_encrypt' to something more specific immidiately. But after hacking a while, I soon had working implementation, so it seems silly to wait 8.2 for it. This is thanks to the fact that for encryption I can ignore most of the OpenPGP complex parts - signing and key-management. IMHO they don't even make sense inside database, they need an end-user application. In short, the goal of this code is not to be full OpenPGP implementation, but just provide more flexible encryption than the usual symmetric encryption. So here is updated pgp_encrypt patch, with support for both symmetric and public-key encryption. Also, as Neil requested, non-failing regression tests - unsupported parts are replaced with empty test named '*-DISABLED'. Note: it uses OpenSSL bignum code - so without OpenSSL no public-key encryption. Look below for plans for fixing this dependance. New names for symmetric-key functions: pgp_sym_encrypt(data, key) pgp_sym_decrypt(data, key) Public key functions: pgp_pub_encrypt(data, key) pgp_pub_decrypt(data, key) pgp_pub_decrypt(data, key, psw) Plus variants with 'arg' and for bytea. Not mentioned in previous mails: armor(bytea) - text dearmor(text) - bytea Apply and remove PGP Ascii Armor. Implemented feature?: * Elgamal-encryption keys - preferred public-key algo for OpenPGP. * Password-protected secret keys. Missing features (needs implementing ASAP): * pgp_key_id() - Function to query the ID of a key, and the key ID from encrypted packet - so user can implement key rings on his own. Maybe: * As it does not parse sign packets, it does not support recipient cipher preferences. It is not important for planned use-case, but maybe it would be nice to have. Does not support (and I see no need): * RSA-encrypt and sign+encrypt keys - they are deprecated in RFC, GnuPG does not even give option to generate them, so IMO it's fine to ignore them. * Picking a key from list of keys - accepting a keyring in place of key. * Several encryption subkeys under one key. * Any form of signing - that also means no key integrity checks (eg - does the subkey belong to master key). Now, the code is significant in the following respect - the module 'contrib/pgcrypto' is complete. As I said, I don't think rest of the OpenPGP makes sense here, and there isn't any other generally-useful crypto functionality that would be good to have. Still, there are various things to do: 1. Polishing of the new PGP code. 2. Rework documentation and add FAQ. 3. Try to extract OpenSSL and zlib settings from main PostgreSQL config. Basically that means that ./configure should put them to separate variables, not into main CFLAGS. 4. Include strong RNG. Yarrow, Fortuna, ?. This is for both symmetricy and public-key encryption. 5. Include bignum code (only ops needed for Elgamal). This is for public-key encrypt/decrypt. 6. Propose crypt(), gen_salt() into mainline for 8.2. They are self-contained, except crypt-md5 depends on a MD5 implentation, which already exists in mainline. Points 4 and 5 are suspicious - I'm not yet sure it can be done in manageable way. But without those, the PGP functions are unusable in default build. It may not be that bad - Yarrow/Fortuna seem to be small pieces only requiring external cipher and hash, which we have. And I could drop parts of libtommath into separate directory. But I don't think such things should be done in hurry. In the end, I think the code can go into 8.1 in current state - requiring OpenSSL. I'll look into dependencies in 8.2 timeframe. -- marko [ Attachment, skipping... ] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] Dbsize backend integration
On Monday 04 July 2005 10:11, Dave Page wrote:
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 04 July 2005 14:54
To: Dave Page
Cc: Dawid Kuroczko; Andreas Pflug; Bruce Momjian;
PostgreSQL-patches; PostgreSQL-development
Subject: Re: [HACKERS] [PATCHES] Dbsize backend integration
Dave Page dpage@vale-housing.co.uk writes:
Aside from the fact that's a change to the API that we had
settled on,
it doesn't solve the actual problem of needing a suitable name for a
function that returns the size of a table /or/ index.
pg_relation_size()
or pg_table_size() can't be used for precisely the reason they were
rejected for that purpose in the first place.
Rejected by whom? pg_relation_size is an excellent choice for that.
Bruce didn't like it
(http://archives.postgresql.org/pgsql-hackers/2005-06/msg01410.php), and
you seemed to object as well
(http://archives.postgresql.org/pgsql-hackers/2005-06/msg01247.php)
Personally I'm beyond caring much now as the amount of time spent trying
to name these simple functions is wildly disproportionate the the effort
take to actually code them. I think we just need to agree there is no
perfect name and rely on the comments and docs to guide people. I think
the current names work OK, and Bruce and Dawid at least agree!
Actually I'd agree with Tom, pg_dbfile_size is ugly, and suggest to me I could
use a filename as an argument. ISTM that if we think that functions like
pg_database_size and pg_tablespace_size all make sense, the natural extension
would be functions called pg_index_size to tell us the size of an index,
pg_table_size to tell us the size of a table (table+toast) without it's
indexes, and some form of pg_table_plus_indexes_size for a table and its
indexes for those that feel we need both. I'm not sold we need a function
that can return either an index or table size, but if so something like
pg_object_size seems ambigious enough to work, and is future proof enough to
handle things like materialized views when and if they arise.
Just my .02 :-)
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Dbsize backend integration
Robert Treat wrote: Actually I'd agree with Tom, pg_dbfile_size is ugly, and suggest to me I could use a filename as an argument. ISTM that if we think that functions like pg_database_size and pg_tablespace_size all make sense, the natural extension would be functions called pg_index_size to tell us the size of an index, pg_table_size to tell us the size of a table (table+toast) without it's indexes, and some form of pg_table_plus_indexes_size for a table and its indexes for those that feel we need both. I'm not sold we need a function that can return either an index or table size, but if so something like pg_object_size seems ambigious enough to work, and is future proof enough to handle things like materialized views when and if they arise. You are into the cycle we were in. We discussed pg_object size (too vague) and pg_index_size (needs pg_toast_size too, and maybe toast indexes; too many functions). -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] HEAD doesn't cope with libraries in non-default locations
On Mon, Jul 04, 2005 at 04:14:51PM +1200, Oliver Jowett wrote: Tom Lane wrote: It appears that somebody has changed things so that the -L switches appear after the -l switches (ie, too late). I'm too tired to investigate now, but my money is on Autoconf 2.59 being the problem ... Perhaps this: http://archives.postgresql.org/pgsql-hackers/2005-07/msg00085.php Would be my guess as well... So should includes/linking for PostgreSQL-built libs be handled seperately? The original problem was that if --with-libraries was specified then libpq etc would be linked from the system locations instead of from within the build. -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] HEAD doesn't cope with libraries in non-default locations
Jim C. Nasby wrote: On Mon, Jul 04, 2005 at 04:14:51PM +1200, Oliver Jowett wrote: Tom Lane wrote: It appears that somebody has changed things so that the -L switches appear after the -l switches (ie, too late). I'm too tired to investigate now, but my money is on Autoconf 2.59 being the problem ... Perhaps this: http://archives.postgresql.org/pgsql-hackers/2005-07/msg00085.php Would be my guess as well... So should includes/linking for PostgreSQL-built libs be handled seperately? The original problem was that if --with-libraries was specified then libpq etc would be linked from the system locations instead of from within the build. Yes, I think so. Peter Eisentraut's analysis strikes me as being correct. cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Catch the commit
On Thu, 30 Jun 2005 00:06:42 +0200 Andreas 'ads' Scherbaum [EMAIL PROTECTED] wrote: is it possible in a module to receive an event, get a trigger fired, get a function called or something like this when the current transaction is about to be committed? Background: In a module (tablelog) i need the latest possible timestamp before committing the data for the case, that there is more then one started transaction. If this happens and the second transaction is commited first, i have for the time the first transaction is going on invalid data in my log. To imagine the problem a little bit: tablelog() does logging of all changes on a table. Here an example: - start of transaction 1 - insert in transaction 1 - start of transaction 2 - insert in transaction 2 - commit transaction 2 - commit transaction 1 In the real world, if i look into the table between commit 2 and 1, i only would see the second insert. But since i have no idea, how to get the time of the commit, for now i log the current timestamp ( now() ). If i use the logged data later and restore the state of the table between the two commits, i see both inserts. Which is actually wrong. The problem only occurs if there are concurrent transactions and only, if a timestamp between the commits is requested. But since it exist, i cannot always be sure to return the correct data. Has anybody an idea about this? Kind regards -- Andreas 'ads' Scherbaum Failure is not an option. It comes bundled with your Microsoft product. (Ferenc Mantfeld) ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] Warnings compiling preproc.y
Compiling HEAD I see the following 2 warnings: ... make[4]: Leaving directory `/home/viy/prj/pgb/src/interfaces/ecpg/compatlib' make -C preproc all make[4]: Entering directory `/home/viy/prj/pgb/src/interfaces/ecpg/preproc' make -C ../../../../src/port all make[5]: Entering directory `/home/viy/prj/pgb/src/port' make[5]: Nothing to be done for `all'. make[5]: Leaving directory `/home/viy/prj/pgb/src/port' bison -y -d preproc.y mv -f y.tab.c ./preproc.c mv -f y.tab.h ./preproc.h /usr/bin/flex -o'pgc.c' pgc.l gcc -O2 -ggdb -DBITMAP_DEBUG -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g -Wno-error -I./../include -I. -I../../../../src/include -D_GNU_SOURCE -DMAJOR_VERSION=4 -DMINOR_VERSION=1 -DPATCHLEVEL=1 -c -o preproc.o preproc.c -MMD In file included from preproc.y:6416: pgc.c: In function `yylex': pgc.c:1503: warning: label `find_rule' defined but not used preproc.y: At top level: pgc.c:3559: warning: `yy_flex_realloc' defined but not used Should those variables be removed? -- Victor Y. Yegorov ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Warnings compiling preproc.y
Victor Yegorov wrote: Compiling HEAD I see the following 2 warnings: bison -y -d preproc.y mv -f y.tab.c ./preproc.c mv -f y.tab.h ./preproc.h /usr/bin/flex -o'pgc.c' pgc.l gcc -O2 -ggdb -DBITMAP_DEBUG -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g -Wno-error -I./../include -I. -I../../../../src/include -D_GNU_SOURCE -DMAJOR_VERSION=4 -DMINOR_VERSION=1 -DPATCHLEVEL=1 -c -o preproc.o preproc.c -MMD In file included from preproc.y:6416: pgc.c: In function `yylex': pgc.c:1503: warning: label `find_rule' defined but not used preproc.y: At top level: pgc.c:3559: warning: `yy_flex_realloc' defined but not used Should those variables be removed? These warnings aren't new; the fault lies in the C code generated by flex, so the problem is not simple to fix. -Neil ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [PATCHES] Dbsize backend integration
-Original Message- From: Robert Treat [mailto:[EMAIL PROTECTED] Sent: 04 July 2005 18:21 To: Dave Page Cc: Tom Lane; Dawid Kuroczko; Andreas Pflug; Bruce Momjian; PostgreSQL-patches; PostgreSQL-development Subject: Re: [HACKERS] [PATCHES] Dbsize backend integration Actually I'd agree with Tom, pg_dbfile_size is ugly, and suggest to me I could use a filename as an argument. I won't repeat Bruce's reply to you, but as an FYI, the reason Bruce suggested pg_dbfile_size over the nicer pg_file_size is that our instrumentation patch includes that particular function, which does accept a filename (provided it's under $PGDATA or the log directory). Dbfile was meant to indicate it's a database related file, rather than some arbitrary filename. /D ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [PATCHES] [PATCH] pgcrypto: pgp_encrypt v3
Bruce Momjian wrote: Your patch has been added to the PostgreSQL unapplied patches list That is not the latest version of Marko's patch. But in any case, the patch is not yet ready for application: http://archives.postgresql.org/pgsql-patches/2005-07/msg00077.php -Neil ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] Dbsize backend integration
On Monday 04 July 2005 13:25, Bruce Momjian wrote:
Robert Treat wrote:
Actually I'd agree with Tom, pg_dbfile_size is ugly, and suggest to me I
could use a filename as an argument. ISTM that if we think that
functions like pg_database_size and pg_tablespace_size all make sense,
the natural extension would be functions called pg_index_size to tell us
the size of an index, pg_table_size to tell us the size of a table
(table+toast) without it's indexes, and some form of
pg_table_plus_indexes_size for a table and its indexes for those that
feel we need both. I'm not sold we need a function that can return
either an index or table size, but if so something like pg_object_size
seems ambigious enough to work, and is future proof enough to handle
things like materialized views when and if they arise.
You are into the cycle we were in. We discussed pg_object size (too
vague) and pg_index_size (needs pg_toast_size too, and maybe toast
indexes; too many functions).
Yeah, I read those discussions, and think you were better off then than you
are now, which is why I went back to it somewhat.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(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: [HACKERS] [PATCHES] Dbsize backend integration
You are into the cycle we were in. We discussed pg_object size (too vague) and pg_index_size (needs pg_toast_size too, and maybe toast indexes; too many functions). Yeah, I read those discussions, and think you were better off then than you are now, which is why I went back to it somewhat. To be honest, the amount of effort being expended on this naming discussion far outweighs the benefits. Maybe it's time for a core member to step in and just resolve it - one way or the other? Chris ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] New warnings in plgsql/src/scan.l
Alvaro Herrera [EMAIL PROTECTED] writes: On Mon, Jul 04, 2005 at 06:51:48PM +0200, Peter Eisentraut wrote: This warning has existed in one from or another ever since the latest flex version is in use. Really? Hmm, maybe the issue is that my system upgraded itself. I see flex is at 2.5.31 ATM, not sure how to find out when it was upgraded. 2.5.31 is known broken; our only response to problems with it is use 2.5.4. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
