Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

* Tom Lane <[EMAIL PROTECTED]> [010305 19:13] wrote: > Lamar Owen <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> Postmaster down, backends alive is not a scenario we're currently > >> prepared for. We need a way to plug that gap. > > > Postmaster can easily enough find out if zombie backen

[HACKERS] Proposed WAL changes

I have just sent to the pgsql-patches list a rather large set of proposed diffs for the WAL code. These changes: * Store two past checkpoint locations, not just one, in pg_control. On startup, we fall back to the older checkpoint if the newer one is unreadable. Also, a physical copy of the

Re: [HACKERS] Re: pg_dump scripts are no longer ordinary-user friendly

On Mon, 5 Mar 2001, Tom Lane wrote: > Philip Warner <[EMAIL PROTECTED]> writes: > > At 22:26 5/03/01 -0500, Tom Lane wrote: > >> Now that you mention it, is it a feature at all? Or a bug? ISTM poor > >> form for a data-only restore to assume it may turn off all pre-existing > >> triggers. > >

Re: [HACKERS] Re: pg_dump scripts are no longer ordinary-user friendly

At 22:40 5/03/01 -0500, Tom Lane wrote: > >For now, I'd be happy if the normal case of a simple restore doesn't >generate warnings. I'll commit the changes shortly. >Improving on that probably takes more thought and >risk than we should be putting in at the end of beta. Agreed.

Re: [HACKERS] Re: pg_dump scripts are no longer ordinary-user friendly

On Mon, 5 Mar 2001, Tom Lane wrote: > Philip Warner <[EMAIL PROTECTED]> writes: > > At 21:37 5/03/01 -0500, Tom Lane wrote: > >> Philip Warner <[EMAIL PROTECTED]> writes: > >>> ... we could go back to the old model of only updating > >>> pg_class in a data-only dump/restore. > >> > >> Works for

Re: [HACKERS] Re: pg_dump scripts are no longer ordinary-user friendly

Philip Warner <[EMAIL PROTECTED]> writes: > At 22:26 5/03/01 -0500, Tom Lane wrote: >> Now that you mention it, is it a feature at all? Or a bug? ISTM poor >> form for a data-only restore to assume it may turn off all pre-existing >> triggers. > Do you recall any of the history - why was it add

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

Tom Lane wrote: > Well, there's always the possibility of a bug leading to postmaster > coredump. Historically those have been pretty rare though. I have never personally seen one, since 6.1.1. > In any case, I'm not sure that the init script is the place to be > solving these problems. Well,

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

Lamar Owen <[EMAIL PROTECTED]> writes: > I don't want to reap the postmaster off -- I want to reap off the > backends associated with that particular postmaster, allowing that > postmaster to die on its own. Duh. Doing this in a safe manner is not > going to be easy, given that the PGDATA is not

Re: [HACKERS] Re: pg_dump scripts are no longer ordinary-user friendly

At 22:26 5/03/01 -0500, Tom Lane wrote: > >> Should we have an option to turn off this feature entirely? > >Now that you mention it, is it a feature at all? Or a bug? ISTM poor >form for a data-only restore to assume it may turn off all pre-existing >triggers. Do you recall any of the history -

Re: [HACKERS] mailing list messages

Bruce Momjian <[EMAIL PROTECTED]> writes: > I wonder if the new Tips at the bottom of email messages can be enabled > for users during their first 30 days of mailing list subscription, then > not appear? I'm pretty durn tired of 'em, and it's not been 30 days yet ;-) A subscription option to tur

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

Lamar Owen <[EMAIL PROTECTED]> writes: > Is it a correct assumption that this is the only time postmaster might > drop out? Well, there's always the possibility of a bug leading to postmaster coredump. Historically those have been pretty rare though. In any case, I'm not sure that the init scri

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

Tom Lane wrote: > Lamar Owen <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> If you think it's easy enough, enlighten the rest of us ;-). > > If postgres reported PGDATA on the command line it would be easy enough. > In ps status you mean? I don't think we are prepared to require ps > stat

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

Tom Lane wrote: > of course, that's the situation you're left with ... but your reasoning > seems circular to me. "I should kill -9 the postmaster to prevent the > situation where I've kill -9'd the postmaster." Ok, while the script can certainly be used from the command line, its primary purpos

