Hi all,
I found this code on the file variables.c and
in the function SetVariable I read:
if (strcmp(current-name, name) == 0)
{
free(current-value);
current-value = strdup(value);
return current-value ? true : false;
}
this mean that if there is no
On Wed, 2003-08-27 at 00:07, Bruce Momjian wrote:
Peter Eisentraut wrote:
Christopher Kings-Lynne writes:
Surely a WARNING is a problem that you should probably fix?
How are should and probably defined?
Or at least pay attention to.
If it were in fact the characteristic of
On Wed, Aug 27, 2003 at 12:21:25 +0800,
Christopher Kings-Lynne [EMAIL PROTECTED] wrote:
I think that WARNING should be used for ALL things that have been
deprecated. eg. implicit FROM, the opaque business, and definitely
unsupported and ignored synacies.
Implicit froms aren't depreciated
Tom Lane wrote:
Mendola Gaetano [EMAIL PROTECTED] writes:
I noticed that some date are not anymore accepted:
test=# select '18/03/71'::date;
ERROR: invalid input syntax for date: 18/03/71
is this the indendeed behaviour ?
If it does not match your DateStyle setting, then yes.
Umm...I
Everything looks like it built clean ... will do a quick, more general
announce tomorrow, but if someone can confirm that things are good, that
would be great ...
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an
In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] (Andrew
Sullivan) transmitted:
As the 7.4 beta rolls on, I thought now would be a good time to start
talking about the future.
I have a potential need in the future for distributed transactions
(XA). To get that from
Rod Taylor [EMAIL PROTECTED] writes:
I would think that a simple optimization would be to push off evaluation
of a subplan whenever possible by re-arranging AND statements.
Thought we did that already ... [ checks code ] ... hmph, it looks like
this is done correctly for quals attached to a
Kevin Brown [EMAIL PROTECTED] writes:
Tom Lane wrote:
If it does not match your DateStyle setting, then yes.
Umm...I hope this is controllable with a GUC variable then.
I was against that change myself, but I lost the argument.
regards, tom lane
You can always just go 'set datestyle...' before doing your insert I guess.
Chris
- Original Message -
From: Tom Lane [EMAIL PROTECTED]
To: Kevin Brown [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, August 28, 2003 11:36 AM
Subject: Re: [HACKERS] Date input changed in 7.4 ?
Hi,
My name is Markus Kräutner, I am using PostgreSQL to build a distributed
biological database as part of my diploma thesis.
I hope this is the right forum for my question.
At the end of several bulk inserts the following statements get executed:
begin
update pom_c2996785 set
Hi,
can anyone give me some information about new approaches to integrate
tertiary memory devices into Postgres? Are there any news since the publication of
Olsen in 1992 (Extending the Postgres Database System to manage tertiary
storage)?
Thanks!
Regards,
Thomas
--
COMPUTERBILD 15/03:
On Wed, Aug 27, 2003 at 09:17:28PM +0200, Markus Kr?utner wrote:
At the end of several bulk inserts the following statements get executed:
begin
update pom_c2996785 set p3=3268837857008 where p3=34804837857008
update pom_c2996795 set p3=3268837857008 where p3=34804837857008
update
[EMAIL PROTECTED] (Tom Lane) wrote in message news:[EMAIL PROTECTED]...
Manfred Koizar [EMAIL PROTECTED] writes:
better. AFAICS Vivek's problem is that it is hard enough to hold a
good part of the working set in the cache, and still his disks are
saturated. Now a VACUUM not only adds one
Markus =?iso-8859-15?q?Kr=E4utner?= [EMAIL PROTECTED] writes:
At the end of several bulk inserts the following statements get executed:
begin
update pom_c2996785 set p3=3268837857008 where p3=34804837857008
update pom_c2996795 set p3=3268837857008 where p3=34804837857008
update pom_c2996804
[EMAIL PROTECTED] (Grant Succeeded) writes:
The best for me by far, is to get the OS to *not* cache stuff. As
long as the database uses the information it inherently has available,
it can make far more effective use of the same amount of memory the OS
would have used to cache the whole
--On Wednesday, August 27, 2003 00:21:23 -0300 Marc G. Fournier
[EMAIL PROTECTED] wrote:
Everything looks like it built clean ... will do a quick, more general
announce tomorrow, but if someone can confirm that things are good, that
would be great ...
My UnixWare Thread.c patch/fix has been
Larry Rosenman [EMAIL PROTECTED] writes:
My UnixWare Thread.c patch/fix has been IGNORED.
I'd like to see a fix before we declare Beta2.
Beta2 is a done deal. When Bruce gets back from the seashore I expect
he'll take a look at the issues you raised, but we're not holding off
beta2 another
On Wed, 27 Aug 2003, Kevin Brown wrote:
There are some cases where it's extremely useful for PostgreSQL to
accept dates of any format it knows about (ambiguities should be
resolved either by looking at the current DateStyle or, failing that, by
applying the recognition in a well-defined order
On Tue, Aug 26, 2003 at 08:04:13PM -0400, Christopher Browne wrote:
Interesting/positive news on this front; the XA specification
documents are now all available in PDF form freely, from the Open
Group, where they used to be fairly pricey.
A step in the right direction, but AFAIC it's too
On Wed, 27 Aug 2003, Bruno Wolff III wrote:
Implicit froms aren't depreciated yet.
It would be really nice, to my mind, if they were killed stone dead.
I've been bitten several times by having an implicit FROM added to a
query that destroyed it.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90
This just doesn't look right.
line 364
case COPY_NEW_FE:
while (datasize 0 !fe_eof)
line 408datasize =- avail;
shouldn't it be datasize -= avail ?
Dave
--
Dave Cramer [EMAIL
Hi all,
Following is from Documentation/vm/overcommit-accounting
-
2 - (NEW) strict overcommit. The total address space commit
for the system is not permitted to exceed swap + a
configurable percentage (default is 50) of physical RAM.
--On Thursday, August 28, 2003 01:06:46 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
Larry Rosenman [EMAIL PROTECTED] writes:
My UnixWare Thread.c patch/fix has been IGNORED.
I'd like to see a fix before we declare Beta2.
Beta2 is a done deal. When Bruce gets back from the seashore I expect
he'll
Yes, in 2.6, which is not yet released. Even after it is released I
expect it to take some time to bed down and make its way into vendor
releases, if the history of 2.4 is anything to go by.
Incidentally, it looks to me like it is only in 2.6 if your kernel is
built with CONFIG_SECURITY, which
On Thursday 28 August 2003 17:11, Andrew Dunstan wrote:
Yes, in 2.6, which is not yet released. Even after it is released I
expect it to take some time to bed down and make its way into vendor
releases, if the history of 2.4 is anything to go by.
Better late than never. I sincerely hope that
I take that last remark back - it is there whether or not
CONFIG_SECURITY is defined or not. The code is in 2 places - ugh.
andrew
Andrew Dunstan wrote:
Yes, in 2.6, which is not yet released. Even after it is released I
expect it to take some time to bed down and make its way into vendor
Dave Cramer wrote:
This just doesn't look right.
line 364
case COPY_NEW_FE:
while (datasize 0 !fe_eof)
line 408 datasize =- avail;
shouldn't it be datasize -= avail ?
AFAIR this is a really outdated KR style of -= .
Hi every one,
I've tried to reindex one of my customer's table to gain some disk space.
I had to stop after 90 m cpu...
I've then pg_dump'ed the database and recreate an other both on 7.3.4 and
7.4b
Both are still running after more than 30 minutes of CPU (100% cpu taken)
creating the
Hi there,
new version of tsearch2 for 7.3.X is available for download from
http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/.
Version for 7.4dev is available from CVS.
Changes:
* Change treating of stop words in boolean expression.
Earlier they were considered as always 'true',
Markus =?iso-8859-15?q?Kr=E4utner?= [EMAIL PROTECTED] writes:
I managed to construct a sample script which also fails in psql. It seems to
be the hash index. If I leave out the create index line or use btree
instead everything works fine.
I will use btree now :)
Good idea ;-). I'll look
Well, it get's worse, I think after bruce ran pgindent it was turned
into
datasize = -avail;
Dave
On Thu, 2003-08-28 at 08:19, Andreas Pflug wrote:
Dave Cramer wrote:
This just doesn't look right.
line 364
case COPY_NEW_FE:
while (datasize 0
Dave Cramer [EMAIL PROTECTED] writes:
This just doesn't look right.
Ugh, you're right.
regards, tom lane
---(end of broadcast)---
TIP 8: explain analyze is your friend
Andreas Pflug [EMAIL PROTECTED] writes:
shouldn't it be datasize -= avail ?
AFAIR this is a really outdated KR style of -= . Compilers *should*
recognize this (and will throw an ambiguity error if there's no space
after =- ), but it's better to use the 'newer' style.
Dave didn't quote it
[EMAIL PROTECTED] writes:
I've then pg_dump'ed the database and recreate an other both on 7.3.4 and
7.4b
Both are still running after more than 30 minutes of CPU (100% cpu taken)
creating the levt_lu_ligne_evt_key.
That's hard to believe. I get
regression=# SELECT levt_lu,count(*) from
At the end of several bulk inserts the following statements get executed:
begin
update pom_c2996785 set p3=3268837857008 where p3=34804837857008
update pom_c2996795 set p3=3268837857008 where p3=34804837857008
update pom_c2996804 set p3=3268837857008 where p3=34804837857008
commit
[Please hold me on the to:/cc: list since I am not subscribed]
After talking this over with some of the great guys on IRC it was
suggested I ask here.
I am currently working on a document about how to convert from MySQL to
PostgreSQL (Sybase, Oracle, DB2, MS SQL Server are also going to be
While looking into a block size mismatch problem between
Postgresql and FreeBSD's FFS, I noticed that postgresql is making
some rather odd-sized requests to malloc(3): 0x2034, 0x2020,
0x4018, 0x8018, etc. Most malloc(3) implementations round large
allocations up to a multiple of a large power of
[EMAIL PROTECTED] writes:
This is on unixware 7 (both 7.3.4 and 7.4b)
I'm on the FR language (I'll re-initdb whith lang=C to see what happens)
Okay. If you find it's still slow in C locale, the next thing to try
would be forcing use of our own qsort, as we already do for Solaris.
You'd need
Okay, so far,
I've reinitdb (on 7.4b) with LANG=C and it worked.
So I reinitDB with LANG=FR and used LANG=C to psql -f xxx.sql template1 to
recreate the db and it worked too...
I did'nt initdb between cvs changes, maybe that's why.
7.4b seems ok.
However, is there a way I can reindex on my 7.3.4
Jeroen Ruigrok/asmodai wrote:
Check constraints: bugs_severity_cstr ((bug_severity =
'blocker'::character varying) OR (bug_severity = 'critical'::character
varying) OR (bug_severity = 'major'::character varying))
If you have even more choices there (as Bugzilla does) you even get:
CONSTRAINT
It seems when you create a new table with the references syntax the
constraint is created with a dependency specifically on a primary key
constraint on the target table.
However when you alter a table to add a foreign key constraint the constraint
is added with a dependency on any unique index
On 28 Aug 2003, Gregory Stark wrote:
It seems when you create a new table with the references syntax the
constraint is created with a dependency specifically on a primary key
constraint on the target table.
However when you alter a table to add a foreign key constraint the constraint
is
Stephan Szabo [EMAIL PROTECTED] writes:
... that would only help if the unique constraint were created before the
references constraint.
But in any case, pg_dump ought to be careful to dump index creation
commands before REFERENCES constraints, I should think. If it isn't
doing that, there's a
[EMAIL PROTECTED] writes:
I've reinitdb (on 7.4b) with LANG=C and it worked.
So I reinitDB with LANG=FR and used LANG=C to psql -f xxx.sql template1 to
recreate the db and it worked too...
That's weird. I don't understand why an initdb in the same locale would
make the problem go away.
I
David Schultz [EMAIL PROTECTED] writes:
While looking into a block size mismatch problem between
Postgresql and FreeBSD's FFS, I noticed that postgresql is making
some rather odd-sized requests to malloc(3): 0x2034, 0x2020,
0x4018, 0x8018, etc.
AFAICT the operative word there is some --- the
My platforms are Unixware 713.
Am I right to be afraid that I have to pg_dump and reload?
Stiil it's amazind, 7.3 has been up for months and I discover the proclem
today...
Well, I don't reindex that often...
On Thu, 28 Aug 2003, Tom Lane wrote:
Date: Thu, 28 Aug 2003 12:19:13 -0400
From: Tom
So where are the new array functions and syntaces documented?
Specifically I want to know how to replace my int_array_aggregate(int) and
int_array_enum(_int) calls. And how to replace my arr *= n calls too.
I think these are supposed be ALL my_array and n = ANY myarray or
something like that?
On Thu, 28 Aug 2003, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
... that would only help if the unique constraint were created before the
references constraint.
But in any case, pg_dump ought to be careful to dump index creation
commands before REFERENCES constraints, I
Tom Lane writes:
Beta2 is a done deal. When Bruce gets back from the seashore I expect
he'll take a look at the issues you raised, but we're not holding off
beta2 another week for that to happen.
Could someone tell the rest of the world ahead of time when release steps
are going to happen?
--On Thursday, August 28, 2003 19:31:17 +0200 Peter Eisentraut
[EMAIL PROTECTED] wrote:
Tom Lane writes:
Beta2 is a done deal. When Bruce gets back from the seashore I expect
he'll take a look at the issues you raised, but we're not holding off
beta2 another week for that to happen.
Could
I've traced through the failure reported here by Markus Kräutner:
http://archives.postgresql.org/pgsql-hackers/2003-08/msg01132.php
What is happening is that as the UPDATE adds tuples (all with the same
hash key value) to the table, the hash bucket being filled eventually
requires more pages, and
Just a follow up,
is it better to give a patch for this kind of stuff ?
Regards
Gaetano Mendola
Mendola Gaetano [EMAIL PROTECTED] wrote:
Hi all,
I found this code on the file variables.c and
in the function SetVariable I read:
if (strcmp(current-name, name) == 0)
{
Greg Stark wrote:
So where are the new array functions and syntaces documented?
Mainly here:
http://developer.postgresql.org/docs/postgres/sql-expressions.html#SQL-SYNTAX-ARRAY-CONSTRUCTORS
http://developer.postgresql.org/docs/postgres/arrays.html
What is the state of things regarding having to use massive strings of
quotes like this (taken from the 7.3 docs)?:
a_output := a_output || '' if v_'' ||
referrer_keys.kind || '' like ''
|| referrer_keys.key_string || ''
then return '' ||
Andrew Dunstan [EMAIL PROTECTED] wrote:
Mendola Gaetano wrote:
Hi all,
is not usefull have a mailing list in where people can
partecipate in a sort of code revision about the
actual code ?
Do you mean code review?
Yep, I'm a drunk dyslectic :-)
Gaetano
Stephan Szabo [EMAIL PROTECTED] writes:
On 28 Aug 2003, Gregory Stark wrote:
It seems when you create a new table with the references syntax the
constraint is created with a dependency specifically on a primary key
constraint on the target table.
However when you alter a table to add a
Joe Conway [EMAIL PROTECTED] writes:
Greg Stark wrote:
So where are the new array functions and syntaces documented?
Mainly here:
http://developer.postgresql.org/docs/postgres/arrays.html
excellent. thank you.
Specifically I want to know how to replace my int_array_aggregate(int) and
It looks like the problem has been introduced by recent changes to dump
more stuff as constraints. pg_dump is careful to dump indexes before
constraints --- but the latter category now includes not only foreign
key constraints, but unique/primary constraints, and those will all end
up sorted by
Hey, I just tried to to a search of the mail archives and got an error.
I was trying to go here:
http://archives.postgresql.org/search.php?q=autovacuumps=50wm=wrdo=0ul=http%3A%2F%2Farchives.postgresql.org%2Fpgsql-hackers%2Fm=allwf=11
and got the following error:
DB err: could not connect
Joe Conway [EMAIL PROTECTED] writes:
Greg Stark wrote:
And how to replace my arr *= n calls too.
See:
http://developer.postgresql.org/docs/postgres/functions-comparisons.html#AEN12154
That reminds me --- contrib/array is definitely obsolete now, and there
may be parts of the other contrib
Andrew Dunstan [EMAIL PROTECTED] writes:
What is the state of things regarding having to use massive strings of
quotes like this (taken from the 7.3 docs)?:
How much of that is already replaceable by the tactic of using
quote_literal() wherever possible? It's safest to be using
quote_literal
This is a spill over from some discussions on some of the FreeBSD
mailing lists about FS performance. After FreeBSD 4.5-RELEASE, the
file system block size was bumped from 8K to 16K. Right now,
PostgreSQL still stores data in 8K blocks. Are there any objections
to me increasing the block size
looking into it ... thanks
On Thu, 28 Aug 2003, Matthew T. O'Connor wrote:
Hey, I just tried to to a search of the mail archives and got an error.
I was trying to go here:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
What is the state of things regarding having to use massive strings of
quotes like this (taken from the 7.3 docs)?:
How much of that is already replaceable by the tactic of using
quote_literal() wherever possible? It's safest to
Sean Chittenden [EMAIL PROTECTED] writes:
Are there any objections
to me increasing the block size for FreeBSD installations to 16K for
the upcoming 7.4 release?
I'm a little uncomfortable with introducing a cross-platform variation
in the standard block size. That would have implications for
Sean Chittenden [EMAIL PROTECTED] writes:
You do realize that you'll be forcing initdbs on people if you
blithely add and remove such a patch?
Yup. I was tempted to include another patch just to bump the catalog
version in the event that it doesn't gracefully detect differing block
sizes...
Thomas Swan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm a little uncomfortable with introducing a cross-platform variation
in the standard block size.
Has anyone looked at changing the default block size across the board
and what the performance improvements/penalties might be? Hardware
Tom Lane wrote:
What I'm thinking of doing is removing the code, and replacing the
README with a note explaining how to convert contrib/array queries to
use the new mainstream syntaxes. That will give contrib/array users
a clue what they're supposed to do. In a release or three the README
could
Joe Conway [EMAIL PROTECTED] writes:
I have no objection to removing it now, but previously I think you
agreed with Bruce's comment that we should leave it intact (but
deprecated) for 7.4, and remove in 7.5.
Did we discuss this already? I'd forgotten.
In any case, the module isn't visibly
Hannu Krosing wrote:
Any idea of performance - is this array_aggregate(anyelement) faster,
slower or about same than int_array_aggregate(int) ?
I haven't tested, but I'd guess for an array of any significant length
int_array_aggregate() is faster (see my other post). That's one of the
reasons I
Are there any objections to me increasing the block size for
FreeBSD installations to 16K for the upcoming 7.4 release?
I'm a little uncomfortable with introducing a cross-platform
variation in the standard block size. That would have implications
for things like whether a table
On Thu, 28 Aug 2003, Tom Lane wrote:
I've traced through the failure reported here by Markus Kräutner:
http://archives.postgresql.org/pgsql-hackers/2003-08/msg01132.php
What is happening is that as the UPDATE adds tuples (all with the same
hash key value) to the table, the hash bucket being
Joe Conway kirjutas N, 28.08.2003 kell 21:15:
Greg Stark wrote:
Specifically I want to know how to replace my int_array_aggregate(int) and
int_array_enum(_int) calls.
I have no idea what those are -- are they from contrib?
You can create an aggregate to turn arbitrary datatype elements
There's been some recent discussion on some of the FreeBSD mailing
lists about PostgreSQL and performance. FreeBSD uses 16K blocks for
its FS and it has been suggested that PostgreSQL on FreeBSD be
modified to use 16K blocks instead of 8K blocks. Are there any
adverse reactions or reasons to not
scott.marlowe [EMAIL PROTECTED] writes:
If I'm reading this right, this bug means you could do:
select * from table where field in (1,2,3,4)
where you should get say 100 rows, and you might not get all 100 rows?
Yes, if you were concurrently inserting into the same table. The given
example
Hi,
I'm doing research on locking pattern of applications. I chose PostgreSQL
7.3.3 as an example application due to availability of sourcecode.
I instrumented the file backend/storage/lmgr/lock.c with printf() statements
in order to find out the locking behaviour of typical applications using
Hello:
I'm developing a TLS library in C# for my PostgreSQL ADO.NET Data
Provider, i can work well using the openssl test server, using:
openssl s_server -accept 443 -key server.key -cert server.crt -tls1 -bugs
But when i try to use it for connect to postgresql (7.4 on
Windows+Cygwin) i get
See:
http://developer.postgresql.org/docs/postgres/functions-comparisons.html#AEN12154
regression=# SELECT g.grosysid, g.groname, s.usesysid, s.usename FROM pg_shadow
s, pg_group g WHERE s.usesysid = any (g.grolist);
These forms below are all equivalent, right?
If so ideally they would
Tom Lane wrote:
Sean Chittenden [EMAIL PROTECTED] writes:
Are there any objections
to me increasing the block size for FreeBSD installations to 16K for
the upcoming 7.4 release?
I'm a little uncomfortable with introducing a cross-platform variation
in the standard block size. That
Greg Stark [EMAIL PROTECTED] writes:
Hmmm I think there's still something missing here. I was using pg_restore -r
(actually I was using -L but the list was originally generated with -r) which
seemed like a good idea at the time. Rereading it now it seems like it
shouldn't change anything
Sean Chittenden [EMAIL PROTECTED] writes:
Hrm, well, given things just went to beta2, I'm going to bump
postgresql-devel to beta2 and include this patch for now, however, I'm
going to explicitly requests that people who have problems or
successes with beta2 on FreeBSD ask me before possible
Tom Lane [EMAIL PROTECTED] writes:
AFAICT the difference is not whether you create the FK constraint during
table creation or add it later (in fact, the same code is executed
either way). The difference in Greg's example is that he said
REFERENCES test in one case and REFERENCES test(a) in
Greg Stark [EMAIL PROTECTED] writes:
Hmmm I think there's still something missing here. I was using pg_restore -r
(actually I was using -L but the list was originally generated with -r) which
seemed like a good idea at the time. Rereading it now it seems like it
shouldn't change anything
Hrm, well, given things just went to beta2, I'm going to bump
postgresql-devel to beta2 and include this patch for now, however,
I'm going to explicitly requests that people who have problems or
successes with beta2 on FreeBSD ask me before possible reporting
problems with a platform
On Thu, 28 Aug 2003, Thomas Swan wrote:
Has anyone looked at changing the default block size across the board
and what the performance improvements/penalties might be? Hardware has
changed quite a bit over the years.
I *think* that the reason for the performance improvement on FreeBSD is
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
I have no objection to removing it now, but previously I think you
agreed with Bruce's comment that we should leave it intact (but
deprecated) for 7.4, and remove in 7.5.
Did we discuss this already? I'd forgotten.
In any case, the module
On Thu, Aug 28, 2003 at 03:56:18PM -0400, Tom Lane wrote:
Sean Chittenden [EMAIL PROTECTED] writes:
Hrm, well, given things just went to beta2, I'm going to bump
postgresql-devel to beta2 and include this patch for now, however, I'm
going to explicitly requests that people who have problems
Tom Lane wrote:
Thomas Swan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm a little uncomfortable with introducing a cross-platform variation
in the standard block size.
Has anyone looked at changing the default block size across the board
and what the performance
On Thu, 28 Aug 2003, Marc G. Fournier wrote:
On Thu, 28 Aug 2003, Thomas Swan wrote:
Has anyone looked at changing the default block size across the board
and what the performance improvements/penalties might be? Hardware has
changed quite a bit over the years.
I *think* that the
Sean Chittenden [EMAIL PROTECTED] writes:
Early performance tests on my laptop suggest it's about 8% faster for
writing when both the FS and PostgreSQL use 16K blocks.
BTW, I don't really believe that one set of tests, conducted on one
single machine, are anywhere near enough justification for
I have a problem with a before trigger raising a heap_mark4update error. It
happens when there are many updates on the same key. OIDs are off
presumably? Am running 7.3.2 on RH 7.3. Have looked around the archives
and found nothing useful - a mention of a known issue and a potential patch?
Or
Marie G. Tuite [EMAIL PROTECTED] writes:
I have a problem with a before trigger raising a heap_mark4update error. It
happens when there are many updates on the same key. OIDs are off
presumably? Am running 7.3.2 on RH 7.3. Have looked around the archives
and found nothing useful - a
Same issue - are there rpms anywhere for 7.3.4?
Thanks.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Tom Lane
Sent: Wednesday, August 27, 2003 10:43 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED] Org; [EMAIL PROTECTED]
Subject: Re: [GENERAL] before
hi ,
iam trying to run gdb on postgresql to stack-trace the functions that get
called when a lock is taken.
gdb *program*
what do i pass in place of program inorder to run gdb on postgresqql
thanks
jenny
_
Get MSN 8 and help protect
On Thu, Aug 28, 2003 at 02:11:26PM -0700, Jenny - wrote:
hi ,
iam trying to run gdb on postgresql to stack-trace the functions that get
called when a lock is taken.
gdb *program*
what do i pass in place of program inorder to run gdb on postgresqql
After the backend is running, get its PID
95 matches
Mail list logo
