Decibel! [EMAIL PROTECTED] writes:
If we're going to make this a ./configure option, ISTM we should
do the same
with XID size as well. I know there are high-velocity databases
that could use
that.
Keep in mind we just changed things so that read-only transactions
don't
consume xids.
On Mar 13, 2008, at 5:14 PM, James Mansion wrote:
James Mansion wrote:
In usage:
AFTER START clears counters and flags.
UPDATE triggers on data set counters and flags.
BEFORE COMMIT examines the counters and flags and performs any
final validation or
adjustments (or external events such
Reini Urban napsal(a):
cygwin 1.5 on NTFS. But 1.7 will a have much larger _PC_PATH_MAX.
_PC_FILESIZEBITS undefined _PC_LINK_MAX = 8 _PC_NAME_MAX = 260 _PC_PATH_MAX =
257
So this is really bad.
Thanks for reporting. It seems not good because postgreSQL assumes that
_PC_PATH_MAX
is minimal
On Thu, 2008-03-20 at 23:07 +, Simon Riggs wrote:
Simon, would it be too much to ask that you concentrate on reviewing
existing patches during commit fest? Trying to get people to think
about random new ideas is about the most direct undermining of the
commit-fest concept that I can
Tom Lane napsal(a):
Alvaro Herrera [EMAIL PROTECTED] writes:
Neil Conway wrote:
Sure -- I sent in a patch earlier, but I'll post an updated version
shortly.
Hmm, I mean just switching the default value in configure.in ... is
there anything else that needs doing at this point?
Well, that's
Simon Riggs [EMAIL PROTECTED] writes:
On Thu, 2008-03-20 at 23:07 +, Simon Riggs wrote:
Simon, would it be too much to ask that you concentrate on reviewing
existing patches during commit fest? Trying to get people to think
about random new ideas is about the most direct
Simon Riggs wrote:
On Thu, 2008-03-20 at 23:07 +, Simon Riggs wrote:
Simon, would it be too much to ask that you concentrate on reviewing
existing patches during commit fest? Trying to get people to think
about random new ideas is about the most direct undermining of the
commit-fest
Simon Riggs wrote:
On Thu, 2008-03-20 at 23:07 +, Simon Riggs wrote:
Simon, would it be too much to ask that you concentrate on reviewing
existing patches during commit fest? Trying to get people to think
about random new ideas is about the most direct undermining of the
On Fri, 2008-03-21 at 08:48 -0400, Bruce Momjian wrote:
I don't think that list is complete. The full archive is:
http://momjian.us/cgi-bin/pgpatches
Sorry, there is no summary.
I've reviewed Nikhil's partitioning patch for now.
I have some time to contribute, but not much. I
What is evil with a polymorphic function?
(1) It's creating a false match --- your proposed entry in the opr_sanity
results has nothing at all to do with what the test is looking for.
(2) Refactoring to have two separate C functions will make the code
clearer, and not noticeably longer.
Hans-Juergen Schoenig [EMAIL PROTECTED] writes:
Doing this for XIDs is pretty useless this days.
It is only targeted for command ids which are consumed heavily by
stored procedure languages.
It happens once on a while that a complex business logic procedure
runs out of command ids inside
Heikki Linnakangas wrote:
Simon Riggs wrote:
Incidentally, I'm in favour of letting Heikki review his own work
because there's a backlog on index changes that appears to be months
long and he has a good chance of tackling that.
Umm, I don't think there's any patches from me in the queue
Zdenek Kotala [EMAIL PROTECTED] writes:
The result will be two datatypes datetime and timestamp_int or
timestamp_float.
This is not happening, at least not without 100 times more work than
anyone has shown willingness to put into the issue. It seems fairly
clear that everyone thinks the int64
Heikki Linnakangas [EMAIL PROTECTED] writes:
Umm, I don't think there's any patches from me in the queue that need
review. There's some discussion threads related to bitmap indexes, but
that's all. We're definitely not going to get bitmap indexes in this
commit fest.
I think there are
Tatsuo Ishii [EMAIL PROTECTED] writes:
Ok, here is the revised patch.
This looks sane to me, but I'd suggest leaving out the mention of 8.4
in the docs. Actually, I'm not sure you need a paragraph at all ---
just adding an example would be enough, I think.
SELECT lo_unlink(173454); --
Andrew Dunstan [EMAIL PROTECTED] writes:
There is your CopyReadLineText speedup, but I think there are too many
open questions on it, e.g.:
...
So I suggest we take it out of the queue for now and kick it back to you.
Per my comments just now, the question is whether it's been adequately
On Thu, Mar 20, 2008 at 6:48 PM, Tom Lane [EMAIL PROTECTED] wrote:
Warren Turkal [EMAIL PROTECTED] writes:
I have to say, I am wondering more and more how real the need is for
the two representations of timestamps. Would it be better to deprecate
the float format or at least make the
A recent message from a would-be mysql converter led me to realize
that we don't check for array decoration when we expand serial.
So this is accepted but doesn't do what one might expect:
regression=# create table foo (f1 serial[11]);
NOTICE: CREATE TABLE will create implicit sequence
On Thu, Mar 20, 2008 at 6:41 PM, Tom Lane [EMAIL PROTECTED] wrote:
Warren Turkal [EMAIL PROTECTED] writes:
I added TimeOffset and DateOffset typedefs to get rid of the instances
using the HAVE_INT64_TIMESTAMP define being used to determine the
types of variables or functions in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 21 Mar 2008 12:55:26 -0400
Tom Lane [EMAIL PROTECTED] wrote:
regression=# create table foo (f1 serial[11]);
NOTICE: CREATE TABLE will create implicit sequence foo_f1_seq for
serial column foo.f1 CREATE TABLE
regression=# \d foo
On Fri, Mar 21, 2008 at 10:25 PM, Tom Lane [EMAIL PROTECTED] wrote:
A recent message from a would-be mysql converter led me to realize
that we don't check for array decoration when we expand serial.
So this is accepted but doesn't do what one might expect:
regression=# create table foo (f1
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
There is your CopyReadLineText speedup, but I think there are too many
open questions on it, e.g.:
...
So I suggest we take it out of the queue for now and kick it back to you.
Per my comments just now, the question is
I would work on this and try to present the performance test results.
I would also go ahead and examine, whether the logic can be added into
heap_form_tuple by any means.
Thanks,
Gokul.
On Wed, Mar 19, 2008 at 12:11 AM, Bruce Momjian [EMAIL PROTECTED] wrote:
Added to TODO:
* Consider
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
There is your CopyReadLineText speedup, but I think there are too many
open questions on it, e.g.:
...
So I suggest we take it out of the queue for now and kick it back to you.
Per my comments just now, the question is whether it's
Heikki Linnakangas wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
There is your CopyReadLineText speedup, but I think there are too
many open questions on it, e.g.:
...
So I suggest we take it out of the queue for now and kick it back to
you.
Per my comments just now,
Added to TODO:
o Prevent SSL from sending network packets to avoid interference
with Win32 signal emulation
http://archives.postgresql.org/pgsql-hackers/2007-12/msg00455.php
---
Magnus
Hi,
We have something that seems to work and may be used as a start point.
Please, take a look at http://gorda.di.uminho.pt/community/pgsqlg/
In particular, take a look at the file src/backend/commands/triggerspecial.
Cheers,
Alfranio.
On Mar 13, 2008, at 5:14 PM, James Mansion wrote:
Tatsuo Ishii [EMAIL PROTECTED] writes:
Ok, here is the revised patch.
This looks sane to me, but I'd suggest leaving out the mention of 8.4
in the docs. Actually, I'm not sure you need a paragraph at all ---
just adding an example would be enough, I think.
SELECT lo_unlink(173454);
28 matches
Mail list logo