Re: [HACKERS] mailing list messages

> Bruce Momjian <[EMAIL PROTECTED]> writes: > > I wonder if the new Tips at the bottom of email messages can be enabled > > for users during their first 30 days of mailing list subscription, then > > not appear? > > I'm pretty durn tired of 'em, and it's not been 30 days yet ;-) I hear you. > A

Re: [HACKERS] Re: pg_dump scripts are no longer ordinary-user friendly

Philip Warner <[EMAIL PROTECTED]> writes: > At 21:37 5/03/01 -0500, Tom Lane wrote: >> Philip Warner <[EMAIL PROTECTED]> writes: >>> ... we could go back to the old model of only updating >>> pg_class in a data-only dump/restore. >> >> Works for me ... > Should we have an option to turn off this

Re: [HACKERS] Re: pg_dump scripts are no longer ordinary-user friendly

At 21:37 5/03/01 -0500, Tom Lane wrote: >Philip Warner <[EMAIL PROTECTED]> writes: >> ... we could go back to the old model of only updating >> pg_class in a data-only dump/restore. > >Works for me ... > Should we have an option to turn off this feature entirely? --

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

Lamar Owen <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> If you think it's easy enough, enlighten the rest of us ;-). > If postgres reported PGDATA on the command line it would be easy enough. In ps status you mean? I don't think we are prepared to require ps status functionality to let the

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

Tom Lane wrote: > Lamar Owen wrote: > > Postmaster can easily enough find out if zombie backends are 'out there' > > during startup, right? > If you think it's easy enough, enlighten the rest of us ;-). If postgres reported PGDATA on the command line it would be easy enough. > > What can postm

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

Lamar Owen <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Please note that the reason we're having this discussion at >> all is that the init script may be used for purposes other than system >> shutdown. So the argument that "it's going to happen anyway" is wrong. > Believe it or not, you jus

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

Lamar Owen <[EMAIL PROTECTED]> writes: > I missed something somehwere: wasn't the consensus a few weeks ago that > pg_ctl shouldn't be used for a system initscript? I thought there was some concern about whether pg_ctl is really "ready for prime time". But I don't recall the details either.

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

> Bruce Momjian wrote: > > This will try a pg_ctl shutdown for 60 seconds, then kill pg_ctl. You > > would then need a kill of you own. > > I missed something somehwere: wasn't the consensus a few weeks ago that > pg_ctl shouldn't be used for a system initscript? Or did I black out > that day?

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

Bruce Momjian wrote: > This will try a pg_ctl shutdown for 60 seconds, then kill pg_ctl. You > would then need a kill of you own. I missed something somehwere: wasn't the consensus a few weeks ago that pg_ctl shouldn't be used for a system initscript? Or did I black out that day? :-) I certain

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

Lamar Owen <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Postmaster down, backends alive is not a scenario we're currently >> prepared for. We need a way to plug that gap. > Postmaster can easily enough find out if zombie backends are 'out there' > during startup, right? If you think it's ea

[HACKERS] mailing list messages

I wonder if the new Tips at the bottom of email messages can be enabled for users during their first 30 days of mailing list subscription, then not appear? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life i

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

Tom Lane wrote: > Please note that the reason we're having this discussion at > all is that the init script may be used for purposes other than system > shutdown. So the argument that "it's going to happen anyway" is wrong. Believe it or not, you just disproved your own statement that the initsc

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

Tom Lane wrote: > Yeah, but only a partial crash. If the admin finishes the job by > killing the backends too, we're fine. Postmaster down, backends alive > is not a scenario we're currently prepared for. We need a way to plug > that gap. Postmaster can easily enough find out if zombie backend

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

> Ok, since I can't seem to count on killproc's exact behavior, istm that > I can: > killproc postmaster -INT > wait some number of seconds > if postmaster still up >killproc postmaster -TERM > wait some number of seconds > if postmaster STILL up >killproc postmaster #and let the grim rea

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

Lamar Owen <[EMAIL PROTECTED]> writes: > The last thing I want to do is > wait too long on some platforms and not long enough on others. The difficulty is to know how long the final checkpoint will take. This depends on (at least) your hard disk speed and the number of dirty buffers, so I think y

