I seem to have misunderstood the problem completely.
I apologize to you all(especially Tom) for disturbing
this thread.
I wonder if there might be such a nice solution when
some of the systems or communications are dead.
And as many people already mentioned, there's not so
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 29 September 2003 01:28
To: Alvaro Herrera
Cc: Peter Eisentraut; Hackers
Subject: Re: [HACKERS] more i18n/l10n issues
Alvaro Herrera [EMAIL PROTECTED] writes:
If you put it that way :-) I'll leave it alone.
Dave Page writes:
I find this a little worrying because if we want a feature or tweak for
pgAdmin we usually have to fight tooth nail to justify getting it
committed (which is not a bad thing), however 'some guys at Red Hat' are
getting switches added to the postmaster without any
Bruce Momjian writes:
Seems we can silently ignore a --use-set-session-authorization flag
because that is now the default, but I don't see how we can ignore a
--no-reconnect flag --- we should throw an error.
Why? The new bevavior of pg_dump is to never reconnect -- exactly the
point of this
Christopher Kings-Lynne wrote:
You could just as easily argue that the lack of integrity testing at
data load time was equally a bug.
I think we need someway of telling postgres to suppress a foreign key
check.
The main problem is that the foreign key column is often not indexed.
So a db
Christopher Kings-Lynne wrote:
Hi,
I notice that the pretty printing version of pg_get_ruledef inserts extra
newlines whereas all the others pretty functions (except view defs) do
not. In fact, Andreas argued against a version of pg_get_triggerdef()
that added extra newlines.
No, I did not *in
So a db designer made a bloody mistake.
The problem is there's no easy way to find out what's missing.
I'd really like EXPLAIN to display all subsequent triggered queries
also, to see the full scans caused by missing indexes.
I'd sure second that!
Chris
---(end of
No, I did not *in general*, but for now because there's no node
traversing and a pretty formatted query can be easily constructed by
yourself as for all other non-pg_get_xxx supported objects.
The reason I bring it up is that if psql is changed to use the pretty
printing option, then the rules
Peter Eisentraut wrote:
Dave Page writes:
I find this a little worrying because if we want a feature or tweak for
pgAdmin we usually have to fight tooth nail to justify getting it
committed (which is not a bad thing), however 'some guys at Red Hat' are
getting switches added to the
Hello,
I'm trying to detect memory leaks in an external postgres extensions.
Since SIZE of postgres process keeps growing between function calls,
does this mean there are memory leaks in the extenal packages or
it might be the postgres itself keeping allocated memory as a buffer
for later use ?
Andreas Pflug kirjutas E, 29.09.2003 kell 12:04:
Christopher Kings-Lynne wrote:
You could just as easily argue that the lack of integrity testing at
data load time was equally a bug.
I think we need someway of telling postgres to suppress a foreign key
check.
The main problem is
So a db designer made a bloody mistake.
The problem is there's no easy way to find out what's missing.
I'd really like EXPLAIN to display all subsequent triggered queries
also, to see the full scans caused by missing indexes.
It could probably be doable for EXPLAIN ANALYZE (by actually tracing
On Monday 29 September 2003 15:58, Christopher Kings-Lynne wrote:
So a db designer made a bloody mistake.
The problem is there's no easy way to find out what's missing.
I'd really like EXPLAIN to display all subsequent triggered queries
also, to see the full scans caused by missing indexes.
On Mon, 29 Sep 2003, Christopher Kings-Lynne wrote:
So a db designer made a bloody mistake.
The problem is there's no easy way to find out what's missing.
I'd really like EXPLAIN to display all subsequent triggered queries
also, to see the full scans caused by missing indexes.
I'd
Shridhar Daithankar kirjutas E, 29.09.2003 kell 13:34:
On Monday 29 September 2003 15:58, Christopher Kings-Lynne wrote:
So a db designer made a bloody mistake.
The problem is there's no easy way to find out what's missing.
I'd really like EXPLAIN to display all subsequent triggered queries
On Sun, Sep 28, 2003 at 23:16:48 -0400,
Bruce Momjian [EMAIL PROTECTED] wrote:
Christopher Kings-Lynne wrote:
If you are referring to my patch, Bruce - that does not fix it. Mine
only addresses psql.
I don't think that pg_dump uses pg_get_constraintdef(). It's probably a
side
The simplest senario(though there could be varations) is
[At participant(master)'s side]
Because the commit operations is done, does nothing.
[At coordinator(slave)' side]
1) After a while
2) re-establish the communication path between the
Christopher Kings-Lynne wrote:
No, I did not *in general*, but for now because there's no node
traversing and a pretty formatted query can be easily constructed by
yourself as for all other non-pg_get_xxx supported objects.
The reason I bring it up is that if psql is changed to use
Peter Eisentraut wrote:
Bruce Momjian writes:
Seems we can silently ignore a --use-set-session-authorization flag
because that is now the default, but I don't see how we can ignore a
--no-reconnect flag --- we should throw an error.
Why? The new bevavior of pg_dump is to never
Nigel J. Andrews wrote:
On Mon, 29 Sep 2003, Christopher Kings-Lynne wrote:
So a db designer made a bloody mistake.
The problem is there's no easy way to find out what's missing.
I'd really like EXPLAIN to display all subsequent triggered queries
also, to see the full scans caused by missing
On Mon, 29 Sep 2003, Hiroshi Inoue wrote:
Hiroshi Inoue wrote:
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
The simplest senario(though there could be varations) is
[At participant(master)'s side]
Because the commit operations is done, does nothing.
Bruno Wolff III wrote:
On Sun, Sep 28, 2003 at 23:16:48 -0400,
Bruce Momjian [EMAIL PROTECTED] wrote:
Christopher Kings-Lynne wrote:
If you are referring to my patch, Bruce - that does not fix it. Mine
only addresses psql.
I don't think that pg_dump uses
Marc G. Fournier wrote:
Master Slave
-- -
commit ready--
--OK
commit done-XX
is the commit done message needed ?
Of course ... how else will the Slave commit? From my understanding, the
concept is
Tom Lane wrote:
[At participant(master)'s side]
Because the commit operations is done, does nothing.
[At coordinator(slave)' side]
1) After a while
2) re-establish the communication path between the
partcipant(master)'s TM.
3) resend the commit requeset to the
Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
... You can make this work, but the resource costs
are steep.
So, after 'n' seconds of waiting, we abandon the slave and the slave
abandons the master.
[itch...] But you surely cannot guarantee that the slave and the
On Mon, 29 Sep 2003, Bruce Momjian wrote:
Marc G. Fournier wrote:
Master Slave
-- -
commit ready--
--OK
commit done-XX
is the commit done message needed ?
Of course ... how else will the
Peter Eisentraut [EMAIL PROTECTED] writes:
Dave Page writes:
I find this a little worrying because if we want a feature or tweak for
pgAdmin we usually have to fight tooth nail to justify getting it
committed (which is not a bad thing), however 'some guys at Red Hat' are
getting switches
Rod Taylor schrieb:
Is this syntax ok?
ALTER TABLE table ALTER COLUMN column TYPE new
type
shouldn't that be
ALTER TABLE table ALTER [COLUMN] column [TYPE] new type
which I clearly remember from different database systems.
Christof
I don't think there is any way to handle cases where the master or slave
just disappears. The other machine isn't under the server's control, so
it has no way of it knowing. I think we have to allow the administrator
to set a timeout, or ask to wait indefinately, and allow them to call an
Master Slave
-- -
commit ready--
--OK
commit done-XX
is the commit done message needed ?
Of course ... how else will the Slave commit? From my
understanding, the
concept is that the
Marc G. Fournier wrote:
is the commit done message needed ?
Of course ... how else will the Slave commit? From my understanding, the
concept is that the master sends a commit ready to the slave, but the OK
back is that OK, I'm ready to commit whenever you are, at which point
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 29 September 2003 15:23
To: Peter Eisentraut
Cc: Dave Page; Alvaro Herrera; Hackers
Subject: Re: [HACKERS] more i18n/l10n issues
Peter Eisentraut [EMAIL PROTECTED] writes:
Dave Page writes:
I find this a
A. On Mon, 2003-09-29 at 10:28, Christof Petig wrote:
Rod Taylor schrieb:
Is this syntax ok?
ALTER TABLE table ALTER COLUMN column TYPE new
type
shouldn't that be
ALTER TABLE table ALTER [COLUMN] column [TYPE] new type
which I clearly
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
If you are referring to my patch, Bruce - that does not fix it. Mine
only addresses psql.
It strikes me that maybe your patch should add parens always, rather
than just in the prettyprint case.
I don't think that pg_dump uses
Rod Taylor [EMAIL PROTECTED] writes:
Questions:
Is this syntax ok?
ALTER TABLE table ALTER COLUMN column TYPE new
type
It should be the same as whatever All Them Other Databases use.
COERCE_ASSIGNMENT is the appropriate coercion technique, I
Bruce Momjian [EMAIL PROTECTED] writes:
but I don't see how we can ignore a --no-reconnect flag --- we should
throw an error.
We can ignore it because we don't reconnect. I only took out the flag
because I noticed it was no longer tested anywhere after I removed the
\connect code paths. I'm
[EMAIL PROTECTED] (Bruce Momjian) writes:
Peter Eisentraut wrote:
Bruce Momjian writes:
The argument that you want a warning because you might have mixed
newlines in the file seems less likely than this case where they are
using a literal carriage return as a data value at the end of the
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
but I don't see how we can ignore a --no-reconnect flag --- we should
throw an error.
We can ignore it because we don't reconnect. I only took out the flag
because I noticed it was no longer tested anywhere after I removed the
Hiroshi Inoue [EMAIL PROTECTED] writes:
But is it 2-phase commit protocol in the first place ?
That is, in your exmaple below
Example:
Master Slave
-- -
commit ready--
--OK
commit done-XX
is the commit
Tom Lane wrote:
Lamar Owen [EMAIL PROTECTED] writes:
This isn't necessarily true. That old of a version of PostgreSQL is probably
running on a quite out-of-date OS -- for instance, if the OS was Red Hat
Linux, then the point at which 6.2.1 was shipped was RHL 5.0. Can you even
compile
Should we allow SHOW ALL to show these variable descriptions?
---
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Dave Page writes:
I find this a little worrying because if we want a feature or tweak for
Bruce Momjian [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
It had been dicussed on and off for quite some time. This limitation
should only apply if you create dumps that contain objects owned by more
than one user. (Does it? I didn't check.)
Yes, but didn't the old code prompt you
Tom Lane wrote:
Yes, but didn't the old code prompt you for passwords, or silently work
if you had things set to 'trust', while our new code requires
super-user?
If you have things set to trust, you can be superuser, eh?
A password approach might be workable using ~/.pgpass, but only
And maybe show the descriptions in pg_settings too?
---
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Dave Page writes:
I find this a little worrying because if we want a feature or tweak for
pgAdmin we
Tom Lane wrote:
The point was to allow a GUI utility to be built that would help in
editing postgresql.conf. It couldn't assume the postmaster is already
running, so just extending the pg_config view wouldn't answer, and
duplicating knowledge of all the GUC variables in a separate tool
would
Bruce Momjian [EMAIL PROTECTED] writes:
And maybe show the descriptions in pg_settings too?
There was discussion of doing that, but it didn't get done in time
(and it's too late now for 7.4 unless you want an initdb). I wouldn't
mind putting it on TODO for 7.5.
I think the SHOW ALL output
Or the slave could reject the request.
Huh? The slave has that option?? In what circumstance?
I thought the slave could reject if someone local already had the row
locked.
No, not at all. The slave would need to reject phase 1 commit ready
for this.
Andreas
On Sat, Sep 27, 2003 at 09:13:27AM -0300, Marc G. Fournier wrote:
I think it was Andrew that suggested it ... when the slave timesout, it
should trigger a READ ONLY mode on the slave, so that when/if the master
tries to start to talk to it, it can't ...
As for the master itself, it should
Zeugswetter Andreas SB SD wrote:
Or the slave could reject the request.
Huh? The slave has that option?? In what circumstance?
I thought the slave could reject if someone local already had the row
locked.
No, not at all. The slave would need to reject phase 1 commit ready
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Marc G. Fournier wrote:
Or the slave could reject the request.
Huh? The slave has that option?? In what circumstance?
I thought the slave could reject if someone local already had the row
locked.
All normal reasons for
On Sun, Sep 28, 2003 at 11:58:24AM -0700, Kevin Brown wrote:
But the postmaster doesn't connect to any database, and in a serious
failure, might not be able to start one.
Ah, true. But I figured that in the context of 2PC and replication that
most of the associated failures were likely to
Andrew Sullivan wrote:
On Sat, Sep 27, 2003 at 09:13:27AM -0300, Marc G. Fournier wrote:
I think it was Andrew that suggested it ... when the slave timesout, it
should trigger a READ ONLY mode on the slave, so that when/if the master
tries to start to talk to it, it can't ...
As for
Joe Conway wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
And maybe show the descriptions in pg_settings too?
There was discussion of doing that, but it didn't get done in time
(and it's too late now for 7.4 unless you want an initdb). I wouldn't
mind putting it on
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
And maybe show the descriptions in pg_settings too?
There was discussion of doing that, but it didn't get done in time
(and it's too late now for 7.4 unless you want an initdb). I wouldn't
mind putting it on TODO for 7.5.
Bruce, you can put
On Mon, Sep 29, 2003 at 11:14:30AM -0300, Marc G. Fournier wrote:
Or the slave could reject the request.
Huh? The slave has that option?? In what circumstance?
In every circumstance where a stand-alone machine would have it.
Machine A may not yet know about conflicting transactions on
Bruce Momjian [EMAIL PROTECTED] writes:
Marc G. Fournier wrote:
Or the slave could reject the request.
Huh? The slave has that option?? In what circumstance?
I thought the slave could reject if someone local already had the row
locked.
All normal reasons for transaction failure are
On Sat, Sep 27, 2003 at 08:36:36AM +, Jeff wrote:
What do commercial databases do about 2PC or other multi-master solutions?
You've done a good job of convincing me that it's unreliable no matter what
(through your posts on this topic over a long time). However, I would think
that
Today's cvs doesn't compile. I think it is due to
cvs diff -r1.7 -r1.8 src/interfaces/ecpg/include/datetime.h
I have dtime_t defined in my sys/types.h. The old version of datetime.h used
#define dtime_t timestamp, the new one uses a typedef. Is there actually
a reason to keep dtime_t, or would
On Fri, Sep 26, 2003 at 05:15:37PM -0400, Rod Taylor wrote:
The first problem is the restart/rejoin problem. When a 2PC member
goes away, it is supposed to come back with all its former locks and
everything in place, so that it can know what to do. This is also
extremely tricky, but I
Alvaro Herrera writes:
#: utils/misc/guc.c:647
msgid collect statistics about executing commands
Is this really statistics about the executing commands?
Looks like it.
#: utils/misc/guc.c:892
msgid
The number must be a positive integer. If 0 is specified then effort *
log2(poolsize)
Andrew Dunstan [EMAIL PROTECTED] writes:
I have been wondering if moving to XML for config files might be a good
idea - and if there are going to be GUIs that write them that gives some
more impetus to the idea.
Or would it be overkill?
Seems like overkill. What would it buy us, other
On Monday 29 September 2003 11:41 am, Jan Wieck wrote:
Tom Lane wrote:
I do agree that people running that old a Linux distro need to think
about updating more than just Postgres, though. They have kernel bugs
as well as PG bugs to fear :-(
Plus all the well known vulnerabilities used by
Perhaps the ALTER command could include an optional clause TRANSFORM
expr-on-oldcol to do this. In that case, defaulting to assignment
coercion would be fine with me.
This would certainly be interesting and shouldn't take too much to
accomplish for simple expressions. If we allow the full
On Mon, Sep 29, 2003 at 06:41:48PM +0100, Patrick Welche wrote:
Today's cvs doesn't compile. I think it is due to
Forgot one question. WHich platform do you use?
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go
On Mon, Sep 29, 2003 at 06:41:48PM +0100, Patrick Welche wrote:
Today's cvs doesn't compile. I think it is due to
cvs diff -r1.7 -r1.8 src/interfaces/ecpg/include/datetime.h
I have dtime_t defined in my sys/types.h. The old version of datetime.h used
Argh, didn't know that some systems have
Michael Meskes wrote:
On Mon, Sep 29, 2003 at 06:41:48PM +0100, Patrick Welche wrote:
Today's cvs doesn't compile. I think it is due to
cvs diff -r1.7 -r1.8 src/interfaces/ecpg/include/datetime.h
I have dtime_t defined in my sys/types.h. The old version of datetime.h used
For ecpg it does
So a db designer made a bloody mistake.
Not necessarily. If I'm never going to update or delete from the parent table
the index would be useless. I find very few of my foreign key relationships
actually need indexes on the child table. I usually only have the unique index
on the parent
Tom Lane [EMAIL PROTECTED] writes:
Not sure to what extent we can apply that theory to views, though.
If it would result in a change in a view's output column datatype,
do we want to allow that (which would mean recursively propagating
that column type change to yet other places)?
Just as a
Rod Taylor [EMAIL PROTECTED] writes:
Perhaps the ALTER command could include an optional clause TRANSFORM
expr-on-oldcol to do this. In that case, defaulting to assignment
coercion would be fine with me.
This would certainly be interesting and shouldn't take too much to
accomplish for
It seems that one way out is just to fall back to read only as soon
as a single failure happens. That's the least graceful but maybe
safest approach to failure, analogous to what fsck does to your root
filesystem at boot time. Of course, since there's no read only
mode at the moment,
Tom Lane writes:
No. The real problem with 2PC in my mind is that its failure modes
occur *after* you have promised commit to one or more parties. In
multi-master, if you fail you know it before you have told the client
his data is committed.
I have a book here which claims that the
I have emptied the patch queue, and have updated the HISTORY file for
7.4. I am looking for any improvements to that file. (I have to move
it to SGML soon.)
Perhaps it is time to start looking at a final release date for 7.4?
--
Bruce Momjian|
No, I'm not. One needs to decide how to handle the situation where a
slave database in a 2PC transaction goes away and comes back, for
whatever reasons that may happen. Since the idea here is to come up
with ways of handling the failure of 2PC in some cases, we need
something which notices
Peter Eisentraut [EMAIL PROTECTED] writes:
It had been dicussed on and off for quite some time. This limitation
should only apply if you create dumps that contain objects owned by more
than one user. (Does it? I didn't check.)
Yes, because SET SESSION AUTHORIZATION yourself is allowed even
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
My live 7.3.4 database dumps data like this:
REVOKE ALL ON TABLE log_freeprofile FROM PUBLIC;
GRANT ALL ON TABLE log_freeprofile TO brett;
GRANT INSERT,SELECT,UPDATE ON TABLE log_freeprofile TO au-php;
GRANT SELECT ON TABLE log_freeprofile TO
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: Monday, September 29, 2003 7:10 AM
To: Marc G. Fournier
Cc: Hiroshi Inoue; Tom Lane; 'Zeugswetter Andreas SB SD';
'Andrew Sullivan'; [EMAIL PROTECTED]
Subject: Re: [HACKERS] 2-phase commit
Marc G. Fournier
Peter Eisentraut wrote:
Tom Lane writes:
No. The real problem with 2PC in my mind is that its failure modes
occur *after* you have promised commit to one or more parties. In
multi-master, if you fail you know it before you have told the client
his data is committed.
I have a book here
On Mon, Sep 29, 2003 at 02:11:37PM -0400, Bruce Momjian wrote:
Should that be visible to non-Informix-compatible builds, or is there
no way to control that.
No, it is just defined if you include datetime.h which is supposed to
replace Informix file. And the datetime type is only used inside
Bruce Momjian [EMAIL PROTECTED] writes:
Current at ftp://momjian.postgresql.org/pub/postgresql/open_items.
A couple things you don't have there:
* Tuple visibility rules for triggers and rules fired by RI actions
(I'm now of the opinion that the visibility patch I put in a few days
ago is
Bruce Momjian [EMAIL PROTECTED] writes:
Perhaps it is time to start looking at a final release date for 7.4?
At the very least we need to set a strings freeze soon, so the
translators can catch up. Peter, are you getting close to done with the
message revisions you've been making?
Manfred Spraul writes:
Ok. Lets assume one coordinator, two partitipants.
Global commit send to both by coordinator. One replies with ok, the
other one remains silent.
What should the coordinator do? It can't fail the transaction - the
first partitipant has commited its part. It can't
Should we maybe get a Beta4 out now that everything is caught up code
wise? Is anyone still sitting on something (other then the translations
stuff) that should be in v7.4?
On Mon, 29 Sep 2003, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Perhaps it is time to start looking at a
On Sun, 28 Sep 2003, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
On Sat, 27 Sep 2003, Tom Lane wrote:
I thought of what seems to be a better design for the check query: use
a LEFT JOIN and check for NULL in the righthand joined column.
Hmm, my initial testing showed that it
On Mon, 29 Sep 2003, Stephan Szabo wrote:
When I lowered random_page_cost to 1, I got an indexscan on fktable, but
that hadn't seemed to finish after about 2 hours (as opposed to about
30-35 minutes for the not exists and about 30 min - 1 1/2 hours for the
Small correction, I'd meant to type
On Mon, 2003-09-29 at 15:55, Peter Eisentraut wrote:
Manfred Spraul writes:
Ok. Lets assume one coordinator, two partitipants.
Global commit send to both by coordinator. One replies with ok, the
other one remains silent.
What should the coordinator do? It can't fail the transaction -
Marc G. Fournier [EMAIL PROTECTED] writes:
Should we maybe get a Beta4 out now that everything is caught up code
wise? Is anyone still sitting on something (other then the translations
stuff) that should be in v7.4?
We still have several open items in Bruce's list, but maybe we can
resolve
On Mon, 2003-09-29 at 14:57, Bruce Momjian wrote:
I have emptied the patch queue, and have updated the HISTORY file for
7.4. I am looking for any improvements to that file. (I have to move
it to SGML soon.)
A patch that improves HISTORY is attached. I added a few bullet items to
the
Stephan Szabo [EMAIL PROTECTED] writes:
As an update, so far I still am getting better results with NOT EXISTS
than the left join.
Hm. Don't suppose you were using EXPLAIN ANALYZE so we could see what's
happening? This is clearly a planner failure, although I'm unsure if we
can expect the
On Mon, 29 Sep 2003, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
As an update, so far I still am getting better results with NOT EXISTS
than the left join.
Hm. Don't suppose you were using EXPLAIN ANALYZE so we could see what's
happening? This is clearly a planner failure,
Patch applied. Thanks.
---
Neil Conway wrote:
On Mon, 2003-09-29 at 14:57, Bruce Momjian wrote:
I have emptied the patch queue, and have updated the HISTORY file for
7.4. I am looking for any improvements to that
Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
My live 7.3.4 database dumps data like this:
REVOKE ALL ON TABLE log_freeprofile FROM PUBLIC;
GRANT ALL ON TABLE log_freeprofile TO brett;
GRANT INSERT,SELECT,UPDATE ON TABLE log_freeprofile TO au-php;
GRANT SELECT ON
I think most people on this list will agree that having OIDs on user
tables is a Bad Thing. For some previous discussion of why, see:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg27374.html
My understanding of the conclusion of previous discussions on this topic
is that getting rid of OIDs
On Mon, Sep 29, 2003 at 12:59:55PM -0400, Bruce Momjian wrote:
working on. I think we have to get beyond the idea that this can be made
failure-proof, and just outline the behaviors for failure, and it has to
be configurable by the administrator.
Exactly. There are plenty of cases where
Jan Wieck wrote:
Just committed a small fix for PL/Tcl.
I don't find it on the TODO, but you might want to add it to the release
notes.
* Fixed PL/Tcl's spi_prepare to accept full qualified type names in
the parameter type list.
Oops, properly added to release notes, removed
Both added. Thanks.
---
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Current at ftp://momjian.postgresql.org/pub/postgresql/open_items.
A couple things you don't have there:
* Tuple visibility rules for
Tom Lane writes:
At the very least we need to set a strings freeze soon, so the
translators can catch up. Peter, are you getting close to done with the
message revisions you've been making?
Yes, I think we're ready for a string freeze. Alvaro, do you have
anything you still want to submit
Commercial systems use:
Mainframe:
CICS
UNIX:
Tuxedo
Encina
Win32:
MTS
DEC/COMPAQ/HP:
ACMS
Probably lots of others that I have never heard about.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
On Mon, Sep 29, 2003 at 12:48:30PM -0400, Andrew Sullivan wrote:
In every circumstance where a stand-alone machine would have it.
Oops. Wrong stage. Never mind.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario
On Mon, Sep 29, 2003 at 11:50:23PM +0200, Peter Eisentraut wrote:
Tom Lane writes:
At the very least we need to set a strings freeze soon, so the
translators can catch up. Peter, are you getting close to done with the
message revisions you've been making?
Yes, I think we're ready for
Neil Conway [EMAIL PROTECTED] writes:
SSL
! Major improvements in SSL performance and security
Did we actually add any security to the SSL code? Performance and
reliability, maybe, but I didn't think we'd done anything to the
security algorithms per se. Did I miss something?
1 - 100 of 136 matches
Mail list logo
