Re: [HACKERS] pgsql-server: Tablespaces.
(Moved to -hackers) Log Message: --- Tablespaces. Alternate database locations are dead, long live tablespaces. Sweet :) There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Comment on TABLESPACE is impossible, no? Tablespaces are a global relation and pg_description isn't. I'll do RENAME and OWNER TO for tablespaces with this patch I'm working on atm if people like. Chris ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] signal 11 on AIX: 7.4.2
My only guess is that getaddrinfo in your libc has a bug somehow that is corrupting the stack (hance the improper backtrace), then crashing. It could be libc on AIX, I suppose, but it strikes me as sort of odd that nobody else ever seens this. Unless nobody else is using AIX 5.1, which is of course possible. I can confirm, that AIX 4.3.2 getaddrinfo is at least a bit *funny*. getaddrinfo seems to not honour nsorder and only does dns, even though the manual sais: Should there be any discrepancies between this description and the POSIX description, the POSIX description takes precedence. The function does return multiple entries, often the first is not the best. Log is: LOG: could not translate service 5432 to address: Host not found WARNING: could not create listen socket for * LOG: could not bind socket for statistics collector: Can't assign requested address LOG: disabling statistics collector for lack of working socket This area probably needs a fix/workaround on AIX :-( Andreas ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] CREATE TABLE ... LIKE composite type
Hi, Is there any reason that the following shouldn't work: CREATE TABLE my_new_table (LIKE my_composite_type); I get the following error (in 7.4.2): ERROR: my_composite_type is a composite type With the improved handling of composite types, will this work in 7.5? Cheers -- Mark Gibson gibsonm |AT| cromwell |DOT| co |DOT| uk Web Developer Database Admin Cromwell Tools Ltd. Leicester, England. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] signal 11 on AIX: 7.4.2
On Thu, Jun 17, 2004 at 06:06:12PM -0400, Bruce Momjian wrote: When you say init directory, what do you mean? /bin? No. The place where the init scripts (which cause postgres to start) live. A -- Andrew Sullivan | [EMAIL PROTECTED] In the future this spectacle of the middle classes shocking the avant- garde will probably become the textbook definition of Postmodernism. --Brad Holland ---(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
[HACKERS] SPI equivalent for libpq PQftable PQFtablecolumn
First time I posted a question using complicated example, but this time I'll be wiser and simplify the question: What is SPI equivalent for libpq PQftable PQFtablecolumn functions ? Regards ! ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pgsql-server: Tablespaces.
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Comment on TABLESPACE is impossible, no? Tablespaces are a global relation and pg_description isn't. Well, it has the same issues as COMMENT ON DATABASE, which we support, though crudely. Perhaps we should think about creating a shared version of pg_description so we could have more reasonable support for comments on shared objects. I'm not in a hurry for this but it would be a reasonable TODO item. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] CREATE TABLE ... LIKE composite type
Mark Gibson [EMAIL PROTECTED] writes: Is there any reason that the following shouldn't work: CREATE TABLE my_new_table (LIKE my_composite_type); Probably not. I can think of reasons why we might not want to let you INHERIT from a composite type, but LIKE is just a one-time copy-the- row-descriptor thing, so it doesn't seem like there should be a problem. Most likely this is happening because LIKE and INHERITS share a lot of code. Anyone feel like looking into it? (I'm not gonna, have too much else to do...) regards, tom lane ---(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
[HACKERS] 7.5-dev, pg_dumpall, dollarquoting
Hi! since we have a lot of databases here that suffer from pg_dump's deficits in 7.3 and 7.4 regarding dependencies, we tried pg_dump from the upcoming 7.5 release. This version works much better, but it is not possible to dump a complete cluster using pg_dumpall in a 7.3 or 7.4 compatible way because pg_dumpall lacks the -X disable-dollar-quoting switch. Would it be possible to modify pg_dumpall to accept the same commands as pg_dump (at least those that make sense) - or am I missing something here ? thanks Stefan ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] SPI equivalent for libpq PQftable PQFtablecolumn
Darko Prenosil [EMAIL PROTECTED] writes: What is SPI equivalent for libpq PQftable PQFtablecolumn functions ? There is none. SendRowDescriptionMessage gets the column ID info by rooting around in the targetlist of the SELECT query, and you'd have to do the same. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] specifying multiple result format codes with libpq
The documentation for PQexecPrepared says:
(There is not currently a provision to obtain different result
columns in different formats, although that is possible in the
underlying protocol.)
Would anyone be interested in a patch to allow this?
I could, for example, change PQsendQueryGuts to do something like:
static int PQsendQueryGuts( PGconn *conn,
const char *command,
const char *stmtName,
int nParams,
const Oid *paramTypes,
const char *const *paramValues,
const int *paramLengths,
const int *paramFormats,
int resultFormat,
... ) /* Add this last argument. */
{
...
if ( resultFormat == -1 ) { /* or == nParams, perhaps? */
va_list args;
const int *resultFormats;
va_start( args, resultFormat );
resultFormats = va_arg( args, const int * );
va_end( args );
if ( pqPutInt( nParams, 2, conn ) 0 )
goto sendFailed;
for ( i = 0; i nParams; i++ )
if ( pqPutInt( resultFormats[i], 2, conn ) 0 )
goto sendFailed;
}
/* This is what libpq does already. */
else if ( pqPutInt( 1, 2, conn ) 0 ||
pqPutInt( resultFormat, 2, conn ) )
goto sendFailed;
...
}
And then teach the other API functions (PQexecParams, PQsendQueryParams,
PQsendQueryPrepared) to accept and pass on the extra ... argument. That
wouldn't break existing code, and new users could set resultFormat to
invoke the new behaviour. It seems a bit ugly, but on the other hand,
it doesn't seem worthwhile to add a new interface for this behaviour.
Thoughts?
-- ams
---(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] korean encoding, but sort order bad
joseph speigle [EMAIL PROTECTED] writes: [EMAIL PROTECTED] pgsql]$ initdb --locale=ko_KR --lc-messages=C -E unicode -D `pwd`/unidata Is that a valid combination of locale and encoding? The locale setting implies a particular encoding, but unfortunately Postgres has no way to tell which one. You may need a locale called ko_KR.utf8 or similar if you want to use unicode encoding. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] SPI equivalent for libpq PQftable PQFtablecolumn
Thanks (again) Tom, I'll try to do as You suggested. I was poking around backend libpq, but was unable to find where exactly that information is prepared and send to libpq buffer. Regards ! - Original Message - From: Tom Lane [EMAIL PROTECTED] To: Darko Prenosil [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, June 18, 2004 5:03 PM Subject: Re: [HACKERS] SPI equivalent for libpq PQftable PQFtablecolumn Darko Prenosil [EMAIL PROTECTED] writes: What is SPI equivalent for libpq PQftable PQFtablecolumn functions ? There is none. SendRowDescriptionMessage gets the column ID info by rooting around in the targetlist of the SELECT query, and you'd have to do the same. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html ---(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] Using domains for case insensitivity
Peter Eisentraut [EMAIL PROTECTED] writes: Shachar Shemesh wrote: According to the docs, domains are not meant for that purpose, but for changing constraints of a type. Is it possible to define a domain that will have the same defaults and constraints as the base type, but will have different comparison functions? Will that provide me with what I need? Domains constrain the allowed values of a data type and nothing more. If you were able to override operators, then you would create a new data type, thus losing a fundamental property of domains. So this is not the route you want to pursue. I agree. I think there are some cases where the function resolution code would pick a function declared to take the domain as input, but it'd be a chancy thing, because for all nontrivial cases the code first flattens domains to base types. You can make a separate type that just happens to use the same I/O functions, and then create a binary-compatible cast to the old type to allow free use of the existing operators. This is much more likely to work reliably. regards, tom lane ---(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: [HACKERS] Casts question
Shachar Shemesh [EMAIL PROTECTED] writes: I have defined a datatype called varcharci, shamelessly yanking the input, output, recv and send functions from varchar. This means (as far as I understand things) that this type is binary compatible with varchar. Use text, not varchar. Why is that? Being as it is that no operator = is defined for varcharci, and that the cast from varchar to varcharci is as assignment anyways, shouldn't postgres be able to do the cast implicitly? Yes, it can cast to varchar, but that doesn't help because there are no varchar operators ;-). To resolve the operator, it has to promote both sides to text, and you didn't offer a cast to text. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] specifying multiple result format codes with libpq
Abhijit Menon-Sen [EMAIL PROTECTED] writes: The documentation for PQexecPrepared says: (There is not currently a provision to obtain different result columns in different formats, although that is possible in the underlying protocol.) Would anyone be interested in a patch to allow this? Yes, but not the way you suggest. The ... approach forces calling code to know *when it is written* how many result columns there will be, because you'd have to actually write that number of parameters in the call. This is true in some simple cases but it's way too inflexible. AFAICS this would need additional libpq functions with different signatures, viz a count+array of result formats. I desisted from doing that in the 7.4 cycle because I thought the whole PQexec API probably ought to be rethought in the light of the v3 protocol, and I didn't want to provide a plethora of functions that would soon be deprecated. No one's gotten around to thinking about a more general redesign of libpq's query API yet, but I'd rather see us do that than put more warts on the functions we have ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Timestamp format question
Hello: A user of the PgSqlClient ADO.NET provider is having problems when with timestamp and time values, he has a postgres 7.4.1 postgres install in a Suse machine. The provider works implements v3.0 of the postgres protocol handling timestamp andtime in binary format, the problem seems to be that the server is sending the timestamp value encoded as an Int64, but when running the same test against the postgresql snapshot for win32 the value seems to be encoded as a double :-\ (i have run the same test postgres 7.4.2 on Fedora Core 1 and seem s to be sending it encoded as a double) What is the supposed format that should be expected for time and timestamp values in binary format ?? There are any way to retrieve the value encoded always in the same way ?? or i'm making something really bad ?? :) -- Best regards Carlos Guzmán Álvarez Vigo-Spain ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] pgsql-server: Tablespaces.
Tom Lane wrote: Christopher Kings-Lynne [EMAIL PROTECTED] writes: Comment on TABLESPACE is impossible, no? Tablespaces are a global relation and pg_description isn't. Well, it has the same issues as COMMENT ON DATABASE, which we support, though crudely. Perhaps we should think about creating a shared version of pg_description so we could have more reasonable support for comments on shared objects. I'm not in a hurry for this but it would be a reasonable TODO item. There are more sharing issues with tablespaces (which are already supported in pgadmin3, btw :-) To drop a tablespace, it must be empty, but it can be quite painful to find out which objects are populating it. Currently, every database has to be queried for pg_class.reltablespace=mytablespaceoid. I'd love to show tablespace dependency information, which would require some sort of global pg_namespace, pg_class and pg_index. Any thoughts about this? Regards, Andreas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Timestamp format question
=?ISO-8859-1?Q?Carlos_Guzm=E1n_=C1lvarez?= [EMAIL PROTECTED] writes: What is the supposed format that should be expected for time and timestamp values in binary format ?? Depends whether you built the server with --enable-integer-timestamps or not. There are any way to retrieve the value encoded always in the same way ? Sure: don't use binary I/O. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Timestamp format question
Hello: Depends whether you built the server with --enable-integer-timestamps or not. Thanks :) Sure: don't use binary I/O. hehe ... :-\ i will do ... thanks again :) -- Best regards Carlos Guzmán Álvarez Vigo-Spain ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] Configuration patch
Mark (see I remembered your name), where are we on this patch? It needs docs and include has to be redone. Should I remove the include part of the patch, add docs, and apply it? --- [EMAIL PROTECTED] wrote: Where are we on this? That's a good question. Tom doesn't like the syntax of include and there are a couple bugs he is concered it. I'm pretty agnostic about the syntax, but I wouldn't get overly worried about the metaphor presented either. include='...' doesn't bother me at all, but some people have a problem with it. Then there is the design of using a callable function for a configuration parameter, personally, I think this feature is useful for the future, Tom seems to have a problem it it. After that, the discussion sort of ends. I'm willing to adress the bugs. I don't think the syntax is a huge deal, IMHO at most it is a documentation problem. --- Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: One interesting idea would be for SET include to work like this: SET include '/var/run/xx' Notice there is no equals here. This would allow users to create files with various settings and enable them all with one SET command. However, this does open a security issue. More than one, in fact. In the first place, as the code presently works, anything coming in from the file would be treated on an equal footing with values sourced from postgresql.conf, thereby allowing unprivileged users to set things they shouldn't. This is potentially fixable, but the other issue isn't: such a facility would allow anyone to ask the backend to read any file the Postgres user account can access. Not very successfully, perhaps, but even the error messages might give useful info about the file's contents to an attacker. This is the same reason that COPY FROM file is a privileged operation. I think it's important that include be restricted to appear only in config files, and not be in any way shape or form a SETtable thing. In summary, I think we need to treat include specially in postgresql.conf (no equals) and remove it as an actual GUC parameter and just have it do includes immediately. (This will probably require special-casing it in the guc-file grammar.) Yes. In fact, it'll be a less-than-trivial change in guc-file, at least if you want the thing to act intuitively (that is, include acts like the target file is actually included right here). This will mean splitting ProcessConfigFile into a recursive read step followed by a nonrecursive apply step. Also, I think that invoking the flex lexer recursively will take a little bit of work. I would suggest splitting the patch into two separate patches, one that handles include and one that handles the other changes. The other stuff is reasonably close to being ready to apply (modulo docs and fixing the standalone-backend case), but include I think is still a ways off. regards, tom lane -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match ---(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 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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] specifying multiple result format codes with libpq
At 2004-06-18 13:11:19 -0400, [EMAIL PROTECTED] wrote: Would anyone be interested in a patch to allow this? Yes, but not the way you suggest. The ... approach forces calling code to know *when it is written* how many result columns there will be, because you'd have to actually write that number of parameters in the call. I suspect I didn't explain my proposal sufficiently well. The signature of, say, PQexecParams does get ... added on to it, but new callers pass in only a count and an array, not one argument per expected result. That way, existing callers would continue to compile without any changes, and new code tells the function to look for the extra arguments by specifying a currently-invalid value for the resultFormat parameter. That said, however: No one's gotten around to thinking about a more general redesign of libpq's query API yet, but I'd rather see us do that than put more warts on the functions we have ... I am in complete agreement with that sentiment. -- ams ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Cannot initdb in cvs tip
Dave Page [EMAIL PROTECTED] writes: I'm getting the following error when trying to initdb with CVS tip. creating template1 database in C:/msys/1.0/local/pgsql/data/base/1 ... ERROR: could not open segment 1 of relation 1663/1/1255 (target block 26189776): No such file or directory The target block number is obviously broken :-(. But maybe you have a build consistency problem --- did you try a make distclean and full rebuild? although it says it's clearing the contents of the directory, in actual fact it leaves the directory structure in place, thus a subsequent initdb will not run without a manual clearup. Hm. The rmtree() function in initdb.c is responsible for this, and I see it has WIN32-specific behavior, which is evidently wrong. Can you recommend a fix? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] signal 11 on AIX: 7.4.2
Quoth [EMAIL PROTECTED] (Bruce Momjian): Andrew Sullivan wrote: On Thu, Jun 17, 2004 at 01:12:10PM -0400, Bruce Momjian wrote: Well, the bad news is that this backtrace isn't very useful. No kidding. It's pretty frustrating. My only guess is that getaddrinfo in your libc has a bug somehow that is corrupting the stack (hance the improper backtrace), then crashing. It could be libc on AIX, I suppose, but it strikes me as sort of odd that nobody else ever seens this. Unless nobody else is using AIX 5.1, which is of course possible. One hypothesis is that this is happening at start up time (this core dump didn't show up in the data/ area, but in the init directory, however, which makes that theory a little suspect). When you say init directory, what do you mean? /bin? No, it's a directory with various init-like scripts. In premium hosting environments, root access is restricted to the site operators, so PostgreSQL doesn't get started up from /etc/init.d. Instead, PostgreSQL and other services get invoked by custom init scripts in a custom init directory. -- let name=cbbrowne and tld=ntlug.org in name ^ @ ^ tld;; http://www.ntlug.org/~cbbrowne/sap.html I am a bomb technician. If you see me running, try to keep up... ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] email browser?
Santo Quartarone [EMAIL PROTECTED] writes: What's the safest email browser? less is pretty safe, more or less ;-). You didn't specify what sort of platform you wanted to use; the choices vary, considerably, between platforms. -- (format nil [EMAIL PROTECTED] cbbrowne cbbrowne.com) http://cbbrowne.com/info/oses.html Who is General Failure and why is he reading my hard disk? -- [EMAIL PROTECTED], Felix von Leitner ---(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
[HACKERS] Minor DROP TABLESPACE issue
Although DROP TABLESPACE can detect tables existing in the target tablespace, it doesn't have any way to detect schemas that reference that tablespace as their default tablespace. Thus you can get implementation-level failures like this one: $ mkdir /tmp/junk regression=# create tablespace junk location '/tmp/junk'; CREATE TABLESPACE regression=# create schema junk tablespace junk; CREATE SCHEMA regression=# drop tablespace junk; DROP TABLESPACE regression=# create table junk.foo(f1 text); ERROR: could not create directory /u/pg_data/pg_tablespaces/292909/155056: No such file or directory regression=# The fact that it fails isn't a big problem, but the error message is pretty unclear if you're unfamiliar with the implementation. The same problem would exist with respect to a database's default tablespace, except that a database will always have its system catalogs stored there and so the file-level check prevents dropping the tablespace. I don't think we can directly prevent the DROP TABLESPACE, since we can't see what's in pg_namespace of other databases. I thought about creating a placeholder file associated with every schema that has a nondefault tablespace, thereby allowing the file-level check to detect the problem. But that looks very ugly, not least because namespaces don't have relfilenode values. What might be the most appropriate solution is just to issue a specialized error message in TablespaceCreateDbspace(): if mkdir fails with ENOENT, we could say something like ERROR: tablespace 292909 has been deleted after making an appropriate stat() test to verify that the symlink is indeed gone. It's not great that we'd have to use the OID in this message, but since the pg_tablespace row is (presumably) gone I don't see any way to get the actual name of the tablespace. Anyone see other alternatives? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Minor DROP TABLESPACE issue
On Fri, 18 Jun 2004, Tom Lane wrote: Although DROP TABLESPACE can detect tables existing in the target tablespace, it doesn't have any way to detect schemas that reference that tablespace as their default tablespace. Thus you can get implementation-level failures like this one: Of course. Never thought of that one. The fact that it fails isn't a big problem, but the error message is pretty unclear if you're unfamiliar with the implementation. The same problem would exist with respect to a database's default tablespace, except that a database will always have its system catalogs stored there and so the file-level check prevents dropping the tablespace. Is it really that bad? NamespaceCreate() could just touch a file at pg_tablespaces/tablespaceoid/MyDatabaseId/namespace oid and RemoveSchema() could remove it. Is there anything ugly that I've missed? Gavin ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] email browser?
On Fri, 2004-06-18 at 08:24, Chris Browne wrote: Santo Quartarone [EMAIL PROTECTED] writes: What's the safest email browser? less is pretty safe, more or less ;-). You didn't specify what sort of platform you wanted to use; the choices vary, considerably, between platforms. I'd say pine is pretty darned safe... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Minor DROP TABLESPACE issue
On Fri, 18 Jun 2004, Tom Lane wrote: Gavin Sherry [EMAIL PROTECTED] writes: Is it really that bad? NamespaceCreate() could just touch a file at pg_tablespaces/tablespaceoid/MyDatabaseId/namespace oid and RemoveSchema() could remove it. No, because that wouldn't be rollback-safe. You'd have to make the placeholder file act enough like a real relation that the smgr delete-at-commit-or-abort mechanisms could handle it. So then you have to buy into not having its name actually collide with any real relations, which is where I started feeling like I didn't want to pursue that solution. This is certainly doable in theory, it just seems like much more complexity than the problem is worth ... Oh yeah... I forgot about OID wrap around issues and integration into WAL, etc, wouldn't be great fun. If we just wanted to make the error message more user friendly, perhaps we could *gulp* store the tablespace name in PG_VERSION. Then again, all of this can probably be handled better in the manual. Gavin ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Minor DROP TABLESPACE issue
On Fri, 18 Jun 2004, Tom Lane wrote: Gavin Sherry [EMAIL PROTECTED] writes: If we just wanted to make the error message more user friendly, perhaps we could *gulp* store the tablespace name in PG_VERSION. That's actually not a bad idea from a debugging standpoint. But I don't see that it helps any for this particular problem. The PG_VERSION file will be gone when we need the info. Duh. I best get some coffee into me. Gavin ---(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] More vacuum.c refactoring
Where are we on this? --- Tom Lane wrote: Manfred Koizar [EMAIL PROTECTED] writes: I understand you, honestly. Do I read between your lines that you didn't review my previous vacuum.c refactoring patch? Please do. It'd make *me* more comfortable. I did not yet, but I will get to it. I encourage everyone else to take a look too. I agree with Alvaro that fooling with this code merits extreme caution. BTW, I do not at all mean to suggest that vacuum.c contains no bugs at the moment ;-). I suspect for example that it is a bit random about whether MOVED_OFF/MOVED_IN bits get cleared immediately, or only by the next transaction that chances to visit the tuple. The next-transaction-fixup behavior has to be there in case the VACUUM transaction crashes, but that doesn't mean that VACUUM should deliberately leave work undone. I see three significant differences between the code in repair_frag() and vacuum_page(). Will study these comments later, but it's too late at night here... again, the more eyeballs on this the better... 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 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] [HACKERS] serverlog function (log_destination file)
Were are we on this?
---
Andreas Pflug wrote:
Tom Lane wrote:
This has got portability issues (fopen(ab))
My doc says b is ignored on ansi systems, and recommends using it. Do
you have other experiences?
and I don't care for its
use of malloc in preference to palloc either.
Do we already have an applicable memory context in the postmaster at
that early stage of initialization?
Also, pg_logfile() will dump core if LogFileName returns null.
How that?
char *filename=LogFileName();
if (filename)
{
...
free(filename);
}
The bigger issue though is whether this is useful at all, if you cannot
solve the file rotation issue (and I don't think you can). As
implemented, the secondary log file cannot be truncated without
restarting the postmaster. I think that reduces it from a possibly
useful feature to a useless toy.
This patch isn't trying to be better on logfile handling than the
default stderr redirection behavior, besides being able to access it
through the postmaster. Seems you insist to name this a toy, many users
don't.
(The fact that pg_logfile_length
returns int and not something wider is pretty silly in this connection.)
2GB logfile seems pretty big...
Regards,
Andreas
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (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 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Twelve days to feature freeze
We have twelve days until July 1, feature freeze. Looking at our list: Win32 - need service manger code, installer is outside project Tablespaces - patch installed; discussing implementation and administration details. Nested transactions - submitted, with phantom xids; only needs trigger and guc work. Tom is going to review it in the next few days. We need to determine that we can complete all the needed nested transaction work by July 1, and we need to give Alvaro feedback so he can complete any needed items. I feel bad we haven't given him feedback sooner, but the patch is difficult to review because it is so large, and Alvaro has been continuing to improve it. With phantom xids done, he is almost complete so we need to give him feedback soon. PITR - Simon is working on doing restores by calling an external program to transfer one file at a time into the pg_xlog directory, processing it, then deleting it. I think he will be done in a few days, and we will review his patch soon. The only good thing about the delay in applying these patches is that the CVS tree isn't moving very much. We are also looking to get pg_autovacuum in the backend done and there are a number of almost-finished patches floating around that I hope we can get in. I will have sporatic connectivity after Monday while I am in Europe so will only be able to help occasionally. Tom will be doing most of the heavy lifting to get us to feature freeze. Thanks, Tom! -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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] Why frequently updated tables are an issue
Is there a TODO here? No one explained why frozen tuples are important. --- Tom Lane wrote: Jan Wieck [EMAIL PROTECTED] writes: On 6/12/2004 3:45 PM, Tom Lane wrote: I don't think it would help very much to define a bit like that --- I can't believe that very many pages would contain only frozen tuples, unless you were to adopt an aggressive policy of using VACUUM FREEZE a lot. I thought this implies an aggressive policy of freezing everything by default. But I guess there is something I am not aware of that makes aggressive freezing a bad thing. Well, it means extra I/O to freeze tuples that you otherwise probably never would. So it's not obvious that aggressive freezing in hopes of saving cycles later is a win. It might be interesting though to have some kind of fast vacuum mode that doesn't worry about freezing tuples, but only reclaiming dead ones. Wouldn't that screw the current FSM population mechanisms? Not that my suggestions above wouldn't do that either :-) Yeah, that's another wholesale mechanism that we'd have to look at refining. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 7: don't forget to increase your free space map settings
Re: [HACKERS] logfile rotation
Actually, this is the current state of this issue. --- Andreas Pflug wrote: Tom Lane wrote: Andreas Pflug [EMAIL PROTECTED] writes: Answering my own question, the distribution of the current logfile name could be done trough a file handle. would you mind commenting on my suggestion so I can continue on that topic? There is no portable way to redistribute a file handle. Seems I didn't make clear enough what I mean. I'd fopen a file handle in the postmaster, and all subsequent processes will inherit that handle just as they do for stderr; no redistribution required. The log filename is written to that file when pg_logfile_rotate is called: fseek(fh, 0, SEEK_SET); fprintf(fh, %s, newlogfilname); fflush(); and all subprocesses may retrieve the filename when required by char buf[MAXPGPATH]; fseek(fh, 0, SEEK_SET); fread(buf, 1, MAXPGPATH, fh); buf[MAXPGPATH-1]=0; // prevent buffer overflow logfile=fopen(buf, a+); Regards, Andreas -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pgsql-server: Tablespaces.
Well, it has the same issues as COMMENT ON DATABASE, which we support, though crudely. Perhaps we should think about creating a shared version of pg_description so we could have more reasonable support for comments on shared objects. I'm not in a hurry for this but it would be a reasonable TODO item. Just add a comment text column to the databases, users, groups and tablespaces tables. Then special case them in obj_description. Chris ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Cannot initdb in cvs tip
Tom Lane said: Dave Page [EMAIL PROTECTED] writes: I'm getting the following error when trying to initdb with CVS tip. creating template1 database in C:/msys/1.0/local/pgsql/data/base/1 ... ERROR: could not open segment 1 of relation 1663/1/1255 (target block 26189776): No such file or directory The target block number is obviously broken :-(. But maybe you have a build consistency problem --- did you try a make distclean and full rebuild? although it says it's clearing the contents of the directory, in actual fact it leaves the directory structure in place, thus a subsequent initdb will not run without a manual clearup. Hm. The rmtree() function in initdb.c is responsible for this, and I see it has WIN32-specific behavior, which is evidently wrong. Can you recommend a fix? You can use the builtin one I wrote originally (and tested quite a bit) that doesn't depend on system() calls ;-) cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Minor DROP TABLESPACE issue
ERROR: tablespace 292909 has been deleted How about schema default tablespace 292909 has been deleted? Chris ---(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] Twelve days to feature freeze
Bruce Momjian said: We have twelve days until July 1, feature freeze. Looking at our list: Win32 - need service manger code, installer is outside project Tablespaces - patch installed; discussing implementation and administration details. Nested transactions - submitted, with phantom xids; only needs trigger and guc work. Tom is going to review it in the next few days. We need to determine that we can complete all the needed nested transaction work by July 1, and we need to give Alvaro feedback so he can complete any needed items. I feel bad we haven't given him feedback sooner, but the patch is difficult to review because it is so large, and Alvaro has been continuing to improve it. With phantom xids done, he is almost complete so we need to give him feedback soon. PITR - Simon is working on doing restores by calling an external program to transfer one file at a time into the pg_xlog directory, processing it, then deleting it. I think he will be done in a few days, and we will review his patch soon. The only good thing about the delay in applying these patches is that the CVS tree isn't moving very much. We are also looking to get pg_autovacuum in the backend done and there are a number of almost-finished patches floating around that I hope we can get in. I will have sporatic connectivity after Monday while I am in Europe so will only be able to help occasionally. Tom will be doing most of the heavy lifting to get us to feature freeze. Thanks, Tom! I am still hopeful that we can get a significant plperl improvement before feature freeze, including shared data space, set returning funcs, composite returning funcs, triggers and an spi query mechanism. It will be touch and go and we might not make the cut, but i'm going to try. cheers andrew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Minor DROP TABLESPACE issue
Christopher Kings-Lynne [EMAIL PROTECTED] writes: ERROR: tablespace 292909 has been deleted How about schema default tablespace 292909 has been deleted? Yeah, I was wondering if we could finger the specific schema that was causing the problem, but the place that would detect the error couldn't really know that. Perhaps we could add a HINT advising to look in pg_namespace for the relevant entry. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pgsql-server: Tablespaces.
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Perhaps we should think about creating a shared version of pg_description so we could have more reasonable support for comments on shared objects. I'm not in a hurry for this but it would be a reasonable TODO item. Just add a comment text column to the databases, users, groups and tablespaces tables. Then special case them in obj_description. Hm ... seems like that requires more special cases, not fewer. What I was imagining was the current database-local pg_description plus a single shared table pg_shared_description. When you add more kinds of shared objects (SQL roles maybe?) obj_description doesn't need to change... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Twelve days to feature freeze
Andrew Dunstan [EMAIL PROTECTED] writes: I am still hopeful that we can get a significant plperl improvement before feature freeze, including shared data space, set returning funcs, composite returning funcs, triggers and an spi query mechanism. It will be touch and go and we might not make the cut, but i'm going to try. I think we're trying to discourage people from the submit big patch on June 30 mindset. If you've got any chance of making feature freeze then you must have something fairly interesting already. Put up a work-in-progress patch so that you can get some feedback sooner, instead of later. As an example, Alvaro's been putting up WIP patches for nested transactions regularly. I have to admit that I personally have been awful about giving him any feedback, but others have done more. 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
