Fujii Masao wrote:
> On Tue, Apr 6, 2010 at 11:48 PM, Heikki Linnakangas
> wrote:
>> Fujii Masao wrote:
>>> On Tue, Apr 6, 2010 at 8:02 PM, Fujii Masao wrote:
> Should we throw an error in pg_xlogfile_name() if called during
> recovery? It's not doing anything useful as it is.
I have
2010/4/7 Greg Smith :
> Merlin Moncure wrote:
>
> On Tue, Apr 6, 2010 at 3:58 PM, Tom Lane wrote:
>
>
> Greg has the right idea: show debug_assertions.
>
>
> why not the entire set of configure options?
>
>
> Given that the standard way to find those is pg_config, there's a couple of
> reasons why
Merlin Moncure wrote:
On Tue, Apr 6, 2010 at 3:58 PM, Tom Lane wrote:
Greg has the right idea: show debug_assertions.
why not the entire set of configure options?
Given that the standard way to find those is pg_config, there's a couple
of reasons why not to prefer that, on top o
On Wed, Apr 7, 2010 at 1:48 AM, Heikki Linnakangas
wrote:
> Ok, here's what I came up with.
Looks OK to me.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Tue, Apr 6, 2010 at 11:48 PM, Heikki Linnakangas
wrote:
> Fujii Masao wrote:
>> On Tue, Apr 6, 2010 at 8:02 PM, Fujii Masao wrote:
Should we throw an error in pg_xlogfile_name() if called during
recovery? It's not doing anything useful as it is.
>>> I have no objection for now.
>>
>>
On Apr 6, 2010, at 5:23 PM, Andrew Dunstan wrote:
> It has been suggested in the past that we should have a full DBD interface in
> plperl, and indeed there was such an animal at one stage, although it was not
> compatibly licensed, and it is probably now way out of date.
>
> The current plperl
On Apr 6, 2010, at 5:06 PM, Tom Lane wrote:
> Somehow, emulating the above doesn't attract me nearly as much as it
> evidently does you. What happens in cases where the parser is unable
> to infer a data type, or infers the wrong one?
An exception should be thrown.
> Or even if it does
> infer
David E. Wheeler wrote:
Yes, I would use unknown, because as you said, in Perl the types of values are
unknown.
DBD::Pg makes extensive use of unknown for prepares.
It has been suggested in the past that we should have a full DBD
interface in plperl, and indeed there was such an animal
"David E. Wheeler" writes:
> DBD::Pg makes extensive use of unknown for prepares. If I do
> my $sth = $dbh->prepare('SELECT foo FROM bar WHERE baz = ?');
> DBD::Pg effectively sends:
> PREPARE dbdpg_1(unknown) AS SELECT from FROM bar WHERE baz = ?';
Somehow, emulating the above doesn't at
On Apr 6, 2010, at 4:54 PM, Tom Lane wrote:
>>try=# create or replace function try() returns void language plperl as $$
>>spi_prepare('select abs($1)', 'text');
>>$$;
>>CREATE FUNCTION
>>try=# select try();
>>ERROR: error from Perl function "try": function abs(text) do
Joseph Adams writes:
> Perhaps there could be conversion functions. E.g.:
Yeah, that's what I was thinking about.
> json_to_string('"hello"') yields 'hello'
> json_to_number('3.14159') yields '3.14159' as text
> (it is up to the user to cast it to the number type s/he wants)
> json_to_b
On Apr 6, 2010, at 4:55 PM, Andrew Dunstan wrote:
> Indeed it doesn't. But (as documented) the argument will be passed *from*
> *perl* as text and converted to the specified type in the glue code. See
> plperl.c for details.
Hrm. If the type is unknown, I think it should just be passed as a str
David E. Wheeler wrote:
On Apr 6, 2010, at 4:40 PM, Tom Lane wrote:
I tried this:
try=# create or replace function try() returns void language plperl as $$
spi_prepare('select length($1)', 'unknown');
$$;
CREATE FUNCTION
try=# select try();
ERROR: error from Perl f
"David E. Wheeler" writes:
> On Apr 6, 2010, at 4:40 PM, Tom Lane wrote:
>> Why would you think this is useful, considering that plperl has no
>> concept of SQL data types? Everything you could pass to
>> spi_exec_prepared is effectively text, no?
> try=# create or replace function try() ret
On Apr 6, 2010, at 4:40 PM, Tom Lane wrote:
>> I tried this:
>>try=# create or replace function try() returns void language plperl as $$
>>spi_prepare('select length($1)', 'unknown');
>>$$;
>>CREATE FUNCTION
>>try=# select try();
>>ERROR: error from Perl function "try
"David E. Wheeler" writes:
> I tried this:
> try=# create or replace function try() returns void language plperl as $$
> spi_prepare('select length($1)', 'unknown');
> $$;
> CREATE FUNCTION
> try=# select try();
> ERROR: error from Perl function "try": failed to find
Hackers,
I tried this:
try=# create or replace function try() returns void language plperl as $$
spi_prepare('select length($1)', 'unknown');
$$;
CREATE FUNCTION
try=# select try();
ERROR: error from Perl function "try": failed to find conversion function
from unkno
Magnus Hagander writes:
> On Wed, Apr 7, 2010 at 00:02, Tom Lane wrote:
>> Oh, another thought here: what is the effect of the combination of this
>> with your other proposal to add more timezones to the list?
> [ none ]
Ah, right, I hadn't looked closely at the logic before. Still have
two co
Tom Lane wrote:
> Alvaro Herrera writes:
> > I'm chasing an apparent index corruption problem, and I came across
> > something I can't quite explain in pg_filedump. Say I dump a non-leaf
> > btree index page:
>
> I think this is actually OK. Remember that in a non-rightmost page,
> item 1 is th
Tom Lane wrote:
> Alvaro Herrera writes:
> > I'm chasing an apparent index corruption problem, and I came across
> > something I can't quite explain in pg_filedump. Say I dump a non-leaf
> > btree index page:
>
> I think this is actually OK. Remember that in a non-rightmost page,
> item 1 is th
On Wed, Apr 7, 2010 at 00:02, Tom Lane wrote:
> Oh, another thought here: what is the effect of the combination of this
> with your other proposal to add more timezones to the list? In
> particular, what happens if we use the extended list in an unpatched
> system that doesn't know about those ne
How to set the collation of a database to the german phone book sort
order?
I did ask this on several places. Finally the moderator of pg-forum.de
recommended to ask here. See the discussion there:
http://www.pg-forum.de/konfiguration/4308-sortierfolge-de_de_phoneb.html
Environment: PostgreSQL 8.4
Alvaro Herrera writes:
> I'm chasing an apparent index corruption problem, and I came across
> something I can't quite explain in pg_filedump. Say I dump a non-leaf
> btree index page:
I think this is actually OK. Remember that in a non-rightmost page,
item 1 is the high key not a data entry.
Oh, another thought here: what is the effect of the combination of this
with your other proposal to add more timezones to the list? In
particular, what happens if we use the extended list in an unpatched
system that doesn't know about those new zone names? I'm wondering
if we *have* to make this
Magnus Hagander writes:
> On Tue, Apr 6, 2010 at 23:44, Tom Lane wrote:
>> I'm not clear on this. Would this patch fix a real seen-in-the-field
>> condition, or is it speculative? In particular, if the loop had kept
>> going in the complainant's machine, would it have found another entry
>> tha
On Tue, Apr 6, 2010 at 23:44, Tom Lane wrote:
> Magnus Hagander writes:
>> When diagnosing a problem for a guy in the german channel (with Stefan
>> as mediator :P), we've found a case where the timezone information in
>> the registry seem to be empty for some timezones. The current timezone
>> m
Hi,
I'm chasing an apparent index corruption problem, and I came across
something I can't quite explain in pg_filedump. Say I dump a non-leaf
btree index page:
***
* PostgreSQL File/Block Formatted Dump Utility - Version 8.3.0
*
* F
Magnus Hagander writes:
> When diagnosing a problem for a guy in the german channel (with Stefan
> as mediator :P), we've found a case where the timezone information in
> the registry seem to be empty for some timezones. The current timezone
> matching code will abort scanning when it comes across
Merlin Moncure writes:
> On Tue, Apr 6, 2010 at 3:58 PM, Tom Lane wrote:
>> Greg has the right idea: show debug_assertions.
> why not the entire set of configure options?
We've discussed that before. pg_config already provides that info,
and there was some concern about security risks of expos
When debugging the other timezone issue, I've come across a bunch of
timezones that are defined in Windows now (my check is 2003R2, which
is the newest one I have readily available) that aren't in our list.
This is because our list is based on Windows XP, and Microsoft have
pushed timezone updates
When diagnosing a problem for a guy in the german channel (with Stefan
as mediator :P), we've found a case where the timezone information in
the registry seem to be empty for some timezones. The current timezone
matching code will abort scanning when it comes across one of these,
thus claiming it c
On Tue, Apr 6, 2010 at 3:58 PM, Tom Lane wrote:
> Pavel Stehule writes:
>> it is little bit offtopic. Can we add info about assertation to
>> version() output?
>
> Greg has the right idea: show debug_assertions.
why not the entire set of configure options?
merlin
--
Sent via pgsql-hackers mai
> Josh, might you have got the numbers wrong when trying to match up query
> runtimes to their queries in the CSVLOG output? That might explain it. Most
> of the queries were BINDs.
I swept up some DEALLOCATEs by acccident, but those don't appreciably
affect the final numbers.
--
On Tue, 2010-04-06 at 10:09 +0300, Heikki Linnakangas wrote:
> > * Walsender and dblink are not interruptible on win32. - related thread
>
> I'd actually be happy to just leave it for 9.0, but it seems like
> consensus has been reached on how to fix it, and Fujii is working on a
> patch, so
On Tue, Apr 6, 2010 at 12:03 PM, Tom Lane wrote:
> Petr Jelinek writes:
>> Dne 6.4.2010 7:57, Joseph Adams napsal(a):
>>> To me, the most logical approach is to do the obvious thing: make
>>> JSON's 'null' be SQL's NULL. For instance, SELECTing on a table with
>>> NULLs in it and converting the
Pavel Stehule writes:
> it is little bit offtopic. Can we add info about assertation to
> version() output?
Greg has the right idea: show debug_assertions.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your su
2010/4/6 Tom Lane :
> "David E. Wheeler" writes:
>> On Apr 6, 2010, at 11:15 AM, Tom Lane wrote:
>>> Huh. I'm still curious, because in my test the overhead of those
>>> options seemed to be about 3x. So there's still something considerably
>>> different between what you did and what I did.
>
>>
Magnus Hagander writes:
> On Mon, Mar 29, 2010 at 11:47 AM, Takahiro Itagaki
> wrote:
>> A patch attached. The name of "PGMODULEEXPORT" might be arguable.
> I agree with this in principle, but won't this break every single
> add-on module out there that supports Win32?
The patch didn't touch th
On Apr 6, 2010, at 12:50 PM, Tom Lane wrote:
> I hadn't, but since you mention it: 10 iterations take about 7.5sec
> with non-assert CVS HEAD and 15sec with asserts, on a 2008 Macbook Pro.
> Color me still confused.
Well it's not just pings that the bricolage tests were running, of course.
J
"David E. Wheeler" writes:
> On Apr 6, 2010, at 11:15 AM, Tom Lane wrote:
>> Huh. I'm still curious, because in my test the overhead of those
>> options seemed to be about 3x. So there's still something considerably
>> different between what you did and what I did.
> Are you doing this on a Mac
Tom Lane wrote:
Robert Haas writes:
With this, I disagree. I see no reason to suppose that a JSON NULL
and an SQL NULL are the same thing.
Oh. If they're not the same, then the problem is easily dodged, but
then what *is* a JSON null?
Probably the same as the javascript null.
r
On Tue, 2010-04-06 at 11:06 -0400, Robert Haas wrote:
> * Redefine smart shutdown in standby mode?
> >>> Drop. Too big a change at this point.
> >>
> >> We have a working patch for this - I want to commit it. I don't think
> >> it's a big change, and the current behavior is extremely pat
On Tue, 2010-04-06 at 20:27 +0200, Erik Rijkers wrote:
> Was the issue eventually found/solved?
We think so, but the event was not conclusively traceable.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
On Apr 6, 2010, at 11:15 AM, Tom Lane wrote:
>> By stupidly having configured with --enable-cassert --enable-debug without
>> realizing it. I've just rebuilt without them and run the tests again using
>> the default postgresql.conf and I'm back down to 57s and 46s over two runs.
>
> Huh. I'm s
David E. Wheeler wrote:
By stupidly having configured with --enable-cassert --enable-debug without
realizing it. I've just rebuilt without them and run the tests again using the
default postgresql.conf and I'm back down to 57s and 46s over two runs.
Every performance test I run, regardless
On Tue, April 6, 2010 19:29, Heikki Linnakangas wrote:
[...]
>
> I've added the ones that should be addressed in the future to the TODO
> list. I added a new subsection for standby server and streaming
> replication related items:
> http://wiki.postgresql.org/wiki/Todo#Standby_server_mode
>
I repo
On Tue, Apr 6, 2010 at 2:20 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Apr 6, 2010 at 1:31 PM, Tom Lane wrote:
>>> Oh. If they're not the same, then the problem is easily dodged, but
>>> then what *is* a JSON null?
>
>> I assume we're going to treat JSON much like XML: basically text,
Robert Haas writes:
> On Tue, Apr 6, 2010 at 1:31 PM, Tom Lane wrote:
>> Oh. If they're not the same, then the problem is easily dodged, but
>> then what *is* a JSON null?
> I assume we're going to treat JSON much like XML: basically text, but
> with some validation (and perhaps canonicalizatio
"David E. Wheeler" writes:
> On Apr 6, 2010, at 10:17 AM, Tom Lane wrote:
>> So I'm not sure where your 15x is coming from, but I don't see it.
> By stupidly having configured with --enable-cassert --enable-debug without
> realizing it. I've just rebuilt without them and run the tests again usin
On Tue, Apr 6, 2010 at 1:31 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Apr 6, 2010 at 12:03 PM, Tom Lane wrote:
>>> To me, what this throws into question is not so much whether JSON null
>>> should equate to SQL NULL (it should), but whether it's sane to accept
>>> atomic values.
>
>>
On Apr 6, 2010, at 10:52 AM, David E. Wheeler wrote:
> Oh FFS! I was looking at the wrong build script. It was indeed built with
> --enable-cassert --enable-debug. Grrr.
>
> Well, that's likely the culprit right there. I'm rebuilding without those now
> and hopefully my tests will be back down
On Apr 6, 2010, at 10:17 AM, Tom Lane wrote:
> So I'm not sure where your 15x is coming from, but I don't see it.
By stupidly having configured with --enable-cassert --enable-debug without
realizing it. I've just rebuilt without them and run the tests again using the
default postgresql.conf and
On Apr 6, 2010, at 9:08 AM, David E. Wheeler wrote:
>> For example, --enable-debug or --enable-cassert.
>
> No.
Oh FFS! I was looking at the wrong build script. It was indeed built with
--enable-cassert --enable-debug. Grrr.
Well, that's likely the culprit right there. I'm rebuilding without
On Tue, Apr 6, 2010 at 12:08 PM, David E. Wheeler wrote:
> On Apr 6, 2010, at 2:32 AM, Takahiro Itagaki wrote:
>
>>> In our test, which does 5801 of these pings during the test, they take
>>> an average of 15x longer to execute on 9.0 as 8.4 ( 0.77ms vs. 0.05ms ).
>>>
>>> Any clue why this would b
On Mon, Mar 29, 2010 at 11:47 AM, Takahiro Itagaki
wrote:
>
> "Vladimir Barzionov" wrote:
>
>> Same problem was already discussed for example here
>> http://dbaspot.com/forums/postgresql/393683-re-general-custom-c-function-palloc-broken.html
>>
>> Looks like the simplest way for correcting the is
Robert Haas writes:
> On Tue, Apr 6, 2010 at 12:03 PM, Tom Lane wrote:
>> To me, what this throws into question is not so much whether JSON null
>> should equate to SQL NULL (it should), but whether it's sane to accept
>> atomic values.
> With this, I disagree. I see no reason to suppose that a
On Tue, Apr 6, 2010 at 12:03 PM, Tom Lane wrote:
> Petr Jelinek writes:
>> Dne 6.4.2010 7:57, Joseph Adams napsal(a):
>>> To me, the most logical approach is to do the obvious thing: make
>>> JSON's 'null' be SQL's NULL. For instance, SELECTing on a table with
>>> NULLs in it and converting the
Tom Lane wrote:
> Heikki Linnakangas writes:
>> I triaged the list of open items on the Streaming Replication wiki page.
>> I propose that we drop the ones I've marked as Drop below, and move the
>> remaining items to the main Open Items page for better visibility.
>
> By "drop" do you mean "move
Tom Lane writes:
> Josh Berkus writes:
>> Continuing the performance test:
>> DBD, like a number of monitoring systems, does "pings" on the database
>> which look like this:
>> SELECT 'DBD::Pg ping test';
>> In our test, which does 5801 of these pings during the test, they take
>> an average o
On Tue, Apr 6, 2010 at 11:05 AM, Alvaro Herrera
wrote:
> Joseph Adams escribió:
>
>> http://constellationmedia.com/~funsite/static/json-0.0.2.tar.bz2
>>
>> My json.c is now 1161 lines long, so I can't quite call it "small" anymore.
>
> Just noticed you don't check the return value of malloc and fr
On Apr 6, 2010, at 7:28 AM, Tom Lane wrote:
> There's something wrong with your test setup. Or, if you'd like me to
> think that there isn't, provide a self-contained test case. I ran a
> small program that does
>
> for (i = 0; i < 1; i++)
> {
> res = PQexec(conn,
Fujii Masao writes:
> On Tue, Apr 6, 2010 at 4:09 PM, Heikki Linnakangas
> wrote:
>>> * Fix things so that any such variables inherited from the server
>>> environment are intentionally *NOT* used for making SR connections.
>>
>> Drop. Besides, we have the same problem with dblink, and I do
Simon Riggs wrote:
> On Tue, 2010-04-06 at 16:07 +0900, Fujii Masao wrote:
>> On Tue, Apr 6, 2010 at 3:47 PM, Heikki Linnakangas
>> wrote:
>>> To follow up on the discussion here:
>>>
>>> http://archives.postgresql.org/pgsql-docs/2010-02/msg00039.php
>>>
>>> It seems like a big oversight that ther
On Tue, Apr 6, 2010 at 2:25 PM, Fujii Masao wrote:
> On Mon, Apr 5, 2010 at 3:18 PM, Fujii Masao wrote:
>> On Fri, Apr 2, 2010 at 11:11 PM, Magnus Hagander wrote:
>>> More to the point, I'm not sure I like the creation of yet another DLL
>>> to deal with this. The reason this isn't just exported
Heikki Linnakangas writes:
> Ok, here's a patch to add signaling between walreceiver and startup
> process. It indeed isn't much code, and seems pretty safe
Great news! Thanks,
--
dim
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
ht
On Apr 6, 2010, at 6:07 AM, Merlin Moncure wrote:
>> In our test, which does 5801 of these pings during the test, they take
>> an average of 15x longer to execute on 9.0 as 8.4 ( 0.77ms vs. 0.05ms ).
>
> did your pings change?
No.
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On Apr 6, 2010, at 2:32 AM, Takahiro Itagaki wrote:
>> In our test, which does 5801 of these pings during the test, they take
>> an average of 15x longer to execute on 9.0 as 8.4 ( 0.77ms vs. 0.05ms ).
>>
>> Any clue why this would be?
>
> Did you use the same configure options between them?
Ye
Heikki Linnakangas writes:
> I triaged the list of open items on the Streaming Replication wiki page.
> I propose that we drop the ones I've marked as Drop below, and move the
> remaining items to the main Open Items page for better visibility.
By "drop" do you mean "move to TODO"? At least some
Petr Jelinek writes:
> Dne 6.4.2010 7:57, Joseph Adams napsal(a):
>> To me, the most logical approach is to do the obvious thing: make
>> JSON's 'null' be SQL's NULL. For instance, SELECTing on a table with
>> NULLs in it and converting the result set to JSON would yield a
>> structure with 'null
On Apr 6, 2010, at 1:59 AM, Andrew Dunstan wrote:
> This needs to be profiled. Otherwise we'd just be speculating on possible
> causes with no real hard data. (This is where tools like oprofile come in
> handy, but I have no idea if something similar is available on OSX.)
I think OS X has dtrac
On Tue, Apr 6, 2010 at 10:36 AM, Heikki Linnakangas
wrote:
> Robert Haas wrote:
>> On Tue, Apr 6, 2010 at 3:09 AM, Heikki Linnakangas
>> wrote:
* Add the GUC parameter to specify the maximum number of log file
segments held in pg_xlog directory to send to the standby server. Which
Joseph Adams escribió:
> http://constellationmedia.com/~funsite/static/json-0.0.2.tar.bz2
>
> My json.c is now 1161 lines long, so I can't quite call it "small" anymore.
Just noticed you don't check the return value of malloc and friends.
How do you intend to handle that? There are various plac
Fujii Masao wrote:
> On Tue, Feb 23, 2010 at 1:44 PM, Fujii Masao wrote:
>> recovery.conf.sample has the following section for Hot Standby.
>> Is this still required?
>>
>>> #---
>>> # HOT STANDBY PARAMETERS
>>> #-
On Mon, Apr 5, 2010 at 11:50 PM, Joseph Adams
wrote:
> Another JSON strictness issue: the JSON standard (
> http://www.ietf.org/rfc/rfc4627.txt ) states that JSON text can only
> be an array or object. However, my implementation currently accepts
> any valid value. Thus, '3', '"hello"', 'true',
Fujii Masao wrote:
> On Tue, Apr 6, 2010 at 8:02 PM, Fujii Masao wrote:
>>> Should we throw an error in pg_xlogfile_name() if called during
>>> recovery? It's not doing anything useful as it is.
>> I have no objection for now.
>
> Here is the patch.
> ...
> + if (RecoveryInProgress())
> +
Robert Haas wrote:
> On Tue, Apr 6, 2010 at 3:09 AM, Heikki Linnakangas
> wrote:
>>> * Add the GUC parameter to specify the maximum number of log file
>>> segments held in pg_xlog directory to send to the standby server. Which is
>>> useful to avoid disk full in the primary.
>> Not only to a
Josh Berkus writes:
> Continuing the performance test:
> DBD, like a number of monitoring systems, does "pings" on the database
> which look like this:
> SELECT 'DBD::Pg ping test';
> In our test, which does 5801 of these pings during the test, they take
> an average of 15x longer to execute on
Simon Riggs writes:
> On Tue, 2010-04-06 at 09:57 -0400, Tom Lane wrote:
>> Or use errmsg_internal instead of errmsg.
> I've changed them to elog() before you said this. Would you like me to
> change them to errmsg_internal or do you mean "...as an option in the
> future"?
It's just a different
On Tue, 2010-04-06 at 09:57 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > On tis, 2010-04-06 at 10:30 +0100, Simon Riggs wrote:
> >> These are all DEBUG messages. Can you explain "marked differently" so I
> >> can do that for you?
>
> > Then it would be better to convert them to use elog(
Heikki Linnakangas writes:
> Ok, here's a patch to add signaling between walreceiver and startup
> process. It indeed isn't much code, and seems pretty safe, so if no-one
> objects strongly, I'll commit.
I object --- this seems like a large change to be sticking in at this
point with no testing.
Peter Eisentraut writes:
> On tis, 2010-04-06 at 10:30 +0100, Simon Riggs wrote:
>> These are all DEBUG messages. Can you explain "marked differently" so I
>> can do that for you?
> Then it would be better to convert them to use elog() instead of
> ereport().
Or use errmsg_internal instead of er
It would be useful to have a relation such that all dirtied buffers got
written out even for failed transactions (barring a crash) and such that
read-any-undeleted were easy to do, despite the non-ACIDity. The overhead of a
side transaction seems overkill for such things as logs or advisory rel
On Tue, 2010-04-06 at 16:01 +0300, Heikki Linnakangas wrote:
> > Having the Startup process wait does not buy us anything at all.
> > Currently if the Startup process finishes more quickly than the
> > WALreceiver it will wait for 100ms.
>
> Ok, here's a patch to add signaling between walreceiver
On Tue, Apr 6, 2010 at 1:47 AM, Josh Berkus wrote:
> Hackers,
>
> Continuing the performance test:
>
> DBD, like a number of monitoring systems, does "pings" on the database
> which look like this:
>
> SELECT 'DBD::Pg ping test';
>
> In our test, which does 5801 of these pings during the test, the
Simon Riggs wrote:
> On Tue, 2010-04-06 at 12:38 +0300, Heikki Linnakangas wrote:
>> Simon Riggs wrote:
>>> On Tue, 2010-04-06 at 10:19 +0300, Heikki Linnakangas wrote:
Fujii Masao wrote:
> On Tue, Apr 6, 2010 at 3:29 AM, Simon Riggs wrote:
>> I was also surprised to note that the Sta
Loïc Vaumerel writes:
> All solutions I found are working the same way : they use dblink.
> I consider these solution more as handiwork than a clean solution.
> I am a little bit concerned about side effects as dblink were not
> intially designed for this.
See plproxy which is designed for this k
Heikki Linnakangas writes:
> When the startup process wakes up after sleep to replay WAL, it does
> replay all the WAL streamed that far. And if more WAL if streamed during
> the replay, it's replayed too before the next sleep. But when it does
> reach the end of already-streamed WAL, it sleeps fo
On Mon, Apr 5, 2010 at 3:18 PM, Fujii Masao wrote:
> On Fri, Apr 2, 2010 at 11:11 PM, Magnus Hagander wrote:
>> More to the point, I'm not sure I like the creation of yet another DLL
>> to deal with this. The reason this isn't just exported from the main
>> backend is the same reason we created t
On Tue, Apr 6, 2010 at 8:01 AM, Simon Riggs wrote:
> On Tue, 2010-04-06 at 07:47 -0400, Robert Haas wrote:
>
>> I've been thinking that the reason we weren't going to beta was
>> because of the SR open items, but I'm starting to think there's not
>> much left that really needs to be dealt with. T
I wrote my previous email before reading this.
On Tue, Apr 6, 2010 at 3:09 AM, Heikki Linnakangas
wrote:
> I triaged the list of open items on the Streaming Replication wiki page.
> I propose that we drop the ones I've marked as Drop below, and move the
> remaining items to the main Open Items pa
On Tue, 2010-04-06 at 07:47 -0400, Robert Haas wrote:
> I've been thinking that the reason we weren't going to beta was
> because of the SR open items, but I'm starting to think there's not
> much left that really needs to be dealt with. The ones from that list
> I think we should fix yet are:
>
On Tue, Apr 6, 2010 at 8:02 PM, Fujii Masao wrote:
>> Should we throw an error in pg_xlogfile_name() if called during
>> recovery? It's not doing anything useful as it is.
>
> I have no objection for now.
Here is the patch.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT
On Tue, 2010-04-06 at 16:07 +0900, Fujii Masao wrote:
> On Tue, Apr 6, 2010 at 3:47 PM, Heikki Linnakangas
> wrote:
> > To follow up on the discussion here:
> >
> > http://archives.postgresql.org/pgsql-docs/2010-02/msg00039.php
> >
> > It seems like a big oversight that there's no way to insert qu
On Tue, Apr 6, 2010 at 7:06 AM, Heikki Linnakangas
wrote:
> Simon Riggs wrote:
>> I am surprised at your arguments for simplicity. With Hot Standby you
>> have insisted that everything should be in place. With SR you seem to
>> have just stopped at a barely working, poorly documented implementatio
On Wed, 2010-03-03 at 21:51 +0900, Fujii Masao wrote:
> The attached patch removes the unnecessary section about HS from
> recovery.conf.sample. Also it changes the grouping of parameters
> in recovery.conf.sample as mentioned above.
I think that comment block is useful for people to remind them
On Tue, 2010-04-06 at 14:06 +0300, Heikki Linnakangas wrote:
> If you insist, I'll work out a patch to send a signal to startup process
> after every fsync(), but it really doesn't seem very important given
> that there's always a delay there anyway.
>
> > We both know you can fix these things ea
Dimitri Fontaine wrote:
> Heikki Linnakangas writes:
>> Well, it would still be useful, as it would shorten the delay. But yeah,
>> there's a delay in asynchronous replication anyway, so we decided to
>> keep it simple and just poll. It's not ideal and definitely needs to be
>> revisited for synch
On Tue, Apr 6, 2010 at 8:06 PM, Heikki Linnakangas
wrote:
> If you insist, I'll work out a patch to send a signal to startup process
> after every fsync(), but it really doesn't seem very important given
> that there's always a delay there anyway.
Agreed. Even if we get rid of the delay of startu
Heikki Linnakangas writes:
> Well, it would still be useful, as it would shorten the delay. But yeah,
> there's a delay in asynchronous replication anyway, so we decided to
> keep it simple and just poll. It's not ideal and definitely needs to be
> revisited for synchronous mode in the future. Sam
Simon Riggs wrote:
> I am surprised at your arguments for simplicity. With Hot Standby you
> have insisted that everything should be in place. With SR you seem to
> have just stopped at a barely working, poorly documented implementation.
That's opposite to my recollection of the hot standby develo
1 - 100 of 119 matches
Mail list logo
