Re: AW: [HACKERS] Proposed WAL changes

Zeugswetter Andreas SB wrote: > > > Could GUC parameters be changed permanently e.g. by SET command ? > > > > For example, > > 1) start postmaster > > 2) set archdir to '' > > 3) shutdown postmaster > > I thought the intended way to change a GUC parameter permanently was to > edit data/postgr

AW: [HACKERS] Proposed WAL changes

> Could GUC parameters be changed permanently e.g. by SET command ? > > For example, > 1) start postmaster > 2) set archdir to '' > 3) shutdown postmaster I thought the intended way to change a GUC parameter permanently was to edit data/postgresql.conf . No ? Andreas

Re: [HACKERS] Proposed WAL changes

Tom Lane wrote: > > "Hiroshi Inoue" <[EMAIL PROTECTED]> writes: > > Could GUC parameters be changed permanently e.g. by SET command ? > > That's what postgresql.conf is for ... > Do I have to send SIGHUP after changing postgresql.conf ? Regards, Hiroshi Inoue ---(end o

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

> This isn't a 64-bit CRC. It's two independent 32-bit CRCs, one done > on just the odd-numbered bytes and one on just the even-numbered bytes > of the datastream. That's hardly any stronger than a single 32-bit CRC; I believe that the longer data the more chance to get same CRC/hash for differ

[HACKERS] I'm back

Hi! Snow in New York -> I'm arrived only today. Reading mail... Vadim ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

[HACKERS] output from EXPLAIN VERBOSE

I am writing an Emacs based navigation/editing tool. I would like to have the backend parse a query, EXPLAIN VERBOSE it I want to know for every non functional column the source (table/attribute). How to interpret the parse tree? ---(end of broadcast)---

Re: [HACKERS] Proposed WAL changes

"Hiroshi Inoue" <[EMAIL PROTECTED]> writes: > Could GUC parameters be changed permanently e.g. by SET command ? That's what postgresql.conf is for ... regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all li

RE: [HACKERS] Proposed WAL changes

> -Original Message- > From: Zeugswetter Andreas SB > > > >> Remove archdir from pg_control; it ought to be a GUC > > >> parameter, not a special case (not that it's implemented > > yet anyway). > > > > > Is archdir really a GUC parameter ? > > > > Why shouldn't it be? I see nothing w

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

> -Original Message- > From: Tom Lane [mailto:[EMAIL PROTECTED]] > > The interlock has to be tightly tied to the PGDATA directory, because > what we're trying to protect is the files in and under that directory. > It seems that something based on file(s) in that directory is the way > to g

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

[EMAIL PROTECTED] (Nathan Myers) writes: > On Linux, /usr/src/linux/include is meaningless for anything in userland; > it's meant only for building the kernel and kernel modules. That Red Hat > tends to expose it to user-level builds is a long-standing bug in Red > Hat's distribution 1) it i

Re: [HACKERS] Red Hat bashing

Nathan Myers wrote: > it further. I offer my apologies for violating it. Well, an apology is not really necessary -- but I do get a little tired at the treatment a good open source company gets at the hands of open source advocates. Yes, they make mistakes. Everyone does. > By the way... do t

Re: [HACKERS] Red Hat bashing

On Tue, Mar 06, 2001 at 04:20:13PM -0500, Lamar Owen wrote: > Nathan Myers wrote: > > That is why there is no problem with version skew in the syscall > > argument structures on a correctly-configured Linux system. (On a > > Red Hat system it is very easy to get them out of sync, but RH fans > >

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

Alfred Perlstein wrote: > What they really need to do is hire some grey beards (old school > Unix folks) to QA the releases and keep stuff like this from > happening/shipping. Like the 250-strong RedHat Beta Team, of which I am a member? :-) I can't disclose the discussions on that list, but, suf

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

> >Alfred Perlstein <[EMAIL PROTECTED]> writes: > >>> Are there any portability problems with relying on shm_nattch to be > >>> available? If not, I like this a lot... > > > >> Well it's available on FreeBSD and Solaris, I'm sure Redhat has > >> some deamon that resets the value to 0 periodically

[HACKERS] psql missing feature

What about (optionally) printing the type of the column data? i.e: io | tu | tipo |data int | int | int2 |date +---+--+ 102242 | 26404 | 1203 | 2000-11-22 (1 row) ---(end of broadcast)--

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

