Tom Lane [EMAIL PROTECTED] wrote
This is pretty much what heapam and btree currently do, but on looking
at it I think it's got a problem: we really ought to mark the buffer
dirty before releasing the critical section. Otherwise, if there's an
elog(ERROR) before the WriteBuffer call is
Jonah H. Harris [EMAIL PROTECTED] wrote
Yeah, I noticed that one. How would you suggest setting
CLASS_TUPLE_SIZE in that case?
What if you put your char[64] before relhassubclass, then you don't change
CLASS_TUPLE_SIZE.
Regards,
Qingqing
---(end of
On Thu, 2006-03-30 at 13:51 -0500, Tom Lane wrote:
This is pretty much what heapam and btree currently do, but on looking
at it I think it's got a problem: we really ought to mark the buffer
dirty before releasing the critical section. Otherwise, if there's an
elog(ERROR) before the
Simon Riggs [EMAIL PROTECTED] writes:
Problem for indexes only. heap xlrecs don't specify exact insert points
Sure they do. They had better, else (for example) the associated index
insertions will be wrong.
Accesses to local buffers don't need to be critical sections either.
True, but in
Qingqing Zhou [EMAIL PROTECTED] writes:
It may be not good but not harmful either. On step2, the transaction will
abort and leave a page that has been changed but not marked dirty. There are
two situtations could happen after that. One is step 3, the other is the
page is still in the buffer
On Thu, Mar 30, 2006 at 10:15:21AM -0500, D'Arcy J.M. Cain wrote:
I had to do multi-master replication for a major project and we wound
up writing our own replication system. The problem is that this sort of
thing really has to be based on your own business rules. There is no
way to make it
On 3/31/06, Qingqing Zhou [EMAIL PROTECTED] wrote:
What if you put your char[64] before relhassubclass, then you
don't change CLASS_TUPLE_SIZE.
Thought about that... but it would be an ugly place for this column.
I know I could get around it by renumbering the attribute, but that's
just a
On 3/31/06, Alvaro Herrera [EMAIL PROTECTED] wrote:
What are you using a char[64] for anyway? You should probably consider
using NameData, if you want to store an identifier.
It's just a fixed length string that will never change in size and as
such, I'd like not to add the overhead of any
On Fri, Mar 31, 2006 at 10:45:15AM -0500, Jonah H. Harris wrote:
On 3/31/06, Alvaro Herrera [EMAIL PROTECTED] wrote:
What are you using a char[64] for anyway? You should probably consider
using NameData, if you want to store an identifier.
It's just a fixed length string that will never
On Fri, 31 Mar 2006 09:35:31 -0600
Jim C. Nasby [EMAIL PROTECTED] wrote:
On Thu, Mar 30, 2006 at 10:15:21AM -0500, D'Arcy J.M. Cain wrote:
I had to do multi-master replication for a major project and we wound
up writing our own replication system. The problem is that this sort of
thing
Jim C. Nasby [EMAIL PROTECTED] writes:
About the only reason I use CHAR in other databases systems is when I
know that the field will always contain the same amount of data, ie:
storing a SHA1. In these cases it's silly to have a 4 byte overhead to
store length. I really wish CHAR in
On Fri, 2006-03-31 at 09:36 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Problem for indexes only. heap xlrecs don't specify exact insert points
Sure they do. They had better, else (for example) the associated index
insertions will be wrong.
Yep, you're right.
Best
Heikki Linnakangas [EMAIL PROTECTED] writes:
On Wed, 29 Mar 2006, Tom Lane wrote:
That loses the ability to reflect tuple deadness back into LP_DELETE
flags, no?
At first glance, it doesn't look so hard. index_getmulti could mark
those tids that are dead, and btgetmulti would rescan the
On 3/31/06, Tom Lane [EMAIL PROTECTED] wrote:
This argument falls flat when you consider that the width of a CHAR
entry is measured in characters, not bytes, and therefore its physical
size is not fixed even if its logical width is.
Gotta love multibyte :)
--
Jonah H. Harris, Database
I wrote:
I'm thinking we should change the code and the README to specify that
you must mark the buffer dirty before you can END_CRIT_SECTION().
While looking at this I realized that in fact we need to, and do,
mark the buffer dirty even earlier than that: look at bufmgr.c
LockBuffer and
Dear PostgreSQL Hackers,
I recently ran into an issue where I was having trouble compiling
PostgreSQL with PL/Perl. Although Mac OS X 10.4 comes with a dynamic
Perl, I long ago compiled my own Perl, which is static. So /usr/bin/
perl was my static Perl, and /usr/bin/perl5.8.6 is the stock
David Wheeler wrote:
But that's a PITA. I'd much rather have been able to tell configure
*which* perl to use:
./configure --with-perl=/usr/bin/perl5.8.6
Would it be possible to add support for an optional argument to the PL/*
options (--with-perl,--with-python, --with-tcl) so that we can
On Mar 31, 2006, at 12:05, Seneca Cunningham wrote:
Like passing PERL=/usr/bin/perl5.8.6 to configure?
Is that currently supported? Because, if so, it's documented AFAICT.
Best,
David
---(end of broadcast)---
TIP 5: don't forget to increase
People:
./configure --with-perl=/usr/bin/perl5.8.6
In support of David's suggestion, I'll point out that most other OSS
software configuration scripts (Apache, PHP, etc.) I deal with supports
the above syntax.
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
Has there ever been any talk of adding a first aggregate function?
It would make porting from Oracle and Access much easier.
Or is there something in the contrib modules that I might have missed?
Thanks,
--
Tony Caduto
AM Software Design
http://www.amsoftwaredesign.com
Home of PG Lightning
On Fri, Mar 31, 2006 at 03:02:47PM -0600, Tony Caduto wrote:
Has there ever been any talk of adding a first aggregate function?
It would make porting from Oracle and Access much easier.
Or is there something in the contrib modules that I might have missed?
There are several oracle
On Mar 31, 2006, at 12:40, Josh Berkus wrote:
In support of David's suggestion, I'll point out that most other OSS
software configuration scripts (Apache, PHP, etc.) I deal with
supports
the above syntax.
Yes, but even the environment variables get me what I want. I
therefore
David Wheeler [EMAIL PROTECTED] writes:
But that's a PITA. I'd much rather have been able to tell configure
*which* perl to use:
./configure --with-perl=/usr/bin/perl5.8.6
The more usual way to handle this sort of thing is to put each version
of perl in a different directory, and then
David Wheeler [EMAIL PROTECTED] writes:
Yes, but even the environment variables get me what I want. I
therefore respectfully submit the attached patch to document them in
the INSTALL file.
It seems rather pointless to document two instances of what is in fact
a generic autoconf-script
On Mar 31, 2006, at 15:52, Tom Lane wrote:
The more usual way to handle this sort of thing is to put each version
of perl in a different directory, and then you can alter PATH while
running configure to pick which one you want. I've got several
versions
of perl on this machine that I select
On Mar 31, 2006, at 16:01, Tom Lane wrote:
It seems rather pointless to document two instances of what is in fact
a generic autoconf-script behavior ...
I'm sorry to be such a moron about this, but what exactly is that
behavior? That you can specify an environment variable for whatever *
Why is the schema ignored entirely when using listen/notify? I couldn't
find any mention of this in the documentation.
Ideally, it should support schemas (and store any string it takes) but
it should at least throw an error when a schema is prepended. I guess
the workaround is to simply
On Fri, Mar 31, 2006 at 06:52:51PM -0500, Tom Lane wrote:
David Wheeler [EMAIL PROTECTED] writes:
But that's a PITA. I'd much rather have been able to tell configure
*which* perl to use:
./configure --with-perl=/usr/bin/perl5.8.6
The more usual way to handle this sort of thing is
On 3/31/06, Martijn van Oosterhout kleptog@svana.org wrote:
On Fri, Mar 31, 2006 at 03:02:47PM -0600, Tony Caduto wrote:
Has there ever been any talk of adding a first aggregate function?
It would make porting from Oracle and Access much easier.
Or is there something in the contrib
On Fri, 2006-03-31 at 20:27 -0500, Agent M wrote:
Why is the schema ignored entirely when using listen/notify?
Per the docs:
Commonly, the notification name is the same as the name of some
table in the database, and the notify event essentially means, I
changed this table, take a
Neil Conway [EMAIL PROTECTED] writes:
i.e. the LISTEN/NOTIFY argument is not the name of a relation, so it
wouldn't make much sense to schema-qualify it.
I'm not entirely sure why we even have the grammar allowing qualified
names in these statements. It's not documented that you can do that.
David Wheeler [EMAIL PROTECTED] writes:
On Mar 31, 2006, at 16:01, Tom Lane wrote:
It seems rather pointless to document two instances of what is in fact
a generic autoconf-script behavior ...
I'm sorry to be such a moron about this, but what exactly is that
behavior? That you can specify
32 matches
Mail list logo
