are we prepared to wait for? */
7. Question: benefits of separate holdtime option from sleeptime?
Simon Riggs wrote:
* provide holdtime delay, default 0 (on all platforms)
Going back on the hackers+patches emails and parsing the code
comments, I'm sorry if I missed that, but I'm
Magnus Hagander wrote:
Bruce Momjian wrote:
Martin Zaun wrote:
4. Issue: missing break in switch, silent override of '-l' argument?
This behaviour has been in there before and is not addresses by the
patch: The user-selected Win32 mklink command mode is never applied
due to a missing
Tom Lane wrote:
Heikki Linnakangas hei...@enterprisedb.com writes:
Martin Zaun wrote:
With these avenues to be explored, can the pg_standby patch on the
CommitFest wiki be moved to the Returned with Feedback section?
Yes, I think we can conclude that we don't want this patch as it is.
On Mon, 2008-12-15 at 17:10 -0500, Bruce Momjian wrote:
Why no backpatch to 8.3? Seems like a clear bugfix to me.
I knew that was going to be asked.
8.3 is really where this is needed. 8.4 has almost no need of this.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training,
Changes:
- added vacuum_delay_point() in gininsertcleanup
- add trigger to run vacuum by number of inserted tuples from
last vacuum. Number of inserted tuples represents number
of really inserted tuples in index and it is calculated as
tuples_inserted + tuples_updated -
On 3 Dec 2008, at 06:57 AM, Heikki Linnakangas [EMAIL PROTECTED]
wrote:
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
If *that* is a use case we're interested in, the incoming tuples
could be accumulated in backend-private memory, and inserted into
the index at commit.
Greg Stark [EMAIL PROTECTED] writes:
If we do this though it would be really nice to do it at a higher
level than the indexam. If we could do it for any indexam that
provides a kind of bulk insert method that would be great.
I'm just not sure how to support all the indexable operators for
Tom Lane wrote:
Greg Stark [EMAIL PROTECTED] writes:
If we do this though it would be really nice to do it at a higher
level than the indexam. If we could do it for any indexam that
provides a kind of bulk insert method that would be great.
I'm just not sure how to support all the
Teodor Sigaev wrote:
- Falling back to regular insert will take long time for update of whole
table - and that was one of reasons of that patch. Users forget to drop
GIN index before a global update and query runs forever.
If *that* is a use case we're interested in, the incoming tuples could
grovel through. The situation will only be rectified at the next vacuum,
but if there's no deletes or updates on the table, just inserts,
autovacuum won't happen until the next anti-wraparound vacuum.
There is not agreement here, see
http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
Heikki Linnakangas [EMAIL PROTECTED] writes:
Teodor Sigaev wrote:
- Falling back to regular insert will take long time for update of whole
table - and that was one of reasons of that patch. Users forget to drop
GIN index before a global update and query runs forever.
If *that* is a use
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
If *that* is a use case we're interested in, the incoming tuples could
be accumulated in backend-private memory, and inserted into the index at
commit. That would be a lot simpler, with no need to worry about
concurrent inserts or
There's a pretty fundamental issue with this patch, which is that while
buffering the inserts in the list pages makes the inserts fast, all
subsequent queries become slower until the tuples have been properly
inserted into the index. I'm sure it's a good tradeoff in many cases,
but there has
Heikki Linnakangas [EMAIL PROTECTED] writes:
I think we need a hard limit on the number of list pages, before we can
consider accepting this patch. After the limit is full, the next inserter can
flush the list, inserting the tuples in the list into the tree, or just fall
back to regular,
Gregory Stark wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
I think we need a hard limit on the number of list pages, before we can
consider accepting this patch. After the limit is full, the next inserter
can
flush the list, inserting the tuples in the list into the tree, or
Hiroshi Saito [EMAIL PROTECTED] wrote:
I think that MinGW does not have a direct relation.
#define_UNICODE is required for wcsftime.
Probably, ITAGAKI-san has only forgotten it.:-)
No, definition of _UNICODE is independent from wcsftime (and
other wcs functions). It affects only _tcs
ITAGAKI Takahiro wrote:
Hiroshi Saito [EMAIL PROTECTED] wrote:
I think that MinGW does not have a direct relation.
#define_UNICODE is required for wcsftime.
Probably, ITAGAKI-san has only forgotten it.:-)
No, definition of _UNICODE is independent from wcsftime (and
other wcs functions). It
Hiroshi Inoue [EMAIL PROTECTED] wrote:
Please call setlocale(LC_CTYPE/LC_ALL, ) first.
Ah, it works! But setlocale(*, ) means that we always use platform
locale (Japanese and SJIS in Japan). It could be different from server
encoding and locale in postgres. Is it acceptable? I think we need to
ITAGAKI Takahiro wrote:
Hiroshi Inoue [EMAIL PROTECTED] wrote:
Please call setlocale(LC_CTYPE/LC_ALL, ) first.
Ah, it works! But setlocale(*, ) means that we always use platform
locale (Japanese and SJIS in Japan).
Maybe you can call setlocale(LC_CTYPE, .20932) instead and you
would get
Hiroshi Saito [EMAIL PROTECTED] wrote:
Umm, format operand seems to be a wide character sequence.
Here is a patch to work around the wide character format string.
The hack is the following line:
+#define strftime(a,b,c,d) strftime_win32(a,b,L##c,d)
We use only literals in the format
Hi ITAGAKI-san.
Um, It was not supported.
http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/ITAGAKI_PATCH.txt
The test of my various past is reproduced. Then, I proposed the management
regarded as best in them. and, to Magnus-san.
Does the reason for persisting in wsftime exceed
Hiroshi Saito [EMAIL PROTECTED] wrote:
Um, It was not supported.
http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/ITAGAKI_PATCH.txt
Hmm... the implementation of wcsftime() in msvcrt seems to be
completely broken.
I ran the attached test (localetest.c) and got the following
井上です。
ITAGAKI Takahiro wrote:
Hiroshi Saito [EMAIL PROTECTED] wrote:
Um, It was not supported.
http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/ITAGAKI_PATCH.txt
Hmm... the implementation of wcsftime() in msvcrt seems to be
completely broken.
I ran the attached test
Hi.
I think that MinGW does not have a direct relation.
#define_UNICODE is required for wcsftime.
Probably, ITAGAKI-san has only forgotten it.:-)
P.S)
日本語になっていましたです:-)
Regards,
Hiroshi Saito
- Original Message -
From: Hiroshi Inoue [EMAIL PROTECTED]
井上です。
ITAGAKI Takahiro
The way I read this patch we do:
1) Get the time in CP_ACP
2) Convert to UTF16
3) Convert to UTF8
4) If necessary, convert to the charset in the database
We could be more efficient by at least folding 1 and 2 into a single
step, which means getting it in UTF16 from the beginning. How about
Hi Magnus-san.
Um, Though regrettable, it is not in a good state.
http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/Mugnus-patch.png
- Original Message -
From: Magnus Hagander [EMAIL PROTECTED]
The way I read this patch we do:
1) Get the time in CP_ACP
2) Convert
Magnus Hagander [EMAIL PROTECTED] writes:
*** a/src/backend/utils/adt/pg_locale.c
--- b/src/backend/utils/adt/pg_locale.c
***
*** 54,59
--- 54,60
#include utils/memutils.h
#include utils/pg_locale.h
+ #include mb/pg_wchar.h
#define
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
*** a/src/backend/utils/adt/pg_locale.c
--- b/src/backend/utils/adt/pg_locale.c
***
*** 54,59
--- 54,60
#include utils/memutils.h
#include utils/pg_locale.h
+ #include mb/pg_wchar.h
#define
Does it work when you're not using C-locale? This looks like the
codepath Tom pointed out was wrong.
//Magnus
Hiroshi Saito wrote:
Hi Magnus-san.
Um, Though regrettable, it is not in a good state.
http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/Mugnus-patch.png
Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
*** a/src/backend/utils/adt/pg_locale.c
--- b/src/backend/utils/adt/pg_locale.c
***
*** 54,59
--- 54,60
#include utils/memutils.h
#include utils/pg_locale.h
+ #include
Hi Magnus-san.
Umm, format operand seems to be a wide character sequence.
- Original Message -
From: Magnus Hagander [EMAIL PROTECTED]
Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
*** a/src/backend/utils/adt/pg_locale.c
---
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Please stick to the convention of including include files in
alphabetical order.
I didn't realize we had such a convention. Is this for all include files or
only within a directory? Are there exceptions where the
Tom Lane [EMAIL PROTECTED] writes:
Please stick to the convention of including include files in
alphabetical order.
I didn't realize we had such a convention. Is this for all include files or
only within a directory? Are there exceptions where the order matters or have
we managed to make sure
On Sun, Nov 16, 2008 at 8:36 AM, Hiroshi Saito [EMAIL PROTECTED] wrote:
Hi.
Then, It continues and a review is desired. Thanks!
In http://msdn.microsoft.com/en-us/library/fe06s4ak(VS.71).aspx says:
Return Value
strftime returns the number of characters placed in strDest and
wcsftime returns
Hi Jaime-san.
Thank you for a review.
I think this purpose to return the value which should originally obtain strftime
by only replacing here. Then, I think that it is a superfluous reaction.
However, some consideration may be necessities.
Regards,
Hiroshi Saito
- Original Message -
On Thu, 2008-11-20 at 11:06 +0530, Pavan Deolasee wrote:
On Mon, Nov 17, 2008 at 9:01 PM, Simon Riggs [EMAIL PROTECTED]
wrote:
It is, in a later version. Apologies if you're reviewing the
wrong one.
The most recent version I can
On Thu, Nov 20, 2008 at 3:12 PM, Simon Riggs [EMAIL PROTECTED] wrote:
The latest Hot Standby patch includes the latest version of
infrastructure changes patch. Thanks for reviewing.
Do you intend to split the patch into smaller pieces ? The latest hot
standby patch is almost 10K+ lines.
On Thu, 2008-11-20 at 15:19 +0530, Pavan Deolasee wrote:
Do you intend to split the patch into smaller pieces ? The latest hot
standby patch is almost 10K+ lines. Splitting that would definitely
help the review process.
If it helps you, then I'll do it. Hang on an hour or so.
--
Simon
On Mon, Nov 17, 2008 at 9:01 PM, Simon Riggs [EMAIL PROTECTED] wrote:
It is, in a later version. Apologies if you're reviewing the wrong one.
The most recent version I can find is v9, but I remember you mentioned v10
somewhere else.
Can you please confirm if v9 is the latest version and point
Simon Riggs wrote:
diff --git a/src/backend/access/transam/subtrans.c b/src/backend/access/transam/
index 063b366..5e64cb4 100644
--- a/src/backend/access/transam/subtrans.c
+++ b/src/backend/access/transam/subtrans.c
@@ -226,6 +226,9 @@ ZeroSUBTRANSPage(int pageno)
*
* oldestActiveXID is
Simon Riggs wrote:
@@ -3845,6 +3850,52 @@ sigusr1_handler(SIGNAL_ARGS)
PG_SETMASK(BlockSig);
+ if (CheckPostmasterSignal(PMSIGNAL_RECOVERY_START))
+ {
+ Assert(pmState == PM_STARTUP);
+
+ /*
+* Go to shutdown mode if a shutdown
This comment in XLogFlush is no longer accurate:
* The current approach is to ERROR under normal conditions, but only
* WARNING during recovery, so that the system can be brought up even if
* there's a corrupt LSN. Note that for calls from xact.c, the ERROR
will
On Mon, 2008-11-17 at 15:51 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
diff --git a/src/backend/access/transam/subtrans.c
b/src/backend/access/transam/
index 063b366..5e64cb4 100644
--- a/src/backend/access/transam/subtrans.c
+++ b/src/backend/access/transam/subtrans.c
@@
On Mon, 2008-11-17 at 16:18 +0200, Heikki Linnakangas wrote:
+
+ /*
+* Load the flat authorization file into
postmaster's ca
+* startup process won't have recomputed
this from the d
+* yet,
On Mon, 2008-11-17 at 16:18 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
@@ -3845,6 +3850,52 @@ sigusr1_handler(SIGNAL_ARGS)
PG_SETMASK(BlockSig);
+ if (CheckPostmasterSignal(PMSIGNAL_RECOVERY_START))
+ {
+ Assert(pmState == PM_STARTUP);
On Tue, Nov 18, 2008 at 12:39 AM, Simon Riggs [EMAIL PROTECTED] wrote:
On Mon, 2008-11-17 at 16:18 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
@@ -3845,6 +3850,52 @@ sigusr1_handler(SIGNAL_ARGS)
PG_SETMASK(BlockSig);
+ if
Hi.
All suggestion is appropriate and has been checked.
CVS-HEAD was examined by MinGW.
$ make check NO_LOCALE=true
...
===
All 118 tests passed.
===
Then, It continues and a review is desired.
Thanks!
Regatrds,
Hiroshi Saito
- Original
Jaime Casanova [EMAIL PROTECTED] wrote:
i'm confused, original patch has this signature:
+ conv_strftime(char *src, size_t len, const char *format, const struct tm
*tm)
your's has:
+strftime_win32(char *dst, size_t dstlen, const char *format, const
you change all src for dst, just a
Hi ITAGAKI-san.
Sorry, very late reaction..
I lost time resources in an individual my machine trouble and busyness.:-(
Now, I appreciate your exact work. ! Then, I desire the best patch for PostgreSQL.
Probably, I think that it is finally helpful in not a problem of only Japan but many
Have we made any progress on this, namely better documentation and
removing the Win32 delay code?
---
Andrew Dunstan wrote:
Simon Riggs wrote:
Well, this is a strange conclusion, leaving me slightly bemused.
The
I have a fairly large TODO list, and Simon has thrown in the towel (and
I imagine he also has a large TODO list).
anyone else want to step in?
cheers
andrew
Bruce Momjian wrote:
Have we made any progress on this, namely better documentation and
removing the Win32 delay code?
On Mon, Nov 3, 2008 at 8:41 PM, ITAGAKI Takahiro
[EMAIL PROTECTED] wrote:
Hello, Saito-san:
Hiroshi Saito [EMAIL PROTECTED] wrote:
next patch is this.
I'm reviewing your patch and cleanup some parts:
i'm confused, original patch has this signature:
+ conv_strftime(char *src, size_t len,
On Fri, 2008-11-07 at 15:44 -0800, Jeff Davis wrote:
Is there a way to avoid wiping A and making a new base backup?
rsync
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Tue, 2008-09-30 at 23:52 +0100, Simon Riggs wrote:
* optional recovery_safe_start_location parameter now provided in
recovery.conf, to allow a consistency point to be manually defined if a
base backup was not taken using standard pg_start/stop backup functions
If using synchronous
Just interested if you repeat your tests not with cracklib-dict,
but using 8-bit words. From our experience we found many hash functions
are optimized for 7-bit words and produce too many collisions
for 8-bit words. That's why we use crc32.
Oleg
On Tue, 4 Nov 2008, Kenneth Marshall wrote:
On Tue, Nov 04, 2008 at 11:32:47PM +0300, Oleg Bartunov wrote:
Just interested if you repeat your tests not with cracklib-dict,
but using 8-bit words. From our experience we found many hash functions
are optimized for 7-bit words and produce too many collisions
for 8-bit words. That's why we
Oleg,
Here is a little more information on the use of CRC32 as
a hash function, with some warning caveats:
http://home.comcast.net/~bretm/hash/8.html
Regards,
Ken
On Tue, Nov 04, 2008 at 03:15:44PM -0600, Kenneth Marshall wrote:
On Tue, Nov 04, 2008 at 11:32:47PM +0300, Oleg Bartunov wrote:
Sorry about the delay for this update to the new hash
index implementation. I was trying to get the WAL logging
in place and forgot to post the actual patch. The WAL
for hash indexes will need to wait for 8.5, but I did
want to add back in the piece of the Bob Jenkins 2006
hash function that was
Hello, Saito-san:
Hiroshi Saito [EMAIL PROTECTED] wrote:
next patch is this.
I'm reviewing your patch and cleanup some parts:
- Avoid casting to LPWSTR.
- Use pre-defined MAX_L10N_DATA instead of STRLEN_MAX.
I'll send a new version.
BTW, we convert strings multiple times in the function.
Hi.
I am sorry to be a very late reaction...
Hiroshi Saito [EMAIL PROTECTED] writes:
From: Magnus Hagander [EMAIL PROTECTED]
Also, the patch needs error checking. strftime() can fail, and the
multibyte conversion functions can certainly fail. That will need to be
added.
I will proposal the
Reworked version of fast insertion patch for GIN.
* shiftList does LockBufferForCleanup, which means that it can be blocked
for an indefinitely long time by a concurrent scan, and since it's
holding
exclusive lock on metapage no new scans or insertions can start
meanwhile.
This is not only
Simon Riggs wrote:
* optional recovery_safe_start_location parameter now provided in
recovery.conf, to allow a consistency point to be manually defined if a
base backup was not taken using standard pg_start/stop backup functions
Do we want to cater for that? It only seems safe if you have
On Wed, 2008-10-08 at 14:43 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
* optional recovery_safe_start_location parameter now provided in
recovery.conf, to allow a consistency point to be manually defined if a
base backup was not taken using standard pg_start/stop backup functions
Are there any plans to commit these libpq-events changes this fest?
http://archives.postgresql.org/pgsql-hackers/2008-09/msg01109.php
I wanted to release an updated libpqtypes but am waiting on the above
patch. If not, I'll release it now.
--
Andrew Chernow
eSilo, LLC
every bit counts
Andrew Chernow [EMAIL PROTECTED] writes:
Are there any plans to commit these libpq-events changes this fest?
Sorry about that, I got distracted. Will look at it shortly.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Andrew Chernow [EMAIL PROTECTED] writes:
To build on this analogy, PGEVT_CONNRESET is like a realloc. Meaning,
the initial malloc PGEVT_REGISTER worked by the realloc
PGEVT_CONNRESET didn't ... you still have free PGEVT_CONNDESTROY the
initial. Its documented that way. Basically if a
Tom Lane wrote:
I'll go ahead and apply this patch in a little bit, but if you concur
with the above reasoning, please put together a followon patch to add
such a function.
regards, tom lane
I attached a patch. You have to copy the events in PQmakeEmptyPGResult
On Fri, Sep 19, 2008 at 2:14 PM, Andrew Chernow [EMAIL PROTECTED] wrote:
BTW, the event system might be an alternative solution for PGNoticeHooks
(PGEVT_NOTICE).
Another possible use of the event hooks -- just spitballing here -- is
to generate an event when a notification comes through (you
BTW, why are all the conn parameters to events declared const? Isn't
the reason for passing them in mainly to give the event proc a chance
to issue queries?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Tom Lane wrote:
BTW, why are all the conn parameters to events declared const? Isn't
Because it looked prettier? Kidding. No idea, do you want me to change
that or do you want to?
the reason for passing them in mainly to give the event proc a chance
to issue queries?
Partly. You
Andrew Chernow [EMAIL PROTECTED] writes:
Tom Lane wrote:
BTW, why are all the conn parameters to events declared const? Isn't
Because it looked prettier? Kidding. No idea, do you want me to change
that or do you want to?
I'll fix it; it's hardly worth passing a patch around for.
Andrew Chernow [EMAIL PROTECTED] writes:
I attached a patch. You have to copy the events in PQmakeEmptyPGResult
because there is no where else to do this, other than copyresult but
that is different because it copies from a result not a conn.
Applied ...
PQgetResult now calls
Merlin Moncure [EMAIL PROTECTED] writes:
On Fri, Sep 19, 2008 at 2:14 PM, Andrew Chernow [EMAIL PROTECTED] wrote:
BTW, the event system might be an alternative solution for PGNoticeHooks
(PGEVT_NOTICE).
Another possible use of the event hooks -- just spitballing here -- is
to generate an
Now, it's questionable how tense we need to be about that as long as
event proc failure aborts calling of later event procs. That means
that procs have to be robust against getting DESTROY with no CREATE
calls in any case. Should we try to make that less uncertain?
I attached a patch
Andrew Chernow wrote:
Now, it's questionable how tense we need to be about that as long as
event proc failure aborts calling of later event procs. That means
that procs have to be robust against getting DESTROY with no CREATE
calls in any case. Should we try to make that less
Andrew Chernow [EMAIL PROTECTED] writes:
Now, it's questionable how tense we need to be about that as long as
event proc failure aborts calling of later event procs. That means
that procs have to be robust against getting DESTROY with no CREATE
calls in any case. Should we try to make that
Tom Lane wrote:
Some thought would need to be given to how that interacts with
RESULTCOPY. Presumably on the destination side, RESULTCOPY is the
equivalent of RESULTCREATE, ie, don't DESTROY if you didn't get COPY.
But what of the source side? Arguably you shouldn't invoke COPY on
events that
Andrew Chernow [EMAIL PROTECTED] writes:
Tom Lane wrote:
Some thought would need to be given to how that interacts with
RESULTCOPY. Presumably on the destination side, RESULTCOPY is the
equivalent of RESULTCREATE, ie, don't DESTROY if you didn't get COPY.
But what of the source side?
Andrew Chernow wrote:
New patch following our discussion with updated docs.
few logical errors). I don't think it makes sense to do it
otherwise, it would be like calling free after a malloc failure.
I can live with that definition, but please document it.
To build on this analogy,
Andrew Chernow [EMAIL PROTECTED] writes:
Missed that one. Good catch :) Update attached.
Looking at this now. Question: why does PQgetResult invoke the
RESULTCREATE event only for non-error results? This seems a rather
odd asymmetry, particularly in view of the fact that a RESULTDESTROY
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
Missed that one. Good catch :) Update attached.
Looking at this now. Question: why does PQgetResult invoke the
RESULTCREATE event only for non-error results?
It didn't seem useful to have the eventproc implementation allocate its
Andrew Chernow [EMAIL PROTECTED] writes:
Tom Lane wrote:
Looking at this now. Question: why does PQgetResult invoke the
RESULTCREATE event only for non-error results?
It didn't seem useful to have the eventproc implementation allocate its
private
storage (or do whatever prep work it
Andrew Chernow [EMAIL PROTECTED] writes:
Yeah. Good point. I fixed it to always fire events.
Applied with editorial revisions --- I don't think I changed any
functionality, but I fixed a number of corner-case bugs and
editorialized on style a bit.
The general question of symmetry between
Brendan Jurd [EMAIL PROTECTED] writes:
I've attached a new version of the patch (version 3), as well as an
incremental patch to show the differences between versions 2 and 3.
Applied with minimal modifications. I changed a couple of error
messages that didn't seem to meet the style guidelines,
On Fri, Sep 12, 2008 at 3:34 AM, Tom Lane [EMAIL PROTECTED] wrote:
Applied with minimal modifications. I changed a couple of error
messages that didn't seem to meet the style guidelines,
Great, thanks Tom. And thanks again to Alex and Martijn for helping
me refine the patch.
and I moved all
On Mon, Sep 08, 2008 at 06:24:14PM +1000, Brendan Jurd wrote:
On Sun, Sep 7, 2008 at 5:58 AM, Alex Hunsaker [EMAIL PROTECTED] wrote:
Im just following this:
http://wiki.postgresql.org/wiki/Reviewing_a_Patch so lets get started.
Hi Alex. Thanks for taking the time to review my patch.
I
On Tue, Sep 9, 2008 at 7:29 PM, Martijn van Oosterhout
[EMAIL PROTECTED] wrote:
I actually had a look at this patch also, though not as thoroughly as
Alex. There was one part that I had some thoughts about in
from_char_parse_int_len:
Hi Martijn. Thanks for your comments.
The use of
On Tue, Sep 9, 2008 at 9:04 PM, Brendan Jurd [EMAIL PROTECTED] wrote:
On Tue, Sep 9, 2008 at 7:29 PM, Martijn van Oosterhout
[EMAIL PROTECTED] wrote:
The use of palloc/pfree in this routine seems excessive. Does len have
upper bound? If so a simple array will do it.
I suppose I could define
On Mon, Sep 8, 2008 at 2:24 AM, Brendan Jurd [EMAIL PROTECTED] wrote:
HEAD actually gets this one wrong; in defiance of the documentation it
returns 2000-09-07. So, it seems to me that the patch shifts the
behaviour in the right direction.
Barring actually teaching the code that some nodes
On Tue, Sep 9, 2008 at 6:46 AM, Brendan Jurd [EMAIL PROTECTED] wrote:
On Tue, Sep 9, 2008 at 9:04 PM, Brendan Jurd [EMAIL PROTECTED] wrote:
On Tue, Sep 9, 2008 at 7:29 PM, Martijn van Oosterhout
[EMAIL PROTECTED] wrote:
The use of palloc/pfree in this routine seems excessive. Does len have
On Sun, Sep 7, 2008 at 5:58 AM, Alex Hunsaker [EMAIL PROTECTED] wrote:
Im just following this:
http://wiki.postgresql.org/wiki/Reviewing_a_Patch so lets get started.
Hi Alex. Thanks for taking the time to review my patch.
Feature test: Everything seems to work as advertised. However before
On Mon, Sep 8, 2008 at 6:24 PM, Brendan Jurd [EMAIL PROTECTED] wrote:
On Sun, Sep 7, 2008 at 5:58 AM, Alex Hunsaker [EMAIL PROTECTED] wrote:
Code review: one minor nit
*** a/src/backend/utils/adt/formatting.c
--- b/src/backend/utils/adt/formatting.c
***
*** 781,787 static
Andrew Chernow escribió:
/*
* PQmakeEmptyPGresult
* returns a newly allocated, initialized PGresult with given status.
* If conn is not NULL and status indicates an error, the conn's
* errorMessage is copied.
*
* Note this is exported --- you wouldn't think an
Andrew Chernow escribió:
Alvaro Herrera wrote:
Andrew Chernow escribió:
* PQclear -
* free's the memory associated with a PGresult
*/
I'd add a comment here stating why the event name is not deallocated;
otherwise it just looks like it's being leaked.
The event name is
On Thu, Sep 4, 2008 at 10:06 AM, Simon Riggs [EMAIL PROTECTED] wrote:
You don't give the text of the query used to do these performance tests,
so I can't validate your test results.
The attachment is the code to generate the text.
Just
$g++ my-permu-code.cpp
$./a.out /tmp/words
--
Best
On Thu, 2008-09-04 at 21:03 +0800, Xiao Meng wrote:
On Thu, Sep 4, 2008 at 10:06 AM, Simon Riggs [EMAIL PROTECTED]
wrote:
You don't give the text of the query used to do these
performance tests,
so I can't validate your test results.
The attachment is the
Abhijit Menon-Sen wrote:
At 2008-08-25 10:24:01 +0300, [EMAIL PROTECTED] wrote:
My original plan was to enable index-only-scans using the DSM as well
for 8.4, but it's pretty clear at this point that I don't have the
time to finish that :-(.
I wonder how hard that would be.
It's doable, for
daveg wrote:
Attached is a the followon patch for pg_dumpall and docs to match pg_dump.
Thanks, committed. (The only change I did was to correct the alignment
in help output.)
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting,
Tom Lane wrote:
[ off-list ]
Matthew T. O'Connor [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm not sure how important it will really be once we have support for
dead-space-map-driven vacuum.
Is that something we can expect any time soon? I haven't heard much
about it really happening for
On Fri, Aug 22, 2008 at 11:36 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
I assume there is no TODO here.
Well, there doesn't seem to be a TODO for partial/restartable vacuums,
which were mentioned upthread. This is a really desirable feature for
big databases and removes one of the reasons to
101 - 200 of 3201 matches
Mail list logo