BeOS haven't this stat (I have a bunch of others but not this one). If I unsterstand correctly, you want to check if there is some backend still attached to shared mem segment of a given key ? In this case, I have an easy solution to fake the stat, because all segment have an encoded nam

[HACKERS] Re: CORBA and PG

> I'm trying to look to see if I can store CORBA objects inside PG, any > ideas... CORBA has mechanisms for locating and executing remote objects. Some services, like the naming service, could use a database as a persistant store. Other services, like the implementation repository, could use a da

[HACKERS] Re: CORBA and PG

> I'm trying to look to see if I can store CORBA objects inside PG, any > ideas... CORBA has mechanisms for locating and executing remote objects. Some services, like the naming service, could use a database as a persistant store. Other services, like the implementation repository, could use a da

[HACKERS] Contributions?

Greetings, I wrote a few simple programs to log Apache access_log entries to pg. If this is something anyone would be interested in or if there is someplace I can submit these to, please let me know. Thanks, Matthew ---(end of broadcast)--- TI

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

* Lamar Owen <[EMAIL PROTECTED]> [010306 13:27] wrote: > Nathan Myers wrote: > > That is why there is no problem with version skew in the syscall > > argument structures on a correctly-configured Linux system. (On a > > Red Hat system it is very easy to get them out of sync, but RH fans > > are u

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

On Tue, Mar 06, 2001 at 12:46:24PM -0800, Nathan Myers wrote: > > On Linux, /usr/src/linux/include is meaningless for anything in userland; > it's meant only for building the kernel and kernel modules. That Red Hat > tends to expose it to user-level builds is a long-standing bug in Red > Hat'

Re: [HACKERS] ERROR: cannot open relation center_out_analog_proc

"G. Anthony Reina" <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> You can't roll back a DROP TABLE under pre-7.1 releases (and 7.0 has >> a big fat warning notice to tell you so!). The physical table file >> is deleted immediately by the DROP, so rolling back the system catalog >> changes doesn

Re: [HACKERS] ERROR: cannot open relation center_out_analog_proc

Tom Lane wrote: > You can't roll back a DROP TABLE under pre-7.1 releases (and 7.0 has > a big fat warning notice to tell you so!). The physical table file > is deleted immediately by the DROP, so rolling back the system catalog > changes doesn't get you back to a working table. > > The only way

Re: [HACKERS] ERROR: cannot open relation center_out_analog_proc

"G. Anthony Reina" <[EMAIL PROTECTED]> writes: > BEGIN WORK; > ... > DROP TABLE center_out_analog_proc; > ... > [fail transaction] > psql:alter_table_format.sql:14: NOTICE: mdopen: couldn't open > center_out_analog_proc: No such file or directory You can't roll back a DROP TABLE under pre-7.1 r

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

Nathan Myers wrote: > That is why there is no problem with version skew in the syscall > argument structures on a correctly-configured Linux system. (On a > Red Hat system it is very easy to get them out of sync, but RH fans > are used to problems.) Is RedHat bashing really necessary here? At l

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

Bruce Momjian writes: > This will try a pg_ctl shutdown for 60 seconds, then kill pg_ctl. You > would then need a kill of you own. pg_ctl automatically times out after 60 seconds. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broa

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

On Tue, Mar 06, 2001 at 08:19:12PM +0100, Peter Eisentraut wrote: > Alfred Perlstein writes: > > > Seriously, there's some dispute on the type that 'shm_nattch' is, > > under Solaris it's "shmatt_t" (unsigned long afaik), under FreeBSD > > it's 'short' (i should fix this. :)). > > What I don't l

Re: [HACKERS] epoch

Patrick Welche writes: > http://www.postgresql.org/devel-corner/docs/user/functions-datetime.html > > patrimoine=# SELECT EXTRACT(EPOCH FROM TIMESTAMP '2001-02-16 20:38:40'); > ERROR: parser: parse error at or near "epoch" > patrimoine=# select version(); > ve

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

Alfred Perlstein <[EMAIL PROTECTED]> writes: > Of course not, the size of the struct changed (short->unsigned > long, basically int16_t -> uint32_t), because the kernel and userland > in Linux are hardly in sync you have the fun of guessing if you > get: > old struct -> old syscall (ok) > new str

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

* Tom Lane <[EMAIL PROTECTED]> [010306 11:49] wrote: > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > What I don't like is that my /usr/include/sys/shm.h (through other > > headers) has [foo] > > whereas /usr/src/linux/include/shm.h has [bar] > > Are those declarations perhaps bit-compatible?

RE: [HACKERS] mailing list messages

there, added ... and even gave an attribute to you :) On Tue, 6 Mar 2001, Mike Mascari wrote: > I like this idea too. How about TIP #1: Don't 'kill -9' the postmaster ;-) > > Mike Mascari > [EMAIL PROTECTED] > > -Original Message- > From: The Hermit Hacker [SMTP:[EMAIL PROTECTED]] > Sen

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

