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 responding
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
2011/1/16 Simone Aiken sai...@ulfheim.net:
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
On Sun, Jan 16, 2011 at 02:26, Andreas Karlsson andr...@proxel.se wrote:
Hi Josh,
Contents and Purpose
This patch adds the \dL command in psql to list the procedual languages.
snip
Some things I noticed when using it though.
I do not like the use of parentheses in
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
On Sat, Jan 15, 2011 at 23:10, Dimitri Fontaine dimi...@2ndquadrant.fr 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
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
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
On Sat, Jan 15, 2011 at 12:17, Simon Riggs si...@2ndquadrant.com wrote:
On Sat, 2011-01-15 at 20:11 +0900, Fujii Masao wrote:
On Fri, Jan 14, 2011 at 9:00 PM, Simon Riggs si...@2ndquadrant.com wrote:
How hard would it be to have a pg_xlog_replay_until(xlog location or
timestamp), to have it
Robert Haas wrote:
On Sat, Jan 15, 2011 at 11:14 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Smith g...@2ndquadrant.com 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
Magnus Hagander mag...@hagander.net 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
Magnus Hagander mag...@hagander.net 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
Nicolas Barbier nicolas.barb...@gmail.com writes:
2011/1/16 Simone Aiken sai...@ulfheim.net:
... 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
Greg Smith g...@2ndquadrant.com 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
Robert Haas robertmh...@gmail.com writes:
On Sat, Jan 15, 2011 at 10:25 AM, Noah Misch n...@leadboat.com 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
On Sun, Jan 16, 2011 at 17:29, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net 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:
Magnus Hagander mag...@hagander.net writes:
+ * The file will be named base.tar[.gz] if it's for the main data directory
+ * or tablespaceoid.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
On Sun, 2011-01-16 at 11:47 -0500, Tom Lane wrote:
Greg Smith g...@2ndquadrant.com 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
On Sun, Jan 16, 2011 at 18:18, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
+ * The file will be named base.tar[.gz] if it's for the main data directory
+ * or tablespaceoid.tar[.gz] if it's for another tablespace.
Well we have UNIQUE, btree (spcname), so
Robert Haas robertmh...@gmail.com 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,
Josh Berkus j...@agliodbs.com 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
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
Magnus Hagander mag...@hagander.net 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
Hello
2011/1/15 Noah Misch n...@leadboat.com:
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
Magnus Hagander mag...@hagander.net writes:
On Sun, Jan 16, 2011 at 18:18, Tom Lane t...@sss.pgh.pa.us 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
Magnus Hagander mag...@hagander.net writes:
Well, we'd try to name the file for that oid-/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
On Sun, Jan 16, 2011 at 18:59, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
Well, we'd try to name the file for that oid-/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
Magnus Hagander mag...@hagander.net writes:
On Sun, Jan 16, 2011 at 18:59, Tom Lane t...@sss.pgh.pa.us 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
On Sun, Jan 16, 2011 at 19:03, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Sun, Jan 16, 2011 at 18:59, Tom Lane t...@sss.pgh.pa.us wrote:
Just stick with the OID. There's no reason that I can see to have
friendly names for these tarfiles --- in most
Simon Riggs si...@2ndquadrant.com 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
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
On Sun, Jan 16, 2011 at 18:45, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Magnus Hagander mag...@hagander.net 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
Greg Smith g...@2ndquadrant.com 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
Magnus Hagander mag...@hagander.net 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 directory|oid.tar.
Regards,
On Sun, Jan 16, 2011 at 19:21, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Magnus Hagander mag...@hagander.net 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
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
Greg Smith g...@2ndquadrant.com 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
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
Magnus Hagander mag...@hagander.net 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
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. It
Andreas Karlsson andr...@proxel.se 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
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
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 to you
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 many
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 mag...@hagander.net 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.
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
On Sun, Jan 16, 2011 at 21:51, Josh Berkus j...@agliodbs.com 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
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 t...@sss.pgh.pa.us 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
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
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 robertmh...@gmail.com writes:
On Sat, Jan 15, 2011 at 10:25 AM, Noah Misch n...@leadboat.com wrote:
Do you value test coverage so little?
If you're asking whether I think real-world usability is more
important than
On Sun, Jan 16, 2011 at 2:30 PM, Andy Colson a...@squeakycode.net 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
On Sat, Jan 15, 2011 at 6:28 PM, Josh Berkus j...@agliodbs.com 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
On Sun, Jan 16, 2011 at 12:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Jan 15, 2011 at 10:25 AM, Noah Misch n...@leadboat.com wrote:
Do you value test coverage so little?
If you're asking whether I think real-world usability is more
important
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
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.
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
On Sun, Jan 16, 2011 at 00:34, Josh Berkus j...@agliodbs.com 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
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 code ..
On Sun, Jan 16, 2011 at 5:37 PM, Kevin Grittner
kevin.gritt...@wicourts.gov 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
2011/1/16 Noah Misch n...@leadboat.com:
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))
On Mon, Jan 10, 2011 at 8:27 AM, Kevin Grittner
kevin.gritt...@wicourts.gov 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
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 jeff.ja...@gmail.com 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
On Tue, Jan 11, 2011 at 5:27 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Nov 30, 2010 at 3:29 PM, Greg Smith g...@2ndquadrant.com 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
Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com 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
On Sun, Jan 16, 2011 at 1:52 AM, Greg Smith g...@2ndquadrant.com 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 si...@2ndquadrant.com 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
On Sat, Jan 15, 2011 at 14:20, Andy Colson a...@squeakycode.net 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.
On Sun, Jan 16, 2011 at 7:34 AM, Josh Berkus j...@agliodbs.com 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
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 timeout,
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 jeff.ja...@gmail.com 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
On Sun, Jan 16, 2011 at 8:41 PM, Kevin Grittner
kevin.gritt...@wicourts.gov 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
On Sun, Jan 16, 2011 at 5:34 PM, Steve Singer ssinger...@sympatico.ca 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
On Sun, Jan 16, 2011 at 8:36 PM, Simon Riggs si...@2ndquadrant.com 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 +
On Sun, Jan 16, 2011 at 7:04 AM, Magnus Hagander mag...@hagander.net 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,
On Sun, Jan 16, 2011 at 11:52 PM, Magnus Hagander mag...@hagander.net 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
On Sun, Jan 16, 2011 at 9:19 AM, Magnus Hagander mag...@hagander.net 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
On Sat, Jan 15, 2011 at 8:33 PM, Tatsuo Ishii is...@postgresql.org 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.
On Sun, Jan 16, 2011 at 3:53 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Magnus Hagander mag...@hagander.net 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
2011/1/13 Pavel Golub pa...@microolap.com:
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:
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.
I must be
On Mon, Jan 17, 2011 at 11:32 AM, Tatsuo Ishii is...@postgresql.org 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
On Mon, Jan 17, 2011 at 11:16 AM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Jan 16, 2011 at 3:53 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Magnus Hagander mag...@hagander.net writes:
Is walreceiver something that the average DBA is going to realize
what it is? Perhaps go for
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
On Sat, Jan 15, 2011 at 8:26 PM, Andreas Karlsson andr...@proxel.se 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
On Sun, Jan 16, 2011 at 10:13 PM, Greg Smith g...@2ndquadrant.com 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.
On Sun, Jan 16, 2011 at 8:52 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Jan 16, 2011 at 7:04 AM, Magnus Hagander mag...@hagander.net 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?
On Sat, Jan 15, 2011 at 2:34 PM, Josh Berkus j...@agliodbs.com 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
On 01/16/2011 07:14 PM, Alex Hunsaker wrote:
On Sat, Jan 15, 2011 at 14:20, Andy Colsona...@squeakycode.net 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:
==
On Sun, Jan 16, 2011 at 9:32 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com 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
On Sun, Jan 16, 2011 at 10:40 PM, Josh Kupershmidt schmi...@gmail.com wrote:
On Sun, Jan 16, 2011 at 8:52 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Jan 16, 2011 at 7:04 AM, Magnus Hagander mag...@hagander.net wrote:
I do not like the use of parentheses in the usage description list
On Wed, Jan 12, 2011 at 5:12 AM, rsmogura rsmog...@softperience.eu 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
1 - 100 of 117 matches
Mail list logo
