[HACKERS] truncate all?

Hi! Would it be possible to implement a truncate all that purges all tuples from *all* tables, without taking account any rules or triggers, but leaving all table structures and rules, triggers, functions, etc intact (sequences do not need to reinitialized)? As far as I understand, the no

Re: [HACKERS] truncate all?

Hi there, I agree with Tom ... even the idea of a TRUNCATE ALL makes me nervous. If we had such a feature, I'd advocate that it be superuser only. This superuser only restriction certainly would be sensible. As for TRUNCATE CASCADE or similar improvements, I agree that they could be

Re: [HACKERS] truncate all?

Hi there, At 17:55 05.08.2003, Josh Berkus wrote: Another way to specify a safe but efficient TRUNCATE ALL command that might be easier to implement than above TRUNCATE table [CASCADE|RESTRICT] might be to implement the functionality of the originally suggested TRUNCATE ALL through a psql

[HACKERS] Tab completion for ALTER ... SET SCHEMA

(Query_for_list_of_schemas); + + /* BEGIN, END, ABORT */ else if (pg_strcasecmp(prev_wd, BEGIN) == 0 || pg_strcasecmp(prev_wd, END) == 0 || Regards, Andreas Karlsson -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Relax table alias conflict rule in 9.3?

, tom lane Great! :) This change would help me upgrade to 9.3x because I've got lots of views that use a table alias that gets rejected by 9.3 while restoring the dump of 9.2. When do you plan to have it in an official release? Cheers Andreas -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Experimental patch for inter-page delay in VACUUM

Zeugswetter Andreas SB SD wrote: Or... It seems to me that we have been observing something on the order of 10x-20x slowdown for vacuuming a table. I think this is WAY overcompensating for the original problems, and would cause it's own problem as mentioned above. Since the granularity

Re: [HACKERS] Open Sourcing pgManage

this). For web access, phpPGadmin should be usable; haven't tried so far. Regards, Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [pgsql-www] [HACKERS] Changes to Contributor List

to see how it could look like :) Mit freundlichen Grüßen Andreas Grabmüller - Original-Nachricht - Von: Dave Page [EMAIL PROTECTED] An: Peter Eisentraut [EMAIL PROTECTED], Robert Treat [EMAIL PROTECTED] CC: Alvaro Herrera [EMAIL PROTECTED], Josh Berkus [EMAIL PROTECTED], [EMAIL PROTECTED

Re: [HACKERS] logical column position

for working around situations that should be avoided anyway. Regards, Andreas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] logical column position

Dave Cramer wrote: Andreas, The point of this is to maintain the column position. I don't think that an alter of a column type should move the column position. Why should ALTER COLUMN change the column number, i.e. position? It may be that programmers should not rely on this, but it happens

Re: [HACKERS] logical column position

Dave Cramer wrote: Andreas, On Wed, 2003-11-19 at 13:07, Andreas Pflug wrote: Dave Cramer wrote: Andreas, The point of this is to maintain the column position. I don't think that an alter of a column type should move the column position. Why should ALTER COLUMN change the column

[HACKERS] ALTER COLUMN/logical column position

all dependent objects Voila! No need for an additional attpos. Regards, Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] ALTER COLUMN/logical column position

SELECT ... FROM pg_attribute ORDER BY attnum continue delivering the expected result. Regards, Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] logical column position

physical storage location. Regards, Andreas regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend ---(end of broadcast)--- TIP 9: the planner will ignore your desire

Re: [HACKERS] logical column position

Tom Lane wrote: Andreas Pflug [EMAIL PROTECTED] writes: I don't quite understand your argumentation. My point is that to change attnum into a logical position without breaking client apps (which is the ostensible reason for doing it that way), we would need to redefine all system catalog

Re: [HACKERS] logical column position

Tom Lane wrote: Andreas Pflug [EMAIL PROTECTED] writes: Maybe my proposal wasn't clear enough: Just as an index references a pg_class entry by it's OID, not some value identifying it's physical storage, all objects might continue referencing columns by attnum. That's exactly the same