Zeugswetter Andreas SB wrote: > > 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.

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

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 again? > If you are going to allocate a few thousand

[HACKERS] epoch

Trying example from: http://www.postgresql.org/devel-corner/docs/user/functions-datetime.html patrimoine=# SELECT EXTRACT(EPOCH FROM TIMESTAMP '2001-02-16 20:38:40'); ERROR: parser: parse error at or near "epoch" patrimoine=# select version(); version

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

* Lamar Owen <[EMAIL PROTECTED]> [010306 11:39] wrote: > Peter Eisentraut wrote: > > Not only note the shm_nattch type, but also shm_segsz, and the "unused" > > fields in between. I don't know a thing about the Linux kernel sources, > > but this doesn't seem right. > > Red Hat 7, right? My RedH

[HACKERS] ERROR: cannot open relation center_out_analog_proc

I was trying to add a column to a table and fill it but ran into a big error. Apparently now Postgres can't open this table to vacuum or to select although it does show up when I ask psql to describe the table (i.e. db01=# /d center_out_analog_proc). I'm using Postgres 7.0.3 on a PII/400 MHz with

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

* Tom Lane <[EMAIL PROTECTED]> [010306 11:30] wrote: > Alfred Perlstein <[EMAIL PROTECTED]> writes: > > * Tom Lane <[EMAIL PROTECTED]> [010306 11:03] wrote: > >> I notice that our BeOS and QNX emulations of shmctl() don't support > >> IPC_STAT, but that could be dealt with, at least to the extent

RE: [HACKERS] mailing list messages

I like this idea too. How about TIP #1: Don't 'kill -9' the postmaster ;-) Mike Mascari [EMAIL PROTECTED] -Original Message- From: The Hermit Hacker [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, March 06, 2001 1:57 PM To: Andrew McMillan Cc: PostgreSQL-development Subject:R

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

Peter Eisentraut <[EMAIL PROTECTED]> writes: > What I don't like is that my /usr/include/sys/shm.h (through other > headers) has [foo] > whereas /usr/src/linux/include/shm.h has [bar] Are those declarations perhaps bit-compatible? Looks a tad endian- dependent, though ...

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

Peter Eisentraut wrote: > Not only note the shm_nattch type, but also shm_segsz, and the "unused" > fields in between. I don't know a thing about the Linux kernel sources, > but this doesn't seem right. Red Hat 7, right? My RedHat 7 system isn't running RH 7 right now (it's this notebook that I

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

Alfred Perlstein <[EMAIL PROTECTED]> writes: > * Tom Lane <[EMAIL PROTECTED]> [010306 11:03] wrote: >> I notice that our BeOS and QNX emulations of shmctl() don't support >> IPC_STAT, but that could be dealt with, at least to the extent of >> stubbing it out. > Well since we already have spinlock

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

* Tom Lane <[EMAIL PROTECTED]> [010306 11:03] wrote: > Alfred Perlstein <[EMAIL PROTECTED]> writes: > >> Are there any portability problems with relying on shm_nattch to be > >> available? If not, I like this a lot... > > > Well it's available on FreeBSD and Solaris, I'm sure Redhat has > > some

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

Alfred Perlstein writes: > Seriously, there's some dispute on the type that 'shm_nattch' is, > under Solaris it's "shmatt_t" (unsigned long afaik), under FreeBSD > it's 'short' (i should fix this. :)). What I don't like is that my /usr/include/sys/shm.h (through other headers) has: typedef unsi

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

Peter Eisentraut wrote: > Well, if you have something clever you want to do if the postmaster > doesn't come down after an orderly shutdown then please share it. The > current alternatives are 'leave running' or 'kill -9'. I know I'd prefer > the former. Well, my preferences aren't really relev

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

Alfred Perlstein <[EMAIL PROTECTED]> writes: >> Are there any portability problems with relying on shm_nattch to be >> available? If not, I like this a lot... > Well it's available on FreeBSD and Solaris, I'm sure Redhat has > some deamon that resets the value to 0 periodically just for kicks >

