On Mon, Feb 14, 2005 at 12:47:44PM +0500, Sibtay Abbas wrote:
Is it possible to get the oid of a function on the basis of its name?.
One way is to cast the function name to regproc (or, with arguments,
to regprocedure) and then to oid:
SELECT 'atan'::regproc::oid;
SELECT
Just got reminded...
Is there a way for a C function to determine the name of the schema in which is
was created?
... John
---(end of broadcast)---
TIP 8: explain analyze is your friend
Tom == Tom Lane [EMAIL PROTECTED] writes:
Tom and changing the buf_table hash table. The only common
Tom operation that needs exclusive lock is reading in a page that
Tom was not in shared buffers already, which will require at
Tom least a kernel call and usually a wait for I/O,
Oliver Jowett wrote:
I'm currently trying to find a clean way to deal with network-dead
clients that are in a transaction and holding locks etc.
The normal client closes socket case works fine. The scenario I'm
worried about is when the client machine falls off the network entirely
for some
On Mon, Feb 14, 2005 at 07:32:15PM +1100, John Hansen wrote:
Is there a way for a C function to determine the name of the
schema in which is was created?
Dunno if there's anything as simple as whats_my_schema(), but
fcinfo-flinfo-fn_oid should contain the function's oid. If nobody
mentions
Richard Huxton wrote:
Oliver Jowett wrote:
I'm currently trying to find a clean way to deal with network-dead
clients that are in a transaction and holding locks etc.
Have you come across the pgpool connection-pooling project?
http://pgpool.projects.postgresql.org/
I've looked at it, haven't
Hi folks,
I ran into big trouble - it seems that my DB is lost.
select * from pg_database gives me 0 rows, but I still can connect to
databases with \c and even select from tables there, although they're also
not visible with \dt.
After asking the guys in the [EMAIL PROTECTED] channel they told
thank you for the detailed reply
But what i wanted to know is that how can we actually get a function's
oid from its
name from within postgresql code itself
Actually i ve introduced a new statement in plpgsql, that supports calling
a plpgsql function from within a plpgsql function for example
Probably off-topic, but I think it's worth to see what astronomers are
doing with their very big spatial databases. For example, we are working
with more than 500,000,000 rows catalog and we use some special
transformation
of coordinates to integer numbers with preserving objects closeness.
Michael Fuhr [EMAIL PROTECTED] writes:
On Mon, Feb 14, 2005 at 07:32:15PM +1100, John Hansen wrote:
Is there a way for a C function to determine the name of the
schema in which is was created?
Dunno if there's anything as simple as whats_my_schema(), but
fcinfo-flinfo-fn_oid should contain
8.0.X will have proper filename reporting for rmtree() failures.
---
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
[ looks at code... ] dbcommands.c is expecting that rmtree() will have
Kouber Saparev [EMAIL PROTECTED] writes:
After asking the guys in the [EMAIL PROTECTED] channel they told
me that the reason is the Transaction ID wraparound, because I have never
ran VACUUM on the whole database.
So they proposed to ask here for help. I have stopped the server, but what
Once you've found a NextXID setting you like, I'd suggest an immediate
pg_dumpall/initdb/reload to make sure you have a consistent set of data.
Don't VACUUM, or indeed modify the DB at all, until you have gotten a
satisfactory dump.
Then put in a cron job to do periodic vacuuming ;-)
Thank
I think you're pretty well screwed as far as getting it *all* back goes,
but you could use pg_resetxlog to back up the NextXID counter enough to
make your tables and databases reappear (and thereby lose the effects of
however many recent transactions you back up over).
Once you've found a NextXID
[EMAIL PROTECTED] wrote:
You know, I don't think a lot of people get the issues I was describing,
or maybe they don't believe it, I don't know, but, I think that it would
be a useful contrib project to create an 'analyze_special('table',
'column', 'method')' function that does a better job at
It must be possible to create a tool based on the PostgreSQL sources that
can read all the tuples in a database and dump them to a file stream. All
the data remains in the file until overwritten with data after a vacuum.
It *should* be doable.
If there data in the table is worth anything, then it
I think you're pretty well screwed as far as getting it *all* back goes,
but you could use pg_resetxlog to back up the NextXID counter enough to
make your tables and databases reappear (and thereby lose the effects of
however many recent transactions you back up over).
Once you've found a
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
This might seem like a stupid question, but since this is a massive
data loss potential in PostgreSQL, what's so hard about having the
checkpointer or something check the transaction counter when it runs
and either issue a db-wide vacuum if
On Mon, Feb 14, 2005 at 11:11:53AM -0500, Tom Lane wrote:
In C, it'd be a lot easier (and faster) to do a couple of SearchSysCache
calls than to use SPI to get those rows.
The following appears to work -- does it look right, aside from the
missing error checking?
tuple =
On Mon, Feb 14, 2005 at 05:02:19PM +0500, Sibtay Abbas wrote:
Actually i ve introduced a new statement in plpgsql, that supports calling
a plpgsql function from within a plpgsql function for example
CALL function_name( params);
How would this differ from PERFORM?
--
Michael Fuhr
Michael Fuhr [EMAIL PROTECTED] writes:
On Mon, Feb 14, 2005 at 11:11:53AM -0500, Tom Lane wrote:
In C, it'd be a lot easier (and faster) to do a couple of SearchSysCache
calls than to use SPI to get those rows.
The following appears to work -- does it look right, aside from the
missing error
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
This might seem like a stupid question, but since this is a massive data
loss potential in PostgreSQL, what's so hard about having the
checkpointer or something check the transaction counter when it runs and
either issue a db-wide vacuum
On Thu, 2005-02-10 at 14:37 -0500, Bruce Momjian wrote:
No, we feel that is of limited value. If the optimizer isn't doing
things properly, we will fix it.
I agree that improving the optimizer is the right answer for normal
usage, so I can't get excited about query-level plan hints, but I
Beautiful, just what I was looking for.
Thnx,
John
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 15, 2005 6:31 AM
To: Michael Fuhr
Cc: John Hansen; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Schema name of function
Michael Fuhr
FYI, core has discussed the pending IBM ARC patent and the usage of
those ideas in 8.0.
Tom has found a 2Q cache algorithm that predates the ARC patent and is
very similar to ARC. The major difference is that it doesn't auto-size
the ARC sub-buffers.
Core believes it is best to backpatch this
This thread has been saved for the 8.1 release:
http://momjian.postgresql.org/cgi-bin/pgpatches2
---
ITAGAKI Takahiro wrote:
Hello, all.
I think that there is room for improvement in WAL.
Here is a patch for
Might it be possible to contact IBM directly and ask if they will allow
usage of the patent for PostgreSQL. They've let 500 patents for open
source, maybe they'll give a write off for this as well.
There is an advantage beyond just not having to re-write the code, but it
would also be sort of an
[EMAIL PROTECTED] wrote:
Might it be possible to contact IBM directly and ask if they will allow
usage of the patent for PostgreSQL. They've let 500 patents for open
source, maybe they'll give a write off for this as well.
There is an advantage beyond just not having to re-write the code,
Should our multi-byte encoding be referred to as UTF8 or Unicode?
I know UTF8 is a type of unicode but do we need to rename anything from
Unicode to UTF8?
Someone asked me via private email.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us
[EMAIL PROTECTED] wrote:
Might it be possible to contact IBM directly and ask if they will allow
usage of the patent for PostgreSQL. They've let 500 patents for open
source, maybe they'll give a write off for this as well.
There is an advantage beyond just not having to re-write the code,
At 2005-02-14 21:14:54 -0500, pgman@candle.pha.pa.us wrote:
Should our multi-byte encoding be referred to as UTF8 or Unicode?
The *encoding* should certainly be referred to as UTF-8. Unicode is a
character set, not an encoding; Unicode characters may be encoded with
UTF-8, among other things.
Bruce Momjian wrote:
[EMAIL PROTECTED] wrote:
Might it be possible to contact IBM directly and ask if they will allow
usage of the patent for PostgreSQL. They've let 500 patents for open
source, maybe they'll give a write off for this as well.
There is an advantage beyond just not having to
Joshua D. Drake wrote:
Bruce Momjian wrote:
[EMAIL PROTECTED] wrote:
Might it be possible to contact IBM directly and ask if they will allow
usage of the patent for PostgreSQL. They've let 500 patents for open
source, maybe they'll give a write off for this as well.
There is an
Abhijit Menon-Sen wrote:
At 2005-02-14 21:14:54 -0500, pgman@candle.pha.pa.us wrote:
Should our multi-byte encoding be referred to as UTF8 or Unicode?
The *encoding* should certainly be referred to as UTF-8. Unicode is a
character set, not an encoding; Unicode characters may be encoded
I have added this syntax to the TODO list:
* Allow GRANT/REVOKE permissions to be applied to all schema objects with one
command
The proposed syntax is:
GRANT SELECT ON ALL TABLES IN public TO phpuser;
GRANT SELECT ON NEW TABLES IN public TO phpuser;
Manfred Koizar wrote:
On Wed, 19 Jan 2005 18:57:48 +0100, I wrote:
My first vacuum.c
refactoring patch, rev 1.281 2004-06-08, added these comments in
repair_frag():
/*
* VACUUM FULL has an exclusive lock on the relation. So
* normally no other transaction can have pending INSERTs or
On Mon, 2005-02-14 at 17:02 +0500, Sibtay Abbas wrote:
thank you for the detailed reply
But what i wanted to know is that how can we actually get a function's
oid from its
name from within postgresql code itself
You'll want to query the syscache. Note that due to function
overloading, there
[EMAIL PROTECTED] writes:
I think that is sort of arrogant. Look at Oracle, you can give the planner
hints in the form of comments.
Arrogant or not, that's the general view of the people who work on the
planner.
The real issue is not so much whether the planner will always get things
right ---
Tom Lane wrote:
[EMAIL PROTECTED] writes:
I think that is sort of arrogant. Look at Oracle, you can give the planner
hints in the form of comments.
Arrogant or not, that's the general view of the people who work on the
planner.
The real issue is not so much whether the planner will
[EMAIL PROTECTED] writes:
Might it be possible to contact IBM directly and ask if they will allow
usage of the patent for PostgreSQL. They've let 500 patents for open
source, maybe they'll give a write off for this as well.
If there were hard evidence that the ARC algorithm was far better than
This has been saved for the 8.1 release:
http://momjian.postgresql.org/cgi-bin/pgpatches2
---
John Hansen wrote:
Hi list,
Attached for your perusal, unicode versions of upper/lower, that work
independent of
Tom Lane wrote:
[EMAIL PROTECTED] writes:
Might it be possible to contact IBM directly and ask if they will allow
usage of the patent for PostgreSQL. They've let 500 patents for open
source, maybe they'll give a write off for this as well.
If there were hard evidence that the ARC
This has been saved for the 8.1 release:
http://momjian.postgresql.org/cgi-bin/pgpatches2
---
ITAGAKI Takahiro wrote:
Hello everyone.
I fixed two bugs in the patch that I sent before.
Check and test new one,
On Mon, 2005-02-14 at 22:56 -0500, Bruce Momjian wrote:
And the user maintenance of updating those hints for every release of
PostgreSQL as we improve the database engine.
... and maintaining those hints as the data changes over time.
But I think this thread has been hijacked toward a subject
[EMAIL PROTECTED] writes:
I think that is sort of arrogant. Look at Oracle, you can give the
planner
hints in the form of comments.
Arrogant or not, that's the general view of the people who work on the
planner.
The real issue is not so much whether the planner will always get things
I will be on Boston for Linuxworld from Tuesday through Thursday. I
will read email only occasionally.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+
Bruce Momjian pgman@candle.pha.pa.us writes:
And ARC has locking requirements that will make it very hard to fix our
SMP buffer management problems in 8.1.
I am working on a buffer manager rewrite using the BufMgrLock breakup
and clock sweep management algorithm we've been discussing. At the
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Might it be possible to contact IBM directly and ask if they will allow
usage of the patent for PostgreSQL. They've let 500 patents for open
source, maybe they'll give a write off for this as well.
There is an advantage beyond just not having to
Neil Conway [EMAIL PROTECTED] writes:
- good, thorough documentation of the internals (naturally this would
help attract OSS developers as well)
I don't know what software you work with but the Postgres source is far and
away the best documented source I've had the pleasure to read. I think
Although this is all true, consider that adding hints will mean that the
Pg developers *never* get bug reports to drive the optimizer improvement
process. This will have the effect of stagnating its development. I
think this would be a bad thing :-)
As an aside note that DB2 UDB does not let you
50 matches
Mail list logo