Re: [HACKERS] logical column position

(which obviously isn't true, unless my proposed shortcut for binary compatible type changes is implemented). When dropping and recreating an object, nobody would expect to get the same identifier. When altering, I *do* expect the identifier to remain the same. Regards, Andreas

Re: [HACKERS] Anyone working on pg_dump dependency ordering?

, and modifying the dump will be hard if a table's code is scattered all around. Regards, Andreas ---(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] Anyone working on pg_dump dependency ordering?

the constraints. I still disagree. cyclic dependencies should be avoided anyhow. You'll get an awful lot of trouble loading data in such a case. Some database systems refuse to create such stuff right away (mssql). Regards, Andreas ---(end of broadcast

Re: [HACKERS] Anyone working on pg_dump dependency ordering?

FOREIGN KEY ; or CREATE TABLE xxx (, PRIMARY KEY (..), FOREIGN KEY (..)); I'd opt for the second version (a little formatted, maybe :-) Regards, Andreas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http

Re: [HACKERS] pg_dump dependency / physical hot backup

(probably including non-vacuumed rows), but because no checks are applied the restore process would be as fast as possible. This would be possible only for the same backend/architecture version, but in case of disaster recovery that's enough. Regards, Andreas ---(end

Re: [HACKERS] Anyone working on pg_dump dependency ordering?

replied 'use pg_dump'. It seems that pg_dump tries to serve both requirements, being a compromise where two dedicated tools could do it better. Regards, Andreas ---(end of broadcast)--- TIP 8: explain analyze is your friend

Re: [HACKERS] Build farm

operated manually :-) Regards, Andreas ---(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

Re: [HACKERS] pg_restore and create FK without verification check

method that dumps physical data, so at restore time there's no need for recreation of FKs. But I didn't see any feedback on this proposal either. Regards, Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] pg_restore and create FK without verification check

Hannu Krosing wrote: Andreas Pflug kirjutas K, 26.11.2003 kell 12:09: ow wrote: It appears there's not a lot of interest in discussing the possibility of FK constraint creation WITHOUT the verification check. How then should one handle the situation with pg_restore and large dbs where

Re: [HACKERS] pg_restore and create FK without verification check

ow wrote: --- Andreas Pflug [EMAIL PROTECTED] wrote: Yes, I mentioned it just a few days when discussing dependency in pg_dump. This is somewhat complementary to WAL and PITR. I'm seeking for a fast way to dump and restore a complete database, like physical file copy, without shutting down

Re: [HACKERS] pg_restore and create FK without verification check

Tom Lane wrote: Andreas Pflug [EMAIL PROTECTED] writes: This is somewhat complementary to WAL and PITR. I'm seeking for a fast way to dump and restore a complete database, like physical file copy, without shutting down the backend. I was thinking of a BACKUP command that streams out

Re: [HACKERS] pg_restore and create FK without verification check

that this should be so hard to fix. Regards, Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] pg_restore and create FK without verification check

ain't got yet. So I lay back patiently (more or less :-) Regards, Andreas ---(end of broadcast)--- TIP 8: explain analyze is your friend

Re: [HACKERS] ALTER COLUMN/logical column position

, Andreas ---(end of broadcast)--- TIP 8: explain analyze is your friend

Re: [HACKERS] pg_restore and create FK without verification check

to find, because EXPLAIN won't explain triggers. I'm planning to create some kind of fk index wizard in pgAdmin3, which finds out about fks using columns that aren't covered by an appropriate index. Maybe this check could be performed (as a NOTICE) when the fk is created? Regards, Andreas

Re: [HACKERS] pg_restore and create FK without verification check

ABC database, while leaving the other five in the cluster untouched. I'd drop that offending DB, restore it, and replay that WAL. Does this sound too esoteric? Regards, Andreas ---(end of broadcast)--- TIP 2: you can get off all lists at once

Re: [HACKERS] pg_restore and create FK without verification check

