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 using
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 entry is
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
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 original page
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
-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 newer
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
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);
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. Before any
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.
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
XLOG
"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
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.
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 before the
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 should be written
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
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 do
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 why
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 kill
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
http://www.faqs.org/rfcs/rfc2369.html about how to embed email list
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
original page
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 been 30 days
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
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(xlog
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 anything).
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 people to
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
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 die
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 heap
* 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 problem is that
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 for this:
* 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)
Hmm ...
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.
We
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? This
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
so it
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 relevant
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
* 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 deamon that
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 spinlocks, I can't
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'm
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 ...
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:
* 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 of
stubbing
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
* 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 RedHat 7
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
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
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]]
Sent:
* 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? Looks a tad
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 struct - old
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();
version
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
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
"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 releases
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 to
"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't get you
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's
* 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 used to
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)---
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
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
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
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
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
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
are used
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,
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
[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
-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 go.
-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 wrong with changing it
"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
Hi!
Snow in New York - I'm arrived only today.
Reading mail...
Vadim
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
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
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 of
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
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/postgresql.conf . No
76 matches
Mail list logo
