Re: [HACKERS] Request for supported platforms
On Tue, 2002-11-05 at 00:40, Bruce Momjian wrote: Ports list updated: http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html Please note that you have an entry for Digital Unix and one for Compaq Tru64 while in fact they are the same OS that went through a whirlwind of name changes. Don't know if official name should be now HP Tru64 or some other... -- Alessio F. Bragadini[EMAIL PROTECTED] APL Financial Services http://village.albourne.com Nicosia, Cyprus phone: +357-22-755750 It is more complicated than you think -- The Eighth Networking Truth from RFC 1925 ---(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] Float output formatting options
Pedro M. Ferreira wrote:
Tom Lane wrote:
Perhaps P_MAXLEN now needs to be (2*(DBL_DIG+2+7)+1), considering
that we'll allow extra_float_digits to be up to 2. What's it used for?
Yes. I guess so, because it is used in what I think is a memory
allocation function. P_MAXLEN is only used twice:
...
I will do the changes tomorrow and send in the appropriate diff's.
Ok. Its done now.
Only one file changed: src/backend/utils/adt/geo_ops.c
All the geometric types should now account for float_extra_digits on output.
A diff -u is attached.
Best reagards,
Pedro
Regards,
Pedro
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
--
--
Pedro Miguel Frazao Fernandes Ferreira
Universidade do Algarve
Faculdade de Ciencias e Tecnologia
Campus de Gambelas
8000-117 Faro
Portugal
Tel./Fax: (+351) 289 800950 / 289 819403
http://w3.ualg.pt/~pfrazao
--- old/postgresql-7.2.1/src/backend/utils/adt/geo_ops.cMon Nov 4 12:01:39
2002
+++ postgresql-7.2.1/src/backend/utils/adt/geo_ops.cTue Nov 5 10:47:56 2002
@@ -80,11 +80,11 @@
#define RDELIM_C ''
/* Maximum number of output digits printed */
-#define P_MAXDIG DBL_DIG
-#define P_MAXLEN (2*(P_MAXDIG+7)+1)
-
-static int digits8 = P_MAXDIG;
+/* ...+2+7 : 2 accounts for extra_float_digits max value */
+#define P_MAXLEN (2*(DBL_DIG+2+7)+1)
+/* Extra digits in float output formatting (in float.c) */
+extern int extra_float_digits;
/*
* Geometric data types are composed of points.
@@ -139,7 +139,12 @@
static int
single_encode(float8 x, char *str)
{
- sprintf(str, %.*g, digits8, x);
+ int ndig = DBL_DIG + extra_float_digits;
+
+ if (ndig 1)
+ ndig=1;
+
+ sprintf(str, %.*g, ndig, x);
return TRUE;
} /* single_encode() */
@@ -190,7 +195,12 @@
static int
pair_encode(float8 x, float8 y, char *str)
{
- sprintf(str, %.*g,%.*g, digits8, x, digits8, y);
+ int ndig = DBL_DIG + extra_float_digits;
+
+ if (ndig 1)
+ ndig=1;
+
+ sprintf(str, %.*g,%.*g, ndig, x, ndig, y);
return TRUE;
}
@@ -974,7 +984,7 @@
#endif
#ifdef GEODEBUG
printf(line_construct_pts- line is neither vertical nor horizontal
(diffs x=%.*g, y=%.*g\n,
- digits8, (pt2-x - pt1-x), digits8, (pt2-y - pt1-y));
+ DBL_DIG, (pt2-x - pt1-x), DBL_DIG, (pt2-y - pt1-y));
#endif
}
}
@@ -1180,8 +1190,8 @@
#ifdef GEODEBUG
printf(line_interpt- lines are A=%.*g, B=%.*g, C=%.*g, A=%.*g, B=%.*g,
C=%.*g\n,
- digits8, l1-A, digits8, l1-B, digits8, l1-C, digits8, l2-A,
digits8, l2-B, digits8, l2-C);
- printf(line_interpt- lines intersect at (%.*g,%.*g)\n, digits8, x, digits8,
y);
+ DBL_DIG, l1-A, DBL_DIG, l1-B, DBL_DIG, l1-C, DBL_DIG, l2-A,
+DBL_DIG, l2-B, DBL_DIG, l2-C);
+ printf(line_interpt- lines intersect at (%.*g,%.*g)\n, DBL_DIG, x, DBL_DIG,
+y);
#endif
return result;
@@ -2390,14 +2400,14 @@
p = line_interpt_internal(tmp, line);
#ifdef GEODEBUG
printf(interpt_sl- segment is (%.*g %.*g) (%.*g %.*g)\n,
- digits8, lseg-p[0].x, digits8, lseg-p[0].y, digits8,
lseg-p[1].x, digits8, lseg-p[1].y);
+ DBL_DIG, lseg-p[0].x, DBL_DIG, lseg-p[0].y, DBL_DIG,
+lseg-p[1].x, DBL_DIG, lseg-p[1].y);
printf(interpt_sl- segment becomes line A=%.*g B=%.*g C=%.*g\n,
- digits8, tmp.A, digits8, tmp.B, digits8, tmp.C);
+ DBL_DIG, tmp.A, DBL_DIG, tmp.B, DBL_DIG, tmp.C);
#endif
if (PointerIsValid(p))
{
#ifdef GEODEBUG
- printf(interpt_sl- intersection point is (%.*g %.*g)\n, digits8,
p-x, digits8, p-y);
+ printf(interpt_sl- intersection point is (%.*g %.*g)\n, DBL_DIG,
+p-x, DBL_DIG, p-y);
#endif
if (on_ps_internal(p, lseg))
{
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] [CYGWIN] command
Title: RE: [CYGWIN] command Florian Litot wrote: what is the command to launch a sql script not in psql thanks psql is used to execute sql scripts as follows: psql -f filename database hth, - Stuart
Re: [HACKERS] a tiny question
Luis Alberto Amigo Navarro [EMAIL PROTECTED] writes: When we improve seq scans, systems scales well up to 8 cpus.When we improve index scan, query performance increase but system stops scaling at about 4 proccessors, profiling shows that it is due to increased memory contention What do you mean by memory contention? Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] a tiny question
a guess it's said inter-locking, I mean data accessed exclusively. I apologize for my english - Original Message - From: Neil Conway [EMAIL PROTECTED] To: Luis Alberto Amigo Navarro [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, November 05, 2002 4:47 PM Subject: Re: [HACKERS] a tiny question Luis Alberto Amigo Navarro [EMAIL PROTECTED] writes: When we improve seq scans, systems scales well up to 8 cpus.When we improve index scan, query performance increase but system stops scaling at about 4 proccessors, profiling shows that it is due to increased memory contention What do you mean by memory contention? Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(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] rebuilding beta4 ... fails in docs build ...
k, rebuuilding now On Mon, 4 Nov 2002, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: one too many things removed? Just broken SGML markup ... fixed I think ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] New beta4 created ...
from looking at the sizes for the previous beta's, it *looks* right ... someone want to take a quick peak? ---(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 beta4 created ...
Marc G. Fournier [EMAIL PROTECTED] writes: from looking at the sizes for the previous beta's, it *looks* right ... someone want to take a quick peak? The code seems right, and the postgres.tar.gz doc tarball seems right, but the man.tar.gz doc tarball seems out of date --- in fact it looks to be 7.2 documentation. Was it supposed to be up to date, or are we leaving that to fix later? 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] New beta4 created ...
On Tue, 5 Nov 2002, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: from looking at the sizes for the previous beta's, it *looks* right ... someone want to take a quick peak? The code seems right, and the postgres.tar.gz doc tarball seems right, but the man.tar.gz doc tarball seems out of date --- in fact it looks to be 7.2 documentation. Was it supposed to be up to date, or are we leaving that to fix later? We'll get this build right yet :) I'm copying the man.tar.gz that is in: cp /var/spool/ftp/pub/dev/doc/man.tar.gz .. The postgres.tar.gz that is in there appears to be good to 1hr ago, but you are right about the man.tar.gz ... Peter? ---(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] Test of PG7.3.2b2 on SGI Irix
Dear Tom, All the regression tests pass except for tests involving Savings Time which are off by one hour. --Bob Details? If you ran it today then the DST-boundary problems shouldn't be there anymore. Here are the diffs: It looks like your files match the solaris-1947 variants; would you confirm that? If so, please send a patch with a resultmap addition that matches your platform. There is already an entry horology/.*-irix6=horology-no-DST-before-1970 but it looks like that's not triggering on your system. It's not the same as the solaris-1947 variants. I compared all three horology files in the expected directory -- none match. There is no such irix6 file in the distribution. Please let me know what else you'd like me to do WRT to this diff. --Bob +-++ | Robert E. Bruccoleri, Ph.D. | email: [EMAIL PROTECTED]| | P.O. Box 314| URL: http://www.congen.com/~bruc | | Pennington, NJ 08534|| +-++ ---(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] Request for supported platforms
-Original Message- From: Bruce Momjian [mailto:pgman;candle.pha.pa.us] Sent: 05 November 2002 03:18 To: Sean Chittenden Cc: Tom Lane; Larry Rosenman; PostgreSQL-development Subject: Re: [HACKERS] Request for supported platforms Ports list updated: http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-pla tforms.html Hi Bruce, I noticed that you haven't updated the entry for Win32 native client-only. That builds OK now thanks to your fixes. Regards, Dave. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] protocol change in 7.4
On Mon, Nov 04, 2002 at 07:22:54PM -0500, Neil Conway wrote:
(1) Add an optional textual message to NOTIFY
(2) Remove the hard-coded limits on database and user names
(SM_USER, SM_DATABASE), replace them with variable-length
fields.
(3) Remove some legacy elements in the startup packet
('unused' can go -- perhaps 'tty' as well). I think the
'length' field of the password packet is also not used,
but I'll need to double-check that.
(4) Fix the COPY protocol (Tom?)
(5) Fix the Fastpath protocol (Tom?)
(6) Protocol-level support for prepared queries, in order to
bypass the parser (and maybe be more compatible with the
implementation of prepared queries in other databases).
(7) Include the current transaction status, since it's
difficult for the client app to determine it for certain
(Tom/Bruce?)
(8) Error codes (maybe needn't change protocol)
- without this is PostgreSQL useless in real DB aplication
(9) Think about full dynamic charset encoding (add new encoding on
the fly)
Karel
--
Karel Zak [EMAIL PROTECTED]
http://home.zf.jcu.cz/~zakkr/
C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] The document
Hello
In the document of postgresql I always see such text '\ref{where_clause} '.
But I wonder how can I see the graphics. In the DocBook software?
Thank you in advance.
Jinqiang Han
Re: [HACKERS] Another bug in tsearch?
On Tue, 5 Nov 2002, Christopher Kings-Lynne wrote: Hi Oleg Teodor, This behaviour is causing problems in my search engine: australia=# select 'banana/pineapple'::mquery_txt; mquery_txt 'banana/pineapple' (1 row) In our case the forward slash symbol should really be treated as a word break. Are there any cases where it shouldn't be? I can maybe only think of 3/4, etc. I wouldn't say it's a bug. It's a feature and called 'filename or path' :) Probably we should interpret it as 3 lexems 'banana/pineapple', 'banana', 'pineapple' or 2 last lexems ? Then you'll have a lot if noise for texts like mailing lists. You could adapt parser to suit you needs, anyway. Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(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] protocol change in 7.4
On 11/05/2002 04:42:55 AM Neil Conway wrote: Mike Mascari [EMAIL PROTECTED] writes: Is there any thought about changing the protocol to support two-phase commit? Not that 2PC and distributed transactions would be implemented in 7.4, but to prevent another protocol change in the future? My understanding is that 2PC is one way to implement multi-master replication. If that's what you're referring to, then I'm not sure I Another use of two-phase commit is in messaging middleware (MOM, message oriented middleware), were both the middleware and the database participate in the same transaction. Consider: - DB: begin - MOM: begin - DB: insert - MOM: send message - DB: prepare - MOM: prepare == fails - DB: rollback - MOM: rollback just a simple example... Maarten - --- Visit our Internet site at http://www.reuters.com Get closer to the financial markets with Reuters Messaging - for more information and to register, visit http://www.reuters.com/messaging Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.
Re: [HACKERS] protocol change in 7.4
Satoshi Nagayasu kirjutas T, 05.11.2002 kell 08:05: Tom Lane wrote: I don't see why 2PC would require any protocol-level change. I would think that the API would be something like BEGIN; issue some commands ... PRECOMMIT; -- if the above does not return an error, then COMMIT; In other words, 2PC would require some new commands, but a new command doesn't affect the protocol layer. I think a precommit-vote-commit phase of 2PC can be implemented in command-lavel or protocol-level. In command-level 2PC, an user application (or application programmer) must know the DBMS is clustered or not (to use PRECOMMIT command). In protocol-layer 2PC, no new SQL command is required. A precommit-vote-commit phase will be called implicitly. It means an user application can be used without any modification. An application can use a traditional way (BEGIN...COMMIT). If application continues to use just BEGIN/COMMIT, then the protocol level must parse command stream and recognize COMMIT in order to replace it with PRECOMMIT, COMMIT. If the communication library has to do that anyway, it could still do the replacement without affecting wire protocol, no ? -- Hannu ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Is my Internet connection slow
'k, is there a reason why it can't be run more often? If you say it's OK then no. I've made it run every 15 minutes now. -- +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen! ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] protocol change in 7.4
Hannu Krosing [EMAIL PROTECTED] wrote: I think a precommit-vote-commit phase of 2PC can be implemented in command-lavel or protocol-level. In command-level 2PC, an user application (or application programmer) must know the DBMS is clustered or not (to use PRECOMMIT command). In protocol-layer 2PC, no new SQL command is required. A precommit-vote-commit phase will be called implicitly. It means an user application can be used without any modification. An application can use a traditional way (BEGIN...COMMIT). If application continues to use just BEGIN/COMMIT, then the protocol level must parse command stream and recognize COMMIT in order to replace it with PRECOMMIT, COMMIT. If the communication library has to do that anyway, it could still do the replacement without affecting wire protocol, no ? In my implementation, 'the extended(2PC) FE/BE protocol' is used only in the communication between the master and slave server(s), not between a client app and the master server. libpq --Normal FE/BE-- (master)postgres --Extended(2PC)FE/BE-- (slave)postgres --Extended(2PC)FE/BE-- (slave)postgres --Extended(2PC)FE/BE-- (slave)postgres A client application and client's libpq can work continuously without any modification. This is very important. And protocol modification between master and slave server(s) is not so serious issue (I think). -- NAGAYASU Satoshi [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Is my Internet connection slow
Peter Eisentraut wrote: 'k, is there a reason why it can't be run more often? If you say it's OK then no. I've made it run every 15 minutes now. Will it run unconditionally or only on a CVS SGML change? -- 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: [HACKERS] protocol change in 7.4
On Tue, Nov 05, 2002 at 08:54:46PM +0900, Satoshi Nagayasu wrote: Hannu Krosing [EMAIL PROTECTED] wrote: In protocol-layer 2PC, no new SQL command is required. A precommit-vote-commit phase will be called implicitly. It means an user application can be used without any modification. An application can use a traditional way (BEGIN...COMMIT). If application continues to use just BEGIN/COMMIT, then the protocol level must parse command stream and recognize COMMIT in order to replace it with PRECOMMIT, COMMIT. If the communication library has to do that anyway, it could still do the replacement without affecting wire protocol, no ? No, I think Satoshi is suggesting that from the client's point of view, he's embedded the entire precommit-vote-commit cycle inside the COMMIT command. In my implementation, 'the extended(2PC) FE/BE protocol' is used only in the communication between the master and slave server(s), not between a client app and the master server. libpq --Normal FE/BE-- (master)postgres --Extended(2PC)FE/BE-- (slave)postgres --Extended(2PC)FE/BE-- (slave)postgres --Extended(2PC)FE/BE-- (slave)postgres A client application and client's libpq can work continuously without any modification. This is very important. And protocol modification between master and slave server(s) is not so serious issue (I think). Ah, but this limits your use of 2PC to transparent DB replication - since the client doesn't have access to the PRECOMMIT phase (usually called prepare phase, but that's anothor overloaded term in the DB world!) it _can't_ serve as the transaction master, so the other use cases that people have mentioned here (zope, MOMs, etc.) wouldn't be possible. Hmm, unless a connection can be switched into 2PC mode, so something other than a postgresql server can act as the transaction master. Does your implementation cascade? Can slaves have slaves? Ross ---(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] Is my Internet connection slow
I have ordered 128k ISDN, to be installed on November 12th. I am too far for ADSL but I hope the distances will increase in the future. -- 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: [HACKERS] Request for supported platforms
Dave Page wrote: -Original Message- From: Bruce Momjian [mailto:pgman;candle.pha.pa.us] Sent: 05 November 2002 03:18 To: Sean Chittenden Cc: Tom Lane; Larry Rosenman; PostgreSQL-development Subject: Re: [HACKERS] Request for supported platforms Ports list updated: http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-pla tforms.html Hi Bruce, I noticed that you haven't updated the entry for Win32 native client-only. That builds OK now thanks to your fixes. Thanks. Updated. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [GENERAL] PostgreSQL IRC Channel... who's the Admin?
*** Topic for #postgresql: 7.3Beta4 is now out, expect RC1 by the end of the week *** Topic for #postgresql set by DarcyB_ on Nov 4 17:54:40 Note that we are all on #EfNet servers ... On Tue, 5 Nov 2002, Justin Clift wrote: Hi all, Who's an Admin for the PostgreSQL IRC Channel (#postgresql) on irc.openprojects.net? The topic there is advertising some items for some guy on eBay, claiming it supports the PostgreSQL channel, and no-one knows anything about it. There also doesn't appear to be any IRC Admin's about. So, does anyone know who the Admin's are, so we can get things fixed up? :-) Regards and best wishes, Justin Clift -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Request for supported platforms
Yes, now it is Digital/HP/Compaq. Updated to existing Tru64 entry. Ports list updated: http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html --- Alessio Bragadini wrote: On Tue, 2002-11-05 at 00:40, Bruce Momjian wrote: Ports list updated: http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html Please note that you have an entry for Digital Unix and one for Compaq Tru64 while in fact they are the same OS that went through a whirlwind of name changes. Don't know if official name should be now HP Tru64 or some other... -- Alessio F. Bragadini [EMAIL PROTECTED] APL Financial Serviceshttp://village.albourne.com Nicosia, Cyprus phone: +357-22-755750 It is more complicated than you think -- The Eighth Networking Truth from RFC 1925 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [CYGWIN] ipc-daemon
Tom Lane writes: I disagree: just because cygipc returns error codes chosen at random doesn't mean that we should neglect the clear meaning of an error code. If a normal Unix system were to return EACCES here, the clear implication would be that there is an existing segment that we do not have permission to access. OK, but shouldn't the looping for a new segment terminate sometime? As it stands it will wrap around and run forever. If we catch it before it wraps and generate an error to the effect that no segments appear to be free, it might serve us. -- Peter Eisentraut [EMAIL PROTECTED] ---(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] protocol change in 7.4
Neil Conway wrote: (6) Protocol-level support for prepared queries, in order to bypass the parser (and maybe be more compatible with the implementation of prepared queries in other databases). Let me add (6b) Protocol level support for query parameters. This would actually make (6) more powerful and speed up non prepared (but similar) queries via the query cache (which is already there IIRC). [I talk about statement USING :var ... ] (n) Platform independant binary representation of parameters and results (like in CORBA). This can _really_ speed up communication with compiled programs if you take the time to implement it. This was previously planned for a future CORBA fe/be protocol, but this does not seem to come any time soon. (n+1) Optional additional Result qualifiers. E.g. dynamic embedded sql has a flag to indicate that this column is a key. Previously it was impossible to set this flag to a meaningful value. Also the standard has additional statistical information about the size of the column etc. If it's unclear what I'm talking about I will look up the exact location in the standard (it's embedded sql, dynamic sql, get descriptor) Yours Christof ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] protocol change in 7.4
Christof Petig wrote: Neil Conway wrote: (6) Protocol-level support for prepared queries, in order to bypass the parser (and maybe be more compatible with the implementation of prepared queries in other databases). Let me add (6b)Protocol level support for query parameters. This would actually make (6) more powerful and speed up non prepared (but similar) queries via the query cache (which is already there IIRC). [I talk about statement USING :var ... ] (n)Platform independant binary representation of parameters and results (like in CORBA). This can _really_ speed up communication with compiled programs if you take the time to implement it. This was previously planned for a future CORBA fe/be protocol, but this does not seem to come any time soon. After one night's sleep I think that perhaps a CORBA based protocol might be less work (but I have no idea about a decent authentification schema, I'd tend to reuse the already authentificated stream). A corbaized query-only interface might easily cover these issues and be less work than a full corba backend access. JDBC (I don't know much about it) might give a reasonable interface design (perhaps combined with a libpq[++|xx] like interface if there's benefit to it). (n+1)Optional additional Result qualifiers. E.g. dynamic embedded sql has a flag to indicate that this column is a key. Previously it was impossible to set this flag to a meaningful value. Also the standard has additional statistical information about the size of the column etc. If it's unclear what I'm talking about I will look up the exact location in the standard (it's embedded sql, dynamic sql, get descriptor) This does not need an implementation soon. But the new protocol should allow future things like this. All these proposals are motivated by (future) ecpg [C/C++] needs. So IMHO the ODBC, JDBC, libpqxx people might be interested in many of these issues, too. We definitely should make sure to have asked them. Yours Christof ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Is my Internet connection slow
Bruce Momjian writes: 'k, is there a reason why it can't be run more often? If you say it's OK then no. I've made it run every 15 minutes now. Will it run unconditionally or only on a CVS SGML change? It will run when anything in CVS changes, which is something yours appears to get wrong, because it still thinks it's 7.3devel. -- Peter Eisentraut [EMAIL PROTECTED] ---(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] v7.3Beta4 Tag'd and Packaged ...
Tom Lane writes: Right-o: HEAD is 7.4devel now ... Will someone merge the 7.3 branch into 7.4devel when the former is released? I don't feel like double-patching... -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Is my Internet connection slow
Peter Eisentraut wrote: Bruce Momjian writes: 'k, is there a reason why it can't be run more often? If you say it's OK then no. I've made it run every 15 minutes now. Will it run unconditionally or only on a CVS SGML change? It will run when anything in CVS changes, which is something yours appears to get wrong, because it still thinks it's 7.3devel. It should only run when src/sgml changes, not any CVS change. And, why do you think mine looks at 7.3devel? -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] v7.3Beta4 Tag'd and Packaged ...
On Tue, 5 Nov 2002, Peter Eisentraut wrote: Tom Lane writes: Right-o: HEAD is 7.4devel now ... Will someone merge the 7.3 branch into 7.4devel when the former is released? I don't feel like double-patching... At this stage, there shouldn't be anything really going *into* STABLE, if we want to get to RC1 ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Is my Internet connection slow
Bruce Momjian wrote: Peter Eisentraut wrote: Bruce Momjian writes: 'k, is there a reason why it can't be run more often? If you say it's OK then no. I've made it run every 15 minutes now. Will it run unconditionally or only on a CVS SGML change? It will run when anything in CVS changes, which is something yours appears to get wrong, because it still thinks it's 7.3devel. It should only run when src/sgml changes, not any CVS change. And, why do you think mine looks at 7.3devel? OK, I figured out why it thought it was 7.3devel. I don't update configure as part of the update, just doc/src/sgml. Updated now. -- 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 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] v7.3Beta4 Tag'd and Packaged ...
... to pull in those changes that were made to the REL7_3_STABLE branch ... Right. But, if I did: cvs checkout -rREL7_3_STABLE pgsql What would I use as BRANCHNAME in the -j to 'pull in' the changes we made to HEAD? Or is there where I'm misunderstanding something? Use HEAD for the tag from within the REL7_3_STABLE branch: cvs update -jHEAD pgsql The files will then show that they are modified, and you can then commit the changes to your branch. - Thomas ---(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] [PORTS] openbsd 3.2, postgresql 7.3beta3 and openssl 'e_os.h' include
Peter Galbavy wrote: According to the feedback I have had, e_os.h is no longer a public interface header file in OpenSSL. 'get_last_socket_error' is a macro that seems to expand to errno. Can I suggest someone with better understanding of the postgresql sources, and ssl support, please pick this up - maybe in time for the 7.3 release ? OK, I am using: #$ openssl OpenSSL version OpenSSL 0.9.6e 30 Jul 2002 and ssl compiles fine here. What version are you using, exactly. Maybe OpenBSD considered e_os.h to be a security risk. ;-) I don't think this will make 7.3 unless we can find more information. I am hesitant to make any changes that may break openssl on other platforms. If we can find a solution, it may be in 7.3.1. -- 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: [HACKERS] Postgresql and multithreading
I have updated the developers FAQ item 1.9 to address this: http://developer.postgresql.org/readtext.php?src/FAQ/FAQ_DEV.html+Developers-FAQ --- Anuradha Ratnaweera wrote: On Wed, Oct 16, 2002 at 01:51:28AM -0400, Bruce Momjian wrote: Let me add one more thing on this thread. This is one email in a long list of Oh, gee, you aren't using that wizz-bang new sync/thread/aio/raid/raw feature discussion where someone shows up and wants to know why. Does anyone know how to address these, efficiently? If somebody pops up asks such dumb questions without even looking at the FAQ, it is bad, if not idiotic, because it takes useful time away from the developers. But my question was not `why don't you implement this feature?`, but `do you have plans to implement this feature in the future?', and in the open source spirit of `if something is not there, go implement it yourself - without troubling developers' ;) Also, I have read the section 1.9 of the developers FAQ (Why don't we use threads in the backend?) long, long ago. If we discuss it, it ends up causing a lot of effort on our part for the requestor to finally say, Oh, gee, I didn't realize that. Please don't. See the NB at end of my first mail of this thread. Anuradha -- Debian GNU/Linux (kernel 2.4.18-xfs-1.1) QOTD: I'll listen to reason when it comes out on CD. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- 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: [HACKERS] PL/Perl and Perl 5.8
Neil Conway wrote: Peter Eisentraut [EMAIL PROTECTED] writes: The HAS_CRYPT_R is true because the function is available even without the prototype, but the struct is not. A plain bug in Perl's configury mechanism. Yeah, that's true. The question is whether it's worth working around the bug. IMHO, yes -- but what do other people think? With no motion on this, I assume we are going to call this a perl bug and not work around it for 7.3. -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] What user to defaults execute as?
Tom Lane writes: Okay, I've thought of one: consider the situation where you want to label each row in a table with the ID of the user who inserted it. Right now, you can do ..., who namedefault current_user, ... or for greater security use a trigger to set the column value. This will stop working if defaults and triggers run as the table owner. According to the SQL standard, privileges on constraints should effectively be checked at the time the constraint is created. For example, when you create a foreign key constraint you may need certain REFERENCES privileges, and equally creating check constraints should require REFERENCES privilege on tables involved in subqueries. While the SQL standard doesn't say anything on how this should apply to column defaults (since there you can't call user-defined functions or subqueries in default clauses), it would make sense to carry this over. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] v7.3Beta4 Tag'd and Packaged ...
On Tue, 5 Nov 2002, Thomas Lockhart wrote: ... to pull in those changes that were made to the REL7_3_STABLE branch ... Right. But, if I did: cvs checkout -rREL7_3_STABLE pgsql What would I use as BRANCHNAME in the -j to 'pull in' the changes we made to HEAD? Or is there where I'm misunderstanding something? Use HEAD for the tag from within the REL7_3_STABLE branch: cvs update -jHEAD pgsql The files will then show that they are modified, and you can then commit the changes to your branch. *groan* I figured I was restricted to that which shows as BRANCH/TAGs in a cvs log :( Noted for next release cycle ... thanks ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] v7.3Beta4 Tag'd and Packaged ...
Marc G. Fournier writes: At this stage, there shouldn't be anything really going *into* STABLE, if we want to get to RC1 ... If we don't put anything into stable then we will never get to anything. Surely we still need to put in some fixes and documentation updates. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] v7.3Beta4 Tag'd and Packaged ...
Peter Eisentraut wrote: Marc G. Fournier writes: At this stage, there shouldn't be anything really going *into* STABLE, if we want to get to RC1 ... If we don't put anything into stable then we will never get to anything. Surely we still need to put in some fixes and documentation updates. I think he means nothing _major_ will be going into stable, just stuff we want for RC1/final. -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PL/Perl and Perl 5.8
On Dienstag, November 5, 2002, at 11:24 Uhr, Bruce Momjian wrote: Neil Conway wrote: Peter Eisentraut [EMAIL PROTECTED] writes: The HAS_CRYPT_R is true because the function is available even without the prototype, but the struct is not. A plain bug in Perl's configury mechanism. Yeah, that's true. The question is whether it's worth working around the bug. IMHO, yes -- but what do other people think? With no motion on this, I assume we are going to call this a perl bug and not work around it for 7.3. I've only just subscribed to this list, so I don't know all of the discussion (given time, I'll look it up in the archives). But if you have found a perl bug, particularly one of configuration, I'm sure the perl developers would be grateful if you could report it to the perl5-porters list (http://lists.perl.org/showlist.cgi?name=perl5-porters). Or I could report it on your behalf, if you don't want to subscribe and unsubscribe and all that. Thank you, Marcel ---(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 beta4 created ...
Marc G. Fournier writes: We'll get this build right yet :) I'm copying the man.tar.gz that is in: cp /var/spool/ftp/pub/dev/doc/man.tar.gz .. The postgres.tar.gz that is in there appears to be good to 1hr ago, but you are right about the man.tar.gz ... Peter? I've uploaded a new one. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [CYGWIN] ipc-daemon
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: I disagree: just because cygipc returns error codes chosen at random doesn't mean that we should neglect the clear meaning of an error code. If a normal Unix system were to return EACCES here, the clear implication would be that there is an existing segment that we do not have permission to access. OK, but shouldn't the looping for a new segment terminate sometime? As it stands it will wrap around and run forever. Hm. It would be reasonable to put a limit on the number of attempts, probably. (There's a similar limit on attempts to create a lockfile.) regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PL/Perl and Perl 5.8
Bruce Momjian [EMAIL PROTECTED] writes: With no motion on this, I assume we are going to call this a perl bug and not work around it for 7.3. Erm, no -- Reinhard Max already sent a fix for this to -patches, Tom had an objection to it, and then Reinhard posted another version (which presumably satisfies Tom's objections). It should probably be in RC1... Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(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] PL/Perl and Perl 5.8
Marcel Grünauer [EMAIL PROTECTED] writes: I've only just subscribed to this list, so I don't know all of the discussion (given time, I'll look it up in the archives). But if you have found a perl bug, particularly one of configuration, I'm sure the perl developers would be grateful if you could report it to the perl5-porters list (http://lists.perl.org/showlist.cgi?name=perl5-porters). Yes, it has already been reported to p5p. The first p5p thread on the topic didn't contain any mention of a fix for the problem being committed to the stable branch, but the Perl maintainers are aware of it, at any rate, and may have fixed it in the interim. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PL/Perl and Perl 5.8
Neil Conway [EMAIL PROTECTED] writes: Erm, no -- Reinhard Max already sent a fix for this to -patches, Tom had an objection to it, and then Reinhard posted another version (which presumably satisfies Tom's objections). Peter didn't like it ... which is about what I'd expected, but I was keeping quiet till he weighed in ... I'm guessing that what we need to do is -D_GNU_SOURCE somewhere in the Makefiles; the $64 question is exactly where (can we restrict it to src/pl/plperl?) and what conditions should cause the Makefiles to add it? Do we want a configure test? FWIW, I see no such failure on HPUX with Perl 5.8.0, but that seems to be because Perl's HAS_CRYPT_R symbol doesn't get set here. Which is odd in itself, because crypt_r() is definitely available on this platform. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [PORTS] openbsd 3.2, postgresql 7.3beta3 and openssl 'e_os.h' include
Bruce Momjian [EMAIL PROTECTED] writes: Peter Galbavy wrote: According to the feedback I have had, e_os.h is no longer a public interface header file in OpenSSL. 'get_last_socket_error' is a macro that seems to expand to errno. OK, I am using: #$ openssl OpenSSL version OpenSSL 0.9.6e 30 Jul 2002 and ssl compiles fine here. What version are you using, exactly. I have OpenSSL 0.9.6g here (which is still the current release according to www.openssl.org). openssl/e_os.h is certainly still there ... but it does contain the comment /* openssl/e_os2.h contains what we can justify to make visible * to the outside; this file e_os.h is not part of the exported * interface. */ which may have prompted the OpenBSD porter to not include it? Anyway, get_last_socket_error() seems exactly equivalent to our macro SOCK_ERRNO in libpq/libpq-int.h. AFAICT, the uses of it in our code are these: /home/postgres/pgsql/src/backend/libpq/be-secure.c: errno = get_last_socket_error(); /home/postgres/pgsql/src/backend/libpq/be-secure.c: errno = get_last_socket_error(); /home/postgres/pgsql/src/interfaces/libpq/fe-secure.c: SOCK_ERRNO = get_last_socket_error(); /home/postgres/pgsql/src/interfaces/libpq/fe-secure.c: SOCK_ERRNO = get_last_socket_error(); and I think every one of these is bogus and should be removed. At best they're no-ops. If that is the only use of e_os.h stuff then we can stop including the file ... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] protocol change in 7.4
Ross J. Reedstrom [EMAIL PROTECTED] wrote: If application continues to use just BEGIN/COMMIT, then the protocol level must parse command stream and recognize COMMIT in order to replace it with PRECOMMIT, COMMIT. If the communication library has to do that anyway, it could still do the replacement without affecting wire protocol, no ? No, I think Satoshi is suggesting that from the client's point of view, he's embedded the entire precommit-vote-commit cycle inside the COMMIT command. Exactly. When user send the COMMIT command to the master server, the master.talks to the slaves to process precommit-vote-commit using the 2PC. The 2PC cycle is hidden from user application. User application just talks the normal FE/BE protocol. In my implementation, 'the extended(2PC) FE/BE protocol' is used only in the communication between the master and slave server(s), not between a client app and the master server. libpq --Normal FE/BE-- (master)postgres --Extended(2PC)FE/BE-- (slave)postgres --Extended(2PC)FE/BE-- (slave)postgres --Extended(2PC)FE/BE-- (slave)postgres A client application and client's libpq can work continuously without any modification. This is very important. And protocol modification between master and slave server(s) is not so serious issue (I think). Ah, but this limits your use of 2PC to transparent DB replication - since the client doesn't have access to the PRECOMMIT phase (usually called prepare phase, but that's anothor overloaded term in the DB world!) it _can't_ serve as the transaction master, so the other use cases that people have mentioned here (zope, MOMs, etc.) wouldn't be possible. Hmm, unless a connection can be switched into 2PC mode, so something other than a postgresql server can act as the transaction master. I think the client should not act as the transaction master. But if it is needed, the client can talk to postgres servers with the extended 2PC FE/BE protocol. Because all postgres servers(master and slave) can understand both the normal FE/BE protocol and the extended 2PC FE/BE protocol. It is switched in the startup packet. See 10 page. http://snaga.org/pgsql/20021018_2pc.pdf I embeded 'the connection type' in the startup packet to switch postgres backend's behavior (normal FE/BE protocol or 2PC FE/BE protocol). In current implementation, if the connection type is 'R', it is handled as the 2PC FE/BE connection (replication connection). Does your implementation cascade? Can slaves have slaves? It is not implemented, but I hope so. :-) And I think it is not so difficult. -- NAGAYASU Satoshi [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] RC1 on Friday?
Are we still on schedule for RC1 on Friday? -- 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] Win32 port
I have copies of Peer Direct's (Jan's company) port of PostgreSQL to Win32, and SRA's port to Win32, and permission to generate a merged patch that can be applied to 7.4. Now that 7.3 is almost complete, I am going to start work on that. I will post patches that deal with specific portability issues, like fork/exec and path separator handling, and once reviewed, apply them to the main CVS tree for 7.4. -- 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 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] Win32 port
Bruce Momjian wrote: I have copies of Peer Direct's (Jan's company) port of PostgreSQL to Win32, and SRA's port to Win32, and permission to generate a merged patch that can be applied to 7.4. Now that 7.3 is almost complete, I am going to start work on that. I will post patches that deal with specific portability issues, like fork/exec and path separator handling, and once reviewed, apply them to the main CVS tree for 7.4. Whoo Hooo! :-) + Justin -- 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 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 -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Win32 port
On Wed, 2002-11-06 at 01:32, Justin Clift wrote: Bruce Momjian wrote: I have copies of Peer Direct's (Jan's company) port of PostgreSQL to Win32, and SRA's port to Win32, and permission to generate a merged patch that can be applied to 7.4. Now that 7.3 is almost complete, I am going to start work on that. I will post patches that deal with specific portability issues, like fork/exec and path separator handling, and once reviewed, apply them to the main CVS tree for 7.4. Whoo Hooo! :-) + Justin Couldn't agree with Justin more. Even though I won't use it in production, We have developers that use postgres on their windows laptops for development and cygwin just doesn't cut it. ---(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] Win32 port
Bruce Momjian kirjutas K, 06.11.2002 kell 08:19: I have copies of Peer Direct's (Jan's company) port of PostgreSQL to Win32, and SRA's port to Win32, and permission to generate a merged patch that can be applied to 7.4. Great! Now that 7.3 is almost complete, I am going to start work on that. I will post patches that deal with specific portability issues, like fork/exec and path separator handling, and once reviewed, apply them to the main CVS tree for 7.4. What C compiler will you be working with ? I hope that at least MingW should be supported ? - Hannu ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] protocol change in 7.4
Satoshi Nagayasu kirjutas K, 06.11.2002 kell 04:15: Ross J. Reedstrom [EMAIL PROTECTED] wrote: If application continues to use just BEGIN/COMMIT, then the protocol level must parse command stream and recognize COMMIT in order to replace it with PRECOMMIT, COMMIT. If the communication library has to do that anyway, it could still do the replacement without affecting wire protocol, no ? No, I think Satoshi is suggesting that from the client's point of view, he's embedded the entire precommit-vote-commit cycle inside the COMMIT command. Exactly. When user send the COMMIT command to the master server, the master.talks to the slaves to process precommit-vote-commit using the 2PC. The 2PC cycle is hidden from user application. User application just talks the normal FE/BE protocol. But _can_ client (libpq/jdbc/...) also talk 2PC FE/BE protocol, i.e. act as master ? In my implementation, 'the extended(2PC) FE/BE protocol' is used only in the communication between the master and slave server(s), not between a client app and the master server. libpq --Normal FE/BE-- (master)postgres --Extended(2PC)FE/BE-- (slave)postgres --Extended(2PC)FE/BE-- (slave)postgres --Extended(2PC)FE/BE-- (slave)postgres A client application and client's libpq can work continuously without any modification. This is very important. And protocol modification between master and slave server(s) is not so serious issue (I think). Ah, but this limits your use of 2PC to transparent DB replication - since the client doesn't have access to the PRECOMMIT phase (usually called prepare phase, but that's anothor overloaded term in the DB world!) it _can't_ serve as the transaction master, so the other use cases that people have mentioned here (zope, MOMs, etc.) wouldn't be possible. Hmm, unless a connection can be switched into 2PC mode, so something other than a postgresql server can act as the transaction master. I think the client should not act as the transaction master. But if it is needed, the client can talk to postgres servers with the extended 2PC FE/BE protocol. Because all postgres servers(master and slave) can understand both the normal FE/BE protocol and the extended 2PC FE/BE protocol. It is switched in the startup packet. Why is the protocol change neccessary ? Is there some fundamental reason that the slave backends can't just wait and see if the first commit command is PRECOMMIT or COMMIT and then act accordingly on for each transaction ? - Hannu ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
