Hi,
I would like to be Mentor for Funded Reviewers. My mission will be:
1) We are empowered to create a better world together.
2) Together we co-create our existence.
3) Together we make Postgresql project a success.
I am looking for long and fruitful association with Postgresql.
2011/1/27 Bruce Momjian :
> Bruce Momjian wrote:
>
>> Peter Eisentraut wrote:
>>
>>> We use small "k" in postgresql.conf, so pg_test_fsync should use the
>>> same. Using "kB" would be more accurate in any case.
>>
>> OK, done with the attached applied patch.
>
> FYI, I had used 'k' because this p
On 26.01.2011 16:46, Felix Schmidt @ Oracle wrote:
Everybody,
I'm interested in the query optimizer of PostgreSQL DB. Where could I
find useful documentation or could you send me a pointer in the source code?
The relevant source code is in src/backend/optimizer directory. If you
google around
Hi,
On Jan 27, 2011, at 9:31 AM, Alex Hunsaker wrote:
> Find attached v3 of the patch. changes include:
> - fix deep recursion due to accidental reversal of check in
> encode_array_literal
> - add proper support for stringifying composite/row types. I did not
> find a good way to quote these f
Hi,
I get reproducible "make -j2" compile error in ecpg/pgtypeslib.
The problem is that after this below is executed:
rm -f pgstrcasecmp.c && ln -s ../../../../src/port/pgstrcasecmp.c .
the compilation of pgstrcasecmp.c doesn't happen and this fails:
ar crs libpgtypes.a numeric.o datetime.o com
On Thu, Jan 27, 2011 at 3:49 AM, wrote:
> Hi,
>
> I would like to be Mentor for Funded Reviewers. My mission will be:
> 1) We are empowered to create a better world together.
> 2) Together we co-create our existence.
> 3) Together we make Postgresql project a success.
> I am lookin
Hi,
I have a talk with MinGW developer, because I am not so familiar with
the UNIX configure and build system, can you help to resolve the
problem please.
: XiaoboGu: try actually reading config.log
20:18 : look for winsock2.h in it
20:18 : you should find it, along with the error nearby
20:19
It seems that psql's \copyright haven't been kept up-to-date with the
changes to COPYRIGHT file around 2001. psql \copyright says:
PostgreSQL Data Base Management System
Portions Copyright (c) 1996-2011, PostgreSQL Global Development Group
This software is based on Postgres95, formerly known
On Thu, Jan 27, 2011 at 20:01, Dimitri Fontaine wrote:
> Ok, done. Of course, it solves the whole problem Itagaki had with
> adminpack because we stop relying on dependencies to get it right now.
I found pg_restore with -c option fails when an extension is created
in pg_catalog. Since pg_catalog
Hi all,
I see now the following lines in libintl.h of version
0.18.1.1 which didn't exist in 0.17 version.
/* Support for the locale chosen by the user. */
#if (defined __APPLE__ && defined __MACH__) || defined _WIN32 || defined
__WIN32__ || defined __CYGWIN__
#undef setlocale
#define setlocale
On Tue, Jan 25, 2011 at 1:02 PM, Fujii Masao wrote:
> On Tue, Jan 25, 2011 at 6:02 AM, Heikki Linnakangas
> wrote:
>> Hmm, perhaps the code would be more readable if instead of the
>> forcePageWrites counter that counts exclusive and non-exclusive backups, and
>> an exclusiveBackup boolean indica
2011/1/27 KaiGai Kohei :
> - Error messages become obtaining "%m", when the error was
> originated from the libselinux interfaces. It will provides
> DBA a hint why interactions with SELinux does not work well.
No space before the ": %m", please.
Also this word looks like a typo: seuciryt
--
On Thu, Jan 27, 2011 at 9:14 PM, Xiaobo Gu wrote:
> On Thu, Jan 27, 2011 at 8:56 PM, Xiaobo Gu wrote:
>> On Thu, Jan 27, 2011 at 8:51 PM, Andrew Dunstan wrote:
>>>
>>>
>>> On 01/27/2011 07:41 AM, Xiaobo Gu wrote:
On Thu, Jan 27, 2011 at 8:37 PM, Andrew Dunstan
wrote:
>
>
Itagaki Takahiro writes:
> I found pg_restore with -c option fails when an extension is created
> in pg_catalog. Since pg_catalog is an implicit search target, so we
> might need the catalog to search_path explicitly.
> Note that I can restore adminpack with not errors because it has
> explicit "p
On Thu, Jan 27, 2011 at 7:31 AM, Xiaobo Gu wrote:
> 20:25 : please contact psql and ask for a list of accept()
> implementations checked
It looks like we check each argument and the return type for a couple
of possibilities:
argument 1 can be int or unsigned int
argument 2 can be struct sockaddr
On 01/27/2011 08:51 AM, Robert Haas wrote:
On Thu, Jan 27, 2011 at 7:31 AM, Xiaobo Gu wrote:
20:25: please contact psql and ask for a list of accept()
implementations checked
It looks like we check each argument and the return type for a couple
of possibilities:
argument 1 can be int or uns
On Thu, Jan 27, 2011 at 1:14 AM, Noah Misch wrote:
> Based on downthread discussion, I figure this will all change a good deal.
> I'll
> still briefly explain the patch as written. Most of the patch is plumbing to
> support the new syntax, catalog entries, and FuncExpr field. The important
> c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/27/2011 14:43, Xiaobo Gu wrote:
>> On 1/27/2011 11:02, Xiaobo Gu wrote:
>>> MSYS does not provide GCC, it only provides some UNIX like tools on
>>> Windows to emulate the *NIX environment.
>>>
>>
>> Yes it does, you are using it.
>
> OK, my fault
On Thu, Jan 27, 2011 at 10:01 PM, Andrew Dunstan wrote:
>
>
> On 01/27/2011 08:51 AM, Robert Haas wrote:
>>
>> On Thu, Jan 27, 2011 at 7:31 AM, Xiaobo Gu wrote:
>>>
>>> 20:25: please contact psql and ask for a list of accept()
>>> implementations checked
>>
>> It looks like we check each argument
On 01/27/2011 09:19 AM, Xiaobo Gu wrote:
On Thu, Jan 27, 2011 at 10:01 PM, Andrew Dunstan wrote:
On 01/27/2011 08:51 AM, Robert Haas wrote:
On Thu, Jan 27, 2011 at 7:31 AM, Xiaobo Guwrote:
20:25: please contact psql and ask for a list of accept()
implementations checked
It looks like
Robert Haas writes:
> OK. I was thinking that instead moving this into
> eval_const_expressions(), we just make the logic in
> find_coercion_pathway() call the "exemptor" function (or whatever we
> call it) right around here:
No, no, no, no. Didn't you read yesterday's discussion? parse_coerce
On Thu, Jan 27, 2011 at 10:44 PM, Xiaobo Gu wrote:
> On Thu, Jan 27, 2011 at 9:32 PM, Andrew Dunstan wrote:
>>
>>
>> On 01/27/2011 07:56 AM, Xiaobo Gu wrote:
Clearly there is a problem, or configure would have worked. You need to
answer the question I asked previously, namely what
On 01/27/2011 09:55 AM, Xiaobo Gu wrote:
The above combinition does not pass, another question,
Because I just want to build the client side of PostgreSQL, can I
ignore this error and let the configure pass
You can try, but I at least am only interested in getting the whole
package to bu
Boszormenyi Zoltan writes:
> I get reproducible "make -j2" compile error in ecpg/pgtypeslib.
FWIW, I can't reproduce that at all, either at -j2 or -j4, on either
Fedora 13 or Fedora 14.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
On Thu, Jan 27, 2011 at 9:46 AM, Tom Lane wrote:
> Robert Haas writes:
>> OK. I was thinking that instead moving this into
>> eval_const_expressions(), we just make the logic in
>> find_coercion_pathway() call the "exemptor" function (or whatever we
>> call it) right around here:
>
> No, no, no,
I wrote:
> While the overall code coverage for PostgreSQL source code is:
>
> Overall coverage rate:
> lines..: 64.8% (130296 of 201140 lines)
> functions..: 72.0% (7997 of 11109 functions)
By the way, I discovered that the above is lower if you just run the
check target. The dcheck
Nicolas Barbier wrote:
> 2011/1/27 Bruce Momjian :
>
> > Bruce Momjian wrote:
> >
> >> Peter Eisentraut wrote:
> >>
> >>> We use small "k" in postgresql.conf, so pg_test_fsync should use the
> >>> same. ?Using "kB" would be more accurate in any case.
> >>
> >> OK, done with the attached applied pa
On Wed, Jan 26, 2011 at 17:37, Andrew Dunstan wrote:
>
>
> On 01/26/2011 11:26 AM, Bruce Momjian wrote:
>>
>> For those of you using git, I wanted to point out that it is fairly easy
>> to remove git branches. For example, I can easily remove a branch on
>> my github repository using:
>>
>>
Bruce Momjian wrote:
> http://en.wikipedia.org/wiki/Bytes#Unit_symbol
>
> You can see the chart on the right.
According to which, the JEDEC standard requires KB and the IEC
standard requires KiB. What standard led us to use kB instead? It
seems to generally mean 1000 instead of 1024.
> Ho
On Thu, Jan 27, 2011 at 10:42 AM, Robert Haas wrote:
> On Thu, Jan 27, 2011 at 9:46 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> OK. I was thinking that instead moving this into
>>> eval_const_expressions(), we just make the logic in
>>> find_coercion_pathway() call the "exemptor" function (or
On Thu, Jan 27, 2011 at 11:13 AM, Magnus Hagander wrote:
> On Wed, Jan 26, 2011 at 17:37, Andrew Dunstan wrote:
>>
>>
>> On 01/26/2011 11:26 AM, Bruce Momjian wrote:
>>>
>>> For those of you using git, I wanted to point out that it is fairly easy
>>> to remove git branches. For example, I can ea
Magnus Hagander writes:
> On Wed, Jan 26, 2011 at 17:37, Andrew Dunstan wrote:
>> I thought we had some hooks on gitmaster to help prevent accidents like
>> inadvertent branch deletion.
> We have hooks to prevent a number of things, but not the removal of
> branches (or tags). We'll send an emai
Kevin Grittner wrote:
> Bruce Momjian wrote:
>
> > http://en.wikipedia.org/wiki/Bytes#Unit_symbol
> >
> > You can see the chart on the right.
>
> According to which, the JEDEC standard requires KB and the IEC
> standard requires KiB. What standard led us to use kB instead? It
> seems to gen
Robert Haas writes:
> Is it not OK for me to have a different idea about which way to go
> with something than you do?
Well, in this case I firmly believe that you're mistaken.
> My personal view is that we ought to try to be increasing the number
> of places where type modifiers behave like the
On 01/27/2011 11:29 AM, Tom Lane wrote:
Given that nobody is supposed to push temporary branches to the master
repo anyway, an intended branch removal should be a pretty darn rare
event. Now, our committers all seem to be pretty careful people, so
I don't feel strongly about having extra secur
On Thu, Jan 27, 2011 at 11:35 AM, Tom Lane wrote:
>> My personal view is that we ought to try to be increasing the number
>> of places where type modifiers behave like they're really part of the
>> type, rather than being an afterthought that we deal with when
>> convenient and otherwise ignore.
>
On Thu, Jan 27, 2011 at 17:36, Andrew Dunstan wrote:
>
>
> On 01/27/2011 11:29 AM, Tom Lane wrote:
>>
>> Given that nobody is supposed to push temporary branches to the master
>> repo anyway, an intended branch removal should be a pretty darn rare
>> event. Now, our committers all seem to be pret
Magnus Hagander wrote:
> On Thu, Jan 27, 2011 at 17:36, Andrew Dunstan wrote:
> >
> >
> > On 01/27/2011 11:29 AM, Tom Lane wrote:
> >>
> >> Given that nobody is supposed to push temporary branches to the master
> >> repo anyway, an intended branch removal should be a pretty darn rare
> >> event. ?
On 27.01.2011 18:41, Bruce Momjian wrote:
Well, branch creation can always be undone --- branch removal seems like
the big problem because it can't.
Actually, all you need to do is to push the branch back to resurrect it.
As long as your local branch is up-to-date with what was removed (or you
On Thu, Jan 27, 2011 at 11:41 AM, Bruce Momjian wrote:
>> Or for that we could just disable branch creation *completely*, and
>> then turn off that restriction that one time / year that we actually
>> create a branch?
>
> Well, branch creation can always be undone --- branch removal seems like
> t
Robert Haas wrote:
> On Thu, Jan 27, 2011 at 11:41 AM, Bruce Momjian wrote:
> >> Or for that we could just disable branch creation *completely*, and
> >> then turn off that restriction that one time / year that we actually
> >> create a branch?
> >
> > Well, branch creation can always be undone --
Andrew Dunstan writes:
> On 01/27/2011 11:29 AM, Tom Lane wrote:
>> Given that nobody is supposed to push temporary branches to the master
>> repo anyway, an intended branch removal should be a pretty darn rare
>> event.
> Pushing a local topic branch by mistake seems much more likely to me.
Ye
Bruce Momjian wrote:
> OK, someone removes a branch.
As was explained earlier on this thread, it's not gone at that
point; it's a dangling reference. I think that unless someone
explicitly "prunes" the dangling references, they are left around
for a week, and can easily be checked out again.
Tom Lane wrote:
> Andrew Dunstan writes:
> > On 01/27/2011 11:29 AM, Tom Lane wrote:
> >> Given that nobody is supposed to push temporary branches to the master
> >> repo anyway, an intended branch removal should be a pretty darn rare
> >> event.
>
> > Pushing a local topic branch by mistake seem
The Postgres core team will be wrapping update releases for all
supported back branches this evening. These updates are prompted by
a minor security issue (reported by Apple, curiously enough) as well
as desire to push out some significant bug fixes that have been made
in the last few weeks.
My a
On Tue, 2011-01-25 at 05:57 -0500, Dan Ports wrote:
> This summary is right on. I would add one additional detail or
> clarification to the last point, which is that rather than checking for
> a cycle, we're checking for a transaction with both "in" and "out"
> conflicts, which every cycle must con
Greg Smith wrote:
I think a helpful next step here would be to put Robert's fsync
compaction patch into here and see if that helps. There are enough
backend syncs showing up in the difficult workloads (scale>=1000,
clients >=32) that its impact should be obvious.
Initial tests show everythin
On Thu, Jan 27, 2011 at 11:52 AM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Thu, Jan 27, 2011 at 11:41 AM, Bruce Momjian wrote:
>> >> Or for that we could just disable branch creation *completely*, and
>> >> then turn off that restriction that one time / year that we actually
>> >> create a
Robert Haas wrote:
> The master branch can be removed the same as any other one - just
> substitute master in place of REL9_0_STABLE in the above commands.
> But why would you do such a nutty thing? Worst case scenario looks to
> me like you type the first of those commands and then go "oh crud".
On Thu, Jan 27, 2011 at 18:19, Robert Haas wrote:
> On Thu, Jan 27, 2011 at 11:52 AM, Bruce Momjian wrote:
>> Robert Haas wrote:
>>> On Thu, Jan 27, 2011 at 11:41 AM, Bruce Momjian wrote:
>>> >> Or for that we could just disable branch creation *completely*, and
>>> >> then turn off that restric
Robert Haas wrote:
> So if someone does this (which does not look at all likely to me):
>
> git push origin :REL9_0_STABLE
> git branch -r -D origin/REL9_0_STABLE
> git branch -d REL9_0_STABLE
>
> ...then, yes, they will need to find someone who has run 'git
> pull' since the last change that
On Thu, Jan 27, 2011 at 12:18 PM, Greg Smith wrote:
> Greg Smith wrote:
>>
>> I think a helpful next step here would be to put Robert's fsync compaction
>> patch into here and see if that helps. There are enough backend syncs
>> showing up in the difficult workloads (scale>=1000, clients >=32) th
On Thu, Jan 27, 2011 at 12:24 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> So if someone does this (which does not look at all likely to me):
>>
>> git push origin :REL9_0_STABLE
>> git branch -r -D origin/REL9_0_STABLE
>> git branch -d REL9_0_STABLE
>>
>> ...then, yes, they will need to f
On Thu, Jan 27, 2011 at 09:02:26AM -0500, Robert Haas wrote:
> OK. I was thinking that instead moving this into
> eval_const_expressions(), we just make the logic in
> find_coercion_pathway() call the "exemptor" function (or whatever we
> call it) right around here:
>
> swi
On Thu, Jan 27, 2011 at 12:22 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> The master branch can be removed the same as any other one - just
>> substitute master in place of REL9_0_STABLE in the above commands.
>> But why would you do such a nutty thing? Worst case scenario looks to
>> me lik
On Jan 27, 2011, at 9:17 AM, Tom Lane wrote:
> The Postgres core team will be wrapping update releases for all
> supported back branches this evening. These updates are prompted by
> a minor security issue (reported by Apple, curiously enough) as well
> as desire to push out some significant bug
On Thu, Jan 27, 2011 at 17:52, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Thu, Jan 27, 2011 at 11:41 AM, Bruce Momjian wrote:
>> >> Or for that we could just disable branch creation *completely*, and
>> >> then turn off that restriction that one time / year that we actually
>> >> create a br
Jeff Davis wrote:
> To clarify, this means that it will get some false positives,
> right?
Yes. But the example you're about to get into isn't one of them.
> For instance:
>
> T1:
> get snapshot
>
> T2:
> get snapshot
> insert R1
> commit
>
> T1:
> read R1
> write R2
>
> T3:
"Kevin Grittner" wrote:
> Now, with serializable transactions, as you saw, T1 will be rolled
> back.
I should probably have mentioned, that if all the transactions were
SERIALIZABLE and the report of transactions from the batch was run
as SERIALIZABLE READ ONLY DEFERRABLE, the start of the rep
Robert Haas wrote:
Based on what I saw looking at this, I'm thinking that the backend
fsyncs probably happen in clusters - IOW, it's not 2504 backend fsyncs
spread uniformly throughout the test, but clusters of 100 or more that
happen in very quick succession, followed by relief when the
backgrou
On Wed, Jan 26, 2011 at 07:31:40AM -0500, Robert Haas wrote:
> I'd also suggest that this big if-block you changed to a case
> statement could just as well stay as an if-block. There are only
> three cases, and we want to avoid rearranging things more than
> necessary. It complicates both review
and...@dunslane.net (Andrew Dunstan) writes:
> On 01/27/2011 11:29 AM, Tom Lane wrote:
>> Given that nobody is supposed to push temporary branches to the master
>> repo anyway, an intended branch removal should be a pretty darn rare
>> event. Now, our committers all seem to be pretty careful peopl
Excerpts from Kevin Grittner's message of jue ene 27 13:22:12 -0300 2011:
> Bruce Momjian wrote:
>
> > http://en.wikipedia.org/wiki/Bytes#Unit_symbol
> >
> > You can see the chart on the right.
>
> According to which, the JEDEC standard requires KB and the IEC
> standard requires KiB. What s
On 26/01/11 04:51, Steve Singer wrote:
> On 10-12-23 08:45 AM, Jan Urbański wrote:
> I see you've merged the changes from the refactoring branch down but
> haven't yet posted an updated patch. This review is based on
> 2f2b4a33bf344058620a5c684d1f2459e505c727
Thanks for the review, I'm attaching
Alvaro Herrera wrote:
> Excerpts from Kevin Grittner's message of jue ene 27 13:22:12
-0300 2011:
>> Bruce Momjian wrote:
>>
>> > http://en.wikipedia.org/wiki/Bytes#Unit_symbol
>> >
>> > You can see the chart on the right.
>>
>> According to which, the JEDEC standard requires KB and the IEC
On 27/01/11 00:41, Jan Urbański wrote:
> I'm also attaching an updated version that should apply on top of my
> github refactor branch (or incrementally over the new set of refactor
> patches that I will post shortly to the refactor thread).
Attached is a patch for master, as the refactorings have
On 19/01/11 02:16, Hitoshi Harada wrote:
> Thanks. I tested the new version and looks ok. I'll mark it "Ready for
> Commiter".
Updated version against master.
Jan
diff --git a/src/include/catalog/pg_pltemplate.h b/src/include/catalog/pg_pltemplate.h
index d987ddc..c0578f9 100644
*** a/src/include
On 23/12/10 14:50, Jan Urbański wrote:
> Here's a patch implementing properly invalidating functions that have
> composite type arguments after the type changes, as mentioned in
> http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
> an incremental patch on top of the plpython-r
On 23/12/10 14:56, Jan Urbański wrote:
> Here's a patch implementing traceback support for PL/Python mentioned in
> http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
> an incremental patch on top of the plpython-refactor patch sent eariler.
Updated to master.
diff --git a/src
On 23/12/10 15:15, Jan Urbański wrote:
> Here's a patch implementing custom parsers for data types mentioned in
> http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
> an incremental patch on top of the plpython-refactor patch sent eariler.
Updated to master.
diff --git a/contr
On 23/12/10 15:32, Jan Urbański wrote:
> Here's a patch implementing explicitly starting subtransactions mentioned in
> http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
> an incremental patch on top of the spi-in-subxacts patch sent eariler.
Updated to the spi-in-subxacts ve
On 11/01/11 12:20, Jan Urbański wrote:
> On 11/01/11 01:27, Tom Lane wrote:
>> Hannu Krosing writes:
>>> On 10.1.2011 17:20, Jan Urbański wrote:
I changed that patch to use Perl instead of sed to generate the
exceptions, which should be a more portable.
Updated as an incremental patch o
(2011/01/27 22:26), Robert Haas wrote:
> 2011/1/27 KaiGai Kohei:
>> - Error messages become obtaining "%m", when the error was
>> originated from the libselinux interfaces. It will provides
>> DBA a hint why interactions with SELinux does not work well.
>
> No space before the ": %m", please.
With the attached patch I have managed to get Postgres built and running
a clean set of regression tests using the Mingw64 toolset on my 64bit
Windows7Pro machine.
There's lots of work still to do (lots of warnings to make go away, for
example), but this is a pretty encouraging start.
It s
On Fri, Jan 28, 2011 at 8:12 AM, Andrew Dunstan wrote:
>
> With the attached patch I have managed to get Postgres built and running a
> clean set of regression tests using the Mingw64 toolset on my 64bit
> Windows7Pro machine.
>
> There's lots of work still to do (lots of warnings to make go away,
On 01/27/2011 08:23 PM, Xiaobo Gu wrote:
On Fri, Jan 28, 2011 at 8:12 AM, Andrew Dunstan wrote:
With the attached patch I have managed to get Postgres built and running a
clean set of regression tests using the Mingw64 toolset on my 64bit
Windows7Pro machine.
There's lots of work still to do
On Fri, Jan 28, 2011 at 8:12 AM, Andrew Dunstan wrote:
>
> With the attached patch I have managed to get Postgres built and running a
> clean set of regression tests using the Mingw64 toolset on my 64bit
> Windows7Pro machine.
>
> There's lots of work still to do (lots of warnings to make go away,
On 01/27/2011 10:37 PM, Xiaobo Gu wrote:
--with-system-tzdata=/usr/share/zoneinfo
Why on earth are you doing this on Windows? That's crazy. Did you run
"make check"? You should always do that after a build before you install.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-h
On Fri, Jan 28, 2011 at 11:44 AM, Andrew Dunstan wrote:
>
>
> On 01/27/2011 10:37 PM, Xiaobo Gu wrote:
>>
>> --with-system-tzdata=/usr/share/zoneinfo
>
> Why on earth are you doing this on Windows? That's crazy. Did you run "make
> check"? You should always do that after a build before you install
On Thu, Jan 27, 2011 at 22:48, Dimitri Fontaine wrote:
> Itagaki Takahiro writes:
>> I found pg_restore with -c option fails when an extension is created
>> in pg_catalog.
> Nice catch, thank you very much (again) for finding those :)
Seems good.
>> extern bool extension_relocatable_p(Oid ext
I was thinking about full-page writes again tonight. I'm still
wondering about the feasibility of getting rid of full-page writes for
certain operations. We can do this, I think, in any case where we can
convince ourselves that if the original operation, or a redo of the
original operation, leave
Robert Haas wrote:
During each cluster, the system probably slows way down, and then recovers when
the queue is emptied. So the TPS improvement isn't at all a uniform
speedup, but simply relief from the stall that would otherwise result
from a full queue.
That does seem to be the case here.
>> I did s/failover/promote. Here is the updated patch.
>
> I rebased the patch to current git master.
I'm thinking about implementing a function which does a promotion for
the standby. It will make pgpool lot easier to control the promotion
since it allow to fire the promotion operation (either
pmod support (optional)
This is nearing completion. GiST is by far the most amount of effort
remaining that I'm aware of. Comments about the API, naming,
representation, interface, funcationality, grammar, etc. are welcome.
Regards,
Jeff Davis
rangetypes-20110127.patch.gz
Description
On Fri, Jan 28, 2011 at 08:44, Tatsuo Ishii wrote:
>>> I did s/failover/promote. Here is the updated patch.
>>
>> I rebased the patch to current git master.
>
> I'm thinking about implementing a function which does a promotion for
> the standby. It will make pgpool lot easier to control the promot
85 matches
Mail list logo