Re: [HACKERS] Re: [GENERAL] MySQL -> Postgres dump converter
Hannu Krosing wrote: >If it's all your code, then you are free to license it under any licence >you desire. ... >What you probably can't do is to revoke the GPL license. You can't revoke it from existing copies "out there", but you can from any copies you release from now on, even of the same code.. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "Many are the afflictions of the righteous; but the LORD delivereth him out of them all." Psalm 34:19
Re: [HACKERS] Open 7.1 items
Hi, there! On Sat, 27 Jan 2001, Bruce Momjian wrote: > Here are the open items for 7.1. Much shorter: > > Reorder INSERT firing in rules > JDBC LargeObject short read return value missing > LAZY VACUUM > JDBC setMaxRows() is global variable affecting other objects > Fix for pg_dump of bad system tables > ODBC not disconnecting properly? > Magnus Hagander ODBC issues? > Merge MySQL/PgSQL translation scripts > Fix ipcclean on Linux > unixODBC > > -- > Bruce Momjian| http://candle.pha.pa.us > [EMAIL PROTECTED] | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 > What about strange write locking of primary index element, if something that references it is changed (inserted or updated), you cannot modify in other transaction something else that references the same primary index element until first transaction ends. For example: CREATE table primtest (id integer primary key); CREATE table foreigntest1 (id integer references primtest); CREATE table foreigntest2 (id integer references primtest); INSERT INTO primtest VALUES (1); BEGIN; INSERT INTO foreigntest1 VALUES (1); -- and in other transaction: INSERT INTO foreigntest2 VALUES (1); -- blocked until COMMIT or ROLLBACK issued in first transaction. /Constantin
Re: [HACKERS] Open 7.1 items
At 23:14 27/01/01 -0500, Bruce Momjian wrote: >I assume this addresses the open item: > > Fix for pg_dump of bad system tables > >I will remove it from the list. Thanks. > I'd remove it from the 'Required for 7.1' list, but leave it on the TODO list, since the task is not quite complete. >> At 07:24 26/01/01 +0900, Tatsuo Ishii wrote: >> >> Fix for pg_dump of bad system tables >> > >> >Ok. I have made patches for fixing some of pg_dump problems(see >> >attached patches). The patches address the problem with user defined >> >functions, operators and aggregates. >> >> These have now been applied with minor modifications. >> ... >> >> In my view this should be considered a 'work-in-progress' and not hold up >> 7.1 since the problem has been there for a long time. >> Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
Re: [HACKERS] Open 7.1 items
> At 23:14 27/01/01 -0500, Bruce Momjian wrote: > >I assume this addresses the open item: > > > > Fix for pg_dump of bad system tables > > > >I will remove it from the list. Thanks. > > > > I'd remove it from the 'Required for 7.1' list, but leave it on the TODO > list, since the task is not quite complete. OK, do you have some text for me. FYI, the "open" list are not all must-do items for 7.1. They are merely items that either need to be done, or moved to the TODO list. It is up to the group to decide which one they want. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Open 7.1 items
I assume this addresses the open item: Fix for pg_dump of bad system tables I will remove it from the list. Thanks. > At 07:24 26/01/01 +0900, Tatsuo Ishii wrote: > >> Fix for pg_dump of bad system tables > > > >Ok. I have made patches for fixing some of pg_dump problems(see > >attached patches). The patches address the problem with user defined > >functions, operators and aggregates. > > These have now been applied with minor modifications. > > > >However I have not address what Tom Lane said yet(actually I do not > >understand what he says). > > > >> The other flavor of problems that pg_dump > >> has in this area are in doing inner joins across system catalogs ... > > This refers to things like: > > SELECT c.relname > FROM pg_index i, pg_class c > WHERE i.indrelid = %s > AND i.indisprimary > AND c.oid = i.indexrelid > > ie. where two or more relations are crossed (pg_index and pg_class in this > case). It assumes that the metadata is valid, and will not highlight > missing data in the secondary table. We should be doing outer joins: > > SELECT c.relname > FROM pg_index i LEFT OUTER JOIN pg_class c on c.oid = i.indexrelid > WHERE i.indrelid = %s > AND i.indisprimary > > and checking for nulls using PQgetisnull. I have actually done this for a > couple of SELECTs (including the above one), and marked all the others as > ': use LOJ'. There are only 2 or 3 more, but they require a little more > thought (an inderstanding) before I change them. > > In my view this should be considered a 'work-in-progress' and not hold up > 7.1 since the problem has been there for a long time. > > > > Philip Warner| __---_ > Albatross Consulting Pty. Ltd. |/ - \ > (A.B.N. 75 008 659 498) | /(@) __---_ > Tel: (+61) 0500 83 82 81 | _ \ > Fax: (+61) 0500 83 82 82 | ___ | > Http://www.rhyme.com.au |/ \| > |---- > PGP key available upon request, | / > and from pgp5.ai.mit.edu:11371 |/ > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Open 7.1 items
At 07:24 26/01/01 +0900, Tatsuo Ishii wrote: >> Fix for pg_dump of bad system tables > >Ok. I have made patches for fixing some of pg_dump problems(see >attached patches). The patches address the problem with user defined >functions, operators and aggregates. These have now been applied with minor modifications. >However I have not address what Tom Lane said yet(actually I do not >understand what he says). > >> The other flavor of problems that pg_dump >> has in this area are in doing inner joins across system catalogs ... This refers to things like: SELECT c.relname FROM pg_index i, pg_class c WHERE i.indrelid = %s AND i.indisprimary AND c.oid = i.indexrelid ie. where two or more relations are crossed (pg_index and pg_class in this case). It assumes that the metadata is valid, and will not highlight missing data in the secondary table. We should be doing outer joins: SELECT c.relname FROM pg_index i LEFT OUTER JOIN pg_class c on c.oid = i.indexrelid WHERE i.indrelid = %s AND i.indisprimary and checking for nulls using PQgetisnull. I have actually done this for a couple of SELECTs (including the above one), and marked all the others as ': use LOJ'. There are only 2 or 3 more, but they require a little more thought (an inderstanding) before I change them. In my view this should be considered a 'work-in-progress' and not hold up 7.1 since the problem has been there for a long time. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
Re: [HACKERS] Open 7.1 items
Philip Warner <[EMAIL PROTECTED]> writes: >> Also I'm not quite sure "#arg" (stringification) is >> portable enough in all platforms.) > The patch looks fine to me, but I have no idea how portable #arg is Use the CppAsString macro from our c.h ... that's what it's for. It's actually fairly unlikely that anyone still uses a compiler that doesn't grok #arg and yet can handle the other ANSI-isms that Postgres requires. However, we may as well stick to the coding conventions we have... regards, tom lane
Re: [HACKERS] Open 7.1 items
At 07:24 26/01/01 +0900, Tatsuo Ishii wrote:
>> Fix for pg_dump of bad system tables
>
>Ok. I have made patches for fixing some of pg_dump problems(see
>attached patches).
...
>Also I'm not quite sure "#arg" (stringification) is
>portable enough in all platforms.)
The patch looks fine to me, but I have no idea how portable #arg is - does
anybody else have some facts on the matter:
+#define AGG_NOTICE(arg) {\
+ fprintf(stderr, "Notice: aggregate \"%s\"(oid %s) is not
dumped.\n",agginfo[i].aggname, a
+ fprintf(stderr, "Reason: " #arg);\
+ fprintf (stderr, " (oid %s) not found.\n",agginfo[i].arg);\
+ }
+
It's easy enough to change the macros to take 2 params, and that would be
my inclination if it's not a solid part of the C standard (for any
non-trivial definintion of 'solid').
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (+61) 0500 83 82 81 | _ \
Fax: (+61) 0500 83 82 82 | ___ |
Http://www.rhyme.com.au |/ \|
|----
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
Re: [HACKERS] Re: [GENERAL] MySQL -> Postgres dump converter
Max Rudensky wrote: > > Guys, > > Thomas said he won't look into GPL'ed code for ideas. > Well, I re-read GPL and found that it's up to author whether is to allow or not > to use code for using in programs with another open-source license. So this isn't > a problem - you may use my program and include code to your without limitations. > I even would prefer to change license to BSD or similar > but I didn't find in GPL ideas about that. > If it's all your code, then you are free to license it under any licence you desire. You are completely free to licence it under both GPL and BSD licenses at the same time. You can even simultaneously license it under a commercial licence if you want to ;) What you probably can't do is to revoke the GPL license. --- Hannu
Re: [HACKERS] Sure enough, the lock file is gone
"Oliver Elphick" <[EMAIL PROTECTED]> writes: > /var/run/postgresql There's another reason why the standard socket directory is /tmp, and that's that it exists everywhere. Not all Unix systems even *have* a /var hierarchy, let alone one that the admin will let you have a playpen in. regards, tom lane
Re: [HACKERS] Sure enough, the lock file is gone
Bruce Momjian wrote: >> Note: programs that run as non-root users may be unable to create files un >der >> /var/run and therefore need a subdirectory owned by the appropriate user. > >This is the killer. We can't require root. Seems we are stuck with >/tmp. I'd be surprised to learn that non-admin users are allowed to write in /usr/local, either. If, on some machine, PostgreSQL is such an unoffical project that the admin won't agree to create /var/run/postgresql, the user can define his own temporary directory using the method we have already included in 7.1; if, on the other hand, he is able to create /usr/local/pgsql, he will also be able to create /var/run/postgresql. Really, how many users do we have who can't get their admin to do this for them? -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "Come now, and let us reason together, saith the LORD; though your sins be as scarlet, they shall be as white as snow; though they be red like crimson, they shall be as wool." Isaiah 1:18
[HACKERS] Re: Sure enough, the lock file is gone
> It would probably be better if the socket files weren't in /tmp but in > a postgres-owned directory. However, at this point we have a huge > backwards compatibility problem to overcome if we want to move the > socket files. The location of the socket files is essentially a core > part of the frontend-backend protocol, because both client and server > must know it ab initio. Move the socket, break your clients. Ok, fair enough. But sometimes unix sucks, don't you think, having to use /tmp as a central place for inter-process communication... blech. Florent -- <[EMAIL PROTECTED]>
RE: [HACKERS] Bug in FOREIGN KEY
-Original Message- > From: Tom Lane [mailto:[EMAIL PROTECTED]] > > > However I'm suspicious if KEY_CHANGED check is necessary. > > Removing KEY_CHANGED stuff seems to solve the TODO > > FOREIGN KEY INSERT & UPDATE/DELETE in transaction "change violation" > > though it may introduce other bugs. > > I suspect it just masks the problem by preventing the trigger code > from executing ... > I've examined the new TODO * FOREIGN KEY INSERT & UPDATE/DELETE in transaction "change violation" a little and am now wondering why it has remained unsolved until now. ISTM there are 2 different RI related issues. 1) "begin; insert; delete(or update pk of) the inserted tuple" causes a "change violation" error. 2) For deferred RI constraints "begin;delete a pk;insert the same pk;commit;" fails(or misbehaves) in case the corresponding fk exist. Shouldn't we distinguish above 2 issues clearly ? And doesn't the new TODO correspond to 1) ? The issue 1) seems to be caused due to the transaction-wide KEY_CHANGED check. Isn't it sufficient to check KEY_CHANGED per query. For example, how about clearing KEY_CHANGED after every DeferredTriggerEndQeury() ? Regards, Hiroshi Inoue
Re: [HACKERS] Re: Sure enough, the lock file is gone
> I understand why the socket needs to be in /tmp, but why the lockfile? It would probably be better if the socket files weren't in /tmp but in a postgres-owned directory. However, at this point we have a huge backwards compatibility problem to overcome if we want to move the socket files. The location of the socket files is essentially a core part of the frontend-backend protocol, because both client and server must know it ab initio. Move the socket, break your clients. There is an option in 7.1 to support defining a different directory for the socket files, but I doubt very many people will use it. I see no real good reason to keep the lockfiles in a different place from the sockets themselves, however. Doing so would just complicate things even more, without adding any real safety or security. regards, tom lane
Re: [HACKERS] Re: Sure enough, the lock file is gone
Peter Eisentraut wrote: > Lamar Owen writes: > > I understand why the socket needs to be in /tmp, but why the lockfile? > The lock file protects the Unix domain socket. Consequently, the name of > the lock file needs to be derivable from the name of the socket file, and > vice versa. Also, the name of the socket file must not vary with other > parameters such as installation layout. I see. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] Re: Sure enough, the lock file is gone
Lamar Owen writes: > I understand why the socket needs to be in /tmp, but why the lockfile? The lock file protects the Unix domain socket. Consequently, the name of the lock file needs to be derivable from the name of the socket file, and vice versa. Also, the name of the socket file must not vary with other parameters such as installation layout. > Lock file cleanup should be the responsibility of the script that starts > postmaster The postmaster does that itself. That's why the pid is in there. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Re: Sure enough, the lock file is gone
The Hermit Hacker wrote: > On Sat, 27 Jan 2001, Lamar Owen wrote: > > Comments? _Why_ is the lock in /tmp? Won't the lock always be put into > > place by the uid used to run postmaster? Is a _world_ writeable > > temporary directory the right place? > first off, the lock file is put in by an unprivileged user, so /tmp works > on all systems ... If /usr/local/pgsql (to use the default) is owned by the user running postmaster, then the postmaster has privileges to put the lockfile in, say, /usr/local/pgsql/lock/., right? Or am I missing something basic here? Is this lock placed by postmaster, or by something else? My 7.1beta3 installation shows two files in /tmp: srwxrwxrwx1 postgres postgres0 Jan 27 14:25 .s.PGSQL.5432 -rw---1 postgres postgres 25 Jan 27 14:25 .s.PGSQL.5432.lock I understand why the socket needs to be in /tmp, but why the lockfile? What or who is using the lockfile (which contains the pid of postmaster and the path to PGDATA for the postmaster)? > second, /tmp on a large portion of systems gets cleaned out after a > reboot, so there are no 'stray locks' to generally worry about... Ironic that RedHat, which can clean /tmp out on a cron basis would be one that doesn't clean it out by default on reboot. Lock file cleanup should be the responsibility of the script that starts postmaster -- or the responsibility of the DBA who manually starts and restarts postmasters, after crashes or at other times. Not a big issue, by any means. Just attempting to understand. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] new version of contrib-intarray
Oleg Bartunov <[EMAIL PROTECTED]> writes: > btw, is there way to specify default ops for index ? Sure, that's what pg_opclass is for. Just insert the opclass name and the OID of the type you want it to be the default index opclass for. regards, tom lane
Re: [HACKERS] Re: Sure enough, the lock file is gone
first off, the lock file is put in by an unprivileged user, so /tmp works
on all systems ...
second, /tmp on a large portion of systems gets cleaned out after a
reboot, so there are no 'stray locks' to generally worry about...
On Sat, 27 Jan 2001, Lamar Owen wrote:
> Florent Guillaume wrote:
> >
> > /tmp is for *temporary* files. Such a lock is not a temporary file, it
> > should go somewhere in /var, why not in /var/lib/pgsql/data ?
>
> /var/lib is also not for locks, per FHS.
>
> /var/lock/pgsql (or /var/lock/postgresql) would be the FHS-mandated
> place for such a file.
>
> Comments? _Why_ is the lock in /tmp? Won't the lock always be put into
> place by the uid used to run postmaster? Is a _world_ writeable
> temporary directory the right place?
>
> 7.2 discussion, however, IMHO.
> --
> Lamar Owen
> WGCR Internet Radio
> 1 Peter 4:11
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
Re: [HACKERS] Re: Sure enough, the lock file is gone
Florent Guillaume wrote: > > /tmp is for *temporary* files. Such a lock is not a temporary file, it > should go somewhere in /var, why not in /var/lib/pgsql/data ? /var/lib is also not for locks, per FHS. /var/lock/pgsql (or /var/lock/postgresql) would be the FHS-mandated place for such a file. Comments? _Why_ is the lock in /tmp? Won't the lock always be put into place by the uid used to run postmaster? Is a _world_ writeable temporary directory the right place? 7.2 discussion, however, IMHO. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] PgAccess - small bug?
This is fixed in the pgaccess version in CVS. > > > > > On Wed, 31 May 2000, Bruce Momjian wrote: > > > I assume this is fixed? > > Oh, it is really old letter from me. I total forget... > > Hmm, I haven't here last version of CVS, but pgaccess in my comp has this > bug still.. > > Bruce, thanks for answer. I not had hope that anyone advert to this. > > Karel > > > > > > > > > Hi, > > > > > > in PgAccess's the create table dialog is small bug. If I define a new table > > > as interits of other table and I not define any column (as 'field' named this > > > dialog) - PgAccess return ERROR message "Your table has not field!". But > > > PgSQL allow define table as: > > > > > > CREATE TABLE xxx () INHERITS(yyy); > > > > > > ...all colunms is from 'yyy'. > > > > > > NOTE: Why a attribute (column) is in the PgAccsess named 'field'? It is > > > abnormal in SQL speech... > > > > > > Karel > > > > > > -- > > > Karel Zak <[EMAIL PROTECTED]> http://home.zf.jcu.cz/~zakkr/ > > > > > > Docs: http://docs.linux.cz (big docs archive) > > > > Kim Project: http://home.zf.jcu.cz/~zakkr/kim/ (process manager) > > > FTP: ftp://ftp2.zf.jcu.cz/users/zakkr/ (C/ncurses/PgSQL) > > > -- > > > > > > > > > > > > > > > > > > -- > > Bruce Momjian| http://www.op.net/~candle > > [EMAIL PROTECTED] | (610) 853-3000 > > + If your life is a hard drive, | 830 Blythe Avenue > > + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 > > > > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Open 7.1 items
> Here are the open items for 7.1. Much shorter: + Runtime btree recovery Vadim
Re: [HACKERS] PgAccess - small bug?
Applied to CVS. Thanks. > Bruce Momjian wrote: > > > > > Constantin Teodorescu wrote: > > > > > > I'll fix it this weekend! > > > > OK, let me know if you release a new pgaccess and I will add it to CVS. > > Bug fixed. Ross patches applied. > HTML documentation updated with what's new. > > Hope it's fine! > You'll find attached the 0.98.7.tar.gz file! > > Best regards, > Teo [ application/x-gzip is not supported, skipping... ] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Sure enough, the lock file is gone
> Jan Wieck wrote: > >Peter Eisentraut wrote: > >> Jan Wieck writes: > >> > >> > Exactly the way you want it to do (open(2) and close(2) of a > >> > UNIX domain socket) was what I had to do to get an old > >> > Mach3-4.3BSD combo into a kernel-panic. > >> > >> The lock file is an ordinary file. > > > >So the crazy-temp-vacuum-cleaner on linux doesn't touch the > >sockets? > > tmpreaper does - that's why I moved the socket in Debian. But you have complete control over the OS, while we don't. The problem I see of moving it is that only Debian-compiled clients will work on Debian systems. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Which version?
My guess is that there is some old/other include that is interfering with our includes. This it the first OID_EQ compile error I can remember seeing. > > > > This happened on SuSE 7.0, compiling with gcc 2.95. Maybe I downloaded some > > > stale corrupted tarball with a file missing - I went to > > > .http://www.pgsql.com/download/ and just clicked on the top "Download" > > > button. Where is F_OIDEQ supposed to be defined anyway? > > here: src/backend/utils/fmgr.h:#define F_OIDEQ 184 > > and here: src/backend/fmgr.h:#define F_OIDEQ 184 > > and it doesn't appear to be inside of an ifdef either. > > Vince. > -- > == > Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net > 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking > Online Campground Directoryhttp://www.camping-usa.com >Online Giftshop Superstorehttp://www.cloudninegifts.com > == > > > > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
[HACKERS] Re: Sure enough, the lock file is gone
/tmp is for *temporary* files. Such a lock is not a temporary file, it should go somewhere in /var, why not in /var/lib/pgsql/data ? > The 'tmpwatch' program on Red Hat will remove the /tmp/.s.PGSQL.5432.lock > file after the server has run 6 days. This will be a problem. > > We could touch (open) the file once every time the ServerLoop() runs > around. It's not perfect but it should work in practice.
Re: [HACKERS] Which version?
On Friday 26 January 2001 19:04, The Hermit Hacker wrote: >Need more information ... specifically what OS are you running? I *just* >built PgSQL 7.0.3 on my freshly installed FreeBSD 4.2-RELEASE box, and it >compiled cleanly ... This happened on SuSE 7.0, compiling with gcc 2.95. Maybe I downloaded some stale corrupted tarball with a file missing - I went to .http://www.pgsql.com/download/ and just clicked on the top "Download" button. Where is F_OIDEQ supposed to be defined anyway? -- MySQL Development Team __ ___ ___ __ / |/ /_ __/ __/ __ \/ / Sasha Pachev <[EMAIL PROTECTED]> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, http://www.mysql.com/ /_/ /_/\_, /___/\___\_\___/ Provo, Utah, USA <___/
Re: [HACKERS] Ungraceful handling of fatal flex errors
Peter Eisentraut <[EMAIL PROTECTED]> writes: > A fatal scanner error (likely a memory exhaustion problem) causes a > straight exit() without clean up, which causes a system-wide restart. > This should fix it: > *** scan.l 2001/01/24 19:43:03 1.85 > --- scan.l 2001/01/27 14:14:29 > *** > *** 55,60 > --- 55,62 > /* No reason to constrain amount of data slurped per myinput() call. */ > #define YY_READ_BUF_SIZE 16777216 > + #define YY_FATAL_ERROR(msg) elog(FATAL, "%s", (msg)) > + > #else /* !FLEX_SCANNER */ > #undef input > But you will now get an unavoidable > scan.c:2145: warning: `yy_fatal_error' defined but not used I have a sneakier idea to avoid the warning. The yy_fatal_error routine is defined as (void) fprintf( stderr, "%s\n", msg ); exit( YY_EXIT_FAILURE ); and this is the only use of fprintf in the scan.c file. How about leaving yy_fatal_error as the error subroutine, and insert #define fprintf(file,fmt,msg) elog(FATAL, "%s", (msg)) regards, tom lane
Re: [HACKERS] plan for running postmaster directly as NT service
Fred Yankowski <[EMAIL PROTECTED]> writes: > a) The 'install' and 'remove' code is quite bulky, although simple. > Is it OK to create a new source file for it, rather than working it > into some existing file? I think this'd be a lot easier to sell (and probably to implement) if the NT-specific stuff is a separate, arm's-length wrapper around the standard Unix version. Possibly you want something that replaces src/backend/main/main.c in an NT build. > b) How can the service log error messages? Is there any syslog type > facility? Syslog support exists. There's still a lot of debugging-type code that scribbles to stderr, but (at least for a first cut) you could just let that go to the bit bucket. > c) What is a good way for the supervisory thread to communicate with > the main thread and shut it down cleanly? Send it an appropriate signal, same as pg_ctl does. regards, tom lane
RE: [HACKERS] plan for running postmaster directly as NT service
> d) How can we insure that the ipc-daemon service starts before the > postgres/postmaster service? I believe that NT has some facility that > allows one service to request start-up of another service, but I have > no idea how to make that happen. You can use Service Dependencies for this. In you call to CreateService() for the service, specify a value for the "lpDependencies" parameter. This parameter holds a pointer to a double null-terminated array of null-separated names of services that this service depends on. The Service Control Manager will make sure these services start first, so the dependencies are satisfied. So just add the ipc-daemon service there, and the rest should happen automatically. See: http://msdn.microsoft.com/library/default.asp?URL=/library/psdk/winbase/serv ices_3p9h.htm //Magnus
[HACKERS] plan for running postmaster directly as NT service
I'm using PostgreSQL on WinNT to support (along with Zope) several websites. I've currently got postmaster running as an NT service by wrapping it with the 'invoker' utility, but I'd prefer to have it run directly as a service so that it can be stopped cleanly. I now know the basics of how to extend a program to make it run directly as an NT service, as I've enhanced the Cygipc (Cygwin) 'ipc-daemon' process to do just that (and I've submitted the patch to the current maintainer of Cygipc). So now I'd like to do the same for postgres/postmaster, but I want you all to vet this plan before I invest much more time. For me, the fundamental question is: If I create a patch that implements this function, what will it take to get it into the main CVS version? Will some established PostgreSQL developer offer to review/champion/mentor my work? Expected plan of operation: 1) Administrator runs 'postgres --install-as-service'. Program installs NT registry entries and calls Windows APIs to register the service, leaving it ready for 'automatic' startup, but not starting the service. The ImagePath key value uses exactly the full path of the 'postgres' program that did the install. After installing the service the program returns immediately. 2) When starting the service from, say, the Services Control Panel, postgres is invoked with a new '--service' command-line flag. When the postgres program starts running it looks for this option right away (much like '-boot') and, finding it, starts up in postmaster mode and passes on the --services flag, causing the postmaster code to do the necessary magic to start up as an NT service. This does not involve any additional forks; the process splits into a supervisory thread and a main thread that runs the existing main work loop. 3) When the service is stopped, the supervisory service thread sends some kind of event/signal/semaphore/... to the main work thread, causing that thread to shut down as if 'pg_ctl -m fast stop' had been called [is this a good choice?]. 4) Administrator runs 'postgres --remove-as-service'. The program removes the registry data for the service and calls APIs to completely remove the service. It shuts down the service first if it's already running. Then it quits. Design questions: a) The 'install' and 'remove' code is quite bulky, although simple. Is it OK to create a new source file for it, rather than working it into some existing file? b) How can the service log error messages? Is there any syslog type facility? If not, is it OK to include a new output interface that would log to the NT event log? Or is there some better scheme? c) What is a good way for the supervisory thread to communicate with the main thread and shut it down cleanly? (I haven't studied the code to find the main wait/select loop yet. Sorry.) d) How can we insure that the ipc-daemon service starts before the postgres/postmaster service? I believe that NT has some facility that allows one service to request start-up of another service, but I have no idea how to make that happen. Your feedback on this plan is more than welcome. I'm willing to put time into getting this working, but only if I get some support from you all. -- Fred Yankowski [EMAIL PROTECTED] tel: +1.630.879.1312 Principal Consultant www.OntoSys.com fax: +1.630.879.1370 OntoSys, Inc 38W242 Deerpath Rd, Batavia, IL 60510, USA
[HACKERS] Ungraceful handling of fatal flex errors
A fatal scanner error (likely a memory exhaustion problem) causes a straight exit() without clean up, which causes a system-wide restart. This should fix it: *** scan.l 2001/01/24 19:43:03 1.85 --- scan.l 2001/01/27 14:14:29 *** *** 55,60 --- 55,62 /* No reason to constrain amount of data slurped per myinput() call. */ #define YY_READ_BUF_SIZE 16777216 + #define YY_FATAL_ERROR(msg) elog(FATAL, "%s", (msg)) + #else /* !FLEX_SCANNER */ #undef input But you will now get an unavoidable scan.c:2145: warning: `yy_fatal_error' defined but not used Objections or concerns? -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Which version?
> > This happened on SuSE 7.0, compiling with gcc 2.95. Maybe I downloaded some > > stale corrupted tarball with a file missing - I went to > > .http://www.pgsql.com/download/ and just clicked on the top "Download" > > button. Where is F_OIDEQ supposed to be defined anyway? here: src/backend/utils/fmgr.h:#define F_OIDEQ 184 and here: src/backend/fmgr.h:#define F_OIDEQ 184 and it doesn't appear to be inside of an ifdef either. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com ==
Re: [HACKERS] RPM: Contrib request.
Tom Lane wrote: > Meanwhile, it's not the RPMs' place to editorialize on which contrib > items are useful. Package 'em all, unless we hit build problems. Interesting point of view :-). Going into 'Uncle Martin' mode (obscure joke alert...). -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] pg_dump -c database problem
At 14:56 24/01/01 -0500, Rod Taylor wrote: >pg_dump -c database > >The \connect is after the DROP TABLE statements where I believe it >should come first. (Gotta connect as the right user before dropping >everything). > This is now fixed. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
Re: [HACKERS] Sure enough, the lock file is gone
Jan Wieck wrote: >Peter Eisentraut wrote: >> Jan Wieck writes: >> >> > Exactly the way you want it to do (open(2) and close(2) of a >> > UNIX domain socket) was what I had to do to get an old >> > Mach3-4.3BSD combo into a kernel-panic. >> >> The lock file is an ordinary file. > >So the crazy-temp-vacuum-cleaner on linux doesn't touch the >sockets? tmpreaper does - that's why I moved the socket in Debian. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "Come now, and let us reason together, saith the LORD; though your sins be as scarlet, they shall be as white as snow; though they be red like crimson, they shall be as wool." Isaiah 1:18
[HACKERS] Re: Sure enough, the lock file is gone
On Fri, 26 Jan 2001, Peter Eisentraut wrote: >Bruce Momjian writes: > >> If we have to do it, let's make it an #ifdef __linux__ option. > >What does Linux have to do with it? FreeBSD does the same thing, only >every three days. I dont' know whether it's not enabled on a fresh >install, but it's there, you only need to flip the switch. I doubt /tmp >cleaning is such an unusual thing, especially on large sites. > Only on a poorly configured FreeBSD box. You do have to turn it on first. FreeBSD (This is a 4.2-Stable box) will only delete files that have not been modified within the set number of days. This amount is variable. You can also tell clean_tmp to ignore any files you wish. This is all configurable via rc.conf and friends. GB -- GB Clark II| Roaming FreeBSD Admin [EMAIL PROTECTED] | General Geek CTHULU for President - Why choose the lesser of two evils?
