btw, there is serious problem with row-level security and constraints. For
example, user with low security level could use unique constraint to know
about existence of a row with higher security. I don't know, what is the
best practice to avoid this.
On Wed, Aug 28, 2013 at 1:37 AM, Greg Smith
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 wrote:
> On Tue, Aug 27, 2013 at 01:57:49PM +0530, Ashutosh Bapat wrote:
> > I want to create
On Tue, Aug 27, 2013 at 11:09 PM, Andres Freund 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 running REINDEX C
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 2013.08.27 7:57 PM, Tom Lane wrote:
Darren Duncan 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
t
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
-Wfo
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
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, wh
On Tue, 2013-08-27 at 09:44 -0400, Tom Lane wrote:
> Boszormenyi Zoltan 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 exer
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 U
Darren Duncan 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 rules. Unfortunately, we d
Alvaro Herrera 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 defined by stats_temp_
On Wed, Aug 28, 2013 at 5:51 AM, Kevin Grittner wrote:
> Amit Kapila 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
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 res
On Aug 27, 2013, at 3:10 PM, Pavel Stehule 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 and
> b
2013/8/27 David E. Wheeler
> On Aug 27, 2013, at 1:36 PM, Pavel Stehule
> 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,
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 inste
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 t
On Aug 27, 2013, at 1:36 PM, Pavel Stehule 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 essentially what you're sayin
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 my
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, a
Amit Kapila 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
> WALSender is started
2013/8/27 Tom Lane
> Pavel Stehule writes:
> > 2013/8/27 David E. Wheeler
> >> 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 discard
On Tue, Aug 27, 2013 at 10:35:40PM +0300, Heikki Linnakangas wrote:
> On 27.08.2013 21:56, Tom Lane wrote:
> >Heikki Linnakangas 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
Pavel Stehule writes:
> 2013/8/27 David E. Wheeler
>> 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 discarded.
> A usual and first solution
Heikki Linnakangas 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 function from a gro
2013/8/27 David E. Wheeler
> On Aug 27, 2013, at 12:30 AM, Pavel Stehule
> 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 dyna
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,
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 GiS
Tom Lane
> 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 reports of performanc
On 27.08.2013 21:56, Tom Lane wrote:
Heikki Linnakangas 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 in 9.3.
Assuming no o
On 08/27/2013 08:32 PM, David E. Wheeler wrote:
> On Aug 27, 2013, at 12:30 AM, Pavel Stehule 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
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 & Servi
Heikki Linnakangas writes:
> On 27.08.2013 03:26, Michael Paquier wrote:
>> On Tue, Aug 27, 2013 at 5:17 AM, David Fetter 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 mult
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 oth
2013-08-27 18:09 keltezéssel, Dimitri Fontaine írta:
Hi,
Boszormenyi Zoltan 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 EXTENSION
TEMPLATE s
On Aug 27, 2013, at 12:30 AM, Pavel Stehule 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 -
> PHP, DBI, Llibpq
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 Fetter wrote:
> >>On Mon, Aug 26, 2013 at 10:29:06PM +0300, Heikki Linnakangas wrote:
> >>>While looking at the pg_restore code, I noticed tha
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
> > http://git.postgresql.org/gitweb/?p=users/andresfreund/postgres.git;a=shortlog;h=refs/heads/
On 27.08.2013 03:26, Michael Paquier wrote:
On Tue, Aug 27, 2013 at 5:17 AM, David Fetter 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 restore several
tab
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. Th
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 curren
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 fir
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,
pr
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 way?
Hi,
Boszormenyi Zoltan 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 extended the SQ
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
wrote:
We define a new page-level bit, something like PD_RECENTLY_FROZEN.
When this bit is set, it means there are no unfrozen tuples on the
page with XIDs
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 branc
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
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 what
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 bda
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
Sent from my iPad
On 27-Aug-2013, at 19:44, Andres Freund 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 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/mem
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 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-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_h
Hi Robert,
On 2013-08-17 12:08:17 -0400, Robert Haas wrote:
> On Sun, Aug 11, 2013 at 1:31 AM, Andres Freund wrote:
> > So, I'd suggest something like:
> >
> > typedef enum BgwHandleStatus {
> >BGWH_SUCCESS, /* sucessfully got status */
> >BGWH_NOT_YET, /* worker hasn't started yet */
> >
Boszormenyi Zoltan 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 does
not mean
On 08/27/2013 01:58 PM, Robert Haas wrote:
> On Tue, Aug 20, 2013 at 2:37 AM, Heikki Linnakangas
> 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
On Tue, Aug 27, 2013 at 12:58 PM, Robert Haas wrote:
> On Tue, Aug 20, 2013 at 2:37 AM, Heikki Linnakangas
> 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
On Tue, Aug 20, 2013 at 2:37 AM, Heikki Linnakangas
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 been mentioned yet.
We
On Sun, Aug 25, 2013 at 3:21 PM, Amit Kapila wrote:
> On Sat, Aug 24, 2013 at 2:46 PM, Sawada Masahiko
> wrote:
>> On Sat, Aug 24, 2013 at 3:14 AM, Josh Berkus wrote:
>>> On 08/23/2013 12:42 AM, Sawada Masahiko wrote:
in case (a), those priority is clear. So I think that re-taking over
>>>
On Tue, Aug 27, 2013 at 7:55 PM, Vik Fearing 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 a bash at im
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,
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
http://www.postgresql.org/docs/9.3/static/sql-creatematerializedvi
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
2013/8/24 Tom Lane
> Pavel Stehule 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 reading, because Tom K. points out exa
68 matches
Mail list logo
