--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
Ü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 language
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 transmit the
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
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 takes pains
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
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).
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 version
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 make it
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
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 patch ok on all python
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 think that
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
tweaking
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 gets into an
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
fails (ONLY ON
- 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
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
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 oleg@sai.msu.su 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
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 PROTECTED]
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 agree
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.o
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):
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 data
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.
Maybe we need separate
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
33 matches
Mail list logo
