Revisiting my original post:
http://archives.postgresql.org/pgsql-hackers/2010-11/msg00318.php
The "Web SQL" spec is still in its abandoned state.
Mozilla has stated that they do not want to support the API,
though they do allow extensions to send calls to sqlite directly.
Many posters respondin
Hello Postgres Hackers,
In reference to this todo item about clustering system table indexes,
( http://archives.postgresql.org/pgsql-hackers/2004-05/msg00989.php )
I have been studying the system tables to see which would benefit from
clustering. I have some index suggestions and a
2011/1/16 Simone Aiken :
> is there a way to make queries on the system tables show me what
> is actually there when I'm poking around? So for example:
>
> Select * from pg_type limit 1;
>
> tells me that the typoutput is 'boolout'. An english string rather
>
On Sun, Jan 16, 2011 at 02:26, Andreas Karlsson wrote:
> Hi Josh,
>
> Contents and Purpose
>
>
> This patch adds the \dL command in psql to list the procedual languages.
> Some things I noticed when using it though.
>
> I do not like the use of parentheses in the usage des
On 01/14/2011 05:23 PM, Stefan Kaltenbrunner wrote:
Hi all!
In preperation of some further improvments to our infrastructure, the
sysadmin team needs to move coridian.postgresql.org (aka
commitfest.postgresql.org) and mintaka.postgresql.org
(media.postgresql.org) to a different host within the
In 9.0, we specifically require using "replication" as database name
to start a replication session. In 9.1 we will have the REPLICATION
attribute to a role - should we change it so that "all" in database
includes replication connections? It certainly goes in the "principle
of least surprise" path.
Currently, replication connections *always* logs something like:
LOG: replication connection authorized: user=mha host=[local]
There's no way to turn that off.
I can't find the reasoning behind this - why is this one not
controlled by log_connections like normal ones? There's a comment in
the co
On Sat, Jan 15, 2011 at 23:10, Dimitri Fontaine wrote:
>>> That should be -D --pgdata, for consistency with pg_dump.
>>
>> pg_dump doesn't have a -D. I assume you mean pg_ctl / initdb?
>
> Yes, sorry, been too fast.
Ok. Updated patch that includes this change attached. I also changed
the tar dire
pg_stat_replication shows all replication information to all users, no
requirement to be a superuser or anything. That leaks a bunch of
information that regular pg_stat_activity doesn't - such as clients IP
addresses. And also of course all the replication info itself, which
may or may not be a pro
Since we now show the application name in pg_stat_replication, I think
it would make sense to have the walreceiver set
fallback_application_name on the connection string, like so:
diff --git a/src/backend/replication/libpqwalreceiver/libpqwalreceiver.c
b/src/backend/replication/libpqwalreceiver/li
On Sat, Jan 15, 2011 at 12:17, Simon Riggs wrote:
> On Sat, 2011-01-15 at 20:11 +0900, Fujii Masao wrote:
>> On Fri, Jan 14, 2011 at 9:00 PM, Simon Riggs wrote:
>> >> How hard would it be to have a pg_xlog_replay_until(> >> timestamp>), to have it resume recovery up to that point and then
>> >> p
Robert Haas wrote:
On Sat, Jan 15, 2011 at 11:14 AM, Tom Lane wrote:
Greg Smith writes:
Does try_relation_open need to have a lock acquisition timeout when AV
is calling it?
Hmm. I think when looking at the AV code, I've always subconsciously
assumed that try_relation_open wo
Magnus Hagander writes:
> In 9.0, we specifically require using "replication" as database name
> to start a replication session. In 9.1 we will have the REPLICATION
> attribute to a role - should we change it so that "all" in database
> includes replication connections? It certainly goes in the "p
Magnus Hagander writes:
> Since we now show the application name in pg_stat_replication, I think
> it would make sense to have the walreceiver set
> fallback_application_name on the connection string, like so:
Seems reasonable, but "postgres" is a mighty poor choice of name
for that, no? I don't
Nicolas Barbier writes:
> 2011/1/16 Simone Aiken :
>>... So even though the documentation says that column
>>maps to pg_proc.oid I can't then write:
>>Select * from pg_proc where oid = 'boolout';
> Type type of typoutput is "regproc", which is really an oid with a
Greg Smith writes:
> try_relation_open calls LockRelationOid, which blocks. There is also a
> ConditionalLockRelationOid, which does the same basic thing except it
> exits immediately, with a false return code, if it can't acquire the
> lock. I think we just need to nail down in what existing
Robert Haas writes:
> On Sat, Jan 15, 2011 at 10:25 AM, Noah Misch wrote:
>> Do you value test coverage so little?
> If you're asking whether I think real-world usability is more
> important than test coverage, then yes.
Quite honestly, I'd be inclined to rip out most of the DEBUG messages I
se
On Sun, Jan 16, 2011 at 17:29, Tom Lane wrote:
> Magnus Hagander writes:
>> Since we now show the application name in pg_stat_replication, I think
>> it would make sense to have the walreceiver set
>> fallback_application_name on the connection string, like so:
>
> Seems reasonable, but "postgres
Magnus Hagander writes:
>> + * The file will be named base.tar[.gz] if it's for the main data directory
>> + * or .tar[.gz] if it's for another tablespace.
>>
>> Well we have UNIQUE, btree (spcname), so maybe we can use that here?
> We could, but that would make it more likely to run into encodi
On Sun, 2011-01-16 at 11:47 -0500, Tom Lane wrote:
> Greg Smith writes:
> > try_relation_open calls LockRelationOid, which blocks. There is also a
> > ConditionalLockRelationOid, which does the same basic thing except it
> > exits immediately, with a false return code, if it can't acquire the
On Sun, Jan 16, 2011 at 18:18, Tom Lane wrote:
> Magnus Hagander writes:
>>> + * The file will be named base.tar[.gz] if it's for the main data directory
>>> + * or .tar[.gz] if it's for another tablespace.
>>>
>>> Well we have UNIQUE, btree (spcname), so maybe we can use that here?
>
>> We could
Robert Haas writes:
> Do we wish to officially document LOCK without TABLE as a good idea to
> start avoiding, in case we decide to do something about that in the
> future?
I'm still not for fixing the ambiguity that way. TABLE is an optional
noise word in other contexts, notably GRANT/REVOKE wh
Josh Berkus writes:
> I think we can be more specific on that last sentence; is there even any
> *theoretical* benefit to settings above 16MB, the size of a WAL segment?
IIRC there's a forced fsync at WAL segment switch, so no.
regards, tom lane
--
Sent via pgsql-hacker
On 01/15/2011 07:41 PM, Andrew Dunstan wrote:
On 01/15/2011 12:29 PM, Andrew Dunstan wrote:
I've been waiting for the latest FDW patches as patiently as I can,
and I've been reviewing them this morning, in particular the file_fdw
patch and how it interacts with the newly exposed COPY API.
Magnus Hagander writes:
>> What if you start a concurrent process that begins streaming the WAL
>> segments just before you start the backup, and you stop it after having
>> stopped the backup. I would think that then, the local received files
>> would be complete. We would only need a program a
Hello
2011/1/15 Noah Misch :
> Hello Pavel,
>
> I'm reviewing this patch for CommitFest 2011-01.
>
Thank you very much,
I am sending a updated version with little bit more comments. But I am
sure, so somebody with good English have to edit my comments.
Minimally I hope, so your questions will be
Magnus Hagander writes:
> On Sun, Jan 16, 2011 at 18:18, Tom Lane wrote:
>> No. Don't even think of going there --- we got rid of user-accessible
>> names in the filesystem years ago and we're not going back. Consider
>> CREATE TABLESPACE "/foo/bar" LOCATION '/foo/bar';
>
> Well, we'd tr
Magnus Hagander writes:
> Well, we'd try to name the file for that "-/foo/bar.tar", which I
> guess would break badly, yes.
> I guess we could normalize the tablespace name into [a-zA-Z0-9] or so,
> which would still be useful for the majority of cases, I think?
Just stick with the OID. There's
On Sun, Jan 16, 2011 at 18:59, Tom Lane wrote:
> Magnus Hagander writes:
>> Well, we'd try to name the file for that "-/foo/bar.tar", which I
>> guess would break badly, yes.
>
>> I guess we could normalize the tablespace name into [a-zA-Z0-9] or so,
>> which would still be useful for the majorit
Magnus Hagander writes:
> On Sun, Jan 16, 2011 at 18:59, Tom Lane wrote:
>> Just stick with the OID. There's no reason that I can see to have
>> "friendly" names for these tarfiles --- in most cases, the DBA will
>> never even deal with them, no?
> No, this is the output mode where the DBA choo
On Sun, Jan 16, 2011 at 19:03, Tom Lane wrote:
> Magnus Hagander writes:
>> On Sun, Jan 16, 2011 at 18:59, Tom Lane wrote:
>>> Just stick with the OID. There's no reason that I can see to have
>>> "friendly" names for these tarfiles --- in most cases, the DBA will
>>> never even deal with them,
Simon Riggs writes:
> I'm fairly confused by this thread.
> We *do* emit a message when we cancel an autovacuum task. We went to a
> lot of trouble to do that. The message is DEBUG2, and says
> "sending cancel to blocking autovacuum pid =".
That doesn't necessarily match one-to-one with actual c
Simon Riggs wrote:
I'm fairly confused by this thread.
That's becuase you think it has something to do with cancellation, which
it doesn't. The original report here noted a real problem but got the
theorized cause wrong. It turns out the code that acquires a lock when
autovacuum decides
On Sun, Jan 16, 2011 at 18:45, Dimitri Fontaine wrote:
> Magnus Hagander writes:
>>> What if you start a concurrent process that begins streaming the WAL
>>> segments just before you start the backup, and you stop it after having
>>> stopped the backup. I would think that then, the local receive
Greg Smith writes:
> Simon Riggs wrote:
>> I'm fairly confused by this thread.
> That's becuase you think it has something to do with cancellation, which
> it doesn't. The original report here noted a real problem but got the
> theorized cause wrong.
I think that cancellations are also a pote
Magnus Hagander writes:
> If you're doing a regular base backup, that's *not* for replication,
> you might want them in files.
+1
So, is that pg_restore -l idea feasible with your current tar format? I
guess that would translate to pg_basebackup -l |.tar.
Regards,
--
Dimitri Fontaine
http://2
On Sun, Jan 16, 2011 at 19:21, Dimitri Fontaine wrote:
> Magnus Hagander writes:
>> If you're doing a regular base backup, that's *not* for replication,
>> you might want them in files.
>
> +1
>
> So, is that pg_restore -l idea feasible with your current tar format? I
> guess that would translat
Tom Lane wrote:
No, I don't believe we should be messing with the semantics of
try_relation_open. It is what it is.
With only four pretty simple callers to the thing, and two of them
needing the alternate behavior, it seemed a reasonable place to modify
to me. I thought the "nowait" bool
Greg Smith writes:
> Tom Lane wrote:
>> No, I don't believe we should be messing with the semantics of
>> try_relation_open. It is what it is.
> With only four pretty simple callers to the thing, and two of them
> needing the alternate behavior, it seemed a reasonable place to modify
> to me.
This is a review of:
https://commitfest.postgresql.org/action/patch_view?id=468
Purpose:
Equal and not-equal _may_ be quickly determined if their lengths are different.
This _may_ be a huge speed up if we dont have to detoat.
The Patch:
==
I was able to read and understand t
Magnus Hagander writes:
> However, it's not quite that simple. "just adding a fork()" doesn't
> work on all our platforms, and you need to deal with feedback and such
> between them as well.
I'd think client-side, we have an existing implementation with the
parallel pg_restore option. Don't know
On Sun, 2011-01-16 at 13:08 -0500, Greg Smith wrote:
> Simon Riggs wrote:
> > I'm fairly confused by this thread.
> >
>
> That's becuase you think it has something to do with cancellation, which
> it doesn't. The original report here noted a real problem but got the
> theorized cause wrong.
Andreas Karlsson writes:
> On Sat, 2011-01-15 at 10:36 -0500, Tom Lane wrote:
>> But I can read the handwriting on the wall: if I want this done right,
>> I'm going to have to do it myself.
> Do I understand you correctly if I interpret what you would like to see
> is the same format used now in
I reviewed a couple patched, and I added my review to the commitfest page.
If I find a problem, its obvious I should mark the patch as "returned with
feedback".
But what if I'm happy with it? I'm not a hacker so cannot do C code review, should I
leave it alone? Mark it as "ready for committ
>> Select typoutput::oid from pg_type limit 1;
> Also, you *can* go back the other way. It's very common to write
>
> Select * from pg_proc where oid = 'boolout'::regproc
>
> rather than looking up the OID first.
> see "Object Identifier Types" in the manual.
Many thanks
On 1/15/11 4:30 PM, Bruce Momjian wrote:
> Josh Berkus wrote:
>> Last I remember, we were going to add this as an option. But I don't
>> see a patch in the queue. Am I missing it? Was I supposed to write it?
>
> I don't know, but let me add that I am confused how this would look to
> users. In
On 1/16/11 11:19 AM, Simon Riggs wrote:
> I would prefer it if we had a settable lock timeout, as suggested many
> moons ago. When that was discussed before it was said there was no
> difference between a statement timeout and a lock timeout, but I think
> there clearly is, this case being just one
> I suggest pg_stat_replication do just like pg_stat_activity, which is
> return NULL in most fields if the user isn't
> (superuser||same_user_as_that_session).
What session would that be, exactly?
I suggest instead either "superuser" or "replication" permissions.
--
Magnus Hagander writes:
> Is "walreceiver" something that "the average DBA" is going to realize
> what it is? Perhaps go for something like "replication slave"?
I think walreceiver is very good here, and the user is already
confronted to such phrasing.
http://www.postgresql.org/docs/9.0/inter
> In 9.0, we specifically require using "replication" as database name
> to start a replication session. In 9.1 we will have the REPLICATION
> attribute to a role - should we change it so that "all" in database
> includes replication connections? It certainly goes in the "principle
> of least surp
On Sun, Jan 16, 2011 at 21:51, Josh Berkus wrote:
>
>> I suggest pg_stat_replication do just like pg_stat_activity, which is
>> return NULL in most fields if the user isn't
>> (superuser||same_user_as_that_session).
>
> What session would that be, exactly?
The user doing the query to pg_stat_repl
>> I suggest instead either "superuser" or "replication" permissions.
>
> That's another idea.
Oh, wait. I take that back ... we're trying to encourage users NOT to
use the "replication" user as a login, yes?
--
-- Josh Berkus
Tom Lane writes:
> Another possibility is to disallow just the single case
> LOCK tablename NOWAIT
> ie, you can write NOWAIT if you include *either* the object type
> or the IN...MODE clause. This is not too hard as far as the grammar
> is concerned, but I'm not exactly sure how to documen
Hello
I looked on this patch too.
It's good idea.
I think, so we can have a function or macro that compare a varlena
sizes. Some like
Datum texteq(..)
{
if (!datumsHasSameLength(PG_GETARG_DATUM(0), PG_GETARG_DATUM(1))
PG_RETURN_FALSE();
... actual code ..
}
Regards
Pavel St
Em 16-01-2011 16:30, Andy Colson escreveu:
I reviewed a couple patched, and I added my review to the commitfest page.
If I find a problem, its obvious I should mark the patch as "returned
with feedback".
But what if I'm happy with it? I'm not a hacker so cannot do C code
review, should I leave
On Sun, Jan 16, 2011 at 12:07:44PM -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Sat, Jan 15, 2011 at 10:25 AM, Noah Misch wrote:
> >> Do you value test coverage so little?
>
> > If you're asking whether I think real-world usability is more
> > important than test coverage, then yes.
>
>
On Sun, Jan 16, 2011 at 2:30 PM, Andy Colson wrote:
> I reviewed a couple patched, and I added my review to the commitfest page.
>
> If I find a problem, its obvious I should mark the patch as "returned with
> feedback".
Only if it's got sufficiently serious flaws that getting it committed
during
On Sat, Jan 15, 2011 at 6:28 PM, Josh Berkus wrote:
>> If the problem is that all the freezing happens at once, then ISTM the
>> solution is to add a random factor. Say, when a tuple just passes the
>> lower threshold it has a 1% chance of being frozen. The chance grows
>> until it is 100% as it r
On Sun, Jan 16, 2011 at 12:07 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Jan 15, 2011 at 10:25 AM, Noah Misch wrote:
>>> Do you value test coverage so little?
>
>> If you're asking whether I think real-world usability is more
>> important than test coverage, then yes.
>
> Quite honestl
On Sun, Jan 16, 2011 at 06:49:27PM +0100, Pavel Stehule wrote:
> I am sending a updated version with little bit more comments. But I am
> sure, so somebody with good English have to edit my comments.
> Minimally I hope, so your questions will be answered.
Thanks. I edited the comments and white s
On Sun, Jan 16, 2011 at 01:05:11PM -0600, Andy Colson wrote:
> This is a review of:
> https://commitfest.postgresql.org/action/patch_view?id=468
Thanks!
> I created myself a more real world test, with a table with indexes and id's
> and a large toasted field.
> This will make about 600 records
I've taken a look at this version of the patch.
Submission Review
This version of the patch applies cleanly to master. It matches your git
repo and includes test + docs.
Usability Review
---
The command syntax now matches what was discussed during the last cf.
T
Robert Haas wrote:
> a quick-and-dirty attempt to limit the amount of I/O caused by hint
> bits. I'm still very interested in knowing what people think about
> that.
I found the elimination of the response-time spike promising. I
don't think I've seen enough data yet to feel comfortable endor
On Sun, Jan 16, 2011 at 00:34, Josh Berkus wrote:
> I think we can be more specific on that last sentence; is there even any
> *theoretical* benefit to settings above 16MB, the size of a WAL segment?
> Certainly there have been no test results to show any.
I don't know if it's applicable to real
On Sun, Jan 16, 2011 at 10:07:13PM +0100, Pavel Stehule wrote:
> I think, so we can have a function or macro that compare a varlena
> sizes. Some like
>
> Datum texteq(..)
> {
> if (!datumsHasSameLength(PG_GETARG_DATUM(0), PG_GETARG_DATUM(1))
> PG_RETURN_FALSE();
>
> ... actual
On Sun, Jan 16, 2011 at 5:37 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>> a quick-and-dirty attempt to limit the amount of I/O caused by hint
>> bits. I'm still very interested in knowing what people think about
>> that.
>
> I found the elimination of the response-time spike promising. I
>
2011/1/16 Noah Misch :
> On Sun, Jan 16, 2011 at 10:07:13PM +0100, Pavel Stehule wrote:
>> I think, so we can have a function or macro that compare a varlena
>> sizes. Some like
>>
>> Datum texteq(..)
>> {
>> if (!datumsHasSameLength(PG_GETARG_DATUM(0), PG_GETARG_DATUM(1))
>> PG_RETURN
On Mon, Jan 10, 2011 at 8:27 AM, Kevin Grittner
wrote:
> Attached is a rebased roll-up of the 3 and 3a patches from last month.
>
> -Kevin
Hi Kevin,
A review:
The main motivation for the patch is to allow future optimization of
read-only transactions, by preventing them from changing back to re
This is a review for the patch sent as
https://commitfest.postgresql.org/action/patch_view?id=456
== Submission ==
The patch applied cleanly atop of plpython refactor patches. The
format is git diff (though refactor patches is format-patch). I did
patch -p1.
It includes adequate amount of test. I
On Sun, Jan 16, 2011 at 6:58 PM, Jeff Janes wrote:
> None of the issues I raise above are severe. Does that mean I should
> change the status to "ready for committer"?
Sounds right to me.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via p
On Tue, Jan 11, 2011 at 5:27 PM, Robert Haas wrote:
> On Tue, Nov 30, 2010 at 3:29 PM, Greg Smith wrote:
>> One of the ideas Simon and I had been considering at one point was adding
>> some better de-duplication logic to the fsync absorb code, which I'm
>> reminded by the pattern here might be he
Tom Lane wrote:
> Simon Riggs writes:
>> It's a major undertaking trying to write software that runs against
>> PostgreSQL for more than one release. We should be making that easier,
>> not harder.
>
> None of the proposals would make it impossible to write a LOCK statement
> that works on all av
On Sun, Jan 16, 2011 at 1:52 AM, Greg Smith wrote:
> Fujii Masao wrote:
>>
>> +int XLOGbuffersMin = 8;
>>
>> XLOGbuffersMin is a fixed value. I think that defining it as a macro
>> rather than a variable seems better.
>>
>> + if (XLOGbuffers > 2048)
>> +
On Sun, 2011-01-16 at 16:30 -0800, Ron Mayer wrote:
> Tom Lane wrote:
> > Simon Riggs writes:
> >> It's a major undertaking trying to write software that runs against
> >> PostgreSQL for more than one release. We should be making that easier,
> >> not harder.
> >
> > None of the proposals would m
On Sat, Jan 15, 2011 at 14:20, Andy Colson wrote:
>
> This is a review of "plperl encoding issues"
>
> https://commitfest.postgresql.org/action/patch_view?id=452
Thanks for taking the time to review!
[...]
>
> The Patch:
> ==
> Applies clean to git head as of January 15 2011. PG built
On Sun, Jan 16, 2011 at 7:34 AM, Josh Berkus wrote:
> I think we can be more specific on that last sentence; is there even any
> *theoretical* benefit to settings above 16MB, the size of a WAL segment?
> Certainly there have been no test results to show any.
If the workload generates 16MB or mor
On Sun, 2011-01-16 at 12:50 -0800, Josh Berkus wrote:
> On 1/16/11 11:19 AM, Simon Riggs wrote:
> > I would prefer it if we had a settable lock timeout, as suggested many
> > moons ago. When that was discussed before it was said there was no
> > difference between a statement timeout and a lock tim
Robert Haas wrote:
> I think you may be confused about what the patch does - currently,
> pages with hint bit changes are considered dirty, period.
> Therefore, they are written whenever any other dirty page would be
> written: by the background writer cleaning scan, at checkpoints,
> and when a
On Sun, Jan 16, 2011 at 7:32 PM, Jeff Janes wrote:
> But since you already wrote a patch to do the whole thing, I figured
> I'd time it.
Thanks!
> I arranged to test an instrumented version of your patch under large
> shared_buffers of 4GB, conditions that would maximize the opportunity
> for it
On Sun, Jan 16, 2011 at 8:41 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
\>> I think you may be confused about what the patch does - currently,
>> pages with hint bit changes are considered dirty, period.
>> Therefore, they are written whenever any other dirty page would be
>> written: by the
On Sun, Jan 16, 2011 at 5:34 PM, Steve Singer wrote:
> I'm marking this as returned with feedback pending your answer on the
> possible memory leak above but I think the patch is very close to being
> ready.
Please use "Waiting on Author" if the patch is to be considered
further for this CommitFe
On Sun, Jan 16, 2011 at 8:36 PM, Simon Riggs wrote:
> I agree with you, but if we want it *this* release, on top of all the
> other features we have queued, then I suggest we compromise. If you hold
> out for more feature, you may get less.
>
> Statement timeout = 2 * (100ms + autovacuum_vacuum_co
On Sun, Jan 16, 2011 at 7:04 AM, Magnus Hagander wrote:
>> I do not like the use of parentheses in the usage description "list
>> (procedural) languages". Why not have it simply as "list procedural
>> languages"?
>
> Because it lists non-procedural langauges as well? (I didn't check it,
> that's j
On Sun, Jan 16, 2011 at 11:52 PM, Magnus Hagander wrote:
> So I'm back to my original question which is, how much work would this
> be? I don't know my way around that part so I can't estimate, and
> what's there so far is certainly a lot better than nothing, but if
> it's not a huge amount of wor
On Sun, Jan 16, 2011 at 9:19 AM, Magnus Hagander wrote:
> Currently, replication connections *always* logs something like:
> LOG: replication connection authorized: user=mha host=[local]
>
> There's no way to turn that off.
>
> I can't find the reasoning behind this - why is this one not
> contro
On Sat, Jan 15, 2011 at 8:33 PM, Tatsuo Ishii wrote:
>> When do the standby launch its walreceiver? It would be extra-nice for
>> the base backup tool to optionally continue streaming WALs until the
>> standby starts doing it itself, so that wal_keep_segments is really
>> deprecated. No idea how
On Sun, Jan 16, 2011 at 3:53 PM, Dimitri Fontaine
wrote:
> Magnus Hagander writes:
>> Is "walreceiver" something that "the average DBA" is going to realize
>> what it is? Perhaps go for something like "replication slave"?
>
> I think walreceiver is very good here, and the user is already
> confro
2011/1/13 Pavel Golub :
> Hello, Pgsql-hackers.
>
> I'm getting such warnings:
>
> pg_dump.c: In function 'dumpSequence':
> pg_dump.c:11449:2: warning: unknown conversion type character 'l' in format
> pg_dump.c:11449:2: warning: too many arguments for format
> pg_dump.c:11450:2: warning: unknown c
>> Good point. I have been always wondering why we can't use exiting WAL
>> transporting infrastructure for sending/receiving WAL archive
>> segments in streaming replication.
>> If my memory serves, Fujii has already proposed such an idea but was
>> rejected for some reason I don't understand.
>
On Mon, Jan 17, 2011 at 11:32 AM, Tatsuo Ishii wrote:
>>> Good point. I have been always wondering why we can't use exiting WAL
>>> transporting infrastructure for sending/receiving WAL archive
>>> segments in streaming replication.
>>> If my memory serves, Fujii has already proposed such an idea
On Mon, Jan 17, 2011 at 11:16 AM, Robert Haas wrote:
> On Sun, Jan 16, 2011 at 3:53 PM, Dimitri Fontaine
> wrote:
>> Magnus Hagander writes:
>>> Is "walreceiver" something that "the average DBA" is going to realize
>>> what it is? Perhaps go for something like "replication slave"?
>>
>> I think
I have finished a first run of benchmarking the current 9.1 code at
various sizes. See http://www.2ndquadrant.us/pgbench-results/index.htm
for many details. The interesting stuff is in Test Set 3, near the
bottom. That's the first one that includes buffer_backend_fsync data.
This iall on ex
On Sat, Jan 15, 2011 at 8:26 PM, Andreas Karlsson wrote:
> Hi Josh,
>
> Here is my review of this patch for the commitfest.
>
> Review of https://commitfest.postgresql.org/action/patch_view?id=439
Thanks a lot for the review!
> Contents and Purpose
>
>
> This patch adds the
On Sun, Jan 16, 2011 at 10:13 PM, Greg Smith wrote:
> I have finished a first run of benchmarking the current 9.1 code at various
> sizes. See http://www.2ndquadrant.us/pgbench-results/index.htm for many
> details. The interesting stuff is in Test Set 3, near the bottom. That's
> the first one
On Sun, Jan 16, 2011 at 8:52 PM, Robert Haas wrote:
> On Sun, Jan 16, 2011 at 7:04 AM, Magnus Hagander wrote:
>>> I do not like the use of parentheses in the usage description "list
>>> (procedural) languages". Why not have it simply as "list procedural
>>> languages"?
>>
>> Because it lists non-
On Sat, Jan 15, 2011 at 2:34 PM, Josh Berkus wrote:
> On 1/14/11 10:51 PM, Greg Smith wrote:
>>
>> ! Since the data is written out to disk at every transaction
>> commit,
>> ! the setting many only need to be be large enough to hold the
>> amount
>> ! of WAL data generated
On 01/16/2011 07:14 PM, Alex Hunsaker wrote:
On Sat, Jan 15, 2011 at 14:20, Andy Colson wrote:
This is a review of "plperl encoding issues"
https://commitfest.postgresql.org/action/patch_view?id=452
Thanks for taking the time to review!
[...]
The Patch:
==
Applies clean to git h
On Sun, Jan 16, 2011 at 9:32 AM, Tom Lane wrote:
> Josh Berkus writes:
>> I think we can be more specific on that last sentence; is there even any
>> *theoretical* benefit to settings above 16MB, the size of a WAL segment?
>
> IIRC there's a forced fsync at WAL segment switch, so no.
However oth
On Sun, Jan 16, 2011 at 10:40 PM, Josh Kupershmidt wrote:
> On Sun, Jan 16, 2011 at 8:52 PM, Robert Haas wrote:
>> On Sun, Jan 16, 2011 at 7:04 AM, Magnus Hagander wrote:
I do not like the use of parentheses in the usage description "list
(procedural) languages". Why not have it simply
On Wed, Jan 12, 2011 at 5:12 AM, rsmogura wrote:
> Dear hackers :) Could you look at this thread from General.
> ---
> I say the backend if you have one "row type" output result treats it as the
> full output result, it's really bad if you use STRUCT types (in your example
> you see few columns, b
1 - 100 of 117 matches
Mail list logo