Re: [HACKERS] mailing list messages

On Wed, 7 Mar 2001, Andrew McMillan wrote: > Bruce Momjian wrote: > > > > 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? > > What about having some basic _PostgreSQL_ tips in there

Re: [HACKERS] mailing list messages

Bruce Momjian wrote: > > 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? What about having some basic _PostgreSQL_ tips in there? This would be especially cute for -novice, I think.

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

* Tom Lane <[EMAIL PROTECTED]> [010306 10:35] wrote: > Alfred Perlstein <[EMAIL PROTECTED]> writes: > > > What about encoding the shm id in the pidfile? Then one can just ask > > how many processes are attached to that segment? (if it doesn't > > exist, one can assume all backends have exited)

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

Alfred Perlstein <[EMAIL PROTECTED]> writes: > * Tom Lane <[EMAIL PROTECTED]> [010306 10:10] wrote: >> The shmem key is driven primarily by port number >> not data directory ...) > This seems like a mistake. > I'm suprised you guys aren't just using some form of the FreeBSD > ftok() algorithm

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

* Tom Lane <[EMAIL PROTECTED]> [010306 10:10] wrote: > Alfred Perlstein <[EMAIL PROTECTED]> writes: > > I'm sure some sort of encoding of the PGDATA directory along with > > the pids stored in the shm segment... > > I thought about this too, but it strikes me as not very trustworthy. > The proble

Re: AW: AW: AW: AW: [HACKERS] WAL-based allocation of XIDs is insecur e

Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes: > I do not however see how the current solution fixes the original problem, > that we don't have a rollback for index modifications. > The index would potentially point to an empty heaptuple slot. How? There will be an XLOG entry inserting the

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

Lamar Owen writes: > > case when the postmaster does not come down after 60 seconds. But this is > > really no problem for the issue at hand because if you do a normal > > runlevel switch then the postmaster will simply keep running, and during a > > system shutdown all the backends are going to

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

Alfred Perlstein <[EMAIL PROTECTED]> writes: > I'm sure some sort of encoding of the PGDATA directory along with > the pids stored in the shm segment... I thought about this too, but it strikes me as not very trustworthy. The problem is that there's no guarantee that the new postmaster will even

Re: [HACKERS] mailing list messages

oh, let me add that as a TIP :) On Tue, 6 Mar 2001, Peter Eisentraut wrote: > Bruce Momjian 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 once again refer pe

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

