On Mon, Dec 22, 2014 at 10:46:16AM -0500, Tom Lane wrote:
> I still find the ChainAggregate approach too ugly at a system structural
> level to accept, regardless of Noah's argument about number of I/O cycles
> consumed. We'll be paying for that in complexity and bugs into the
> indefinite future,
There is a new column added in pg_authid (rolbypassrls)
and the updation for same is missed in below places:
a. System catalog page for pg_authid
http://www.postgresql.org/docs/devel/static/catalog-pg-authid.html
b. Do we want to add this new column in pg_shadow view?
With Regards,
Amit Kapila.
E
On 8/29/14 4:01 PM, Peter Eisentraut wrote:
> On 8/28/14 9:01 AM, Kyotaro HORIGUCHI wrote:
>> I found this issue when trying per-pg_user (role) loading of
>> auto_analyze and some tweaking tool. It is not necessarily set by
>> the user by own, but the function to decide whether to load some
>> modu
On 12/22/14 7:56 PM, Andrew Dunstan wrote:
> Currently the buildfarm animal crake (my development instance) is
> running the bin check, but not any other animal. These tests still take
> for too long, not least because each set of tests requires a separate
> install.
You can avoid that by using ma
On Tue, Dec 23, 2014 at 4:10 AM, Oskari Saarenmaa wrote:
>
> 08.11.2014, 04:03, Peter Eisentraut kirjoitti:
> > On 11/4/14 3:52 PM, Peter Eisentraut wrote:
> >> > Here are patches to address that. First, it reports errors when
> >> > attempting to create a tar header that would truncate file or s
Here's a five-part split of the remaining pieces of this patch.
Patch 0001 is the one I posted in
http://www.postgresql.org/message-id/20141220022308.gy1...@alvh.no-ip.org
which adds support for COMMENT ON CONSTRAINT .. ON DOMAIN. This just
splits OBJECT_CONSTRAINT in OBJECT_TABCONSTRAINT and
OB
Here's a completely different idea. How about we add an option that
means "vacuum this table before running the test" (can be given several
times); by default the set of vacuumed tables is the current pgbench_*
list, but if -f is specified then the default set is cleared. So if you
have a -f scri
Currently the buildfarm animal crake (my development instance) is
running the bin check, but not any other animal. These tests still take
for too long, not least because each set of tests requires a separate
install.
I have complained about this before, but we don't seem to have made any
prog
On Mon, Dec 22, 2014 at 4:34 PM, Peter Geoghegan wrote:
> To put it another way, creating a separate object obfuscates
> scanRTEForColumn(), since it's the only client of
> updateFuzzyAttrMatchState().
Excuse me. I mean *not* creating a separate object -- having a unified
state representation fo
On Mon, Dec 22, 2014 at 5:50 AM, Robert Haas wrote:
> Looking over the latest patch, I think we could simplify the code so
> that you don't need multiple FuzzyAttrMatchState objects. Instead of
> creating a separate one for each RTE and then merging them, just have
> one. When you find an inexac
> "Robert" == Robert Haas writes:
>> I would be interested in seeing more good examples of the size and
>> type of grouping sets used in typical queries.
Robert> From what I have seen, there is interest in being able to do
Robert> things like GROUP BY CUBE(a, b, c, d) and have that be
R
> First of all - I'm not entirely convinced the "IF EXISTS" approach is
> somehow better than "-f implies -n" suggested before, but I don't have a
> strong preference either.
I revisited the "-f implies -n" approach again. The main reason why I
wanted to avoid the approach was, it breaks the backw
On Mon, Dec 22, 2014 at 11:48:52PM +0100, Christoph Berg wrote:
> Hi,
>
> I've played with trying to find out which minimal set of files I need
> from the old version to make pg_upgrade work. Interestingly, this
> includes the good old postmaster binary:
>
> $ sudo -u postgres pgsql/bin/pg_upgrad
Hi,
I've played with trying to find out which minimal set of files I need
from the old version to make pg_upgrade work. Interestingly, this
includes the good old postmaster binary:
$ sudo -u postgres pgsql/bin/pg_upgrade -b /var/tmp/pgsql/bin/ -B
/usr/lib/postgresql/9.5/bin/ -d /etc/postgresql/9
On Fri, Nov 14, 2014 at 01:57:16AM +0100, Andreas Karlsson wrote:
> *** a/configure.in
> --- b/configure.in
> *** AC_DEFINE_UNQUOTED(MAXIMUM_ALIGNOF, $MAX
> *** 1751,1756
> --- 1751,1759
> AC_CHECK_TYPES([int8, uint8, int64, uint64], [], [],
> [#include ])
>
> + # Check
08.11.2014, 04:03, Peter Eisentraut kirjoitti:
> On 11/4/14 3:52 PM, Peter Eisentraut wrote:
>> > Here are patches to address that. First, it reports errors when
>> > attempting to create a tar header that would truncate file or symlink
>> > names. Second, it works around the problem in the tests
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > * Adam Brightwell (adam.brightw...@crunchydatasolutions.com) wrote:
> > > I have attached an updated patch for review
> > > (role-attribute-bitmask-v7.patch).
> > >
> > > This patch incorporates the 'v5a' patch proposed
On Mon, Dec 22, 2014 at 1:24 PM, Heikki Linnakangas
wrote:
> I feel that it needs to be possible to specify the constraint unambiguously
> in all cases. These are very rare use cases, but we should have an escape
> hatch for the rare cases that need it.
>
>
> What would it take to also support par
On 12/21/14, 8:55 PM, Fabrízio de Royes Mello wrote:
> And why that, but not
> say schema-wide ANALYZE, CLUSTER, TRUNCATE, ...
>
+1. I can write patches for each of this maintenance statement too.
If we're going to go that route, then perhaps it would
On 12/22/14, 10:05 AM, Andres Freund wrote:
While the feature itself might be fairly innocuous, I'm just wondering
>why we need to encourage manual vacuuming. And why that, but not
>say schema-wide ANALYZE, CLUSTER, TRUNCATE, ...
There's one argument for supporting more for VACUUM than the rest
Stephen Frost wrote:
> Hey Alvaro,
>
> * Adam Brightwell (adam.brightw...@crunchydatasolutions.com) wrote:
> > I have attached an updated patch for review
> > (role-attribute-bitmask-v7.patch).
> >
> > This patch incorporates the 'v5a' patch proposed by Alvaro, input
> > validation (Assert) check
On 12/20/2014 11:14 PM, Peter Geoghegan wrote:
On Sat, Dec 20, 2014 at 2:16 AM, Martijn van Oosterhout
wrote:
What I find curious about the opclass thing is: when do you ever have
an opclass that has a different idea of equality than the default
opclass for the type? In other words, when is B-T
Hey Alvaro,
* Adam Brightwell (adam.brightw...@crunchydatasolutions.com) wrote:
> I have attached an updated patch for review
> (role-attribute-bitmask-v7.patch).
>
> This patch incorporates the 'v5a' patch proposed by Alvaro, input
> validation (Assert) check in 'check_role_attribute' and the do
Re: Peter Eisentraut 2014-11-03 <5457f54e.4020...@gmx.net>
> On 11/2/14 2:00 PM, Noah Misch wrote:
> >> Ick; I concur with your judgment on those aspects of the IPC::Cmd design.
> >> Thanks for investigating. So, surviving options include:
> >>
> >> 1. Require IPC::Run.
> >> 2. Write our own run()
On 22/12/14 20:14, Jaime Casanova wrote:
On Thu, Dec 18, 2014 at 7:14 AM, Petr Jelinek wrote:
Hi,
v2 version of this patch is attached.
a few more tests revealed that passing null as the sample size
argument works, and it shouldn't.
Fixed.
in repeatable it gives an error if i use null a
On Tuesday, December 23, 2014, Robert Haas wrote:
> On Mon, Dec 22, 2014 at 11:19 AM, Andrew Gierth
> > wrote:
> > Tom> The other reason that's a bad comparison is that I've not seen
> > Tom> many queries that use more than a couple of window frames,
> > Tom> whereas we have to expect that the
On Mon, Dec 22, 2014 at 11:19 AM, Andrew Gierth
wrote:
> Tom> The other reason that's a bad comparison is that I've not seen
> Tom> many queries that use more than a couple of window frames,
> Tom> whereas we have to expect that the number of grouping sets in
> Tom> typical queries will be sig
On 12/21/2014 02:18 PM, Tom Lane wrote:
=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes:
I work with some customer that have databases with a lot of schemas and
sometimes we need to run manual VACUUM in one schema, and would be nice to
have a new option to run vacuum in relations from a specif
On Thu, Dec 18, 2014 at 7:14 AM, Petr Jelinek wrote:
> Hi,
>
> v2 version of this patch is attached.
>
a few more tests revealed that passing null as the sample size
argument works, and it shouldn't.
in repeatable it gives an error if i use null as argument but it gives
a syntax error, and it sho
On 22.12.2014 18:41, Andres Freund wrote:
> On 2014-12-22 18:17:56 +0100, Tomas Vondra wrote:
>> On 22.12.2014 17:47, Alvaro Herrera wrote:
>>> Tomas Vondra wrote:
On 22.12.2014 07:36, Tatsuo Ishii wrote:
> On 22.12.2014 00:28, Tomas Vondra wrote:
>>>
>> (8) Also, I think it's not nece
On 2014-12-22 18:17:56 +0100, Tomas Vondra wrote:
> On 22.12.2014 17:47, Alvaro Herrera wrote:
> > Tomas Vondra wrote:
> >> On 22.12.2014 07:36, Tatsuo Ishii wrote:
> >>> On 22.12.2014 00:28, Tomas Vondra wrote:
> >
> (8) Also, I think it's not necessary to define function prototypes for
> >>
Tomas Vondra wrote:
> I'm not objecting to prototypes in general, but I believe the principle
> is to respect how the existing code is written. There are almost no
> other prototypes in pgbench.c - e.g. there are no prototypes for
> executeStatement(), init() etc. so adding the prototypes in this
On Mon, Dec 22, 2014 at 3:17 PM, Alvaro Herrera
wrote:
>
> Stephen Frost wrote:
> > * Andres Freund (and...@2ndquadrant.com) wrote:
>
> > > There's one argument for supporting more for VACUUM than the rest - it
> > > can't be executed directly as the result of a query as the others
> > > can... I
On 22.12.2014 17:47, Alvaro Herrera wrote:
> Tomas Vondra wrote:
>> On 22.12.2014 07:36, Tatsuo Ishii wrote:
>>> On 22.12.2014 00:28, Tomas Vondra wrote:
>
(8) Also, I think it's not necessary to define function prototypes for
executeStatement2 and is_table_exists. It certainly is no
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2014-12-22 12:12:12 -0500, Stephen Frost wrote:
> > We might end up turning the autovacuum process into a generalized
> > scheduler/cron-like entity that way though.
>
> I'm not talking about autovacuum, just plain vacuumdb.
Oh, right, clearly
Stephen Frost wrote:
> * Andres Freund (and...@2ndquadrant.com) wrote:
> > There's one argument for supporting more for VACUUM than the rest - it
> > can't be executed directly as the result of a query as the others
> > can... I wonder if that'd not better be answered by adding a feature to
> > va
On 2014-12-22 12:12:12 -0500, Stephen Frost wrote:
> * Andres Freund (and...@2ndquadrant.com) wrote:
> > On 2014-12-21 14:18:33 -0500, Tom Lane wrote:
> > > While the feature itself might be fairly innocuous, I'm just wondering
> > > why we need to encourage manual vacuuming. And why that, but not
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2014-12-21 14:18:33 -0500, Tom Lane wrote:
> > While the feature itself might be fairly innocuous, I'm just wondering
> > why we need to encourage manual vacuuming. And why that, but not
> > say schema-wide ANALYZE, CLUSTER, TRUNCATE, ...
>
> T
Stephen Frost wrote:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > Overall, this whole line of development seems like bloating the parse
> > tables for little gain.
>
> Still, I see this point also. I do think it'd be really great if we
> could figure out a way to segregate these kind
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Multi-table CLUSTER uses multiple transactions, so this should not be an
> issue. That said, I don't think there's much point in CLUSTER SCHEMA,
> much less TRUNCATE SCHEMA. Do you normally organize your schemas so
> that there are some that co
Re: Alvaro Herrera 2014-12-22 <20141222165157.gd1...@alvh.no-ip.org>
> Multi-table CLUSTER uses multiple transactions, so this should not be an
> issue. That said, I don't think there's much point in CLUSTER SCHEMA,
> much less TRUNCATE SCHEMA. Do you normally organize your schemas so
> that ther
José Luis Tallón wrote:
> On 12/21/2014 10:30 PM, Fabrízio de Royes Mello wrote:
> >[snip]
>
> I do agree that "vacuum schema" might very well be useful (I'll probably use
> it myself from time to time, too).
> ANALYZE SCHEMA (specially coupled with some transaction-wide "SET
> statistics_target"
Tomas Vondra wrote:
> On 22.12.2014 07:36, Tatsuo Ishii wrote:
> > On 22.12.2014 00:28, Tomas Vondra wrote:
> >> (8) Also, I think it's not necessary to define function prototypes for
> >> executeStatement2 and is_table_exists. It certainly is not
> >> consistent with the other functions d
> "Tom" == Tom Lane writes:
[Noah]
>> I caution against using window function performance as the
>> template for GROUPING SETS performance goals. The benefit of
>> GROUPING SETS compared to its UNION ALL functional equivalent is
>> 15% syntactic pleasantness, 85% performance opportuniti
On 2014-12-21 14:18:33 -0500, Tom Lane wrote:
> =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes:
> > I work with some customer that have databases with a lot of schemas and
> > sometimes we need to run manual VACUUM in one schema, and would be nice to
> > have a new option to run vacuum in relatio
On 12/21/2014 10:30 PM, Fabrízio de Royes Mello wrote:
[snip]
I do agree that "vacuum schema" might very well be useful (I'll probably
use it myself from time to time, too).
ANALYZE SCHEMA (specially coupled with some transaction-wide "SET
statistics_target" could be beneficial)
> And why
On 12/22/2014 03:15 AM, Michael Paquier wrote:
On Thu, Dec 18, 2014 at 4:13 AM, Heikki Linnakangas
wrote:
On 10/22/2014 01:55 PM, Teodor Sigaev wrote:
Suggested patch adds GIN support contains operator for ranges over scalar
column.
It allows more effective GIN scan. Currently, queries like
Noah Misch writes:
> On Sat, Dec 13, 2014 at 04:37:48AM +, Andrew Gierth wrote:
> "Tom" == Tom Lane writes:
>> Tom> That seems pretty grotty from a performance+memory consumption
>> Tom> standpoint. At peak memory usage, each one of the Sort nodes
>> Tom> will contain every input row,
>> Ha
On Mon, Dec 22, 2014 at 5:16 AM, Heikki Linnakangas
wrote:
> Peter Geoghegan suggested [1] moving rbtree.c to src/backend/lib, which I
> think makes a lot of sense. Now that we have several other general purpose
> data structures in src/backend/lib (linked lists, a binary heap, and a
> pairing hea
Etsuro Fujita writes:
> I haven't done anything about the issue that postgresGetForeignPlan() is
> using get_parse_rowmark(), discussed in eg, [2]. Tom, will you work on
> that?
Yeah, we need to do something about the PlanRowMark data structure.
Aside from the pre-existing issue in postgres_fdw,
On 12/22/2014 05:19 PM, Tom Lane wrote:
However, wasn't there some speculation about removing rbtree entirely?
Not that I recall. It's still used for GIN bulk loading. There might be
better ways to do that, but there hasn't been any serious discussion on
that.
There was some discussion on r
Heikki Linnakangas writes:
> Peter Geoghegan suggested [1] moving rbtree.c to src/backend/lib, which
> I think makes a lot of sense. Now that we have several other general
> purpose data structures in src/backend/lib (linked lists, a binary heap,
> and a pairing heap), rbtree.c would definitely
Michael Paquier wrote:
> And here is an updated patch following those lines. Similarly to the
> things in contrib/, a set of variables are used to define for each
> module what are the extra libraries, include dirs, etc. This refactors
> quite a bit of code, even if there are a couple of exception
On Thu, Dec 18, 2014 at 10:37 AM, Michael Paquier
wrote:
> On Thu, Dec 18, 2014 at 4:02 AM, Alvaro Herrera
> wrote:
>>
>> I know this is how it currently works, but it looks way too messy to me:
>>
>> + my $pgarchivecleanup = AddSimpleFrontend('pg_archivecleanup');
>> + my $pgstandby
On Sat, Dec 20, 2014 at 7:30 PM, Peter Geoghegan wrote:
> On Sat, Dec 20, 2014 at 3:17 PM, Peter Geoghegan wrote:
>> Attached patch implements this scheme.
>
> I had another thought: "NAMEDATALEN + 1" is a better representation of
> "infinity" for matching purposes than INT_MAX. I probably should
On Sat, Dec 20, 2014 at 9:17 AM, Michael Paquier
wrote:
> But now, here are some things to consider if we use directly the
> reloptions available with RelationData:
> - If the parameters toast.autovacuum_* are not set, toast relations
> inherit values from their parent relation. Looking at autovac
On Fri, Dec 19, 2014 at 8:40 AM, Petr Jelinek wrote:
> What I hope to get from this is agreement on the general approach and
> protocol so that we can have common base which will both make it easier to
> create external logical replication solutions and also eventually lead to
> full logical repli
On Fri, Dec 19, 2014 at 4:18 AM, M Tarkeshwar Rao
wrote:
> We are facing this issue and want to analyse this through logging.
> can you please share a sample Postgres config file to enable max logging with
> syslog support?
>
> What should be the debug level so that I can capture the failure info
On Tue, Dec 16, 2014 at 1:28 PM, Stephen Frost wrote:
> The magic "audit" role has SELECT rights on a given table. When any
> user does a SELECT against that table, ExecCheckRTPerms is called and
> there's a hook there which the module can use to say "ok, does the audit
> role have any permission
On 22.12.2014 07:36, Tatsuo Ishii wrote:
> On 22.12.2014 00:28, Tomas Vondra wrote:
>>
>> (2) The 'executeStatement2' API is a bit awkward as the signarure
>>
>> executeStatement2(PGconn *con, const char *sql, const char *table);
>>
>> suggests that the 'sql' command is executed when 'table
On 22.12.2014 10:07, Petr Jelinek wrote:
> On 21/12/14 18:38, Tomas Vondra wrote:
>>
>> (1) The patch adds a new catalog, but does not bump CATVERSION.
>>
>
> I thought this was always done by committer?
Right. Sorry for the noise.
>
>> (2) The catalog naming (pg_tablesamplemethod) seems a bit
On 2014/12/18 7:04, Tom Lane wrote:
> Etsuro Fujita writes:
>> Attached are updated patches. Patch fdw-inh-5.patch has been created on
>> top of patch fdw-chk-5.patch.
> I've committed fdw-chk-5.patch with some minor further adjustments;
> Have not looked at the other patch yet.
I updated the
On 12/16/2014 10:41 PM, Jeff Janes wrote:
On Wed, Dec 10, 2014 at 3:46 PM, Robert Haas wrote:
On Wed, Dec 10, 2014 at 3:28 PM, Heikki Linnakangas
wrote:
Care to code it up?
Here you are.
That was quick.
You need to add a semicolon to the end of line 20 in pairingheap.c.
In addition to
Peter Geoghegan suggested [1] moving rbtree.c to src/backend/lib, which
I think makes a lot of sense. Now that we have several other general
purpose data structures in src/backend/lib (linked lists, a binary heap,
and a pairing heap), rbtree.c would definitely be better placed in
src/backend/li
On 12/20/2014 10:50 PM, Peter Geoghegan wrote:
On Wed, Dec 17, 2014 at 6:07 AM, Heikki Linnakangas
wrote:
How about adding a src/backend/lib/README for that, per attached?
I took a quick look at this. Some observations:
* I like the idea of adding a .../lib README. However, the README
fails
On 21/12/14 18:38, Tomas Vondra wrote:
Hi,
On 18.12.2014 13:14, Petr Jelinek wrote:
Hi,
v2 version of this patch is attached.
I did a review of this v2 patch today. I plan to do a bit more testing,
but these are my comments/questions so far:
Thanks for looking at it!
(0) There's a TABLE
66 matches
Mail list logo