(this really shouldn't happen), but merely to send a NOTICE to the user so he can check if he maybe eventually by chance in doubt should create an index. Databases will certainly suffer much more from missing indexes than from too many indexes. Regards, Andreas ---(end

Re: [HACKERS] ALTER COLUMN/logical column position

% of daily column change work, that's why I implemented it in pgAdmin3 (targeting the system tables directly...), so it's worth the effort handling them separately. I might add it some time to the backend (as an additional code path to the big version). Regards, Andreas

Re: [HACKERS] Foreign key data type mismatches

the castability characteristics between the two data types? Sounds like a good idea. IMHO normally only *equal* data types should be referenced in a good data model design, but there's probably the need for some relaxed check option too. Regards, Andreas ---(end

Re: [HACKERS] [pgadmin-support] Cannot add an column of type serial

David Sigeti wrote: At 12:21 PM 12/10/2003 +0100, Andreas Pflug wrote: David Sigeti wrote: I am using pgadminIII 1.0.2 with PostgreSQL 7.4 under W2K SP4 and Cygwin (current as of 2 or 3 weeks ago). The server is running locally. If I attempt to add an column of type serial or bigserial

Re: [HACKERS] [PATCHES] Double Backslash example patch

... not yet tested, I'll have to check that patch. Regards, Andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] cascading column drop to index predicates

that span that single column should be dropped without CASCADE. Regards, Andreas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] cascading column drop to index predicates

Tom Lane wrote: Rod Taylor [EMAIL PROTECTED] writes: I think Andreas is trying to argue that if you drop column b from index (a, b) that the index should be converted into index(a) -- assuming of course there isn't already an index(a). That seems to be well outside the charter of DROP

Re: [HACKERS] Brokenness in parsing of pg_hba.conf

for clarity reasons. Regards, Andreas ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] Dumb question: How do I determine programmatically

Dann Corbit wrote: What API call can I make to find out if a column is nullable or not? SELECT attnotnull FROM pg_attribute ... see documentation Internals/System Catalogs Regards, Andreas ---(end of broadcast)--- TIP 1: subscribe

Re: [HACKERS] OLE DB driver

a proven piece of software. Regards, Andreas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] OLE DB driver

Shachar Shemesh wrote: Andreas Pflug wrote: I wonder if this could be implemented as a wrapper around libpq. This way, the OLEDB driver would benefit from a proven piece of software. Regards, Andreas That's what I'm doing. I'm not sure why other drivers didn't do that as well (maybe

Re: [HACKERS] Write cache

disabling write caching, because SCSI disks are usually targeted towards professional usage. Regards, Andreas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] RFC: Very large scale postgres support

in a single database? Regards, Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] RFC: Very large scale postgres support

dbms efforts that might well be replaced by organizational/app level tools. Regards, Andreas ---(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] RFC: Very large scale postgres support

Keith Bottner wrote: I understand your position Andreas and respect your opinion; maybe what I have identified as requirements is what you are specifying as *real* issues. I hope so, because I to would like to avoid unnecessary dbms efforts. You got me very right. I didn't mean to declare high

[HACKERS] Improved index creation (was:MS SQL features for new version)

the rest, now with locking, to get up-to-date. This way, the index creation impact on ins/upd/del would be minimized. Regards, Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] pg_restore problems and suggested resolution

