2013-08-27 01:24 keltezéssel, Andrew Gierth írta:
Latest version of patch. This should be it as far as code goes; there
may be some more regression test work, and a doc patch will be
forthcoming.
This version supports, in addition to the previous stuff:
[snip]
In my limited testing, it works
On 08/27/2013 01:56 AM, Antonin Houska wrote:
However what you stress now is control of the (continuous) WAL stream
and thus something that affects normal operation, rather than setup. I
still think the pg_basebackup does not have to throttle the WAL stream,
so this your request does not
2013/8/24 Tom Lane t...@sss.pgh.pa.us
Pavel Stehule pavel.steh...@gmail.com writes:
Oracle has a special function for returning sets from procedures - see a
new functionality Implicit Result Sets
http://tkyte.blogspot.cz/2013/07/12c-implicit-result-sets.html
That article is worth
On 08/27/2013 05:06 AM, David Rowley wrote:
Heikki wrote that it might be useful to allow formatting in the
log_line_prefix here
http://www.postgresql.org/message-id/5187cadb.50...@vmware.com
I thought I'd take a bash at implementing space padding part on
log_line_prefix options.
It's been
Hi All,
I want to create a materialized view as the output of a plpgsql function
returning a set of rows. But that function creates temporary tables and
thus can not be used for creating materialized view as per the
documentation at
On 7/29/13 2:04 AM, KONDO Mitsumasa wrote:
I think that it is almost same as small dirty_background_ratio or
dirty_background_bytes.
The main difference here is that all writes pushed out this way will be
to a single 1GB relation chunk. The odds are better that multiple
writes will combine,
On Tue, Aug 27, 2013 at 7:55 PM, Vik Fearing vik.fear...@dalibo.com wrote:
On 08/27/2013 05:06 AM, David Rowley wrote:
Heikki wrote that it might be useful to allow formatting in the
log_line_prefix here
http://www.postgresql.org/message-id/5187cadb.50...@vmware.com
I thought I'd take
On Sun, Aug 25, 2013 at 3:21 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Sat, Aug 24, 2013 at 2:46 PM, Sawada Masahiko sawada.m...@gmail.com
wrote:
On Sat, Aug 24, 2013 at 3:14 AM, Josh Berkus j...@agliodbs.com wrote:
On 08/23/2013 12:42 AM, Sawada Masahiko wrote:
in case (a), those
On Tue, Aug 20, 2013 at 2:37 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Throttling in the client seems much better to me. TCP is designed to handle
a slow client.
Other people have already offered some good points in this area, but
let me just add one thought that I don't think has
On Tue, Aug 27, 2013 at 12:58 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Aug 20, 2013 at 2:37 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Throttling in the client seems much better to me. TCP is designed to
handle
a slow client.
Other people have already offered some
On 08/27/2013 01:58 PM, Robert Haas wrote:
On Tue, Aug 20, 2013 at 2:37 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Throttling in the client seems much better to me. TCP is designed to handle
a slow client.
Other people have already offered some good points in this area, but
let
Boszormenyi Zoltan z...@cybertec.at writes:
When adding regression tests, can you please add intentional
syntax error cases to exercise all the new ereport()s?
Please do not add test cases merely to prove that. Yeah, you should
probably have exercised each error case in devel testing, but that
Hi Robert,
On 2013-08-17 12:08:17 -0400, Robert Haas wrote:
On Sun, Aug 11, 2013 at 1:31 AM, Andres Freund and...@anarazel.de wrote:
So, I'd suggest something like:
typedef enum BgwHandleStatus {
BGWH_SUCCESS, /* sucessfully got status */
BGWH_NOT_YET, /* worker hasn't started
On 2013-07-26 08:50:51 -0400, Robert Haas wrote:
Btw, you seem to want to support this in bgworkers started by a
bgworker. That's not going to work without some changes if the
intermediate bgworker is one without a backend since those don't use
procsignal_sigusr1_handler.
Hi Robert,
[just sending an email which sat in my outbox for two weeks]
On 2013-08-13 21:09:06 -0400, Robert Haas wrote:
...
Nice to see this coming. I think it will actually be interesting for
quite some things outside parallel query, but we'll see.
I've not yet looked at the code, so I just
On 2013-08-27 15:34:22 +0900, Michael Paquier wrote:
I have been working a little bit more on this patch for the next
commit fest. Compared to the previous version, I have removed the part
of the code where process running REINDEX CONCURRENTLY was waiting for
transactions holding a snapshot
Hi Noah,
On 2013-06-09 17:25:59 -0400, Noah Misch wrote:
*** a/src/backend/tcop/postgres.c
--- b/src/backend/tcop/postgres.c
***
*** 69,74
--- 69,75
#include tcop/tcopprot.h
#include tcop/utility.h
#include utils/lsyscache.h
+ #include utils/memdebug.h
Sent from my iPad
On 27-Aug-2013, at 19:44, Andres Freund and...@2ndquadrant.com wrote:
Hi Noah,
On 2013-06-09 17:25:59 -0400, Noah Misch wrote:
*** a/src/backend/tcop/postgres.c
--- b/src/backend/tcop/postgres.c
***
*** 69,74
--- 69,75
#include tcop/tcopprot.h
Hi,
pg_xlogdump cannot properly be built with pgxs since it needs a
sourcetree around. That already has confused some users...
How about the attached patch which will tell it's not supported instead
of an ominous build error about files that have no rules?
Greetings,
Andres Freund
--
Andres
Hi,
Thanks to the valgrind instrumentation I found a small oversight in the
relfilenodemap patch which is fixed in the attached patch.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
From
On 08/27/2013 10:36 AM, Heikki Linnakangas wrote:
0001-Divorce-pg_dump-E-option-from-PGCLIENTENCODING.patch
Separates pg_dump -E from PGCLIENTENCODING.
Wouldn't it be better to do this another way? Separating these two will
be confusing, to say the least, as well as inconsistent with
On 27.08.2013 18:03, Andrew Dunstan wrote:
On 08/27/2013 10:36 AM, Heikki Linnakangas wrote:
0001-Divorce-pg_dump-E-option-from-PGCLIENTENCODING.patch
Separates pg_dump -E from PGCLIENTENCODING.
Wouldn't it be better to do this another way? Separating these two will
be confusing, to say the
Andres Freund wrote:
The git tree is at:
git://git.postgresql.org/git/users/andresfreund/postgres.git branch
xlog-decoding-rebasing-cf4
http://git.postgresql.org/gitweb/?p=users/andresfreund/postgres.git;a=shortlog;h=refs/heads/xlog-decoding-rebasing-cf4
I gave this recently rebased branch a
On 10.06.2013 21:58, Heikki Linnakangas wrote:
On 01.06.2013 23:21, Robert Haas wrote:
On Sat, Jun 1, 2013 at 2:48 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
We define a new page-level bit, something like PD_RECENTLY_FROZEN.
When this bit is set, it means there are no unfrozen
Hi,
Boszormenyi Zoltan z...@cybertec.at writes:
Here's a review for this patch.
Thanks for that review Zoltan!
No, it has one reject in src/bin/pg_dump/pg_backup_archiver.c.
It was obvious to fix, version 12a is attached.
Included in the new version of the patch (v13), attached.
It has
On 08/27/2013 11:14 AM, Heikki Linnakangas wrote:
On 27.08.2013 18:03, Andrew Dunstan wrote:
On 08/27/2013 10:36 AM, Heikki Linnakangas wrote:
0001-Divorce-pg_dump-E-option-from-PGCLIENTENCODING.patch
Separates pg_dump -E from PGCLIENTENCODING.
Wouldn't it be better to do this another
On 27.08.2013 18:56, Heikki Linnakangas wrote:
Here's an updated patch.
Ah, forgot one thing:
Here's a little extension I've been using to test this. It contains two
functions; one to simply consume N xids, making it faster to hit the
creation of new XID ranges and wraparound. The other,
Thank you for feedback.
On 26.08.2013 22:20, Alvaro Herrera wrote:
1. this assumes there is only one holder, which is not correct.
(Consider two backends holding shared lock on something and another one
stuck trying to acquire exclusive)
Hmm, true. Then it's not that simple as I thought in
On 8/27/13 7:58 AM, Robert Haas wrote:
We have a *general* need to be able to throttle server-side resource
utilization, particularly I/O. This is a problem not only for
pg_basebackup, but for COPY, CLUSTER, VACUUM, and even things like
UPDATE. Of all of those, the only one for which we
Tarvi Pillessaar escribió:
Thank you for feedback.
On 26.08.2013 22:20, Alvaro Herrera wrote:
1. this assumes there is only one holder, which is not correct.
(Consider two backends holding shared lock on something and another one
stuck trying to acquire exclusive)
Hmm, true. Then it's
On 27.08.2013 03:26, Michael Paquier wrote:
On Tue, Aug 27, 2013 at 5:17 AM, David Fetterda...@fetter.org wrote:
On Mon, Aug 26, 2013 at 10:29:06PM +0300, Heikki Linnakangas wrote:
While looking at the pg_restore code, I noticed that while it
supports specifying multiple --table options to
On 2013-08-27 11:32:30 -0400, Alvaro Herrera wrote:
Andres Freund wrote:
The git tree is at:
git://git.postgresql.org/git/users/andresfreund/postgres.git branch
xlog-decoding-rebasing-cf4
On Tue, Aug 27, 2013 at 08:14:32PM +0300, Heikki Linnakangas wrote:
On 27.08.2013 03:26, Michael Paquier wrote:
On Tue, Aug 27, 2013 at 5:17 AM, David Fetterda...@fetter.org wrote:
On Mon, Aug 26, 2013 at 10:29:06PM +0300, Heikki Linnakangas wrote:
While looking at the pg_restore code, I
On Aug 27, 2013, at 12:30 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
I disagree - Tom K. speaking about what he likes or dislikes (and about what
he didn't use) He forgot about strong points of implicit result or
interesting points. Clients usually has no problem with dynamic datasets
2013-08-27 18:09 keltezéssel, Dimitri Fontaine írta:
Hi,
Boszormenyi Zoltan z...@cybertec.at writes:
Here's a review for this patch.
Thanks for that review Zoltan!
You're welcome.
I would like to see the control parameters documented in allcaps
in CREATE EXTENSION TEMPLATE. Then ALTER
Andres Freund wrote:
pg_xlogdump cannot properly be built with pgxs since it needs a
sourcetree around. That already has confused some users...
How about the attached patch which will tell it's not supported instead
of an ominous build error about files that have no rules?
Hmm, the other
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 27.08.2013 03:26, Michael Paquier wrote:
On Tue, Aug 27, 2013 at 5:17 AM, David Fetterda...@fetter.org wrote:
On Mon, Aug 26, 2013 at 10:29:06PM +0300, Heikki Linnakangas wrote:
While looking at the pg_restore code, I noticed that while it
Andres Freund wrote:
Hi,
Thanks to the valgrind instrumentation I found a small oversight in the
relfilenodemap patch which is fixed in the attached patch.
Pushed, thanks.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
On 08/27/2013 08:32 PM, David E. Wheeler wrote:
On Aug 27, 2013, at 12:30 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
I disagree - Tom K. speaking about what he likes or dislikes (and about what
he didn't use) He forgot about strong points of implicit result or
interesting points.
On 27.08.2013 21:56, Tom Lane wrote:
Heikki Linnakangashlinnakan...@vmware.com writes:
Would anyone object to backpatching that change to 9.3 ? The risk seems
very small, and it would be good to do the other options in the same
release as --table. It was an oversight to only do it for --table
Tom Lane t...@sss.pgh.pa.us
Another point here is that you could get some of the hoped-for
benefit just by increasing BLCKSZ ... but nobody's ever
demonstrated any compelling benefit from larger BLCKSZ (except on
specialized workloads, if memory serves).
I think I've seen a handful of
Kevin,
I think I've seen a handful of reports of performance differences
with different BLCKSZ builds (perhaps not all on community lists).
My recollection is that some people sifting through data in data
warehouse environments see a performance benefit up to 32KB, but
that tests of GiST
On 08/27/2013 10:14 AM, Heikki Linnakangas wrote:
Would anyone object to backpatching that change to 9.3 ? The risk seems
very small, and it would be good to do the other options in the same
release as --table. It was an oversight to only do it for --table in 9.3.
Assuming no objections,
2013/8/27 David E. Wheeler da...@justatheory.com
On Aug 27, 2013, at 12:30 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I disagree - Tom K. speaking about what he likes or dislikes (and about
what he didn't use) He forgot about strong points of implicit result or
interesting points.
Heikki Linnakangas hlinnakan...@vmware.com writes:
As the code stands, you have to pass the argument types to the
--function flag, ie. --function=myfunc(integer). It's annoyingly picky
about the spelling, as the it has to match exactly what pg_dump prints,
but it does handle selecting one
Pavel Stehule pavel.steh...@gmail.com writes:
2013/8/27 David E. Wheeler da...@justatheory.com
But whatever the keyword, I think it makes sense to require one to return
results to the caller. Any query that does not return, yield, or capture
(select into) values should just have its results
On Tue, Aug 27, 2013 at 10:35:40PM +0300, Heikki Linnakangas wrote:
On 27.08.2013 21:56, Tom Lane wrote:
Heikki Linnakangashlinnakan...@vmware.com writes:
Would anyone object to backpatching that change to 9.3 ? The risk seems
very small, and it would be good to do the other options in the
2013/8/27 Tom Lane t...@sss.pgh.pa.us
Pavel Stehule pavel.steh...@gmail.com writes:
2013/8/27 David E. Wheeler da...@justatheory.com
But whatever the keyword, I think it makes sense to require one to
return
results to the caller. Any query that does not return, yield, or capture
(select
Amit Kapila amit.kapil...@gmail.com wrote:
What is happening here is that incase of '*' as priority of both
are same, system will choose whichever comes in list of
registered standby's first (list is maintained in structure
WalSndCtl). Each standby is registered with WalSndCtl when a new
On 8/27/13 3:54 PM, Josh Berkus wrote:
I believe that Greenplum currently uses 128K. There's a definite
benefit for the DW use-case.
Since Linux read-ahead can easily give big gains on fast storage, I
normally set that to at least 4096 sectors = 2048KB. That's a lot
bigger than even this,
On 7/20/13 10:08 AM, Kohei KaiGai wrote:
Hmm. I didn't have this idea. It seems to me fair enough and kills
necessity to enhance RangeTblEntry and getrelid() indeed.
I try to fix up this implementation according to your suggestion.
How is that going? I'm going to do a serious review of this
On Aug 27, 2013, at 1:36 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
I agree with David that we should use some new syntax to specify
return-results-directly-to-client, assuming we ever get any such
functionality. It seems like a pretty bad choice of default behavior,
which is
Here's a patch to move src/port/pgcheckdir.c to src/common/checkdir.c
and add the shareable part of postmaster's current checkDataDir code
into it, as pg_check_dir_permissions. This is in the spirit of using it
in pgstat to check the directory defined by stats_temp_directory.
(This is basically
2013/8/27 David E. Wheeler da...@justatheory.com
On Aug 27, 2013, at 1:36 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I agree with David that we should use some new syntax to specify
return-results-directly-to-client, assuming we ever get any such
functionality. It seems like a
Hi Alvaro,
On 2013-08-27 14:47:49 -0400, Alvaro Herrera wrote:
Andres Freund wrote:
pg_xlogdump cannot properly be built with pgxs since it needs a
sourcetree around. That already has confused some users...
How about the attached patch which will tell it's not supported instead
of
On Aug 27, 2013, at 3:10 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
CREATE PROCEDURE foo()
BEGIN
SELECT 1,2;
SELECT 2;
SELECT 3,4
END;
And is not strange expect a result
CALL foo()
1,2
2
3,4
Procedure is a script (batch) moved to server side for better performance
On 08/28/2013 12:10 AM, Pavel Stehule wrote:
so if I write on client side
BEGIN;
SELECT 1,2;
SELECT 2;
SELECT 3,4;
END;
then I expect results
1,2
2
3,4
And you are perfectly ok to discard the results
Actually it would be much more helpful to have
discard the results syntax
On Wed, Aug 28, 2013 at 5:51 AM, Kevin Grittner kgri...@ymail.com wrote:
Amit Kapila amit.kapil...@gmail.com wrote:
What is happening here is that incase of '*' as priority of both
are same, system will choose whichever comes in list of
registered standby's first (list is maintained in
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Here's a patch to move src/port/pgcheckdir.c to src/common/checkdir.c
and add the shareable part of postmaster's current checkDataDir code
into it, as pg_check_dir_permissions. This is in the spirit of using it
in pgstat to check the directory
Darren Duncan dar...@darrenduncan.net writes:
I have a proposal.
Assuming we decide to do away with RULEs,
You lost me already.
If we had replacement functionality for everything that can be done with
rules, we could start to think about when we might begin to tell people
they can't use
On Tue, Aug 27, 2013 at 04:14:27PM +0200, Andres Freund wrote:
On 2013-06-09 17:25:59 -0400, Noah Misch wrote:
***
*** 846,851 exec_simple_query(const char *query_string)
--- 847,856
TRACE_POSTGRESQL_QUERY_START(query_string);
+ #ifdef USE_VALGRIND
On Tue, 2013-08-27 at 09:44 -0400, Tom Lane wrote:
Boszormenyi Zoltan z...@cybertec.at writes:
When adding regression tests, can you please add intentional
syntax error cases to exercise all the new ereport()s?
Please do not add test cases merely to prove that. Yeah, you should
probably
On Mon, 2013-08-26 at 23:24 +, Andrew Gierth wrote:
Latest version of patch. This should be it as far as code goes; there
may be some more regression test work, and a doc patch will be
forthcoming.
In src/include/optimizer/paths.h, you are using operator as a function
argument name, which
On Tue, 2013-08-27 at 17:36 +0300, Heikki Linnakangas wrote:
Here is a set of three patches that I've been working on:
There is a compiler warning:
pg_backup_db.c:243:0: warning: PARAMS_ARRAY_SIZE redefined [enabled by
default]
pg_backup_db.c:139:0: note: this is the location of the previous
This doesn't build:
make -C pg_upgrade_support all
make[2]: Entering directory
`/var/lib/jenkins/jobs/postgresql_commitfest_world/workspace/contrib/pg_upgrade_support'
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute
On 2013.08.27 7:57 PM, Tom Lane wrote:
Darren Duncan dar...@darrenduncan.net writes:
I have a proposal.
Assuming we decide to do away with RULEs,
You lost me already.
If we had replacement functionality for everything that can be done with
rules, we could start to think about when we
On Tue, Aug 27, 2013 at 01:57:49PM +0530, Ashutosh Bapat wrote:
I want to create a materialized view as the output of a plpgsql function
returning a set of rows. But that function creates temporary tables and
thus can not be used for creating materialized view as per the
documentation at
On Tue, Aug 27, 2013 at 11:09 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-08-27 15:34:22 +0900, Michael Paquier wrote:
I have been working a little bit more on this patch for the next
commit fest. Compared to the previous version, I have removed the part
of the code where process
I would be good, if this set gets documented, lest users will be confused.
Can you point me to relevant sections of document? I can add this
documentation.
On Wed, Aug 28, 2013 at 10:12 AM, Noah Misch n...@leadboat.com wrote:
On Tue, Aug 27, 2013 at 01:57:49PM +0530, Ashutosh Bapat wrote:
I
69 matches
Mail list logo
