A few thoughts on LWLock data structures...
In lwlock.c we hold a list of lwlocks held:
held_lwlocks[MAX_SIMUL_LWLOCKS]
where
#define MAX_SIMUL_LWLOCKS 100
The code for LWLockRelease assumes that the last acquired lock will
always be the first one to be released, and uses an O(N) loop to s
Following some advice from Intel,
http://www.intel.com/cd/ids/developer/asmo-na/eng/technologies/threading
/20469.htm?page=2
I'm looking at whether the LWLock data structures may be within the same
cache line.
Intel uses 128 byte cache lines on its high end processors.
slru.c uses BUFFERALIGN wh
Bruce Momjian wrote:
> Uh, if we bump up the major library version in 8.0.X, will that
> require 8.0.0 user applications to be recompiled?
No, they just keep using the old library.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)
3. When the default is changed, the dependency is updated
to reflect the new sequence. The old sequence is left intact
as an independent object.
What exactly is the use-case of that (or any other manipulation of a
serial column's default)? There is no point that I can see in just
rolling one
G u i d o B a r o s i o <[EMAIL PROTECTED]> writes:
> Following belows thread
> http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg43381.html
> I am experiencing the same problem on a brand new, extremely fresh, solaris
> 5.9 and PostgreSQL 7.4.6 box.
> As expected, the problem was solv
Robin Chauhan <[EMAIL PROTECTED]> writes:
> I installed PostGIS, which appeared to work just fine. The I
> installed contrib/btree_gist, and since then I've had issues.
> PostgreSQL 7.3.2 on i686-pc-linux-gnu, compiled by GCC egcs-2.91.66
> Would you have any advice for me?
Try a more modern Po
Hi Tom!
Tom Lane [2005-02-02 12:01 -0500]:
> Martin Pitt <[EMAIL PROTECTED]> writes:
> > What would you propose as a solution?
>
> Do nothing.
That's unfortunately not an option.
> The problem you are raising isn't very serious since
> RPM-style installations don't support concurrent installa
Following belows thread
http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg43381.html
I am experiencing the same problem on a brand new, extremely fresh, solaris 5.9
and PostgreSQL 7.4.6 box.
As expected, the problem was solved when passing the -d [1-5] to the
postmaster. But... I was
I tried asking on [EMAIL PROTECTED], and Mark
Cave-Ayland suggested
I ask you folks.
I installed PostGIS, which appeared to work just fine. The I
installed contrib/btree_gist, and since then I've had issues.
Some background: My postgres setup is on Red Hat linux, installed
from RPMs. It is a s
uhmm,...
Forgot to change the copyright.
Please accept this under the same terms as postgresql itself.
... John
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressH
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
| Gaetano Mendola <[EMAIL PROTECTED]> writes:
|
|>my warning was due the fact that in the docs is written nowhere this
|>drawback.
|
|
| The SELECT reference page already says that the output rows are computed
| before applying ORDER BY
Hi!
(sorry for the additional addresses; I'm not subscribed to -hackers,
so my mail will last a while until it arrives there).
Tom Lane [2005-02-02 11:07 -0500]:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Martin Pitt has detected that the libpq API has changed incompatibly
> > between 7.4
Neil Conway <[EMAIL PROTECTED]> writes:
> On Wed, 2005-02-02 at 23:22 -0500, Tom Lane wrote:
>> The syntax you are showing is designed
>> to return a scalar. It will (and should) barf on multiple rows as well
>> as multiple columns.
> I don't understand; the example I posted is of an SRF that ret
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> This suffers from the same problems that currval does when using
> connection pools tho.
I still don't see this as much of a real world problem however,
more of a "doctor, it hurts when I do this" variety. As the DBD::Pg docs
point out, you sho
On Wed, 2005-02-02 at 23:22 -0500, Tom Lane wrote:
> The syntax you are showing is designed
> to return a scalar. It will (and should) barf on multiple rows as well
> as multiple columns.
I don't understand; the example I posted is of an SRF that returns
multiple rows of multiple columns, which i
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> ISTM this is a bug, but it's not clear to me what is the solution.
>> I can think of two:
>>
>> 1. Changing the default is forbidden
>> 2. When the default is changed, the dependency on the sequence is
>> dropped, and the seq
On Wed, 2005-02-02 at 23:22 -0500, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > neilc=# select a, (select * from abc) from abc;
> > ERROR: subquery must return only one column
>
> > Is there a reason we can't treat a subselect in the target list as
> > returning a composite type?
Neil Conway <[EMAIL PROTECTED]> writes:
> neilc=# select a, (select * from abc) from abc;
> ERROR: subquery must return only one column
> Is there a reason we can't treat a subselect in the target list as
> returning a composite type?
Given the 8.0 infrastructure for unnamed record types it migh
On Wed, Feb 02, 2005 at 03:49:59PM -0800, Joshua D. Drake wrote:
> Alvaro Herrera wrote:
>
> >On Wed, Feb 02, 2005 at 01:54:48PM -0800, Joshua D. Drake wrote:
> >
> >>It is not pilot error if PostgreSQL allows it. There is
> >>nothing "illegal" about the above commands in their execution.
> >>The
This behavior seems inconsistent:
neilc=# create table abc (a int, b int);
CREATE TABLE
neilc=# create function foo_abc() returns setof abc as 'select * from
abc' language sql;
CREATE FUNCTION
neilc=# insert into abc values (5, 10);
INSERT 17234 1
neilc=# insert into abc values (10, 20);
INSERT 17
Bruce Momjian writes:
> In fact by upping the major every time will 7.2 clients automatically use
> the 7.3 libpq or will they have to be relinked?
If you do not bump the soname then 7.2 clients will automatically immediately
start using the new library when it's installed. (actually when ldconf
Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Tom Lane wrote:
> > > Well, if you just want to bump libpq's SO_MAJOR_VERSION, I won't
> > > object.
> >
> > Yes. Unless someone objects, I will do that for 8.0.* and 8.1.*.
>
> I am thinking we should up the 8.0.* and 8.1.* releases to have the
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > ... If they don't have
> > different sonames, then we declare that they are compatible, so it
> > should be OK to have only the latest version installed. That requires
> > us to stay honest with the sonames, but it does not requ
> Attempts to return the id of the last value to be inserted into a table.
> You can either provide a sequence name (preferred) or provide a table
> name with optional schema. The $catalog and $field arguments are always
> ignored.
> The current value of the sequence is returned by a call to the
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Merlin Moncur wrote:
> That is a shortcoming of the DBD::pg driver which really should be
> returning a key (comprised of columns, some or none of which may be
> defaulted by the server).
Actually, the spec comes from DBI, not DBD::Pg, and is ins
Alvaro Herrera wrote:
On Wed, Feb 02, 2005 at 01:54:48PM -0800, Joshua D. Drake wrote:
It is not pilot error if PostgreSQL allows it. There is
nothing "illegal" about the above commands in their execution.
The pg_dump application should recognize that the object has
changed and react accordingly
Hi list,
Attached for your perusal, unicode versions of upper/lower, that work
independent of locale except for the following languages:
Turkish, Azeri, and Lithuanian.
There are 15 locale specific cases in total not covered.
--
John Hansen <[EMAIL PROTECTED]>
GeekNET
collate.tar.gz
Descrip
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> ... If they don't have
> different sonames, then we declare that they are compatible, so it
> should be OK to have only the latest version installed. That requires
> us to stay honest with the sonames, but it does not require us to
> increase the
Peter Eisentraut wrote:
> Tom Lane wrote:
> > Well, if you just want to bump libpq's SO_MAJOR_VERSION, I won't
> > object.
>
> Yes. Unless someone objects, I will do that for 8.0.* and 8.1.*.
I am thinking we should up the 8.0.* and 8.1.* releases to have the same
major number, but not make a ma
a_ogawa <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Based on this I think we ought to go with the "unrolled" approach,
> I agree. The unrolled approach is a good result in most environments.
I have committed changes along this line in HEAD and 8_0 branches.
> First of all, this macro will
> > According to our RELEASE_CHANGES documentation:
>
> > The major version number should be updated whenever the
> source of the
> > library changes to make it binary incompatible. Such
> changes include,
> > but are not limited to:
>
> > 1. Removing a public functi
On Wed, Feb 02, 2005 at 01:54:48PM -0800, Joshua D. Drake wrote:
> It is not pilot error if PostgreSQL allows it. There is
> nothing "illegal" about the above commands in their execution.
> The pg_dump application should recognize that the object has
> changed and react accordingly.
ISTM this is
Tom Lane wrote:
> Well, if you just want to bump libpq's SO_MAJOR_VERSION, I won't
> object.
Yes. Unless someone objects, I will do that for 8.0.* and 8.1.*.
> The Linux conventions for library names, for one,
> essentially require us to bump SO_MAJOR_VERSION for every release if
> we want to ha
create table foo (foo serial not null, bar text);
create sequence foo_seq;
alter table foo alter column foo set default nextval('foo_seq');
This is flat out pilot error: you do not get to mess with the default
expression of a SERIAL column, because it's part of the internal
implementation of
> This "portable" function is so unportable that I see no reason to
> accept it as precedent.
Hm. Instead of altering the syntax, what slipping in the last
inserted/updated tuple into the PQResult object? Maybe is a protocol
level option? Now everybody gets to use it with minimal muss.
Merlin
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> However if you do the following:
> create table foo (foo serial not null, bar text);
> create sequence foo_seq;
> alter table foo alter column foo set default nextval('foo_seq');
This is flat out pilot error: you do not get to mess with the default
Greg Stark <[EMAIL PROTECTED]> writes:
> This is from the DBI documentation -- that is, the non-driver-specific
> abstract interface documentation.
>Returns a value 'identifying' the row just inserted, if possible.
>Typically this would be a value assigned by the database s
Tom Lane wrote:
Greg Stark <[EMAIL PROTECTED]> writes:
Tom Lane <[EMAIL PROTECTED]> writes:
How is what you're suggesting more portable?
Well, the driver would be free to implement $sth->last_insert_id() using
whatever proprietary extensions it has available. The non-portableness would
at least be
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > Greg Stark <[EMAIL PROTECTED]> writes:
> > > Tom Lane <[EMAIL PROTECTED]> writes:
> > >> How is what you're suggesting more portable?
> For postgres it looks like currently it requires you to pass in the
table
> and
> field might even need a "driver-spe
Hello,
Ran into this little gem with a customer today:
This works:
create table foo (foo int not null, bar text);
create sequence foo_seq;
alter table foo alter column foo set default nextval('foo_seq');
pg_dump will correctly dump the table:
CREATE TABLE foo (
foo integer DEFAULT nextval('foo_s
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > Tom Lane <[EMAIL PROTECTED]> writes:
> >> How is what you're suggesting more portable?
>
> > Well, the driver would be free to implement $sth->last_insert_id() using
> > whatever proprietary extensions it has avail
Bruce Momjian wrote:
> The only downside I see to bumping the major
> number each time is that the major number could get pretty big. Do
> the dynamic library systems handle two-digit library version numbers
> properly?
MySQL's client library is at 12, so I don't see a problem.
--
Peter Eisentr
Tom,
> Why is that a problem? The complaint seems about analogous to saying
> we should not have groups because you can't REVOKE rights from an
> individual user if he has them via a group membership.
Oh, mostly I'm just bitching because I had seeing a new feature I can't
use ;-)
--
Josh Berk
Christopher Kings-Lynne wrote:
> I notice the CONNECT BY patch has been updated for 8.0:
>
> http://gppl.moonbone.ru/
>
> Seriously, we really need to get this into 8.1. Convert it to the
> standard WITH RECURSIVE syntax if necessary...
Yep, we are just waiting for someone to do the work.
--
On Wed, Feb 02, 2005 at 09:50:16AM -0800, Dann Corbit wrote:
> Obviously, you cannot create ordering in hash indexes, which is why
> nobody else does that either.
>
> The list of relational database systems that offer asc/desc on btree
> index files is quite extensive.
How many in that list allow
Tom Lane wrote:
> Bruce Momjian writes:
> > According to our RELEASE_CHANGES documentation:
>
> > The major version number should be updated whenever the source of the
> > library changes to make it binary incompatible. Such changes include,
> > but are not limited to:
>
Bruce Momjian writes:
> According to our RELEASE_CHANGES documentation:
> The major version number should be updated whenever the source of the
> library changes to make it binary incompatible. Such changes include,
> but are not limited to:
> 1. Removing
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > We can rectify the mistake, but then we need to change the SONAME.
> > That's what it's for.
>
> Well, if you just want to bump libpq's SO_MAJOR_VERSION, I won't object.
>
> This brings up a point that I think has been discussed
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> We can rectify the mistake, but then we need to change the SONAME.
> That's what it's for.
Well, if you just want to bump libpq's SO_MAJOR_VERSION, I won't object.
This brings up a point that I think has been discussed before: we
operate on the ass
Obviously, you cannot create ordering in hash indexes, which is why
nobody else does that either.
The list of relational database systems that offer asc/desc on btree
index files is quite extensive.
The list of relational database systems that do not offer it is:
1. PostgreSQL
2. ?
It will mak
Tom Lane wrote:
> Martin Pitt <[EMAIL PROTECTED]> writes:
> > What would you propose as a solution?
>
> Do nothing. The problem you are raising isn't very serious since
> RPM-style installations don't support concurrent installation of
> multiple PG versions anyway. That being the case, it doesn'
Tom Lane wrote:
> Bruce Momjian writes:
> > Added to release checklist:
> > * Update inet/cidr data types with newest Bind patches
>
> You should also add "check for zic database updates".
Uh, we already have:
* Update timezone data to match latest zic database (see
src/ti
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> Allow ASC/DESC direction modifiers for index columns.
We aren't going to do that, because it would be a meaningless concept
for indexes that don't impose a linear sort order (which is to say,
everything except btrees). The concept that actually fits int
Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> > On Tue, Feb 01, 2005 at 12:56:20AM -0500, Tom Lane wrote:
> >> His point stands though: if you are accessing Postgres through some kind
> >> of connection-pooling software, currval() cannot be trusted across
> >> transaction boundaries,
Allow ASC/DESC direction modifiers for index columns.
Almost every database has this, and it is a pest to have to
write a function for every index column you want descending.
Now, it is not technically difficult (nothing more than –compare(x,y)
instead of compare(x,y) to produce the
> Tom Lane <[EMAIL PROTECTED]> writes:
> "INSERT/UPDATE ... RETURNING" isn't something a driver can take
advantage
> of.
> It would require it to modify your statements which it can't do
safely. So
> your application would have such non-portable SQL code written into
it.
> Switch
> databases and yo
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> How is what you're suggesting more portable?
> Well, the driver would be free to implement $sth->last_insert_id() using
> whatever proprietary extensions it has available. The non-portableness would
> at least be hidd
Mark Cave-Ayland wrote:
>
> > -Original Message-
> > From: Tom Lane [mailto:[EMAIL PROTECTED]
> > Sent: 31 January 2005 16:35
> > To: Mark Cave-Ayland
> > Cc: pgsql-hackers@postgresql.org
> > Subject: Re: [HACKERS] 7.3.8 under FC3 takes excessive semaphores?
>
> (cut)
>
> > Judging by t
Tom Lane wrote:
> Paul Vixie <[EMAIL PROTECTED]> writes:
> > i have two suggestions. first, look at the rest of the current source file,
> > in case there are other fixes.
>
> Right, I already grabbed the latest.
>
> > second, track changes this source file during
> > your release engineering pr
Bruce Momjian writes:
> Added to release checklist:
> * Update inet/cidr data types with newest Bind patches
You should also add "check for zic database updates".
regards, tom lane
---(end of broadcast)---
TIP 9: the
Martin Pitt <[EMAIL PROTECTED]> writes:
> What would you propose as a solution?
Do nothing. The problem you are raising isn't very serious since
RPM-style installations don't support concurrent installation of
multiple PG versions anyway. That being the case, it doesn't really
matter whether 8.0
Tom Lane <[EMAIL PROTECTED]> writes:
> How is what you're suggesting more portable?
Well, the driver would be free to implement $sth->last_insert_id() using
whatever proprietary extensions it has available. The non-portableness would
at least be hidden in the driver layer. Switch out the driver
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Martin Pitt has detected that the libpq API has changed incompatibly
> between 7.4 and 8.0. This has the effect, for example, that 7.4's psql
> cannot run with 8.0's libpq.
[ shrug... ] I don't think we've ever guaranteed that anyway. I will
resist
Rafael Martinez Guerrero wrote:
Hello
I have a problem running initdb 8.0.1. I get this error message when I
try to run this command in my system:
---
-bash-2.05b$ /local/opt/postgresql/bin/initdb
The program "postgres" is needed by
Rafael Martinez Guerrero <[EMAIL PROTECTED]> writes:
> If we install the binaries for postgres under /local/opt/postgresql/bin,
> initdb in this directory will be a symblink to
> "/local/store/bbking/.postgresql/ver-8.0.1/opt/postgresql/bin/[EMAIL
> PROTECTED]
> uxlibc63=20
> and=20
> /local/opt/
"Mark Cave-Ayland" <[EMAIL PROTECTED]> writes:
> Just off the top of my head, would it not be feasible to add a column to
> pg_class called lastinsert that points to the OID of the pg_attribute column
> to return after an insert?
No. The thing everyone is ignoring here is that the INSERT command
Tom Lane wrote:
> Based on this I think we ought to go with the "unrolled" approach, ie,
> we'll create a macro to initialize the fixed fields of fcinfo but fill
> in the arg and argisnull arrays with code like what's already in
> FunctionCall2:
I agree. The unrolled approach is a good result in
Hello
I have a problem running initdb 8.0.1. I get this error message when I
try to run this command in my system:
---
-bash-2.05b$ /local/opt/postgresql/bin/initdb
The program "postgres" is needed by initdb but was not found in the
Martin Pitt has detected that the libpq API has changed incompatibly
between 7.4 and 8.0. This has the effect, for example, that 7.4's psql
cannot run with 8.0's libpq. Example:
$ LD_LIBRARY_PATH=/home/peter/devel/pg80/pg-install/lib
/home/peter/devel/pg74/pg-install/bin/psql --help
/home/peter
Tom Lane wrote:
> I seem to recall that there was some special consideration for files
> that would conditionally show up in multiple executables. Or were
> you going to fix that by having just one .mo file for all the
> clients?
The current method is to explicitly register the source file in eac
Hi Tom and others,
> I think the correct solution is not to mess with what's admittedly a
legacy aspect of
> our client API. Instead we should invent the "INSERT RETURNING" and
"UPDATE RETURNING"
> commands that have been discussed repeatedly (see the pghackers archives).
That would
> allow peop
71 matches
Mail list logo