bitten by triggers inadvertantly left disabled before...I think Tom has a good point. Might be, but disabled triggers are not only useful when restoring a database. We need this, and supporting this without hacking would be helpful. Regards, Andreas ---(end

Re: [HACKERS] A plan to improve error messages with context, hint

Fabien COELHO wrote: The current status of clients is that none of those I use will report anything useful. pgAdmin3's query tool will set a mark on the offending line. Regards, Andreas ---(end of broadcast)--- TIP 2: you can get off all lists

Re: [HACKERS] Tablespaces

purposes. IMHO there are only two viable options: - no tablespaces for win32, i.e. recommend *ix for bigger installations - a different tablespace storage approach., e.g. simple desktop links (or alike) redirecting to a directory. Regards, Andreas ---(end of broadcast

Re: [HACKERS] Slony-I makes progress

asking for opinions and input. I don't want this to be my baby. In the end I am a developer, not a DBA. I know how to do it, but don't have the ultimate wisdom about how to manage it. If somebody likes to contribute a gui tool, I'm sure we could help to implement this in pgAdmin3. Regards, Andreas

Re: [HACKERS] PITR Functional Design v2 for 7.5

until a full backup has been performed successfully. Regards, Andreas ---(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

Re: [HACKERS] PITR Functional Design v2 for 7.5

Tom Lane wrote: Andreas Pflug [EMAIL PROTECTED] writes: When I'm doing a file level hot backup, I can't be sure about the backup order. To be sure the cluster is in a consistent state regarding checkpoints, pg_clog must be the first directory backed up. You are going off in the wrong

Re: [HACKERS] grants

it on the todo-list) Regards, Andreas ---(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] PITR Functional Design v2 for 7.5

Tom Lane wrote: Andreas Pflug [EMAIL PROTECTED] writes: Tom Lane wrote: Why is that a useful approach? You might as well shut down the postmaster and do a cold filesystem backup, We're talking about *hot* backup, aren't we? Exactly. The approach you're sketching can't work

Re: [HACKERS] grants

Kris Jurka wrote: On Wed, 10 Mar 2004, Andreas Pflug wrote: Edgar Mares wrote: hi there i'm having troubles to find how to GRANT SELECT ON all-tables-onmydb TO specificuser this is just to give the access to specificuser to query the database and find troubles

Re: [HACKERS] PITR Functional Design v2 for 7.5

Tom Lane wrote: Andreas Pflug [EMAIL PROTECTED] writes: To clarify: I'd expect a cluster to be workable, if I - disable VACUUM until backup completed - issue CHECKPOINT - backup clog (CHECKPOINT and backup clog are the backup checkpoint) - backup all datafiles (which include at least all

Re: [HACKERS] The Name Game: postgresql.net vs. pgfoundry.org

www.pgfoundry.org C) Don't care as long as the porting is relatively painless. Isn't gforge a pgsql related project itself? So I'd suggest: www.postgresql.org - main PostgreSQL site gforge.postgresql.org - gforge interface site projectname.postgresql.org - gforge hosted projects Regards, Andreas

Re: [HACKERS] pg_advisor schema proof of concept

. Regards, Andreas ---(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] pg_advisor schema proof of concept

the advice can be shown as attribute of each object. Regards, Andreas ---(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] alter table alter columns vs. domains

on. Regards, Andreas ---(end of broadcast)--- TIP 8: explain analyze is your friend

Re: [HACKERS] MS SQL features for new version

Shridhar Daithankar wrote: Hi all, Just stumbled upon this. just an FYI, http://www.microsoft.com/sql/yukon/productinfo/top30features.asp Notice the Snapshot Isolation. Sounds like MVCC for MSSQL? Regards, Andreas ---(end of broadcast)--- TIP 5

[HACKERS] conversion problems with domains

PostgreSQL 7.3.2 CREATE DOMAIN testdom AS int4; CREATE TABLE testtab(testcol testdom); INSERT INTO testtab VALUES (1); INSERT INTO testtab VALUES (2); VACUUM ANALYZE testtab; SELECT * FROM testtab WHERE testcol 1; The select will give ERROR: convert_numeric_to_scalar: unsupported type

[HACKERS] setuid functions

? Best regards -- Andreas 'ads' Scherbaum ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] new food for the contrib/ directory

Justin Clift wrote: Hi Bruce, Haven't looked at the code, but there's no license with it. Andreas, are you cool with having the same License as PostgreSQL for it (BSD license)? :-) Regards and best wishes, Justin Clift Bruce Momjian wrote: Can someone comment on this? I

Re: [HACKERS] new food for the contrib/ directory

/ ;-) -- Andreas 'ads' Scherbaum ---(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] new food for the contrib/ directory