Re: [HACKERS] Re: pg_dump scripts are no longer ordinary-user friendly

Philip Warner <[EMAIL PROTECTED]> writes: > ... we could go back to the old model of only updating > pg_class in a data-only dump/restore. Works for me ... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and uns

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

Tom Lane wrote: > The tricky part of this is not to give up the ability to restart when > there *has* been a crash. But kill -9 effectively _is_ an admin-initiated crash. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 2

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

Tom Lane wrote: > However, with an explicit kill level that doesn't happen: you get one > signal of the specified value, no more. Possibly it would be better for > the init script to send SIGINT (forcibly disconnect clients) instead of > SIGTERM, however. So I'm now leaning to "killproc postmast

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

Lamar Owen <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> The tricky part of this is not to give up the ability to restart when >> there *has* been a crash. > But kill -9 effectively _is_ an admin-initiated crash. Yeah, but only a partial crash. If the admin finishes the job by killing the ba

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

Lamar Owen <[EMAIL PROTECTED]> writes: > Is 6.1 this different from 6.2? Scott sent me a copy of /etc/init.d/functions from his box, and it has largely the same behavior (I hadn't read the whole code to notice that it doesn't use the default killlevel...). What's actually happening here is that

Re: [HACKERS] How to handle waitingForLock in LockWaitCancel()

Hiroshi Inoue <[EMAIL PROTECTED]> writes: >> I suspect you will find that these crashes occur during the window just >> after > Sorry what does 'just after' mean ? > Isn't it during the semop() ? >> the semop() call in IpcSemaphoreLock() --- see the comment If an interrupt during the semop led

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

