Tom Lane writes:
> [EMAIL PROTECTED] writes:
> on which configure didn't detect the absence of libz.so
> >>
> >> Really? Details please. It's hard to see how it could have messed
> >> up on that.
>
> > I didn't look well enough -- I apologize. The library is there, but
> > ld.so believes
> Anyone recall anything about that? A quick search of my archives didn't
> turn up the discussion that I thought I remembered.
Hmm. Maybe now we know what you dream about at night ;)
- Thomas
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > I like neither unexpected errors nor doing the wrong
> > thing by handling tuples which aren't guaranteed to
> > be up-to-date. After mark4update, the tuple is
> > guaranteed to be up-to-date and heap_update won't
> > fail even thou
Uploading now. Should show up on ftp.postgresql.org soon.
Look in /pub/dev/test-rpms.
BETA TEST USE ONLY.
Tom, try out a PPC build on this one. I know of one problem that I have
to fix -- postgresql-perl fails dependencies for libpq.so (I backed out
the patch to Makefile.shlib). A --nodeps in
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > select * from table_a a
> > where ((select data_a from table_a where id = a.id) >
> >(select data_b from table_a where id = a.id));
> > ERROR: parser: parse error at or near ">"
>
> I think I finally got this right ... see if you can
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> I like neither unexpected errors nor doing the wrong
> thing by handling tuples which aren't guaranteed to
> be up-to-date. After mark4update, the tuple is
> guaranteed to be up-to-date and heap_update won't
> fail even though some commands etc neglect
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Why does LockClassinfoForUpdate() insist on doing heap_mark4update?
>
> > Because I want to guard the target pg_class tuple by myself.
> > I don't think we could rely on the assumption that the lock on
> > the
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Why does LockClassinfoForUpdate() insist on doing heap_mark4update?
> Because I want to guard the target pg_class tuple by myself.
> I don't think we could rely on the assumption that the lock on
> the corresponding relation is held.
> yes, here are the output:
>
> datname |datdba|encoding|datpath
> -+--++-
> template1|31| 5|template1
> map | 1003| 5|map
> helyes | 1003| 5|helyes
>
> i found that if i put a space behin
Tom Lane wrote:
>
> Why does LockClassinfoForUpdate() insist on doing heap_mark4update?
Because I want to guard the target pg_class tuple by myself.
I don't think we could rely on the assumption that the lock on
the corresponding relation is held. For example, AlterTableOwner()
doesn't seem to op
Andreas SB Zeugswetter wrote:
> Tom Lane wrote:
> > Instead of a partial row CRC, we could just as well use some other
> > bit of identifying information, say the row OID. ... Checking that
> > there is a valid tuple at the slot indicated by the index item,
> > and that it has the right OID, shoul
Why does LockClassinfoForUpdate() insist on doing heap_mark4update?
As far as I can see, this accomplishes nothing except to break
concurrent index builds. If I do
create index tenk1_s1 on tenk1(stringu1);
create index tenk1_s2 on tenk1(stringu2);
in two psqls at approximately
Trond Eivind Glomsrød wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > In particular, this was and is a RedHat-made change. It does not break
> > anything that I am aware of, and allows the distributions to do their
> > thing as well.
> Note that this wasn't included in Red Hat Linux 7... it'
Lamar Owen <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
> > Trond Eivind Glomsrød writes:
> > > We have a libtool tuned to work with lots of platforms, like ia64,
> > > s390 etc... this makes sure it's used.
>
> > We don't use libtool. Nor does libtool care about the processor.
>
> In
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Trond Eivind Glomsrød writes:
>
> > > We don't use libtool.
> >
> > Doing so would be a good thing.
>
> Not if our code is more portable than libtool's.
And this is the case? libtool covers pretty much everything... and you
don't need to use it fo
Peter Eisentraut wrote:
> Trond Eivind Glomsrød writes:
> > We have a libtool tuned to work with lots of platforms, like ia64,
> > s390 etc... this makes sure it's used.
> We don't use libtool. Nor does libtool care about the processor.
'We' has a lot of different meanings. In your sentence,
Peter Eisentraut wrote:
> The patch I recommended was
> - LDFLAGS_SL:= -Bdynamic -shared -soname $(shlib)
> + LDFLAGS_SL:= -Bdynamic -shared -soname
>lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION)
And that is what was in 7.0.3.
> but that's not what your patch does. The
Trond Eivind Glomsrød writes:
> > We don't use libtool.
>
> Doing so would be a good thing.
Not if our code is more portable than libtool's.
> > Nor does libtool care about the processor.
>
> As you can see from the actual code segment, only the
> config.{guess,sub} files are copied.
But you a
Lamar Owen writes:
> > | diff -uNr postgresql-7.1beta3.orig/src/Makefile.shlib
>postgresql-7.1beta3/src/Makefile.shlib
> > | - LINK.shared = $(COMPILER) -shared -Wl,-soname,$(soname)
> > | + LINK.shared = $(COMPILER) -shared -Wl
> > | endif
>
> > This cannot possibly be righ
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Trond Eivind Glomsrød writes:
>
> > We have a libtool tuned to work with lots of platforms, like ia64,
> > s390 etc... this makes sure it's used.
>
> We don't use libtool.
Doing so would be a good thing.
> Nor does libtool care about the proces
> > Is there a way to relate this to the names of the databases? Why the
> > change? Or am I missing something key here..
>
> See the thread on the renaming in the archives. In short, this is part
> of Vadim's work on WAL -- the new naming makes certain things easier for
> WAL.
>
> Utilities
Trond Eivind Glomsrød writes:
> We have a libtool tuned to work with lots of platforms, like ia64,
> s390 etc... this makes sure it's used.
We don't use libtool. Nor does libtool care about the processor.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Tom Lane wrote:
> Let me know when you think the 7.1 RPM specfile is stable enough to be
> worth testing, and I'll try to build PPC RPMs.
Ok. Should be coincident with -2. I'm planning to have a -2 out later
this week.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Lamar Owen <[EMAIL PROTECTED]> writes:
>> It is. 7.1 builds cleanly on PPC without any CFLAGS hackery. I think
>> we can even survive the -fsigned-char stupidity now ;-)
> Oh, good. Makes it much cleaner. Care to test that theory? :-)
I already did, I believe, but just in plain builds from s
Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > doing. This is a fix for the broken rpm setup found on Linux-PPC, as
> > found by Tom Lane. It would be marvelous if this would be expendable at
> > this juncture.
> It is. 7.1 builds cleanly on PPC without any CFLAGS hackery. I th
Lamar Owen <[EMAIL PROTECTED]> writes:
>> | %ifarch ppc
>> | NEW_CFLAGS=`echo $CFLAGS|xargs -n 1|grep -v "\-O"|xargs -n 100`
>> | NEW_CFLAGS="$NEW_CFLAGS -O0"
>> This is no longer necessary.
> Depends on the convolutions the particular build of rpm itself is
> doing. This is a fix for the brok
Trond Eivind Glomsrød wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > Peter Eisentraut wrote:
> > > Re: rpm-pgsql-7.1beta3.patch
> > > | diff -uNr postgresql-7.1beta3.orig/src/Makefile.shlib
>postgresql-7.1beta3/src/Makefile.shlib
> > > | - LINK.shared = $(COMPILER) -shared -Wl,-son
bpalmer wrote:
>
> On older versions of PG, 7.0 included, in the $PDGATA/base folder you
> could see the names of the databases for that $PGDATA. Now all I see is:
No longer.
> Is there a way to relate this to the names of the databases? Why the
> change? Or am I missing something key her
Lamar Owen <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
> > Lamar Owen writes:
> > > Ok, I have a first set of 7.1beta3 RPMs uploading now. These RPMs pass
> > > regression on my home RedHat 6.2 machine, which has all locale environment
> > > variables disabled (/etc/sysconfig/i18n dele
On older versions of PG, 7.0 included, in the $PDGATA/base folder you
could see the names of the databases for that $PGDATA. Now all I see is:
$ ls -l
total 16
drwx-- 2 postgres wheel 1536 Jan 12 15:42 1
drwx-- 2 postgres wheel 1536 Jan 12 15:41 18719
drwx-- 2 postgres whee
Peter Eisentraut wrote:
> Lamar Owen writes:
> > Ok, I have a first set of 7.1beta3 RPMs uploading now. These RPMs pass
> > regression on my home RedHat 6.2 machine, which has all locale environment
> > variables disabled (/etc/sysconfig/i18n deleted and a reboot).
> Some thoughts:
> Re: rpm-
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> select * from table_a a
> where ((select data_a from table_a where id = a.id) >
>(select data_b from table_a where id = a.id));
> ERROR: parser: parse error at or near ">"
I think I finally got this right ... see if you can break the rev
Lamar Owen writes:
> Ok, I have a first set of 7.1beta3 RPMs uploading now. These RPMs pass
> regression on my home RedHat 6.2 machine, which has all locale environment
> variables disabled (/etc/sysconfig/i18n deleted and a reboot).
Some thoughts:
Re: rpm-pgsql-7.1beta3.patch
| diff -uNr pos
I use Postgres 7.1, FreeBSD 4.0
I configure, build and install it with:
./configure --enable-locale --enable-multibyte --with-perl
gmake
gmake install
initdb -E KOI8
The problem is: when database encoding and client encoding are
different then 'locale' features, such as 'upper' etc don't work.
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> select * from table_a a
> where ((select data_a from table_a where id = a.id) >
>(select data_b from table_a where id = a.id));
> ERROR: parser: parse error at or near ">"
Ugh. The grammar does some pretty squirrely things with parenth
While below is ok:
select * from table_a a
where (select data_a from table_a where id = a.id) >
(select data_b from table_a where id = a.id);
but this fails:
select * from table_a a
where ((select data_a from table_a where id = a.id) >
(select data_b from table_a wh
[Cc:ed to hackers list]
From: Maneerat Sappaso <[EMAIL PROTECTED]>
Subject: PostgreSQL 7.0.2 with thai locale.
Date: Mon, 15 Jan 2001 16:42:44 -0700 (GMT)
Message-ID: <[EMAIL PROTECTED]>
> Dear sir,
>
> I'm a 4 years student in Burapha University,Thailand
> I develop postgreS
Lamar Owen wrote:
>Ok, I have a first set of 7.1beta3 RPMs uploading now.
... >
>pgaccess currently will not run unless you reconfigure to use -i in the
>startup. This is also being fixed in the RPMset -- there is a change necess
>ary
>in postgresql.config, I just have to do the c
> Instead of a partial row CRC, we could just as well use some other bit
> of identifying information, say the row OID. Given a block CRC on the
> heap page, we'll be pretty confident already that the heap page is OK,
> we just need to guard against the possibility that it's older than the
> ind
39 matches
Mail list logo