Tom Lane wrote: Andreas Scherbaum [EMAIL PROTECTED] writes: Justin Clift wrote: Did we reach an opinion as to whether we'll include GPL'd code? My vote is to not include this code, as it just muddies the water with PostgreSQL being BSD based. Hmm, there's enough GPL'ed stuff

Re: [HACKERS] new food for the contrib/ directory

Tom Lane wrote: Andreas Scherbaum [EMAIL PROTECTED] writes: On the other hand, i copied some parts from contrib/noupdate (there'e no licence in the readme) and now i think, this is contributed under BSD licence. I'm sure or i'm wrong? I think, i have to change the licence. Who

Re: [HACKERS] new food for the contrib/ directory

Hello, there's a new archive available with a bugfix for handling null values. Thanks to Steve Head for reporting this. http://ads.ufp.de/projects/Pg/ Regards -- Andreas 'ads' Scherbaum ---(end of broadcast

Re: [HACKERS] Cygwin / Debian dpkg / PostgreSQL / KDE2 and 3

On 4 Jun 2002, Dave Cramer wrote: Java is another possibility, since it is already cross platform. ... with certain licensing issues ... Just a remark Andreas. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please

[HACKERS] Escaping in C-language functions

and insert it into another table (how to handle \0 values)? Best regards -- Andreas 'ads' Scherbaum ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs

Re: [HACKERS] Big problem

the users about what they're going to do. Regards, Andreas ---(end of broadcast)--- TIP 8: explain analyze is your friend

Re: [HACKERS] tablespaces and DB administration

, Andreas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

Re: [HACKERS] tablespaces and DB administration

without that. Regards, Andreas I would say that this is almost completely misinformed. Depending on the OS and the hardware, of course, a write on one spindle may not affect the performance of another. There are so many great things that happen when you have separate spindles. The OS manages

Re: [HACKERS] tablespaces and DB administration

mean for pg_xlog. Well, writing off-reality benchmarks on hardware setups I'd never suggest for db server usage proves... what? Additionally, do you care about safety? Regards, Andreas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] tablespaces and DB administration

, Andreas ---(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] tablespaces and DB administration

drive. Nicely parallelizable by a raid controller if it has a minimum of smartness. Regards, Andreas ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL

Re: [HACKERS] tablespaces and DB administration

. Please do read dbms disk io white papers, e.g. http://msdn.microsoft.com/archive/en-us/dnarsqlsg/html/sqlperftune.asp Teaching hardware issues is OT for this list. Regards, Andreas ---(end of broadcast)--- TIP 8: explain analyze is your friend

Re: [HACKERS] tablespaces and DB administration

Dear anonymous, This is really making me tired, and still OT. May anybody interested read the document you're citing abusively, or believe you that storage controllers are only capable of one command at a time or not. Regards, Andreas ---(end of broadcast

[HACKERS] pgsql 7.5 frontend changes wrapup

TABLE ALTER COLUMN TYPE - COMMENT ON CAST/CONVERSION/LANGUAGE Regards, Andreas ---(end of broadcast)--- TIP 8: explain analyze is your friend

[HACKERS] serverlog function

For adminstrator's convenience, I'd like to see a function that returns the serverlog. Are there any security or other issues that should prevent me from implementing this? Regards, Andreas ---(end of broadcast)--- TIP 6: Have you searched our

Re: [HACKERS] serverlog function

Tom Lane wrote: Andreas Pflug [EMAIL PROTECTED] writes: For adminstrator's convenience, I'd like to see a function that returns the serverlog. What do you mean by returns the serverlog? Are you going to magically recover data that has gone to stderr or the syslogd daemon? If so, how

Re: [HACKERS] serverlog function (log_destination file)

Andreas Pflug wrote: Tom Lane wrote: Andreas Pflug [EMAIL PROTECTED] writes: For adminstrator's convenience, I'd like to see a function that returns the serverlog. What do you mean by returns the serverlog? Are you going to magically recover data that has gone to stderr or the syslogd

Re: [HACKERS] serverlog function

Bruce Momjian wrote: Andreas Pflug wrote: I'd like to see the serverlog even if I can't go and look at the log file, because I don't have file access to the server. Understand. Unfortunately, we don't allow such functionality. The only solution I can think of is to use syslog

Re: [HACKERS] serverlog function (log_destination file)

Tom Lane wrote: If I were trying to solve Andreas' problem, I'd pipe stderr to some program that stores recent log output in a file that I know the location of and can read from the hypothetical log-grabber function. Actually I don't see that there's any need to involve Postgres itself

Re: [HACKERS] serverlog function (log_destination file)

Tom Lane wrote: Andreas Pflug [EMAIL PROTECTED] writes: What if there's no file access If you don't have any access to the machine then you are not really a DBA, you only play one on TV. However you may call me, I can think of many cases where I'd like to look at the server log, without

Re: [HACKERS] serverlog function (log_destination file)

position) size (may be null meaning max) is the chunk size (max: currently 5) position (may be null meaning -size) is the start position; positive counting from log file start, negative from end. Regards, Andreas Index: backend/postmaster/postmaster.c

