Ted Petrosky wrote:
I am trying to create the libpq.a as a universal binary (both ppc and
intel macs). Does anyone have any information on this process?
I use the following notes to build libpq and the bin/ tools to ship with
pgAdmin. I know it is possible to build the entire server, as a
Hi,
The short summary that I use for .a files is:
Build on PPC
Build on Intel
On either run
lipo -create lib/libpq.a ../ppc/lib/libpq.a ../intel/lib/libpq.a
Before a
file libpq.a
shows
libpq.a: current ar archive
After lipo it shows:
libpq.a: Mach-O fat file with 2 architectures
Hello,
From: Jim C. Nasby [EMAIL PROTECTED]
Also, I have a dumb question... BgBufferSync uses buf_id1 to keep
track
of what buffer the bgwriter_all scan is looking at, which means that
it should remember where it was at the end of the last scan; yet
it's
initialized to 0 every time
Is there a big reason why TOAST tables are called such cryptic names?
e.g. pg_toast.pg_toast_16399
Wouldn't it be more pleasant to have them called the same thing as their
parent
e.g. pg_toast.name_toast
This would be very convenient for most purposes, though it would mean
we'd have to do
Hi,
Is anyone working on plan invalidation? I might take a stab at it during
the 8.3 cycle. I haven't given it any thought yet, I thought I'd check
first to avoid duplicate work.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of
Ted Petrosky wrote:
Thanks for the reply at last nights cocoahead meeting in NYC I asked
and found a solution for libpq.a.
1. config and make on a ppc
2. config and make on intel
copy and rename the libpq.a from each system to a common directory and
run 'lipo' on them:
lipo libpqppc.a
On Wed, 13 Dec 2006 11:29:44 +, Simon Riggs [EMAIL PROTECTED] wrote:
Is there a big reason why TOAST tables are called such cryptic names?
e.g. pg_toast.pg_toast_16399
Wouldn't it be more pleasant to have them called the same thing as their
parent
e.g. pg_toast.name_toast
Wouldn't
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
We change libpq from time to time. Besides, how many DBs are there that
match the name pattern /^conn:.*=/ ? My guess is mighty few. So I don't
expect lots of surprise.
Um, but how many DB names have an = in them at all?
Andrew - Supernews [EMAIL PROTECTED] writes:
You're suffering from a fundamental confusion between the ltcmp/rtcmp
operators (which indeed must be trichotomous with the join operator)
and the sort operators.
[ thinks for awhile... ] OK, you have a point, but if we want to take
that seriously
Gurjeet Singh [EMAIL PROTECTED] writes:
In ExplainOnePlan(), we are calling ExecutorStart() and ExecutorEnd()
even if we are not doing EXPLAIN ANALYZE. Whereas, ExecutorRun() is called
only if we are ANALYZEing.
Can we avoid calls to Executor{Start|End}() here, or is it necessary to
On 12/13/06, Tom Lane [EMAIL PROTECTED] wrote:
Gurjeet Singh [EMAIL PROTECTED] writes:
Can we avoid calls to Executor{Start|End}() here, or is it necessary
to
call them even for non-ANALYZE case?
No; at least not unless you want to duplicate the permission-checking
machinery inside
Heikki Linnakangas [EMAIL PROTECTED] writes:
Is anyone working on plan invalidation? I might take a stab at it during
the 8.3 cycle. I haven't given it any thought yet, I thought I'd check
first to avoid duplicate work.
I'd been planning to tackle it too, but would be happy to let someone
Gurjeet Singh [EMAIL PROTECTED] writes:
On 12/13/06, Tom Lane [EMAIL PROTECTED] wrote:
No; at least not unless you want to duplicate the permission-checking
machinery inside ExecutorStart.
I had seen the ExecCheckRTPerms() call inside InitPlan(), but didn't know
that we considered even the
On Tue, 12 Dec 2006, Albe Laurenz wrote:
Date: Tue, 12 Dec 2006 16:42:50 +0100
From: Albe Laurenz [EMAIL PROTECTED]
To: ohp@pyrenet.fr, pgsql-hackers list pgsql-hackers@postgresql.org,
[EMAIL PROTECTED]
Subject: RE: [HACKERS] unixware and --with-ldap
Olivier PRENANT wrote:
When I
Hi Tom,
I was in the process of testing this. But I believe tweaking with
configure.in will not help me as I have no way to regenerate configure...
Please advise.
Best regards,
On Tue, 12 Dec 2006, Tom Lane wrote:
Date: Tue, 12 Dec 2006 11:04:08 -0500
From: Tom Lane [EMAIL PROTECTED]
To:
ohp@pyrenet.fr writes:
I was in the process of testing this. But I believe tweaking with
configure.in will not help me as I have no way to regenerate configure...
Install autoconf; it's no big deal.
regards, tom lane
---(end of
On Wed, 2006-12-13 at 04:23 +, Andrew - Supernews wrote:
While testing a PITR recovery, I discovered that recovery.conf doesn't
seem to allow specifying ' in the command string, making it hard to
protect the restore_command against problematic filenames (whitespace
etc.). This doesn't seem
On Wed, Dec 13, 2006 at 06:27:38PM +0900, Takayuki Tsunakawa wrote:
No. BgBufferSync() correctly keeps track of the position to restart
scanning at. bufid1 is not initialized to 0 every time BgBufferSync()
is called, because bufid1 is a static local variable. Please see the
following code. It
I've written up a Warm Standby script as a .c program rather than
scripts, to allow it to be portable and potentially shipped as part of
PostgreSQL core.
pg_standby is designed to be a wait-for restore_command, required to
turn a normal archive recovery into a Warm Standby. Within the
On Mon, Dec 11, 2006 at 12:24:12AM +0100, Peter Eisentraut wrote:
Simon Riggs wrote:
Well, I'd like a way of making EXPLAIN ANALYZE return something
useful within a reasonable amount of time. We can define that as the
amount of time that the user considers is their goal for the query.
On Wed, 2006-12-13 at 19:28 +, Simon Riggs wrote:
On Wed, 2006-12-13 at 04:23 +, Andrew - Supernews wrote:
While testing a PITR recovery, I discovered that recovery.conf doesn't
seem to allow specifying ' in the command string, making it hard to
protect the restore_command against
On Tue, 2006-12-12 at 18:54 -0500, Gregory Stark wrote:
A brief explanation including an example regression test (the SAVEPOINT
locking bug discovered recently) and the patch here:
http://community.enterprisedb.com/concurrent/index.html
One of the original inspirations for this was the
Thumbs up on this from a lurker.
I recall a previous post about some sort of progress bar hack that
would show you where in a plan a currently executing query was at. Has
any work been done on this?
Josh Reich
Jim C. Nasby wrote:
On Mon, Dec 11, 2006 at 12:24:12AM +0100, Peter Eisentraut
On Mon, Dec 11, 2006 at 12:08:30PM -0500, Tom Lane wrote:
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Short version: is it optimal for vacuum to always populate reltuples
with live rows + dead rows?
If we didn't do that, it would tend to encourage the use of seqscans on
tables with lots
After further thought about the mergejoinable-operators issue and some
other longstanding planner problems, I have a modest proposal to make:
we should invent the notion of operator class groups, which identify
sets of compatible operator classes. (I'm not wedded to the name class
group; it seems
I wrote:
The real question on the table is whether it's worth distinguishing
between mergejoinable equality operators and transitive equality
operators. I suggest that it probably isn't --- do you have any
examples with more real-world application than the x = 2y case?
The proposal I just
Jim C. Nasby [EMAIL PROTECTED] writes:
On Mon, Dec 11, 2006 at 12:08:30PM -0500, Tom Lane wrote:
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Short version: is it optimal for vacuum to always populate reltuples
with live rows + dead rows?
If we didn't do that, it would tend to encourage
On Wed, Dec 13, 2006 at 04:27:09PM -0500, Tom Lane wrote:
After further thought about the mergejoinable-operators issue and some
other longstanding planner problems, I have a modest proposal to make:
we should invent the notion of operator class groups, which identify
sets of compatible
Simon Riggs [EMAIL PROTECTED] writes:
OK, I would propose to extend the guc-file.l to include sufficient code
to allow the parsing of the conf files to be identical between the
postgresql.conf and the recovery.conf (it isn't the same yet).
It would probably be far easier for long-term
Martijn van Oosterhout kleptog@svana.org writes:
On Wed, Dec 13, 2006 at 04:27:09PM -0500, Tom Lane wrote:
we should invent the notion of operator class groups, which identify
sets of compatible operator classes.
I think it's a good idea, though I would point out that in the examples
given
I'd love to see your program. Could you please submit to -pacthes?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
I've written up a Warm Standby script as a .c program rather than
scripts, to allow it to be portable and potentially shipped as part of
PostgreSQL core.
pg_standby is designed to be a
I wrote:
We further require that any given opclass be a member of at most one class
group (this simplifies matters, and there isn't any application I can see
for one opclass being in more than one group), and that a class group
contain at most one opclass for a given datatype (ditto).
BTW, I
On 2006-12-13, Simon Riggs [EMAIL PROTECTED] wrote:
On Wed, 2006-12-13 at 19:28 +, Simon Riggs wrote:
On Wed, 2006-12-13 at 04:23 +, Andrew - Supernews wrote:
While testing a PITR recovery, I discovered that recovery.conf doesn't
seem to allow specifying ' in the command string,
[ replying to myself again, how tacky :-( ]
I wrote:
BTW, I forgot to mention one of the motivations for that last
restriction: I'm thinking it would be convenient to allow index
declarations to accept either an opclass name or a class group name.
Thus you could say pattern_ops instead of
Andrew - Supernews [EMAIL PROTECTED] writes:
That only helps if you can trust %p not to contain whitespace or $. If it
is always relative to somewhere in the data dir then this is probably ok,
but if it's an absolute path then you can't assume that.
It is relative, so I think this is actually
Simon Riggs wrote:
I've written up a Warm Standby script as a .c program rather than
scripts, to allow it to be portable and potentially shipped as part of
PostgreSQL core.
Great! It'll make the DBA's work much easier, could help the adoption of
PITR (nowadays people thinks it's to
Euler Taveira de Oliveira [EMAIL PROTECTED] writes:
Simon Riggs wrote:
Should this be reworked as an src/bin program? Or is the contrib module
the best form for this in 8.3?
Please submit it to -patches. IMHO it should stay in src/bin because
it'll be part of a solution that is tightly
For those of you with a long memory, I found Al Dev's resume in MS Word
format:
http://www.devan.8k.com/resume-msword.doc
Seems he is lives or lived in Texas.
---
- Forwarded message from Al_Dev -
Simon Riggs wrote:
I've also written a test program that uses this. I'm using this on a
server at EDB to run a continuous Warm Standby test.
Would anybody consider this test script worth including somewhere in
core? and/or: Might it become part of the build farm?
Buildfarm automatically
Olivier PRENANT wrote:
When I swithed to the newest version og pgbuildfarm, I noticed that
--with-ldap (now by defaut) didn't work on UnixWare.
This is because, on Unixware, ldap needs lber and resolv.
Or was libldap not linked against liblber and libresolv?
Dunno!
Did'nt do it myself,
40 matches
Mail list logo