Peter Eisentraut wrote: > > Lamar Owen writes: > > > I missed something somehwere: wasn't the consensus a few weeks ago that > > pg_ctl shouldn't be used for a system initscript? > > The consensus(?) was that there was some work to do in pg_ctl before it > was robust enough to be used (for anyt

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

> After thinking about this a little, I believe I see why Vadim did it > the way he did. Suppose we tried to make the code sequence be > > obtain write lock on buffer; > XLogOriginalPage(buffer); // copy page to xlog if first since ckpt > modify buffer; > XLogInsert(xl

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

I wrote: > The decision whether to log the whole buffer has to be atomic with the > actual entry of the xlog record. Unless we want to hold the xlog insert > lock for the entire time that we're (eg) splitting a btree page, that > means we log the buffer after the modification work is done, not be

Re: [HACKERS] mailing list messages

Tom Lane <[EMAIL PROTECTED]> writes: > 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

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

> >> 5. We will now run a new transaction with the same XID that was in use > >> before the crash. If that transaction commits, then we have a tuple on > >> disk that will be considered valid --- and should not be. > > > I do not think this is true. Before any modification to a page the > > ori

Re: [HACKERS] mailing list messages

Bruce Momjian 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 once again refer people to RFC 2369 about how to embed email list mana

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

> Bruce Momjian writes: > > > This will try a pg_ctl shutdown for 60 seconds, then kill pg_ctl. You > > would then need a kill of you own. > > pg_ctl automatically times out after 60 seconds. Oh, yea, that's right, I saw that in the documenation. Forget my script. Just run pg_ctl first, then

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

Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes: > Is it so hard to swap ? First write page to log then modify in shmem. > Then those pages would have additional value, because > then utilities could do all sorts of things with those pages. After thinking about this a little, I believe I see

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

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

Lamar Owen writes: > I missed something somehwere: wasn't the consensus a few weeks ago that > pg_ctl shouldn't be used for a system initscript? The consensus(?) was that there was some work to do in pg_ctl before it was robust enough to be used (for anything). That work has been done. An examp

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

> >> Hmm. Actually, what is written to the log is the *modified* page not > >> its original contents. > > Well, that sure is not what was discussed on the list for implementation !! > > I thus really doubt above statement. > > Read the code. Ok, sad. > > > Each page about to be modified shou

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

Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes: >> Hmm. Actually, what is written to the log is the *modified* page not >> its original contents. > I thus really doubt above statement. Read the code. > Each page about to be modified should be written to the txlog once, > and only once befo

[HACKERS] Re: pg_dump writes SEQUENCEs twice with -a

At 16:07 6/03/01 +0100, kovacsz wrote: >The problem hasn't >disappeared yet. In 7.1beta4... As per an earlier message today, the problem is fixed in CVS Philip Warner| __---_ Albatross Consulting Pty. L

AW: [HACKERS] Proposed WAL changes

> >> Remove archdir from pg_control; it ought to be a GUC > >> parameter, not a special case (not that it's implemented > yet anyway). > > > Is archdir really a GUC parameter ? > > Why shouldn't it be? I see nothing wrong with changing it on-the-fly. Yes, I think this is a good change, like

Re: [HACKERS] There is error at the examples in PL/pgSQL

"Lu Raymond" <[EMAIL PROTECTED]> writes: > NOTICE: plpgsql: ERROR during compile of emp_stamp near line 1 > "RROR: parse error at or near " Save your script with Unix-style newlines, not DOS-style (LF not CR/LF). regards, tom lane ---(end of broad

Re: [HACKERS] Proposed WAL changes

"Hiroshi Inoue" <[EMAIL PROTECTED]> writes: >> Remove archdir from pg_control; it ought to be a GUC >> parameter, not a special case (not that it's implemented yet anyway). > Is archdir really a GUC parameter ? Why shouldn't it be? I see nothing wrong with changing it on-the-fly.

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

Hiroshi Inoue <[EMAIL PROTECTED]> writes: > Yes there must be XLogFlush() before writing buffers. > BTW how do we get the next XID if WAL files are corrupted ? My not-yet-committed changes include storing the latest CheckPoint record in pg_control (as well as in the WAL files). Recovery from XLO

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

Hello, 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. Considering the early beta state I was not alarmed. But since I noticed that yesterday's snapshot still has the problem, I'd really like to tell you about it. H

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

Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes: >> 5. We will now run a new transaction with the same XID that was in use >> before the crash. If that transaction commits, then we have a tuple on >> disk that will be considered valid --- and should not be. > I do not think this is true. Befo

[HACKERS] There is error at the examples in PL/pgSQL

Hello,all I use your a example of PL/pgSQL, but I found some errors when I execute these codes. The details are followings, First, I create a exam.sql that includes these codes as followings, CREATE TABLE emp ( empname text, salary int4, last_date datetime, last_user name); CREATE

[HACKERS] Re: CORBA and PG

> I'm trying to look to see if I can store CORBA objects inside PG, any > ideas... CORBA has several mechanisms for finding CORBA objects, including the naming service and the implementation repository. The naming service provides a directory for objects, returning IORs to allow a client to conta

RE: [HACKERS] Proposed WAL changes

> -Original Message- > From: Tom Lane > > 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

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

> I especially don't think that we should second-guess what the admin > wants us to do by auto-killing backends that are still serving > clients. Sure. But it would be nice anyway if pg_ctl could do this with a specific command line switch. -- << Tout n'y est pas parfait, mais on y honore ce

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

> > > 5. We will now run a new transaction with the same XID that was in use > > > before the crash. If that transaction commits, then we have a tuple on > > > disk that will be considered valid --- and should not be. > > > > I do not think this is true. Before any modification to a page the ori

[HACKERS] Banner links not working (fwd)

This just came to the webmaster mailbox: --- Most of the top banner links on http://jdbc.postgresql.org (like Documentation, Tutorials, Resources, Development) throw up 404s if followed. Thought you ought to know. Still trying to find the correct driverClass/connectString for the Postgres J

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

Zeugswetter Andreas SB wrote: > > > 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 en

RE: [HACKERS] CORBA and PG

Quoting Franck Martin <[EMAIL PROTECTED]>: > 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... Although I've not tried it (yet) it should be possible to access Java EJB's from corba. If so, then u

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

> 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 shmem > WAL buffer. > >