Re: [PATCHES] [HACKERS] serverlog function (log_destination file)

, that's why I implemented it as *additional* log_destination. Regards, Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [pgsql-hackers-win32] [HACKERS] Tablespaces

don't use win32 for high performance pgsql databasing is equivalent to don't use pgsql. Regards, Andreas ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

Re: [PATCHES] [HACKERS] serverlog function (log_destination file)

fixed, and documentation. Since I don't have a doc build system functional, there might be tag mismatches or other typos; please check. IMHO this should be committed without waiting for log rotation stuff. Regards, Andreas Index: doc/src/sgml/func.sgml

Re: [HACKERS] [pgsql-hackers-win32] [PATCHES] Compiling libpq with VisualC

no solution for static linkage. This would require some PQinitThreadStuff() routine, which may be called only once (and ultimately can't check for that itself, if you don't trust a static var). Regards, Andreas ---(end of broadcast)--- TIP 1: subscribe

Re: [PATCHES] [HACKERS] serverlog function (log_destination file)

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

[HACKERS] logfile rotation

that. I'd also like to see a table pg_logfile which contains all logfile names, to be able to access older logfiles. Comments? Regards, Andreas Index: doc/src/sgml/func.sgml === RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml

Re: [HACKERS] logfile rotation

that the postmaster should never depend on the correctness of any shared memory data structure; but this patch would make it do so. I understand that, so what's the suggested way to store data common for all backends? Regards, Andreas ---(end of broadcast

Re: [HACKERS] logfile rotation

Andreas Pflug wrote: We agreed long ago that the postmaster should never depend on the correctness of any shared memory data structure; but this patch would make it do so. I understand that, so what's the suggested way to store data common for all backends? Answering my own question

Re: [pgsql-hackers-win32] [HACKERS] [PATCHES] Compiling libpq with

pthread_mutex_t singlethread_lock; +static long mutex_initialized = 0; +if (!InterlockedExchange(mutex_initialized, 1L)) +pthread_mutex_init(singlethread_lock, NULL); // wraps CreateMutex(NULL,FALSE,NULL) +#endif Regards, Andreas ---(end

Re: [HACKERS] Improving postgresql.conf

the default setting. How about *requiring* to set any variable, at least to xxx='default'? This would remove any ambiguities (and force to review postgresql.conf after upgrading, which is a good idea anyway). Regards, Andreas ---(end of broadcast)--- TIP

Re: [HACKERS] Improving postgresql.conf

Tom Lane wrote: Andreas Pflug [EMAIL PROTECTED] writes: How about *requiring* to set any variable, at least to xxx='default'? Don't like that ... we are not in the fascism business here ;-). Well enforcing setting variables, in the presence of a preconfigured file isn't exactly

Re: [HACKERS] logfile rotation

Andreas Pflug wrote: Andreas Pflug wrote: We agreed long ago that the postmaster should never depend on the correctness of any shared memory data structure; but this patch would make it do so. I understand that, so what's the suggested way to store data common for all backends? Answering my

  1   2   3   4   5   6   7   8   9   10   >