Ühel kenal päeval, N, 2007-01-25 kell 22:19, kirjutas Jan Wieck:
> Granted this one has a few open ends so far and I'd like to receive some
> constructive input on how to actually implement it.
>
> The idea is to clone an existing serializable transactions snapshot
> visibility information from
On 1/25/2007 11:41 PM, Bruce Momjian wrote:
Jan Wieck wrote:
On 1/25/2007 6:49 PM, Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
>> To provide this data, I would like to add another "log" directory,
>> pg_tslog. The files in this directory will be similar to the clog, but
>> contain
Jan Wieck wrote:
> On 1/25/2007 6:49 PM, Tom Lane wrote:
> > Jan Wieck <[EMAIL PROTECTED]> writes:
> >> To provide this data, I would like to add another "log" directory,
> >> pg_tslog. The files in this directory will be similar to the clog, but
> >> contain arrays of timestamptz values.
> >
>
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Jim C. Nasby wrote:
> >> If we extended relations by more than one page at a time we'd probably
> >> have a better shot at the blocks on disk being contiguous and all read
> >> at the same time by the OS.
>
> > Actually, there is evid
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Jim C. Nasby wrote:
>> If we extended relations by more than one page at a time we'd probably
>> have a better shot at the blocks on disk being contiguous and all read
>> at the same time by the OS.
> Actually, there is evidence that adding only a single
Granted this one has a few open ends so far and I'd like to receive some
constructive input on how to actually implement it.
The idea is to clone an existing serializable transactions snapshot
visibility information from one backend to another. The semantics would
be like this:
backend1:
On 1/25/2007 8:42 PM, Richard Troy wrote:
On Thu, 25 Jan 2007, Jan Wieck wrote:
For a future multimaster replication system, I will need a couple of
features in the PostgreSQL server itself. I will submit separate
proposals per feature so that discussions can be kept focused on one
feature per
On Thu, 25 Jan 2007, Jan Wieck wrote:
>
> For a future multimaster replication system, I will need a couple of
> features in the PostgreSQL server itself. I will submit separate
> proposals per feature so that discussions can be kept focused on one
> feature per thread.
Hmm... "will need" ... Hav
On 1/25/2007 7:33 PM, Tom Lane wrote:
1 fires always
0 fires never
N fires in "Normal" mode
R fires in "Replica" mode
other letters available for other future mode values?
If you consistently think of "origin" and "replica" modes th
On 1/25/2007 7:41 PM, Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
On 1/25/2007 6:47 PM, Neil Conway wrote:
Would this feature have any use beyond the specific project/algorithm
you have in mind?
The tablelog project on pgfoundry currently uses the transactions start
time but would
On 1/25/2007 6:49 PM, Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
To provide this data, I would like to add another "log" directory,
pg_tslog. The files in this directory will be similar to the clog, but
contain arrays of timestamptz values.
Why should everybody be made to pay this
Jan Wieck <[EMAIL PROTECTED]> writes:
> On 1/25/2007 6:47 PM, Neil Conway wrote:
>> Would this feature have any use beyond the specific project/algorithm
>> you have in mind?
> The tablelog project on pgfoundry currently uses the transactions start
> time but would be very delighted to have the c
Jan Wieck <[EMAIL PROTECTED]> writes:
>>> A fires always
>>> N fires never
>>> O fires on transaction origin only
>>> R fires on replica only
> Good question. I don't know. I'd rather error on the safe side and make
> it multiple states, for now I only have Normal and Replica mode.
Hm, "
On 1/25/2007 6:47 PM, Neil Conway wrote:
On Thu, 2007-01-25 at 18:16 -0500, Jan Wieck wrote:
For conflict resolution purposes in an asynchronous multimaster system,
the "last update" definition often comes into play. For this to work,
the system must provide a monotonically increasing timestamp
Martijn van Oosterhout writes:
> 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 box '((0,0),(2,2))' ~ point '(1,1)';
>>> ERROR: operator does not exist: box ~ point
>>
>> I don't see a reason, although yo
On 1/25/2007 6:55 PM, Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
The value definitions of tg_enabled would be
A fires always
N fires never
O fires on transaction origin only
R fires on replica only
A new per session GUC variable, restricted to superuse
Jan Wieck <[EMAIL PROTECTED]> writes:
> The value definitions of tg_enabled would be
> A fires always
> N fires never
> O fires on transaction origin only
> R fires on replica only
> A new per session GUC variable, restricted to superusers, will define if
> the sessio
Jan Wieck <[EMAIL PROTECTED]> writes:
> To provide this data, I would like to add another "log" directory,
> pg_tslog. The files in this directory will be similar to the clog, but
> contain arrays of timestamptz values.
Why should everybody be made to pay this overhead?
> The COMMIT syntax will
On Thu, 2007-01-25 at 18:16 -0500, Jan Wieck wrote:
> For conflict resolution purposes in an asynchronous multimaster system,
> the "last update" definition often comes into play. For this to work,
> the system must provide a monotonically increasing timestamp taken at
> the commit of a transact
On Wed, 24 Jan 2007, Tom Lane wrote:
> * For an untrusted language: must be superuser to either create or use
> the language (no change from current rules). Ownership of the
> pg_language entry is really irrelevant, as is its ACL.
>
> * For a trusted language:
>
> * if pg_pltemplate.something is
The experience with Slony-I has shown that
a) different behavior of triggers and rules on a transactions origin
and a replica is essential;
b) mucking around with the system catalog to achieve this is futile.
This would be even more catastrophic in a multimaster environment, where
reg
For a future multimaster replication system, I will need a couple of
features in the PostgreSQL server itself. I will submit separate
proposals per feature so that discussions can be kept focused on one
feature per thread.
For conflict resolution purposes in an asynchronous multimaster system,
Is this a TODO?
---
Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> > I've found a situation that causes DROP FUNCTION to fail (tested
> > in 8.1.6, 8.2.1, and 8.3devel):
>
> Ugh ... I haven't traced this throu
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
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)
> >
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
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
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 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
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
"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 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
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
> > 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 :
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
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/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
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
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
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
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
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
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
> 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
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
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,
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
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
"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
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
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
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
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
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
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
> 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
"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
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
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
>> 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:
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
"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
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 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
> 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
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
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
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 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 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?
-
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 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
"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
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
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
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
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
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 <[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.
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
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
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
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
> 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
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
> "-
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
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
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
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
"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
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
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
> >
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
*
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
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
[
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
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
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.
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
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
1 - 100 of 123 matches
Mail list logo
