Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Would there be objections to me expanding on the syslog
> sections in the docs?
No, but ...
> # Log all 'postgres' events to /var/log/pgsql
> !postgres
> *.* /var/log/pgsql
> # Nothing after this li
On Tue, 30 Sep 2003, Bruce Momjian wrote:
> Stephan Szabo wrote:
> > > If we go that direction, why don't we just make a GUC variable to
> > > disable constraint checking. Is that what this will do, or is it more
> > > limited. I know it breaks referential integrity, but we have had many
> > > f
I think the INSTALL file needs to be updated. Its list of configure
options doesn't seem to mention --enable-thread-safety. I don't know
what else...
Chris
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister c
Hi Guys,
I just spent the last half hour learning syslog and log rolling with
postgres. Would there be objections to me expanding on the syslog
sections in the docs?
http://developer.postgresql.org/docs/postgres/logfile-maintenance.html
I want to:
* Add a link to the third paragraph there wh
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I assume it would be only setable by the super-user.
That might be a good restriction too (on top of my speculation about not
allowing it in postgresql.conf). Only allow it to be SET per-session,
and only by a superuser.
regards
Bruce Momjian <[EMAIL PROTECTED]> writes:
> How many folks are going to remember to do this? Why make it hard for
> them? Someone is going to forget too easily. "Why is this restore
> taking so long? Oh, I forgot that switch." Or they put it in a login
> file and forget it is set. Seems safer
Stephan Szabo wrote:
> > If we go that direction, why don't we just make a GUC variable to
> > disable constraint checking. Is that what this will do, or is it more
> > limited. I know it breaks referential integrity, but we have had many
> > folks as for it, it is on the TODO list, and there are
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> What is the correct signal (and number) that should be sent to postgres
> when you want to roll its logs?
There is no log-rolling functionality in PG. Use syslog, or pipe the
postmaster's output into something like Apache's logrotate program.
Tom Lane wrote:
> > If we go that direction, why don't we just make a GUC variable to
> > disable constraint checking.
>
> You mean in general, even for plain old insert/update/delete changes?
> Yipes. What happened to ACID compliance?
>
> What I actually expected to ensue was a discussion about
Christopher Kings-Lynne wrote:
> Hi guys,
>
> What is the correct signal (and number) that should be sent to postgres
> when you want to roll its logs?
>
> I can't seem to see the answer...
There isn't one. You have to pipe into something like Apache's
rotatelogs or use syslog.
--
Bruce Mo
On Tue, 30 Sep 2003, Bruce Momjian wrote:
> Jan Wieck wrote:
> >
> >
> > Tom Lane wrote:
> >
> > > Jan Wieck <[EMAIL PROTECTED]> writes:
> > >> I think I can accept it to be the choice of the DBA what to do. Pg_dump
> > >> has that kind of options already, one can choose between COPY and INSERT
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Jan Wieck wrote:
>> Tom Lane wrote:
>>> if we were to go that route would be a boolean GUC variable that simply
>>> prevents ALTER TABLE ADD FOREIGN KEY from doing the validity checks.
>>
>> Okay too. And this would be simple and safe enough to add it at
Hi guys,
What is the correct signal (and number) that should be sent to postgres
when you want to roll its logs?
I can't seem to see the answer...
Chris
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Jan Wieck wrote:
>
>
> Tom Lane wrote:
>
> > Jan Wieck <[EMAIL PROTECTED]> writes:
> >> I think I can accept it to be the choice of the DBA what to do. Pg_dump
> >> has that kind of options already, one can choose between COPY and INSERT
> >> for example. Why not adding the choice of dumping F
Correct me if I am wrong but I remember postgresql throwing error that foreign
key field was not unique in foreign table. Obviously it can not detect that
without an index. Either primary key or unique constraint would need an
index.
What am I missing here?
IOW, how do I exactly create foreig
Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
I think I can accept it to be the choice of the DBA what to do. Pg_dump
has that kind of options already, one can choose between COPY and INSERT
for example. Why not adding the choice of dumping FKeys as ALTER TABLE
or CREATE CONSTRAINT TR
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> CREATE TYPE foo_type AS (a INTEGER);
> DECLARE
> my_var foo_type%rowtype;
> ERROR: "foo_type" is a composite type
> CONTEXT: compile of PL/pgSQL function "foo" near line 2
Hmm, that was an unintended side-effect of another change.
I can't see
Jan Wieck <[EMAIL PROTECTED]> writes:
> I think I can accept it to be the choice of the DBA what to do. Pg_dump
> has that kind of options already, one can choose between COPY and INSERT
> for example. Why not adding the choice of dumping FKeys as ALTER TABLE
> or CREATE CONSTRAINT TRIGGER?
We
Tom Lane wrote:
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
I think we need someway of telling postgres to suppress a foreign key check.
Well, the subtext argument here is "do we fix it by providing a way to
suppress the check, or do we fix it by making the check fast enough to
be tolerable
(I think my previous attempt got aborted by a lost connection, so a
message like this may arrive twice)
On Mon, 29 Sep 2003, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> >> Hm. Don't suppose you were using EXPLAIN ANALYZE so we could see what's
> >> happening? This is clearly
A really nice overview of how various transaction managers are modeled:
http://www.ti5.tu-harburg.de/Lecture/99ws/TP/06-OverviewOfTPSystemsAndPr
oducts/sld001.htm
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appr
On Mon, 29 Sep 2003, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> >> 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 planner to get the right answer with no p
Stephan Szabo <[EMAIL PROTECTED]> writes:
>> 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 planner to get the right answer with no pg_statistic entries.
> The left join one seem
Hi all,
I'm experiencing problem with Postgresql 7.4Beta 3,
the following function is working in Postgres 7.3.X and
if I remember well also in 7.4beta2:
CREATE TYPE foo_type AS (a INTEGER);
CREATE OR REPLACE FUNCTION foo ( )
RETURNS SETOF foo_type AS'
DECLARE
my_var foo_type%rowtype;
BEGIN
Neil Conway <[EMAIL PROTECTED]> writes:
> On Mon, 2003-09-29 at 18:18, [EMAIL PROTECTED] wrote:
>> The GUC route sounds good. I'd like to see ctid handling beefed up at the
>> same time. For example, some operators such as != would be nice and might
>> ease the pain a little for people used to us
Neil Conway <[EMAIL PROTECTED]> writes:
> On Mon, 2003-09-29 at 18:37, Tom Lane wrote:
>> It doesn't seem to me that this really buys much. What we really want
>> is a way for a dump/reload to remove OIDs from tables that formerly had
>> them; otherwise people will not easily be able to migrate th
[EMAIL PROTECTED] ("Dann Corbit") writes:
> Tuxedo
Note that this is probably the only one of the lot that is _really_
worth looking at in a serious way, as the XA standard was essentially
based on Tuxedo. (Irrelevant Aside: BEA had releases of CICS running
on both Unix and Windows NT, so it isn'
> It doesn't seem to me that this really buys much. What we really want
> is a way for a dump/reload to remove OIDs from tables that formerly had
> them; otherwise people will not easily be able to migrate their existing
> tables away from having OIDs.
Doesn't ALTER TABLE ... SET WITHOUT OIDS all
Tom Lane wrote:
> 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
On Mon, 2003-09-29 at 18:18, [EMAIL PROTECTED] wrote:
> The GUC route sounds good. I'd like to see ctid handling beefed up at the
> same time. For example, some operators such as != would be nice and might
> ease the pain a little for people used to using oids as their "tuple id" :)
Are we encou
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 f
Greg Stark wrote:
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 i
On Mon, 2003-09-29 at 18:37, Tom Lane wrote:
> It doesn't seem to me that this really buys much. What we really want
> is a way for a dump/reload to remove OIDs from tables that formerly had
> them; otherwise people will not easily be able to migrate their existing
> tables away from having OIDs.
Neil Conway <[EMAIL PROTECTED]> writes:
> (1) Add a GUC var, with a name such as "default_use_oids", defaulting to
> true. This controls whether a CREATE TABLE that doesn't include WITH or
> WITHOUT OIDS gets created with OIDs.
This I think was pretty noncontroversial.
> (2) When dumping a table,
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> 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:
> ...
> Objections, comments, etc. are welcome.
The GUC route sounds good. I'd like to see ctid handling beefed
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 r
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 Ca
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?
http://www.post
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
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 r
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, r
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 gra
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
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";
> > GR
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 th
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 f
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, 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 "high
"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
reso
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 transac
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 ty
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 sh
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 a
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 co
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?
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 wr
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
co
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 w
> -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.
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_freepr
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
> 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 noti
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| http://candle.pha.pa.us
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 sol
> > 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
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
> accomplis
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
> > > 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 tab
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
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
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
> 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 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
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, othe
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 * "
> "
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, b
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 just
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 so
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 failu
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
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
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 p
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 ...
>
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 lik
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
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 pha
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
> > > 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
---
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 sh
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 have
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
> >> p
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,
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
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 pro
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 Postgr
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
> i
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
[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 t
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'
1 - 100 of 141 matches
Mail list logo
