[EMAIL PROTECTED] wrote:
Peter Galbavy wrote:
You may not distribute this tool without the express written
permission of Mark Russinovich.
Then by no means should *any* of that code be included into PostgreSQL. In
fact, comments should not even make reference to it.
Does anybody have that written
Marc G. Fournier wrote:
On Sat, 15 May 2004, Bruce Momjian wrote:
Fabien COELHO wrote:
Dear hackers,
I wish to submit a small patch so that server includes and
all necessary configuration files could be installed *by default*.
The current status is that server includes files are only
Bruce Momjian wrote:
Jan Wieck wrote:
I think if we go for the plan outlined, we will not need a special
configure flag. (People might decide to move the install dir long after
they install it.) By default, everything sits under pgsql as pgsql/bin,
pgsql/lib, etc. I can't see how making
Greg Stark wrote:
Jan Wieck [EMAIL PROTECTED] writes:
You know how much trouble that causes? The existance of LD_LIBRARY_PATH in your
environment disables setuid() for security reasons on some platforms. So one
would have to wrap every PG related program into equally named shell scripts or
aliases
Bruce Momjian wrote:
Jan Wieck wrote:
Bruce Momjian wrote:
Jan Wieck wrote:
I think if we go for the plan outlined, we will not need a special
configure flag. (People might decide to move the install dir long after
they install it.) By default, everything sits under pgsql as pgsql/bin
Peter Eisentraut wrote:
Bruce Momjian wrote:
We already have --disable-rpath. Seems we would just need something
to use the *.a files.
I think it is perfectly sufficient to say that if you want a relocatable
install, don't use rpath. Static linking will lead to all other kinds
of madness.
Boy,
Bruce Momjian wrote:
Peter Eisentraut wrote:
Bruce Momjian wrote:
We already have --disable-rpath. Seems we would just need something
to use the *.a files.
I think it is perfectly sufficient to say that if you want a relocatable
install, don't use rpath. Static linking will lead to all other
Bruce Momjian wrote:
Peter Eisentraut wrote:
Jan Wieck wrote:
Boy, nobody was suggesting 100% static linking. What kind of madness
are you getting into if you link libpq.a into psql? There is
something between all or nothing, isn't there?
It's not going to be only psql and libpq. The next
Marc G. Fournier wrote:
On Sun, 16 May 2004, Bruce Momjian wrote:
I personally don't think Win32 is enough of a new feature either, but
others disagree.
Jan, correct me if I'm wrong ... Jan's point is that we have enough
already to warrant a beta on June 1st, even without Win32 ... Win32 (or
any
Bruce Momjian wrote:
Tom Lane wrote:
Manfred Koizar [EMAIL PROTECTED] writes:
The straightforward pg_clog lookup is still in transam.c,
but has been deactivated:
* Now this func in shmem.c and gives quality answer by scanning
* PGPROC structures of all running backend. - vadim 11/26/96
What
Hans-Jürgen Schönig wrote:
Marc G. Fournier wrote:
On Mon, 17 May 2004, Bruce Momjian wrote:
Marc G. Fournier wrote:
Agreed, but you are a me too, not a huge percentage of our userbase.
How do you know? Have you polled our complete userbase?
Basically, after 6-7 months of development, I want
Bruce Momjian wrote:
Marc G. Fournier wrote:
On Mon, 17 May 2004, Bruce Momjian wrote:
Most hopefully this is very discouraging! Connection pools are a nice
thing and I have used pgpool recently with great success, for pooling
connections. But attempting to deliver multimaster replication as
Bruce Momjian wrote:
Andrew Dunstan wrote:
I think we should use the relative-path method *unless* the configure
command called out specific installation directories (that is, not
just --prefix but --datadir and/or related options). If you use one of
those then that absolute path should be used
Mario Weilguni wrote:
Interesting.
We have made COMPLETELY different experiences.
There is one question people ask me daily: When can we have sychronous
replication and PITR?.
Performance is not a problem here. People are more interested in
stability and enterprise features such as those I have
Marc G. Fournier wrote:
On Mon, 17 May 2004, Joshua D. Drake wrote:
Personally, Win32, subtransactions and PITR are what we are after.
Second would be inclusion of plPHP and plPerlNG which are arguably the
most widely used languages to connect to PostgreSQL.
plPHP and plPerlNG both belong on
Marc G. Fournier wrote:
On Mon, 17 May 2004, Joshua D. Drake wrote:
plPHP and plPerlNG both belong on pgfoundry, not in the core distribution
...
Uhhh?? Are you ripping out all core pls then? plPerlNG is supposed to
replace plPerl, I was talking with Bruce and he seemed to think that (as
long
Bruce Momjian wrote:
Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
On Thu, 29 Apr 2004, Tom Lane wrote:
In the first place it's unfair to other developers to make schedule
slips at the last moment, and especially to *plan* to do so.
Isn't it equally unfair to slip the scheduale
Greg Stark wrote:
Jan Wieck [EMAIL PROTECTED] writes:
The whole sync() vs. fsync() discussion is in my opinion nonsense at this
point. Without the ability to limit the amount of files to a reasonable number,
by employing tablespaces in the form of larger container files, the risk of
forcing
Tom Lane wrote:
The specific details aren't especially relevant to this thread, though.
What is relevant is that we agree to a commitment that we will make
it easy to build modules outside the current Postgres build environment,
and that we will have an ongoing commitment to make sure that that
Rod Taylor wrote:
I think most of the current contrib projects are more missing the
advantage version independence would have for the ease of sitting in
contrib and having the whole project management around them just done.
Yes, doing your own gborg project costs time. You have to maintain
Alvaro Herrera wrote:
On Thu, Apr 22, 2004 at 12:29:36AM -0400, Bruce Momjian wrote:
I am thinking they could untar into a directory under pgsgl/ or have a
way to point to a 'configure'-run source tree and pull values from
there.
If you include pg_config.h, or use Makefile.global, you have
Taking into account that quite a few people have repeatedly stated that
the components in contrib are considered more supported/recommended than
similar solutions found on gborg or any other external site, I suggest
we move the projects dbmirror and dblink to gborg. The rserv contrib
module
Joe Conway wrote:
Jan Wieck wrote:
Taking into account that quite a few people have repeatedly stated that
the components in contrib are considered more supported/recommended than
similar solutions found on gborg or any other external site, I suggest
we move the projects dbmirror and dblink
Marc G. Fournier wrote:
On Wed, 21 Apr 2004, scott.marlowe wrote:
I almost agree, but I think things that are being actively developed to
eventually move into the backend, like autovacuum or slony-I should be in
contrib. Things that aren't destined for backend integration should be
removed
Joe Conway wrote:
Marc G. Fournier wrote:
Why is it the core developers responsibility to make sure that an
application stays in sync with the main tree? Personally, that is giving
life to software that could just as easily be unused by anyone, but kept
in the code base because a commit was made
Tom Lane wrote:
Andrew Sullivan [EMAIL PROTECTED] writes:
On Thu, Apr 15, 2004 at 07:52:59PM -0400, Tom Lane wrote:
I can see from your trace that you are using the getaddrinfo code from
libc, but where is configure finding a header that declares struct
addrinfo?
Hrm, I can't seem to tell. I
Tom Lane wrote:
I've got a problem with these variables in freelist.c:
static int strategy_cdb_found;
static int strategy_cdb_replace;
These two most definitely are per backend because they hold status
information about the blocks this backend specifically is mucking
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
Tom Lane wrote:
I've got a problem with these variables in freelist.c:
static int strategy_cdb_found;
static int strategy_cdb_replace;
These two most definitely are per backend because they hold status
information
Andrew Dunstan wrote:
Jan Wieck wrote:
Christopher Kings-Lynne wrote:
... on projects.postgresql.org, or similar.They really aren't
doing any good in /contrib.
I've already set up a category conversion tools on pgFoundry, and
my idea was one project per target system.
I reckon
Christopher Kings-Lynne wrote:
... on projects.postgresql.org, or similar.They really aren't
doing any good in /contrib.
I've already set up a category conversion tools on pgFoundry, and
my idea was one project per target system.
I reckon that by far the best way to do a mysql2pgsql
Fabien COELHO wrote:
Is it better in /contrib or gborg?
Gborg imho. I thought we were trying to move all non-core code there
now. Isn't that why psqlodbc etc. were moved?
The argument was that it can be devopped and released independently?
Features in contrib/ have a premium over external
Fabien COELHO wrote:
If you want to promote postgreSQL, then it should be good that anything
from outside (whether standard or not) can work with postgreSQL, but
anything that work in pg may not work outside;-)
I couldn't disagree more. What you are asking for is to do whatever (you
think) gets
Bruce Momjian wrote:
SRA America is sponsoring an evening event with me in NYC. If folks
want to go, the details are on our web site under Events.
I marked my calendar. If anyone wants to talk replication on the
sidelines, I'll be there.
Jan
--
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Seems like useful functionality. Right now, how does an administrator
kill another backend from psql? They can't.
The question to ask is should they be able to?
I think any such facility is inherently a security
Dustin Sallings wrote:
On Mar 24, 2004, at 20:29, Tom Lane wrote:
Not here. You want me to trust some bit of code (with absolutely zero
understanding of the source text it's hacking on) to figure out how to
resolve conflicting patches? That sounds like a recipe for big-time
unhappiness.
The
Gavin Sherry wrote:
On Sun, 21 Mar 2004, Matthew T. O'Connor wrote:
On Sun, 2004-03-21 at 20:31, Christopher Kings-Lynne wrote:
I think these configuration issues will become a lot easier if you make
the autovacuum daemon a subprocess of the postmaster (like, say, the
checkpoint process).
Greg Stark wrote:
Jan Wieck [EMAIL PROTECTED] writes:
the point is that PostgreSQL is no GNU product, never has been and if someone
intends to he shall do so after yanking out the contributions I made.
Note that when you released your contributions you did so under a license that
imposed
Bruce Momjian wrote:
Jan Wieck wrote:
Greg Stark wrote:
Jan Wieck [EMAIL PROTECTED] writes:
the point is that PostgreSQL is no GNU product, never has been and if someone
intends to he shall do so after yanking out the contributions I made.
Note that when you released your contributions
Christopher Browne wrote:
Further bonus: the GUI project need only have a database connection
to one of the databases to control things. No need for ANYTHING else.
After fleshing it out a little, that's a pretty slick approach.
You miss the point, sorry.
This make GUI easy to write approach
Alex J. Avriette wrote:
On Fri, Mar 05, 2004 at 12:47:23AM +0100, Jochem van Dieten wrote:
I personally don't think that a GUI tool should be the province of the
Slony project. Seriously. I think that Slony should focus on a
I very much agree with this, but this is Jan's baby, so I didn't
Jochem van Dieten wrote:
Jan Wieck said:
The communication channels are event tables. The node daemons
use listen and notify to send messages from on to another.
Messages are only exchanged over this when the replication cluster
configuration is changed or every 10 seconds to tell new
Tom,
with the since 7.4 deprecated copy support functions in libpq, is there
any define or other way to figure out if compiling against a pre-7.4 or
post-7.4 libpq?
Jan
--
#==#
# It's easier to get forgiveness for being wrong
Followup-To: Slony1-general ML
Alex J. Avriette wrote:
On Wed, Mar 03, 2004 at 04:57:28PM -0500, Jan Wieck wrote:
After some substantial progress on the Slony-I engine development, I'd
like to give a little status report and invite everyone who wants to
participate in this project to join
After some substantial progress on the Slony-I engine development, I'd
like to give a little status report and invite everyone who wants to
participate in this project to join the mailing list and the development
team.
The project homepage is here:
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
Tom Lane wrote:
Maybe there should be a provision similar to the stats collector's
check-for-read-ready-from-a-pipe?
the case of the bgwriter is a bit of a twist here. In contrast to the
collectors it is connected to the shared memory. So
Tom Lane wrote:
I noticed while doing some debugging this morning that if the postmaster
crashes for some reason (eg kill -9) the bgwriter process never goes
away. Backends will eventually exit when their clients quit, and the
stats collection processes shut down nicely, but the bgwriter process
Tom Lane wrote:
I just saw the parallel regression tests hang up again. Inspection
revealed that StrategyInvalidateBuffer() was stuck in an infinite loop
because the freelist was circular.
(gdb) p StrategyControl-listFreeBuffers
$5 = 579
(gdb) p BufferDescriptors[579]
$6 = {bufNext = 106, data =
Bruce Momjian wrote:
Jan Wieck wrote:
Attached is a corrected version that solves the query cancel problem by
not napping any more and going full speed as soon as any signal is
pending. If nobody objects, I'm going to commit this tomorrow.
Jan, three questions. First, is this useful now
Bruce Momjian wrote:
Jan Wieck wrote:
Tom Lane wrote:
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
So Imho the target should be to have not much IO open for the checkpoint,
so the fsync is fast enough, even if serial.
The best we can do is push out dirty pages with write() via
Tom Lane wrote:
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
So Imho the target should be to have not much IO open for the checkpoint,
so the fsync is fast enough, even if serial.
The best we can do is push out dirty pages with write() via the bgwriter
and hope that the kernel will see
Jan Wieck wrote:
Tom Lane wrote:
Shutdown of an idle postmaster used to take about two or three seconds
(mostly due to the sync/sleep(2)/sync in md_sync). For the last couple
of days it's taking more like a dozen seconds. I presume somebody broke
something, but I'm unsure whether to pin
The attached patch applies to CVS tip as of 02/05/2004 and implements
the cost based vacuum delay feature.
A detailed description with charts of different configuration settings
can be found here:
http://developer.postgresql.org/~wieck/vacuum_cost/
There is a problem left that seems to be
Attached is a corrected version that solves the query cancel problem by
not napping any more and going full speed as soon as any signal is
pending. If nobody objects, I'm going to commit this tomorrow.
Jan
Jan Wieck wrote:
The attached patch applies to CVS tip as of 02/05/2004 and implements
Tom Lane wrote:
Shutdown of an idle postmaster used to take about two or three seconds
(mostly due to the sync/sleep(2)/sync in md_sync). For the last couple
of days it's taking more like a dozen seconds. I presume somebody broke
something, but I'm unsure whether to pin the blame on bgwriter or
Steve Tibbett wrote:
I think users would prefer %ProgramFiles%\PostgreSQL - that's what Mozilla
and some other projects do, although still other projects do
%ProgramFiles%\GNU\PostgreSQL.
What would be the reason to put PostgreSQL into %ProgramFiles%\GNU ?
Jan
I'd vote for
Christopher Kings-Lynne wrote:
Hi guys,
In what version of Postgres did the pg_stat_activity view appear?
Must have been 7.2 as the tags in postmaster/pgstat.c only go back to
REL7_2_BETA1.
Jan
--
#==#
# It's easier to get
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Are those exposed through the libpq interface?
No, because libpq doesn't really have any concept of prepared statements.
It would probably make sense to add some more API to libpq to allow
creation and interrogation of
Simon Riggs wrote:
Jan,
[...]
My thoughts are about multiple concurrent accesses, specifically FTS on
large tables, rather than sequential ones.
Single or multiple backends is irrelevant here because a data block only
exists once, and therefore we have only one shared buffer cache.
Buffers
Magnus Hagander wrote:
Hello!
The backend signals code today uses pqsignal() instead of signal() at
all places. But it uses kill() and sigsetmask() (through the macro
PG_SETMASK) directly.
I propose to change this to pqkill() and pqsigsetmask(). In pqsignal.h,
these would be #define:d back to
Simon,
have you read src/backend/storage/buffer/README of current CVS tip?
The algorithm in the new replacement strategy is an attempt to figure
that SMALL_TABLE_THRESHOLD automatically. Do you see anything that can
be improved in that algorithm?
Jan
Simon Riggs wrote:
This discussion seems
Dann Corbit wrote:
When replication is implemented, what is going to happen with database
systems that rely heavily on sequences for primary keys?
Don't know which replication system you mean, there are some implemented
already.
As for Slony, I plan to have the functions setval(), nextval() and
Josh Berkus wrote:
People,
I don't have the time to make enough different attempts to find the one
that pleases all. My argument still is that all this IO throttling and
IO optimizing is mainly needed for dedicated servers, because I think
that if you still run multiple services on one box
Christopher Browne wrote:
2. Jan Wieck's work on SLONY-1
Many are keen to see the code, but it's not out yet. And it is
not self-evident that it will necessarily be ready to release in
conjunction with 7.5 (Not to say it _can't_ happen, but just that
we'll see the code
Stephen wrote:
The vacuum delay patch is not the ideal solution but it worked like a charm
on my servers. I really need the vacuum delay patch or a better solution in
7.5. I'm getting millions of requests a month and running VACUUM without the
patch makes PostgreSQL useless for many consecutive
Martin Marques wrote:
Mensaje citado por David Garamond [EMAIL PROTECTED]:
Marc G. Fournier wrote:
From the Firebird FAQ:
The first beta was released on January 29, 2003. We are hoping to be
close to a full release some time around Easter 2003.
They are at RC8 right now ... running a
Tom Lane wrote:
Wouldn't it be a win for heap_tuple_toast_attrs() to fall out quickly
if the tuple contains no varlena attributes? I'm thinking of adding
a test like
/* Nothing to do if tuple contains no varlena fields */
if ((newtup !HeapTupleAllFixed(newtup)) ||
Tom Lane wrote:
Christopher Browne [EMAIL PROTECTED] writes:
Stephen [EMAIL PROTECTED] writes:
Any chance we'll see the VACUUM delay patch (throttle) get into 7.5?
The hope, in 7.5, is to have ARC, which is the super-duper-duper
version, working.
Actually, I'm not sure that ARC should be
Neil Conway wrote:
Tom Lane [EMAIL PROTECTED] writes:
This is a bug Jan introduced recently --- he forgot to modify the
shared memory setup code to allow space for the new data structures
used by ARC. Jan, would you mind fixing that soon? It's getting in
people's way.
Jan had asked that I
Michael Glaesemann wrote:
On Jan 4, 2004, at 6:51 PM, Bruce Momjian wrote:
Michael Glaesemann wrote:
On Dec 29, 2003, at 11:28 AM, Sai Hertz And Control Systems wrote:
I would like to share my concerns about the IEEE 754 specification
and
floating point handling by PostgreSQL .
What specifically
Sai Hertz And Control Systems wrote:
Dear Jan Wieck ,
Floating point math itself is not precise, but rather an approximation,
usually of 8 or 14 digits. You can't approximate money. This isn't a
PostgreSQL issue but rather a general programming issue.
Thanks, Bruce. I assume the arbitrary
Sai Hertz And Control Systems wrote:
Dear Jan Wieck ,
Yes I agree with you Jan , most of the time we round the amount and
this is done by truncating greater than 3 decimal digits and
rounding the 3 digit to 2 in other words :
select trunc(1000.236897,3);
then
selecr round(1000.236,2
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
Yeah, looks like ... but I actually want to have a clean reproduction of
the error before I attempt to fix it.
Well, I can tell you that just running make check over and over isn't
a real efficient way to reproduce the problem. It might work
Tom Lane wrote:
Note that buffer 160 gets cleared twice in this sequence. The second
time, the CDB for 174 gets found, leading to failure when 174 is cleared.
I believe the correct fix is to do CLEAR_BUFFERTAG on the buffer (and
maybe the CDB too?) when returning a buffer to the freelist in
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
Tom Lane wrote:
Another little problem is that plpgsql doesn't really have any mechanism
for invalidating cached stuff at all; it will leak memory like there's
no tomorrow if we start dropping cached subplans.
Everyone seems to look
each postgres connection having a unique thread in
that jvm and having each connection thread run with its own class loader
instance so that separate classes (and thus static members) are loaded
for each connection.
thanks,
--Barry
Jan Wieck wrote:
I have included the JDBC mailing list since I
that particular
catalog object or not?
Jan
On Wed, 31 Dec 2003, Jan Wieck wrote:
ivan wrote:
why all backend can not using one cache, which would be always
Variable sized shared memory with garbage collection for SPI plans?
in real state ... or i can just clear only my cache, at first
ivan wrote:
as new know plpgsql has special cache which remember too long (event
non-existing tables (i mean old oid)) so i suggest to create same function
only in plpgsql which would clear this cache, or sth like this ?
for ie, where i drop table i would do plpgsql_clear_cache ();
and when i
drop, create etc in function, but using only EXECUTE ..
Do you have any numbers about how that would affect performance?
Jan
there must be same solution .. no ?
On Wed, 31 Dec 2003, Jan Wieck wrote:
ivan wrote:
as new know plpgsql has special cache which remember too long (event
non-existing
ivan wrote:
but , all in all, do you think that now it is ok ?
No, I don't. I just prefer complete solutions over patchwork.
Jan
On Wed, 31 Dec 2003, Jan Wieck wrote:
ivan wrote:
why all backend can not using one cache, which would be always
Variable sized shared memory with garbage collection
I have included the JDBC mailing list since I guess most Java developers
are around here, but not necessarily on Hackers.
Dave Cramer and I where discussing a few issues about the PL/Java
implementation last night and would like to get more input and
suggestions on the matter.
The basic
Manfred Spraul wrote:
Bruce Momjian wrote:
Anyone see an attack path here?
Should we have one lock per hash bucket rather than one for the entire
hash?
That's the simple part. The problem is the aging strategy: we need a
strategy that doesn't rely on a global list that's updated
Tom Lane wrote:
Manfred Spraul [EMAIL PROTECTED] writes:
Are there strategies that do not rely on a global lock? The Linux kernel
uses a lazy LRU with referenced bits: on access, the referenced bit is
set. The freespace logic takes pages from the end of a linked list, and
checks that bit: if
Sai Hertz And Control Systems wrote:
Dear all ,
I would like to share my concerns about the IEEE 754 specification and
floating point handling by PostgreSQL .
Also I would like to learn how professional users of PostgreSQL work
with rounding of monetary terms .
For all monetary values the
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Manfred Spraul wrote:
I remember there were patches that tried other algorithms instead of the
simple LRU for the buffer manager. Has anyone tried to change the
locking of the buffer manager?
CVS HEAD already has an
Ivelin Ivanov wrote:
That was uncalled for.
Statements like this do not make the Postgres
community any healthier.
You don't have any benefit of pushing back Java users.
On the other hand, can you imagine the reaction of the Java camp to an
idea like why not rewrite JBoss in Tcl and PL/Tcl so
Tom Lane wrote:
I just had the parallel regression tests hang up due to what appears to
be a bug in the new ARC code. The CLUSTER test gets into an infinite
loop trying to do CLUSTER clstr_1;. The loop is in
StrategyInvalidateBuffer's check that the buffer is already in the
freelist; it isn't,
Tom Lane wrote:
BTW, I just managed to reproduce the hang, after a whole afternoon of
trying ... only it was with a non-debug build. Sigh. Anyway, it seems
my HP machine has a significantly higher probability of showing the
problem than my Linux machine --- I have been unable to see the problem
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
It seems to me that buffers that are thrown away via
StrategyInvalidateBuffer() do not get their relnode and blocknum cleaned
out.
Mmmm. They definitely should be; if you look at the prior version of
buf_table.c, BufTableDelete did
Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
Then again, in the case of pg_upgrade, wouldn't just disabling access from
anywhere except localhost prevent others from getting in?
Not if your normal operating mode includes connections from clients
running locally. I really don't see
Tom Lane wrote:
strk [EMAIL PROTECTED] writes:
The question now is: what does that message mean ?
It means that the magic number that should be on the first page of the
btree index isn't right. We can deduce that something has clobbered the
first page of the index, but guessing what and how
Andrew Rawnsley wrote:
Other pl* (perl, python, tcl) languages have vanilla C glue code.
Might be better to stick to this. If you aren't using advanced C++
features that shouldn't be too hard - well structured C can be just as
readable as well structured C++. At the very lowest level, about
Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Is there anything stopping us going through the code and finding all
ereports that can be fixed by a REINDEX, and issue a HINT with all of
them saying that they should REINDEX the broken index?
How would you know which ones
Christopher Kings-Lynne wrote:
I couldn't agree more. Look at this very instance. He now found the
right reindex command and the corrupted file is gone. We don't have the
slightest clue what happened to that file. Was it truncated? Did some
other process scribble around in the shared memory?
strk wrote:
I get the following error when vacuuming a db or inserting
a big value in a column of a toastable datatype (GEOMETRY).
ERROR: Index pg_toast_8443892_index is not a btree
My last action has been killing a psql that was getting
mad about receiving too much input and beeping as hell
strk wrote:
JanWieck wrote:
strk wrote:
I get the following error when vacuuming a db or inserting
a big value in a column of a toastable datatype (GEOMETRY).
ERROR: Index pg_toast_8443892_index is not a btree
My last action has been killing a psql that was getting
mad about receiving
Kurt Roeckx wrote:
On Mon, Dec 08, 2003 at 01:27:35PM -0500, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I've been able to reproduce this on one of my machines, and it's nasty.
In that case I'm confused about why this code compiles on my machine:
What compiler are
Tom Lane wrote:
Kurt Roeckx [EMAIL PROTECTED] writes:
I can compile current cvs with gcc 2.95.3, openssl 0.9.7b and
zlib 1.2.1.
current CVS meaning since I fixed the include order ?
Good question. Using my cvsup tree here, which I did sup today already.
So what -D would trigger the failure?
Jan
Steve Wampler wrote:
Would it be (is it?) possible to add timestamp to the log
messages put out by postgresql? I've got several databases
running in an environment where users have this annoying
habit of coming up to me with (Oh yes, three days ago around
4pm our instrument had trouble writing
Oli Sennhauser wrote:
People might be more interested in debating this topic with you if we
hadn't discussed it at length just a couple months back. There wasn't
consensus then that we had to offer an escape hatch, and you've not
offered any argument that wasn't made before.
I'm simply
ow wrote:
--- Tom Lane [EMAIL PROTECTED] wrote:
People might be more interested in debating this topic with you if we
hadn't discussed it at length just a couple months back. There wasn't
consensus then that we had to offer an escape hatch, and you've not
offered any argument that wasn't made
401 - 500 of 910 matches
Mail list logo