Nathan Myers wrote: > Not to be a zealot, but this isn't _Linux_ boot-script code, it's > _Red Hat_ boot-script code. Red Hat would like for us all to confuse > the two, but they jes' ain't the same. (As a rule of thumb, where it > works right, credit Linux; where it doesn't, blame Red Hat. :-)

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

Hiroshi Inoue <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> I think we need a stronger interlock to prevent this scenario, but I'm >> unsure what it should be. Ideas? > Seems the simplest way is to inhibit starting postmaster > if the pid file exists. Then we're unable to recover from a cras

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

Bruce Momjian wrote: > > # TERM first, then KILL if not dead > Yes, this seems like the proper way to do it. Now to verify that 6.1 is the sameor different H The mirrors of ftp.redhat.com (and, in fact, RedHat.com itself) no longer have the updates or the original for 6.1

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

On Mon, Mar 05, 2001 at 08:55:41PM -0500, Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > killproc should send a kill -15 to the process, wait a few seconds for > > it to exit. If it does not, try kill -1, and if that doesn't kill it, > > then kill -9. > > Tell it to the Linux pe

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

Tom Lane wrote: > > Now, killing the postmaster -9 and not cleaning up the backends has > always been a good way to shoot yourself in the foot, but up to now the > worst thing that was likely to happen to you was isolated corruption in > specific tables. In the brave new world of WAL the stakes a

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

>if [ "$notset" = "1" ] ; then > if ps h $pid>/dev/null 2>&1; then > # TERM first, then KILL if not dead > kill -TERM $pid > usleep 10 > if ps h $pid >/dev/null 2>&1 ; then > sleep 1 > if ps h $pid >/dev/null 2>&1 ; then >

Re: [HACKERS] How to handle waitingForLock in LockWaitCancel()

Tom Lane wrote: > > Hiroshi Inoue <[EMAIL PROTECTED]> writes: > > [ backtrace snipped ] > > Hmm, this is definitely not operating as intended: LockWaitCancel is > getting interrupted, because ProcessInterrupts may be called when it's > trying to acquire the lockmanager spinlock, and ProcessInterr

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

Tom Lane wrote: > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > killproc should send a kill -15 to the process, wait a few seconds for > > it to exit. If it does not, try kill -1, and if that doesn't kill it, > > then kill -9. > > Tell it to the Linux people ... this is their boot-script code

[HACKERS] Re: pg_restore -U

At 22:51 5/03/01 +0100, Peter Eisentraut wrote: >Could we use some other letter for the pg_restore '-U' option? psql and >wrapper scripts use -U to select the user name to connect as (different >from -u), and I'd like to implement this sometime for the pg_dump tools as >well. How does -L ("list"

[HACKERS] Re: pg_dump scripts are no longer ordinary-user friendly

At 20:00 5/03/01 -0500, Tom Lane wrote: >I suppose this is only a cosmetic issue, but we're going to get >questions/complaints about it... is there any way to avoid needing >those UPDATEs? I definitely prefer it to match the old behaviour, and since by default we put triggers at the end, we could

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

Bruce Momjian <[EMAIL PROTECTED]> writes: > killproc should send a kill -15 to the process, wait a few seconds for > it to exit. If it does not, try kill -1, and if that doesn't kill it, > then kill -9. Tell it to the Linux people ... this is their boot-script code we're talking about.

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

> Lamar Owen <[EMAIL PROTECTED]> writes: > > Thanks for the headsup, Tom. Time to nix killproc and do something > > cleaner -- compatible, but cleaner. > > As far as I could tell from the 6.1 scripts, it would work to do > > killproc postmaster -TERM > Yes, amazing it has a -9 default.

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

killproc should send a kill -15 to the process, wait a few seconds for it to exit. If it does not, try kill -1, and if that doesn't kill it, then kill -9. > Tom Lane wrote: > > checkpoint record. Clueless admins who resort to kill -9 as a routine > > admin tool *will* lose their databases. Mor

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

Lamar Owen <[EMAIL PROTECTED]> writes: > Thanks for the headsup, Tom. Time to nix killproc and do something > cleaner -- compatible, but cleaner. As far as I could tell from the 6.1 scripts, it would work to do killproc postmaster -TERM The problem is just that killproc has an overenth

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

Tom Lane wrote: > checkpoint record. Clueless admins who resort to kill -9 as a routine > admin tool *will* lose their databases. Moreover, the init scripts > that are running around now are dangerous weapons if used with 7.1. Thanks for the headsup, Tom. Time to nix killproc and do something

[HACKERS] pg_dump scripts are no longer ordinary-user friendly

It used to be that if you had a pg_dump file without ACL checks, you could load it as an unprivileged user. Now you get a ton of complaints about those handy little "update pg_class" commands. I suppose this is only a cosmetic issue, but we're going to get questions/complaints about it... is the

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

* Tom Lane <[EMAIL PROTECTED]> [010305 14:51] wrote: > > I think we need a stronger interlock to prevent this scenario, but I'm > unsure what it should be. Ideas? Re having multiple postmasters active by accident. The sysV IPC stuff has some hooks in it that may help you. One idea is to check

[HACKERS] Re: How to shoot yourself in the foot: kill -9 postmaster

At 3/5/2001 04:30 PM, you wrote: >Now, killing the postmaster -9 and not cleaning up the backends has >always been a good way to shoot yourself in the foot, but up to now the >worst thing that was likely to happen to you was isolated corruption in >specific tables. In the brave new world of WAL t

[HACKERS] How to shoot yourself in the foot: kill -9 postmaster

I have spent several days now puzzling over the corrupted WAL logfile that Scott Parish was kind enough to send me from a 7.1beta4 crash. It looks a lot like two different series of transactions were getting written into the same logfile. I'd been digging like mad in the WAL code to try to explai

RE: [HACKERS] CORBA and PG

I guess these stubs are for accessing PG as a corba server... I'm trying to look to see if I can store CORBA objects inside PG, any ideas... Franck Martin Network and Database Development Officer SOPAC South Pacific Applied Geoscience Commission Fiji E-mail: [EMAIL PROTECTED]

Re: [HACKERS] pg_restore -U

Sounds good. > Could we use some other letter for the pg_restore '-U' option? psql and > wrapper scripts use -U to select the user name to connect as (different > from -u), and I'd like to implement this sometime for the pg_dump tools as > well. How does -L ("list") sound? > > -- > Peter Eis

[HACKERS] pg_restore -U

Could we use some other letter for the pg_restore '-U' option? psql and wrapper scripts use -U to select the user name to connect as (different from -u), and I'd like to implement this sometime for the pg_dump tools as well. How does -L ("list") sound? -- Peter Eisentraut [EMAIL PROTECTED

Re: [HACKERS] WAL-based allocation of XIDs is insecure

Ian Lance Taylor <[EMAIL PROTECTED]> writes: > Tom Lane <[EMAIL PROTECTED]> writes: >> Up through 7.0, Postgres allocated XIDs a thousand at a time, and not >> only did the not-yet-used XIDs get lost in a crash, they'd get lost in >> a normal shutdown too. What I propose will waste XIDs in a cras

Re: [HACKERS] WAL-based allocation of XIDs is insecure

Tom Lane <[EMAIL PROTECTED]> writes: > Ian Lance Taylor <[EMAIL PROTECTED]> writes: > > I described myself unclearly. I was suggesting an addition to what > > you are suggesting. The worst case can not be worse. > > Then I didn't (and still don't) understand your suggestion. Want to > try aga

