On 1/24/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
Pavan Deolasee wrote:
> I have just counted the number of read/write calls on the CLOG blocks.
As
> you can
> see the total number of CLOG reads jumped from 545323 to 1181851 i.e.
> 1181851 - 545323 = 636528 CLOG block reads for 1554697 p
Tom Lane wrote:
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
I think the proper fix is probably to establish a new eval_context
when we enter an EXCEPTION block, and destroy it again on the way out.
Slightly annoying, but probably small next to the other overhead of
a subtra
Good memory you have and you exactly right.
Yes... the replication is using posgres's normal transactions ie 2 phase
commits and it works like a dream.
When moving data during replication, the locks are happening at record
level, and its intrinsic to the postgres transaction machinery.
ie po
On Wed, 24 Jan 2007 22:27:10 +0100, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> I wrote:
>> The closest I could find is Oracle Text, the full-text search for
>> Oracle.
>
> Oh, and note that Oracle Text is an "extension" and not included in the
> Oracle database product proper.
>
Same with
Pavan Deolasee wrote:
On 1/24/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
Hmm. So there is some activity there. Could you modify the patch to
count how many of those reads came from OS cache? I'm thinking of doing
a gettimeofday() call before and after read, and counting how many
calls fin
Jim C. Nasby wrote:
On Thu, Jan 25, 2007 at 12:52:02AM -0300, Alvaro Herrera wrote:
Jim C. Nasby wrote:
I'll generally start with a cost delay of 20ms and adjust based on IO
utilization.
I've been considering set a default autovacuum cost delay to 10ms; does
this sound reasonable?
The pro
Hm, having skimmed through the Evgen Potemkin's recursive queries patch I find
it quite different from what I was expecting. My own thinking was headed off
in a different direction.
Basically the existing patch reimplements a new kind of join which implements
a kind of nested loop join (with newe
On 1/24/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
Peter Eisentraut wrote:
>> contrib is a horrible misnomer. Can we maybe bite the bullet and call
>> it something else?
> plugins?
How about 'modules' or 'extras' or 'extensions'? :)
standard-plugins might be more informative. I think of th
On 1/25/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
Pavan Deolasee wrote:
>
> Also is it worth optimizing on the total read() system calls which might
> not
> cause physical I/O, but
> still consume CPU ?
I don't think it's worth it, but now that we're talking about it: What
I'd like to d
Ühel kenal päeval, N, 2007-01-25 kell 11:08, kirjutas Gregory Stark:
> Hm, having skimmed through the Evgen Potemkin's recursive queries patch I find
> it quite different from what I was expecting. My own thinking was headed off
> in a different direction.
>
> Basically the existing patch reimplem
Pavan Deolasee wrote:
Another simpler solution for VACUUM would be to read the entire CLOG file
in local memory. Most of the transaction status queries can be satisfied
from
this local copy and the normal CLOG is consulted only when the status is
unknown (TRANSACTION_STATUS_IN_PROGRESS)
The clo
Dawid Kuroczko wrote:
> This is the reason I like 'modules' best. It makes one think that it
> is something maybe part of core, maybe not, but it has been isolated
> into separate entity for maintenance reasons.
On etymological grounds, "modules" would also be my favorite, but the
term "module"
Hi,
Alvaro Herrera wrote:
1. There will be two kinds of processes, "autovacuum launcher" and
"autovacuum worker".
Sounds similar to what I do in Postgres-R: one replication manager and
several "replication workers". Those are called "remote backends" (which
is somewhat of an unfortunate name
On Thu, Jan 25, 2007 at 11:08:14AM +, Gregory Stark wrote:
> b) I do want to be able to support depth-first searching too. I'm not sure how
> to reconcile that with the repeated-join conceptual model. We could always
> resort the entire result set after generating it but that seems like an
> un
I'm looking over the VC build trying to eliminate what warnings are
left. One thing that appears in a couple of places is stuff like:
.\src\bin\psql\print.c(2014): warning C4090: 'function' : different
'const' qualifiers
This happens in psql when we do free() on a variable that's "const char
**".
Looking at the VC warnings, I find that in ECPGDynamicType()
(typename.c in ecpglib), the default branch of the case statement
returns "-type". But the function returns "unsigned int", so returning a
negative value seems very strange to me.
At least it throws a warning in VC++.
//Magnus
---
Magnus Hagander wrote:
> I'm looking over the VC build trying to eliminate what warnings are
> left. One thing that appears in a couple of places is stuff like:
>
> .\src\bin\psql\print.c(2014): warning C4090: 'function' : different
> 'const' qualifiers
>
> This happens in psql when we do free() on
"Peter Eisentraut" <[EMAIL PROTECTED]> writes:
> The code in question is:
>
> const char **headers;
>
> [...]
>
> free(headers);
Perhaps it ought not be declared "const char **headers" if you're planning on
freeing it? I mean, it's not like you can pass an actual pointer to consta
On Thu, Jan 25, 2007 at 01:38:14PM +0100, Peter Eisentraut wrote:
> Magnus Hagander wrote:
> > I'm looking over the VC build trying to eliminate what warnings are
> > left. One thing that appears in a couple of places is stuff like:
> >
> > .\src\bin\psql\print.c(2014): warning C4090: 'function' :
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> I won't claim to know the inners good enough to comment on it. Does
> "const char **" really mean that the point is const, or the pointer that
> it points to is const?
"const char **" means the character at the end of the pointer chain is
constant.
"Martijn van Oosterhout" writes:
> On Thu, Jan 25, 2007 at 11:08:14AM +, Gregory Stark wrote:
>> b) I do want to be able to support depth-first searching too. I'm not sure
>> how
>> to reconcile that with the repeated-join conceptual model. We could always
>> resort the entire result set aft
On Thu, 25 Jan 2007, Magnus Hagander wrote:
> I'm looking over the VC build trying to eliminate what warnings are
> left. One thing that appears in a couple of places is stuff like:
>
> .\src\bin\psql\print.c(2014): warning C4090: 'function' : different
> 'const' qualifiers
Seems like other proje
On Fri, Jan 26, 2007 at 12:26:45AM +1100, Gavin Sherry wrote:
> On Thu, 25 Jan 2007, Magnus Hagander wrote:
>
> > I'm looking over the VC build trying to eliminate what warnings are
> > left. One thing that appears in a couple of places is stuff like:
> >
> > .\src\bin\psql\print.c(2014): warning
On Thu, Jan 25, 2007 at 01:20:10PM +, Gregory Stark wrote:
> "const char **" means the character at the end of the pointer chain is
> constant. Which means my previous message is misguided, ignore it, sorry. In
> short, yes, this is a limitation of the const syntax in C and you have to cast
> i
Current WAL Header uses 32 bytes on a 64-bit CPU. It seems possible to
reduce this to 24 bytes, without reducing resilience, when
full_page_writes = off. This will reduce overall WAL volumes by around
5-15%, depending upon the application with performance gains in various
ways.
If full_page_writes
Simon Riggs wrote:
Current WAL Header uses 32 bytes on a 64-bit CPU. It seems possible to
reduce this to 24 bytes, without reducing resilience, when
full_page_writes = off. This will reduce overall WAL volumes by around
5-15%, depending upon the application with performance gains in various
ways.
Gavin Sherry wrote:
On Thu, 25 Jan 2007, Magnus Hagander wrote:
I'm looking over the VC build trying to eliminate what warnings are
left. One thing that appears in a couple of places is stuff like:
.\src\bin\psql\print.c(2014): warning C4090: 'function' : different
'const' qualifiers
[
Sorry if this is a duplicate -- resending since it hasn't made it to the
list after 1 1/2 hour, possibly due to large attachment (?); here's a
URL instead:
http://www.joeconway.com/das_data_load_failure2.sql.gz
]
We just came upon a crash bug in Postgres >= 8.2. The attached
standalone scrip
Thanks, I've heard that, but in this case won't exactly fit my needs...
..First, I'm working on a PostgreSQL 8.1.4 modification, and it
would be really difficult to add all the changes I've made to the
new version.
...Second, I need to do all this form the backend (Postgres
Source Code). I can't
Discussion "tsearch in core patch, for inclusion" shows
(http://archives.postgresql.org/pgsql-hackers/2007-01/msg01165.php and
following http://archives.postgresql.org/pgsql-hackers/2007-01/msg01186.php)
that there are some problems with contrib promotion and expansion.
I've encountered with bad
On Thu, 2007-01-25 at 14:04 +, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > Current WAL Header uses 32 bytes on a 64-bit CPU. It seems possible to
> > reduce this to 24 bytes, without reducing resilience, when
> > full_page_writes = off. This will reduce overall WAL volumes by around
> >
"Joe Conway" <[EMAIL PROTECTED]> writes:
> psql:/home/jconway/pgsql/das_data_load_failure2.sql:419: PANIC: failed
> to add item to the left sibling for "pk_status_log_2007_01_4_10"
Was this preceded by a WARNING?
Was the server running with a log_min_messages low enough to log WARNINGs?
I pr
Gregory Stark wrote:
"Joe Conway" <[EMAIL PROTECTED]> writes:
psql:/home/jconway/pgsql/das_data_load_failure2.sql:419: PANIC: failed
to add item to the left sibling for "pk_status_log_2007_01_4_10"
Was this preceded by a WARNING?
Was the server running with a log_min_messages low enough t
Stefan Kaltenbrunner wrote:
Gregory Stark wrote:
"Joe Conway" <[EMAIL PROTECTED]> writes:
psql:/home/jconway/pgsql/das_data_load_failure2.sql:419: PANIC: failed
to add item to the left sibling for "pk_status_log_2007_01_4_10"
Was this preceded by a WARNING?
Was the server running with a lo
Joe Conway wrote:
We just came upon a crash bug in Postgres >= 8.2. The attached
standalone script (just needs a database with plpgsql installed)
reproduces the crash for me on 32-bit machines (i686) but NOT on 64 bit
machines (x86_64), for Postgres 8.2 and cvs-head, but not on 8.1. We've
verifie
Folks,
At this moment the following is the list of the unused OIDs. For the
uuid datatype I use a script for generating catalog entries. I can close
some gaps there if the "masters" are okay with this. Are any OIDs
reserved for later or any range can be used in this case?
2 - 9
32
86 - 88
90
100
Nikolay Samokhvalov wrote:
> 1. Change default behaviour of .sql file so it will be
> installed in schema instead of "public" (e.g., "hstore"
> schema will contain all hstore relations and functions).
That might be a good idea in any case.
> 2. Allow running configure with "--with-" (or
> "-
> uuid datatype I use a script for generating catalog entries. I can close
> some gaps there if the "masters" are okay with this. Are any OIDs
> reserved for later or any range can be used in this case?
IMHO, better way is to use some high oids ( for example, starting from 8000 )
and before comm
Gregory Stark wrote:
> "Martijn van Oosterhout" writes:
>
>> On Thu, Jan 25, 2007 at 11:08:14AM +, Gregory Stark wrote:
>>> b) I do want to be able to support depth-first searching too. I'm not sure
>>> how
>>> to reconcile that with the repeated-join conceptual model. We could always
>>> re
Heikki Linnakangas wrote:
Joe Conway wrote:
We just came upon a crash bug in Postgres >= 8.2. The attached
standalone script (just needs a database with plpgsql installed)
reproduces the crash for me on 32-bit machines (i686) but NOT on 64 bit
machines (x86_64), for Postgres 8.2 and cvs-head, bu
Alvaro Herrera wrote:
> Jim C. Nasby wrote:
>
>> I'll generally start with a cost delay of 20ms and adjust based on IO
>> utilization.
>
> I've been considering set a default autovacuum cost delay to 10ms; does
> this sound reasonable?
It really depends on the system. Most of our systems run any
On Thu, Jan 25, 2007 at 10:45:43AM -0400, Luis D. García wrote:
> Well, maybe I didn't make myself clear, this is what I need to do:
>
> I need to know the values of some fields (columns) from the last
> inserted tuple. The problem is that I need to do this in the moment
> I'm inserting a new one
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> ISTM that we would get the effect your looking for by just moving the
> xl_tot_len field to the end, and only storing it for records with backup
> blocks:
I like that formulation better --- seems like less
change-for-the-sake-of-change.
This is a fairly large patch and I would like the chance to review it
before it goes in --- "we'll commit tomorrow" is not exactly a decent
review window.
Not a problem.
One possible argument for this over the contrib version is a saner
approach to dumping and restoring configurations. However
Heikki Linnakangas wrote:
Heikki Linnakangas wrote:
Joe Conway wrote:
We just came upon a crash bug in Postgres >= 8.2. The attached
standalone script (just needs a database with plpgsql installed)
reproduces the crash for me on 32-bit machines (i686) but NOT on 64 bit
machines (x86_64), for Po
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Hmm. There seems to be something wrong in the free space calculation in
> the algorithm for choosing the right split location. I'll dig deeper,
> unless someone beats me to it..
I seem to recall that that part of the code was changed recently, so
the patch. I'm personally not sold on the need for modifications to the
SQL grammar, for example, as opposed to just using a set of SQL-callable
functions and some new system catalogs.
SQL grammar isn't changed significantly - just add variants of CREATE/DROP/ALTER
/COMMENTS commands. Next, fun
Gevik Babakhani <[EMAIL PROTECTED]> writes:
> At this moment the following is the list of the unused OIDs. For the
> uuid datatype I use a script for generating catalog entries. I can close
> some gaps there if the "masters" are okay with this. Are any OIDs
> reserved for later or any range can be
"Nikolay Samokhvalov" <[EMAIL PROTECTED]> writes:
> 1. Change default behaviour of .sql file so it will be
> installed in schema instead of "public" (e.g., "hstore"
> schema will contain all hstore relations and functions).
This might be a good idea, but it's hardly transparent; it can be
count
On Thu, Jan 25, 2007 at 07:52:50PM +0900, Galy Lee wrote:
> It is very hard for any normal user to set this correctly. I think the
> experience / trial-and-error approach is awful for the user, every DBA
> need to be an expert of vacuum to keep the system stable. For vacuum is
> still a big thre
Teodor Sigaev wrote:
>> the patch. I'm personally not sold on the need for modifications to the
>> SQL grammar, for example, as opposed to just using a set of SQL-callable
>> functions and some new system catalogs.
>
> SQL grammar isn't changed significantly - just add variants of
> CREATE/DROP/AL
On Thu, Jan 25, 2007 at 08:04:49AM -0800, Joshua D. Drake wrote:
>
> It really depends on the system. Most of our systems run anywhere from
> 10-25ms. I find that any more than that, Vacuum takes too long.
How do you measure the impact of setting it to 12 as opposed to 15?
-
On 1/25/07, Teodor Sigaev <[EMAIL PROTECTED]> wrote:
It's should clear enough for now - dump data from old db and load into new one.
But dump should be without any contrib/tsearch2 related functions.
Upgrading from 8.1.x to 8.2.x was not tivial because of very trivial
change in API (actually no
On Thu, Jan 25, 2007 at 01:23:57PM +0100, Magnus Hagander wrote:
> Looking at the VC warnings, I find that in ECPGDynamicType()
> (typename.c in ecpglib), the default branch of the case statement
> returns "-type". But the function returns "unsigned int", so returning a
> negative value seems very
On Thu, 2007-01-25 at 11:03 -0500, Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > ISTM that we would get the effect your looking for by just moving the
> > xl_tot_len field to the end, and only storing it for records with backup
> > blocks:
>
> I like that formulation bette
though that we still have the more odd grammar of actually using Tsearch
to query. Although I don't really have a better suggestion without
adding some ungodly obscure operator.
IMHO, best possible solution is 'WHERE table.text_field @ text'.
Operator @ internally makes equivalent of 'to_tsvecto
> The problem with this proposal is that the ISPs aren't the ones running
> configure --- these days, most people are running prebuilt packages
> (RPMs or DEBs or what have you). So what you are hoping is that the
> packagers will choose to do this and thereby force these modules into
> the "stan
Joshua D. Drake wrote:
The problem with this proposal is that the ISPs aren't the ones running
configure --- these days, most people are running prebuilt packages
(RPMs or DEBs or what have you). So what you are hoping is that the
packagers will choose to do this and thereby force these modules
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> I would like to see pgcrypto (or at least some of it's functionality) in
> core.
I believe the reason we keep it separate is so that people can easily
make crypto-free versions of PG for use in countries where encryption
capability is considered
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > That's basically how the existing patch approached the problem. It invents a
> > new type of join and a new type of tuplestore that behaves this way. This
> > has
> > the advantage of working the way Oracle users expect and being relatively
> > s
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Hmm. There seems to be something wrong in the free space calculation in
the algorithm for choosing the right split location. I'll dig deeper,
unless someone beats me to it..
I seem to recall that that part of the code was changed
>> Well perhaps it is time to trim Contrib even further. E.g;
>>
>> Why is ltree still in contrib? What prevents it from being in core?
>
> not sure - ltree is quite useful but I'm not convinced it is really core
> material
Why?
>
>>
>> Why is pgcrypto,pgstattuple and pg_freespacemap in contri
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>> I would like to see pgcrypto (or at least some of it's functionality) in
>> core.
>
> I believe the reason we keep it separate is so that people can easily
> make crypto-free versions of PG for use in countries where encryption
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> I think I found it. The page splitting code didn't take into account
> that when the new item is the first one on the right page, it also
> becomes the high key of the left page.
Good catch! This is something that would not make a difference with
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I believe the reason we keep it separate is so that people can easily
>> make crypto-free versions of PG for use in countries where encryption
>> capability is considered subject to arms regulations. Not sure how
>> important that
> You miss the point. Everybody knows that those laws are not too hard
> to circumvent if you are willing to break the law. The question is
> how hard is it for someone to distribute Postgres into one of those
> countries *without* breaking any local law. We won't be making things
> better if w
On Thu, 25 Jan 2007, Nikolay Samokhvalov wrote:
On 1/25/07, Teodor Sigaev <[EMAIL PROTECTED]> wrote:
It's should clear enough for now - dump data from old db and load into new
one.
But dump should be without any contrib/tsearch2 related functions.
Upgrading from 8.1.x to 8.2.x was not tivial
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> I'm afraid the bug has been there for ages, but the 90%-fillfactor on
> rightmost page patch made it much more likely to get triggered.
But that patch has been there for ages too; the only new thing in 8.2 is
that the fillfactor is configurable, bu
decibel=# select version();
PostgreSQL 8.3devel on i386-apple-darwin8.8.2, compiled by GCC
i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5363)
decibel=# select box '((0,0),(2,2))' ~ point '(1,1)';
ERROR: operator does not exist: box ~ point
LINE 1: select box '((0,0),(2,2
On Thu, 25 Jan 2007, Joshua D. Drake wrote:
The problem with this proposal is that the ISPs aren't the ones running
configure --- these days, most people are running prebuilt packages
(RPMs or DEBs or what have you). So what you are hoping is that the
packagers will choose to do this and ther
Oleg Bartunov wrote:
> On Thu, 25 Jan 2007, Joshua D. Drake wrote:
>
>>
>>> The problem with this proposal is that the ISPs aren't the ones running
>>> configure --- these days, most people are running prebuilt packages
>>> (RPMs or DEBs or what have you). So what you are hoping is that the
>>> p
Joshua D. Drake wrote:
> Tom Lane wrote:
> > Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> >> I would like to see pgcrypto (or at least some of it's
> >> functionality) in core.
> >
> > I believe the reason we keep it separate is so that people can
> > easily make crypto-free versions of PG fo
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Oleg Bartunov wrote:
>> we have several requests to improve ltree, particularly, people want
>> to expand class of allowed symbols and configurable separator, which is
>> hard-coded right now. Also, we discussed GiN support for ltree.
> O.k. but how
FWIW:
> * Better packaging support, eg make it easier to add/remove an extension
> module and control how pg_dump deals with it. We talked about that
> awhile back but nobody did anything with the ideas.
+1
> * Better documentation for the contrib modules; some of them are
> reasonably well do
Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> Oleg Bartunov wrote:
>>> we have several requests to improve ltree, particularly, people want
>>> to expand class of allowed symbols and configurable separator, which is
>>> hard-coded right now. Also, we discussed GiN support for l
Joshua D. Drake wrote:
> Tom Lane wrote:
>> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>>> Oleg Bartunov wrote:
we have several requests to improve ltree, particularly, people want
to expand class of allowed symbols and configurable separator, which is
hard-coded right now. Also,
Why is ltree still in contrib? What prevents it from being in core?
Nothing. But I don't see any advantage of placing it in core - it changes
nothing in SQL, API or feature. Moving tsearch2 into core allows to manage
configuration with nice SQL API, using SysCache, automatical rereading
diction
> I don't think two releases from API change to API change is enough -
> postgresql is running larger and larger databases by now and I expect
> people to upgrade less often in the future (and iirc you already said
> something along the lines of recommending such things on occasion to
> your custo
Teodor Sigaev wrote:
>> Why is ltree still in contrib? What prevents it from being in core?
> Nothing. But I don't see any advantage of placing it in core - it
> changes nothing in SQL, API or feature. Moving tsearch2 into core allows
> to manage configuration with nice SQL API, using SysCache, aut
This might be a good idea, but it's hardly transparent; it can be
counted on to break the applications of just about everyone using those
modules today.
Hmm, can we make separate schema for all contib modules and include it in
default search_path? It will not touchs most users.
--
Teodor Siga
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
I'm afraid the bug has been there for ages, but the 90%-fillfactor on
rightmost page patch made it much more likely to get triggered.
But that patch has been there for ages too; the only new thing in 8.2 is
that the fillfactor is c
Teodor Sigaev wrote:
>> This might be a good idea, but it's hardly transparent; it can be
>> counted on to break the applications of just about everyone using those
>> modules today.
>
> Hmm, can we make separate schema for all contib modules and include it
> in default search_path? It will not to
Joshua D. Drake wrote:
Teodor Sigaev wrote:
This might be a good idea, but it's hardly transparent; it can be
counted on to break the applications of just about everyone using those
modules today.
Hmm, can we make separate schema for all contib modules and include it
in default search
In a thread in July last year, I raised the possibility of transforming
a query to allow functional indexes to be utilised automatically.
http://archives.postgresql.org/pgsql-hackers/2006-07/msg00323.php
This idea can work and has many benefits, but there are some
complexities. I want to summarise
On 1/25/07, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
decibel=# select version();
PostgreSQL 8.3devel on i386-apple-darwin8.8.2, compiled by GCC
i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5363)
decibel=# select box '((0,0),(2,2))' ~ point '(1,1)';
ERROR: operator does
The author of this bug was good enough to send me a copy, since I don't
normally read the -bugs list. It can now be found at
http://archives.postgresql.org/pgsql-bugs/2007-01/msg00111.php .
I dug into it a bit and found that pltcl and plpython appear to use
almost identical code, but only pl
On 1/18/2007 10:35 AM, Tom Lane wrote:
<[EMAIL PROTECTED]> writes:
Many of the keywords listed in keywords.c are defined with symbolic
names that end in '_P' (underscore P).
What differentiates those keywords from the other keywords? What does
the 'P' stand for?
P = Parser. The reason for th
I have had to reverse out this patch because Py_RETURN_TRUE is only
supported in Python versions >= 2.3, and we support older versions. I
did add a comment:
* We would like to use Py_RETURN_TRUE and Py_RETURN_FALSE here for
* generating SQL from trigger functions, but those are only
*
> > Some years ago there was discussion of consistently P-ifying *all* those
> > macros, but it didn't get done; I think Thomas or somebody objected that
> > it would make gram.y needlessly harder to read.
>
> Are there many people who read gram.y on a regular base?
I can't seem to put it down :
I wrote:
I see that SQL level prepare calls regprocin() to resolve type names,
so maybe we should that for the PLs when calling SPI_prepare as well.
Of course, that should be regtypein()
cheers
andrew
---(end of broadcast)---
TIP 9: In vers
Tom Lane wrote:
> [EMAIL PROTECTED] (Bruce Momjian) writes:
> > Fix for plpython functions; return true/false for boolean,
>
> This patch has broken a majority of the buildfarm.
Yea, reverted with comment added.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.c
Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> I see that SQL level prepare calls regprocin() to resolve type names,
>> so maybe we should that for the PLs when calling SPI_prepare as well.
> Of course, that should be regtypein()
[ squint... ] build_regtype_array seems a rather stupid bit of code
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> A simpler, alternate proposal is to allow the user to specify whether a
> functional index is transformable or not using CREATE or ALTER INDEX,
> with a default of not transformable. That then leaves the responsibility
> for specifying this with the user,
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I dug into it a bit and found that pltcl and plpython appear to use
> almost identical code, but only pltcl has this limitation documented.
> I'm inclined to say we should document this for plperl and plpython for
> stable releases and remove the limi
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I see that SQL level prepare calls regprocin() to resolve type names,
so maybe we should that for the PLs when calling SPI_prepare as well.
Of course, that should be regtypein()
[ squint... ] build_regtype_array seems
Markus Schiltknecht wrote:
Hi Markus,
>
> Alvaro Herrera wrote:
> >1. There will be two kinds of processes, "autovacuum launcher" and
> >"autovacuum worker".
>
> Sounds similar to what I do in Postgres-R: one replication manager and
> several "replication workers". Those are called "remote bac
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I dug into it a bit and found that pltcl and plpython appear to use
almost identical code, but only pltcl has this limitation documented.
I'm inclined to say we should document this for plperl and plpython for
stable releases and re
Jim C. Nasby wrote:
> On Mon, Jan 22, 2007 at 12:17:39PM -0800, Ron Mayer wrote:
> > Gregory Stark wrote:
> > >
> > > Actually no. A while back I did experiments to see how fast reading a file
> > > sequentially was compared to reading the same file sequentially but
> > > skipping
> > > x% of the
On Thu, Jan 25, 2007 at 01:59:33PM -0500, Merlin Moncure wrote:
> On 1/25/07, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
> >decibel=# select version();
> > PostgreSQL 8.3devel on i386-apple-darwin8.8.2, compiled by GCC
> > i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5363)
> >
Is there a TODO here?
---
Heikki Linnakangas wrote:
> Pavan Deolasee wrote:
> > Another simpler solution for VACUUM would be to read the entire CLOG file
> > in local memory. Most of the transaction status queries can be sat
1 - 100 of 123 matches
Mail list logo
