--On Dienstag, Januar 30, 2007 23:24:40 + Simon Riggs
<[EMAIL PROTECTED]> wrote:
Basically what I see here is a whole lot of work and new executor
infrastructure for something that will be a win in a very narrow
use-case and a significant loss the rest of the time. I think there
are more pro
Ühel kenal päeval, T, 2007-01-30 kell 14:52, kirjutas Guido Goldstein:
> I've checked the patch with postgres 8.1.3 and 8.2.1
> with python 2.4 and 2.5 on intel 32 bit and amd 64 bit
> systems; all systems running linux.
>
> *And* it's not a feature patch but a bug-fixing one!
> Python is a langu
On Tue, Jan 30, 2007 at 11:45:24AM -0500, Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > But I guess maybe the added check has to be not just (!syslogger_started)
> > but (!syslogger_started && is_postmaster)?
>
> That would at least get you out of the problem of having to trans
Tom Lane wrote:
Are you still concerned about the PageGetFreeSpace issue?
Not anymore.
The failure case I had in mind was not being able to find any valid
split points when a page is full of max-sized index tuples. On a closer
look, that doesn't seem to be a problem. Even though checksplitlo
On 1/31/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> Btw, I noticed that the toast_insert_or_update() is re-entrant.
> toast_save_datum() calls simple_heap_insert() which somewhere down the
> line calls toast_insert_or_update() again.
The toast code tak
On 1/31/07, Pavan Deolasee <[EMAIL PROTECTED]> wrote:
Attached is a patch which would print the recursion depth for
toast_insert_or_update() before PANICing the server to help us
examine the core.
Here is the attachment.
Thanks,
Pavan
--
EnterpriseDB http://www.enterprisedb.com
toas
David Fetter wrote:
On Tue, Jan 30, 2007 at 03:49:14PM -0500, Andrew Dunstan wrote:
4. visibility/searchpath issues. I don't think long search paths are a
huge issue, but I think we can make life a bit easier by tweaking
searchpath support a bit (David's clever SQL notwithstanding).
T
Hannu Krosing wrote:
> Officially by who ?
>
> 2.3 was the first version to introduce bool as a subtype of int, in
> 2.2.3 True and False were introduced as two variables pointing to
> integers 1 and 0.
>
> So to make your patch ok on all python versions, just make it
> conditional on python vers
Bruce Momjian wrote:
> Hannu Krosing wrote:
> > Officially by who ?
> >
> > 2.3 was the first version to introduce bool as a subtype of int, in
> > 2.2.3 True and False were introduced as two variables pointing to
> > integers 1 and 0.
> >
> > So to make your patch ok on all python versions, just
Bruce Momjian schrieb:
Hannu Krosing wrote:
Officially by who ?
2.3 was the first version to introduce bool as a subtype of int, in
2.2.3 True and False were introduced as two variables pointing to
integers 1 and 0.
So to make your patch ok on all python versions, just make it
conditional on p
Tino Wildenhain wrote:
> Bruce Momjian schrieb:
> > Hannu Krosing wrote:
> >> Officially by who ?
> >>
> >> 2.3 was the first version to introduce bool as a subtype of int, in
> >> 2.2.3 True and False were introduced as two variables pointing to
> >> integers 1 and 0.
> >>
> >> So to make your pat
Tino Wildenhain <[EMAIL PROTECTED]> writes:
> Bruce Momjian schrieb:
>> I thought about suggesting that, but do we want plpython to have
>> different result behavior based on the version of python used? I didn't
>> think so.
> Why not?
Indeed --- the underlying language changed, so I should thin
On Wed, Jan 31, 2007 at 09:31:00AM -0500, Andrew Dunstan wrote:
> David Fetter wrote:
> >On Tue, Jan 30, 2007 at 03:49:14PM -0500, Andrew Dunstan wrote:
> >>4. visibility/searchpath issues. I don't think long search paths
> >>are a huge issue, but I think we can make life a bit easier by
> >>tweaki
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> On 1/31/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> The toast code takes pains to ensure that the tuples it creates won't be
>> subject to re-toasting. Else it'd be an infinite recursion.
> I think I found it. The toast_insert_or_update() function get
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Mittwoch, 17. Januar 2007 17:12 schrieb Tom Lane:
>> "Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
>>> simple if I use -m64 for 64 bit then all end binaries are generated
>>> 64-bit and the shared libraries are generated 32-bit and the compilation
>
- Forwarded message from elein <[EMAIL PROTECTED]> -
To: pgsql-general@postgresql.org
Cc: elein <[EMAIL PROTECTED]>
Subject: [GENERAL] 8.2.1 Compiling Error
Mail-Followup-To: pgsql-general@postgresql.org
From: elein <[EMAIL PROTECTED]>
Debian Linux. Have always built from scratch with no
elein <[EMAIL PROTECTED]> writes:
> gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wendif-labels
> -fno-strict-aliasing -g -Wno-error -L../../../../src/port
> -Wl,-rpath,'/local/pgsql82/lib' preproc.o type.o ecpg.o ecpg_keywords.o
> output.o keywords.o c_keywords.o ../ecpglib/typ
Hi there,
following discussion in -patches about lock compatibility matrix,
posted by Teodor, we have another matrix
http://mira.sai.msu.su/~megera/pgsql/lockmatrix/c2.html
Besides formatting improvements, it has addtional lock with
temporary name UPDATE EXCLUSIVE (UE), which is the same as
EX
I have made these adjustments to the documentation. Do people want the
error message strings also updated? It will probably make the
translation easier/clearer in the future, but it does involve some error
message wording churn. CVS HEAD only, of course.
---
Oleg Bartunov writes:
> Besides formatting improvements, it has addtional lock with
> temporary name UPDATE EXCLUSIVE (UE), which is the same as
> EXCLUSIVE, but doesn't conflicts with SHARE UPDATE EXCLUSIVE (SUE),
> which aquired by VACUUM and autovacuum. The reason for this is that
> at present
On Wed, 2007-01-31 at 11:38 -0800, elein wrote:
> - Forwarded message from elein <[EMAIL PROTECTED]> -
>
> To: pgsql-general@postgresql.org
> Cc: elein <[EMAIL PROTECTED]>
> Subject: [GENERAL] 8.2.1 Compiling Error
> Mail-Followup-To: pgsql-general@postgresql.org
> From: elein <[EMAIL PRO
On Wed, Jan 31, 2007 at 03:41:31PM -0500, Tom Lane wrote:
> elein <[EMAIL PROTECTED]> writes:
> > gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wendif-labels
> > -fno-strict-aliasing -g -Wno-error -L../../../../src/port
> > -Wl,-rpath,'/local/pgsql82/lib' preproc.o type.o ecpg.o
imad <[EMAIL PROTECTED]> writes:
> OK, so renaming does not work in the same block.
> You can rename a vairable in a nested block and thats why it works for
> OLD/NEW.
> BTW, what is the purpose behind it? Declaring a variable in a block
> and quickly renaming it does not make sense to me.
I agr
elein wrote:
- Forwarded message from elein <[EMAIL PROTECTED]> -
Build error is:
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wendif-labels
-fno-strict-aliasing -g -Wno-error -L../../../../src/port
-Wl,-rpath,'/local/pgsql82/lib' preproc.o type.o ecpg.o ecpg_keywords.
G'day hackers,
I had some hand-wavy thoughts about some potential gains for
postgres in the data archiving/warehousing area. I'm not able
to do any work myself on this, and don't actually have a
pressing need for it so I'm not "requesting" someone do it, but
I thought it might be worth discussing
On Thu, 1 Feb 2007, Chris Dunlop wrote:
> G'day hackers,
G'Day Chris,
> already - I couldn't find anything in the mail archives, but
> that doesn't mean it's not there...)
There has been a lot of discussion about this kind of thing over the
years.
> The main idea is that, there might be space
Uh, where are we on this?
---
Tom Lane wrote:
> I 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):
> >> http://arc
G'day Gavin,
In maillist.postgres.dev, you wrote:
> On Thu, 1 Feb 2007, Chris Dunlop wrote:
>> The main idea is that, there might be space utilisation and
>> performance advantages if postgres had "hard" read-only
>> tables, i.e. tables which were guaranteed (by postgres) to
>> never have their d
Added to TODO:
* Fix problem when multiple subtransactions of the same outer transaction
hold different types of locks, and one subtransaction aborts
http://archives.postgresql.org/pgsql-hackers/2006-11/msg01011.php
http://archives.postgresql.org/pgsql-hackers/2006-12/msg1.php
--
Where are we on this?
---
Magnus Hagander wrote:
> On Tue, Dec 19, 2006 at 04:58:22PM +0100, Zeugswetter Andreas ADI SD wrote:
> >
> > > > > > MinGW has fseeko64 and ftello64 with off64_t.
> > > > > >
> > > > >
> > > >
Added to TODO:
> * Tighten trigger permission checks
>
> http://archives.postgresql.org/pgsql-hackers/2006-12/msg00564.php
and:
> * Tighten function permission checks
>
> http://archives.postgresql.org/pgsql-hackers/2006-12/msg00568.php
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Uh, where are we on this?
Still in the think-about-it mode, personally ... my proposed fix is
certainly much too invasive to consider back-patching, so unless someone
comes up with a way-simpler idea, it's 8.3 material at best ...
Bruce Momjian wrote:
> I have made these adjustments to the documentation. Do people want
> the error message strings also updated?
I have no problem with that. They seem to be in pretty good shape
already, so the changes should be few.
--
Peter Eisentraut
http://developer.postgresql.org/~pet
33 matches
Mail list logo