Re: [HACKERS] WAL-based allocation of XIDs is insecure

Tom Lane <[EMAIL PROTECTED]> writes: > Ian Lance Taylor <[EMAIL PROTECTED]> writes: > > I think your example demonstrates something slightly different. I > > think it demonstrates that Postgres must flush the XLOG entry to disk > > before it flushes any buffer to disk which uses an XID which was

Re: [HACKERS] WAL-based allocation of XIDs is insecure

Ian Lance Taylor <[EMAIL PROTECTED]> writes: > I think your example demonstrates something slightly different. I > think it demonstrates that Postgres must flush the XLOG entry to disk > before it flushes any buffer to disk which uses an XID which was just > allocated. That would be an alternati

Re: [HACKERS] How to handle waitingForLock in LockWaitCancel()

Hiroshi Inoue <[EMAIL PROTECTED]> writes: > [ backtrace snipped ] Hmm, this is definitely not operating as intended: LockWaitCancel is getting interrupted, because ProcessInterrupts may be called when it's trying to acquire the lockmanager spinlock, and ProcessInterrupts will see the ProcDiePendi

Re: [HACKERS] WAL-based allocation of XIDs is insecure

Tom Lane <[EMAIL PROTECTED]> writes: > After thinking about this for a little, it seems to me that XID > assignment should be handled more like OID assignment: rather than > handing out XIDs one-at-a-time, varsup.c should allocate them in blocks, > and should write an XLOG record to reflect the a

Re: [HACKERS] Uh, this is *not* a 64-bit CRC ...

[EMAIL PROTECTED] (Nathan Myers) writes: > The CRC-64 code used in the SWISS-PROT genetic database is (now) at: > ftp://ftp.ebi.ac.uk/pub/software/swissprot/Swissknife/old/SPcrc.tar.gz > From the README: > The code in this package has been derived from the BTLib package > obtained fr

[HACKERS] WAL-based allocation of XIDs is insecure

Consider the following scenario: 1. A new transaction inserts a tuple. The tuple is entered into its heap file with the new transaction's XID, and an associated WAL log entry is made. Neither one of these are on disk yet --- the heap tuple is in a shmem disk buffer, and the WAL entry is in the

AW: AW: [HACKERS] WAL & RC1 status

> > One issue about too many checkpoints in pg_control, is that you then > > need to keep more logs, and in my pgbench tests the log space was a > > real issue, even for the one checkpoint case. I think a utility to > > recreate a busted pg_control would add a lot more stability, than one > > more

Re: AW: [HACKERS] WAL & RC1 status

> Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes: > >> At least one of my concerns (single point of failure) would require a > >> change to the layout of pg_control, which would force initdb anyway. > > > Was that the "only one checkpoint back in time in pg_control" issue ? > > Yes. Is chan

Re: [HACKERS] Query Planning time increased 3 times on 7.1 compared to 7.0.3

Christof Petig <[EMAIL PROTECTED]> writes: > We noticed that after upgrading to 7.1beta[245] the execution time for > some often used queries went up by a factor of 2 or more. I get the desired plan after doing VACUUM ANALYZE ... regards, tom lane ---

Re: AW: [HACKERS] WAL & RC1 status

Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes: >> At least one of my concerns (single point of failure) would require a >> change to the layout of pg_control, which would force initdb anyway. > Was that the "only one checkpoint back in time in pg_control" issue ? Yes. > One issue about too

Re: [HACKERS] CORBA and PG

Quoting Franck Martin <[EMAIL PROTECTED]>: > Does anyone has pointers on CORBA and PostgreSQL? > > What is the story ? There's some old stubs for one of the orbs somewhere in the source (C/C++) Also the old JDBC/Corba example is still there (src/interfaces/jdbc/example/corba) Peter -- Pet

Re: [HACKERS] Oops! Its bug in parser????

Vic <[EMAIL PROTECTED]> writes: >> What version of PostgreSQL are you using ? > PostgreSQL 7.0.0 on i686-pc-linux-gnu, compiled by gcc egcs-2.91.66 Evidently not a released version, but some beta, since this behavior was changed before 7.0 release (cf. scan.l CVS log for 18-Mar-2000). I *stron

AW: [HACKERS] Query Planning time increased 3 times on 7.1 compared to 7.0.3

> Here is one of the queries, it takes about half a second on our computer > (PII 233 with 256MB RAM) to execute and returns typically 1-4 rows via > two index scans with high selectivity. So it looks to me that planning > time outwages execution time by far. 7.0 took about 0.15 > seconds (which

Re: [HACKERS] Query Planning time increased 3 times on 7.1 compared to 7.0.3

Justin Clift wrote: > Hi Christof, > > I'm not aware of the problem with int2 indexes collapsing. Can you give > me some more info, and I'll put it on the techdocs.postgresql.org > website. Oh, I'm sorry for my strange wording. I said that the index search collapses to a sequential scan if you

[HACKERS] RE: [CORE] WAL & RC1 status

> I've reported the major problems to the mailing lists > but gotten almost no feedback about what to do. I can't comment without access to code -:( > commit: 2001-02-26 17:19:57 > 0/0059996C: prv 0/00599948; xprv 0/; xid 0; > RM 0 info 00 len 32 > checkpoint: redo 0/0059996C; undo 0/00

Re: [HACKERS] Oops! Its bug in parser????

> What version of PostgreSQL are you using ? > PostgreSQL 7.0.0 on i686-pc-linux-gnu, compiled by gcc egcs-2.91.66 > > I believe this is fixed a long time ago. If you don't want to upgrade just put spaces in > > select myfield from mytable where myfield = -1 Ya - i don't want make upgra

Re: [HACKERS] Oops! Its bug in parser????

Vic wrote: > Hi > I try this "construction" : select myfield from mytable where > myfield=-1 > And get this: > ERROR: Unable to identify an operator '=-' for types 'numeric' and > 'int4' What version of PostgreSQL are you using ? I believe this is fixed a long time ago. If you don't w

[HACKERS] CORBA and PG

Does anyone has pointers on CORBA and PostgreSQL? What is the story ? Cheers... [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL

Re: [HACKERS] Getting unique ID through SQL

Hi Patrick, With PostgreSQL, I do this inside PL/PGSQL functions (but I'll do it outside a function here to make it simpler) : Lets say you have : foobar=# create table demonstration (barfoo serial, data varchar(10)); NOTICE: CREATE TABLE will create implicit sequence 'demonstration_barfoo_seq

[HACKERS] Oops! Its bug in parser????

Hi I try this "construction" : select myfield from mytable where myfield=-1 And get this: ERROR: Unable to identify an operator '=-' for types 'numeric' and 'int4' You will have to retype this query using an explicit cast I don't lik this! Vic ---(end o

AW: [HACKERS] WAL & RC1 status

> Since there is not a separate WAL version stamp, introducing one now > would certainly force an initdb. I don't mind adding one if you think > it's useful; another 4 bytes in pg_control won't hurt anything. But > it's not going to save anyone's bacon on this cycle. Yes, if initdb, that would

Re: [HACKERS] How to handle waitingForLock in LockWaitCancel()

Tom Lane wrote: > > Hiroshi Inoue <[EMAIL PROTECTED]> writes: > > I sometimes encountered SEGV errors in my test case > > when I canceled the execution. > > Can you provide backtraces from these SEGVs? > ISTM the backtrace isn't sufficient to figure out how the error occured. As far as I see th