On Mon, Mar 6, 2017 at 1:26 PM, Amit Langote
wrote:
> On 2017/03/06 16:49, Ashutosh Bapat wrote:
>> On Mon, Mar 6, 2017 at 12:48 PM, Amit Langote wrote:
>>> On 2017/03/06 15:41, Michael Paquier wrote:
This comment is not completely correct. Children can be temp tables,
they just cannot b
Hi Vinayak,
On 2017/02/28 18:24, vinayak wrote:
> The attached patch reports the different phases of analyze command.
> Added this patch to CF 2017-03.
In the updated monitoring.sgml:
+
+ computing heap stats
+
+ VACUUM is currently computing heap stats.
+
+
+
+
Hi,
pg_dump segfaults if there are more than one DO_PUBLICATION_REL objects to
dump.
create table foo (a int);
create publication foo_pub;
alter publication foo_pub add table foo;
$ pg_dump
create table bar (a int);
alter publication foo_pub add table bar;
$ pg_dump -s
Segmentation fault (cor
Ok, I think I understand the complete picture.
At Mon, 06 Mar 2017 15:58:56 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20170306.155856.198084190.horiguchi.kyot...@lab.ntt.co.jp>
> > I can guess two ways to fix this. One is change the definition of
> > T_NAME.
> >
> > | #define T_
Hello,
At Fri, 3 Mar 2017 12:53:04 +0900, Michael Paquier
wrote in
> On Thu, Mar 2, 2017 at 2:20 PM, Kyotaro HORIGUCHI
> wrote:
> > 5) Just remove plain map files and all related code. Addition to
> >that, Makefile stores hash digest of authority files in
> >Unicode/authoriy_hashes.txt
On Mon, Mar 6, 2017 at 4:18 PM, Amit Langote
wrote:
> About autovacuum_* parameters - we currently don't handle partitioned
> tables in autovacuum.c, because no statistics are reported for them. That
> is, relation_needs_vacanalyze() will never return true for dovacuum,
> doanalyze and wraparound
On 2017/03/06 17:01, Ashutosh Bapat wrote:
> On Mon, Mar 6, 2017 at 1:26 PM, Amit Langote
> wrote:
>> On 2017/03/06 16:49, Ashutosh Bapat wrote:
>>> On Mon, Mar 6, 2017 at 12:48 PM, Amit Langote wrote:
On 2017/03/06 15:41, Michael Paquier wrote:
> This comment is not completely correct. C
On Sat, Mar 4, 2017 at 7:53 PM, Amit Kapila wrote:
> On Mon, Feb 20, 2017 at 4:04 PM, Rushabh Lathia
> wrote:
> >
> > My colleague Rahila reported compilation issue with
> > the patch. Issue was only coming with we do the clean
> > build on the branch.
> >
> > Fixed the same into latest version
>
> We can leave it for the committer to decide, maybe. Committers often
> rewrite surrounding comments to improve wording, correcting factual
> errors, etc.
>
Sure.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list
Hi,
On Sat, Mar 04, 2017 at 02:49:36PM -0500, Peter Eisentraut wrote:
> On 3/1/17 08:36, Peter Eisentraut wrote:
> > On 2/22/17 18:24, Jim Nasby wrote:
> >>> Yes, by that logic matview refresh should always be last.
> >>
> >> Patches for head attached.
> >>
> >> RLS was the first item added after
By the way,
At Mon, 06 Mar 2017 17:07:55 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20170306.170755.68410634.horiguchi.kyot...@lab.ntt.co.jp>
> Ok, I think I understand the complete picture.
>
> At Mon, 06 Mar 2017 15:58:56 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
> wrote
On 2017/03/04 4:24, Peter Eisentraut wrote:
> On 2/27/17 01:57, Amit Langote wrote:
>> I see that if the table is a inheritance parent, and ONLY is not
>> specified, the child tables are also added to the publication.
>
>> If the child table is later removed from the inheritance hierarchy, it
>> c
On 2017/03/06 18:04, Amit Langote wrote:
> One more option is for OpenTableList() called by CreatePublication() and
> AlterPublicationTables() to not disregard inheritance, as if ONLY was
> specified.
Oops, meant to say: One more option is for OpenTableList to disregard
inheritance...
Thanks,
Ami
Thanks Ashutosh & Robert for the explanation.
On Mon, Mar 6, 2017 at 10:02 AM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> On Sat, Mar 4, 2017 at 2:50 PM, Robert Haas wrote:
> > On Thu, Mar 2, 2017 at 6:48 PM, Ashutosh Bapat
> > wrote:
> >> On Thu, Mar 2, 2017 at 6:06 PM, Rushabh
On Mon, Mar 6, 2017 at 11:12 AM, Ashutosh Bapat
wrote:
> On Mon, Mar 6, 2017 at 11:05 AM, Simon Riggs wrote:
>> On 6 March 2017 at 05:29, Ashutosh Bapat
>> wrote:
>>
>>> Just to confirm, you want the output to look like this
> \d+ t1
> Table "public.t1
Thank you for the comment.
At Fri, 3 Mar 2017 14:47:20 -0500, Peter Eisentraut
wrote in
> On 3/1/17 19:54, Kyotaro HORIGUCHI wrote:
> >> Please measure it in size, not in number of segments.
> > It was difficult to dicide which is reaaonable but I named it
> > after wal_keep_segments because i
On 2017/03/06 17:02, Amit Langote wrote:
Hi Vinayak,
On 2017/02/28 18:24, vinayak wrote:
The attached patch reports the different phases of analyze command.
Added this patch to CF 2017-03.
In the updated monitoring.sgml:
+
+ computing heap stats
+
+ VACUUM is currently com
>
>
> I understood you reasoning of why startup_cost = input_startup_cost and not
> input_total_cost for aggregation by sorting. But what I didn't understand is
> how come higher startup cost for aggregation by sorting would force hash
> aggregation to be chosen? I am not clear about this part.
Se
Hi,
On 2017/03/02 15:23, Amit Khandekar wrote:
> On 23 February 2017 at 16:02, Amit Langote
> wrote:
>>
>>> 2. In the patch, as part of the row movement, ExecDelete() is called
>>> followed by ExecInsert(). This is done that way, because we want to
>>> have the ROW triggers on that (sub)partition
At Fri, 3 Mar 2017 21:31:24 -0500, Peter Eisentraut
wrote in
<88397afa-a8ec-8d8a-1c94-94a4795a3...@2ndquadrant.com>
> On 3/3/17 14:51, Petr Jelinek wrote:
> > On 03/03/17 20:37, Peter Eisentraut wrote:
> >> On 2/27/17 00:23, Kyotaro HORIGUCHI wrote:
> >>> Yeah, the patch sends converted string w
On 06/03/17 11:06, Kyotaro HORIGUCHI wrote:
> At Fri, 3 Mar 2017 21:31:24 -0500, Peter Eisentraut
> wrote in
> <88397afa-a8ec-8d8a-1c94-94a4795a3...@2ndquadrant.com>
>> On 3/3/17 14:51, Petr Jelinek wrote:
>>> On 03/03/17 20:37, Peter Eisentraut wrote:
On 2/27/17 00:23, Kyotaro HORIGUCHI wr
psql currently supports \di+ to view indexes,
List of relations
Schema |Name| Type | Owner | Table | Size | Description
++---+---+-++-
public | ii | index | amos |
On 1 March 2017 at 01:58, David Steele wrote:
> PostgreSQL currently requires the file mode mask (umask) to be 0077.
> However, this precludes the possibility of a user in the postgres group
> performing a backup (or whatever). Now that
> pg_start_backup()/pg_stop_backup() privileges can be deleg
Hi,
On Thu, Feb 16, 2017 at 08:14:28AM +0530, Amit Kapila wrote:
> On Thu, Feb 16, 2017 at 12:27 AM, Robert Haas wrote:
> > On Wed, Feb 15, 2017 at 1:39 PM, Robert Haas wrote:
> >> On Wed, Feb 15, 2017 at 7:11 AM, Amit Kapila
> >> wrote:>
> >>> support related patch. In anycase, to avoid conf
On Mon, Mar 6, 2017 at 4:57 PM, Michael Banck wrote:
> Hi,
>
> On Thu, Feb 16, 2017 at 08:14:28AM +0530, Amit Kapila wrote:
>> On Thu, Feb 16, 2017 at 12:27 AM, Robert Haas wrote:
>> > On Wed, Feb 15, 2017 at 1:39 PM, Robert Haas wrote:
>> >> On Wed, Feb 15, 2017 at 7:11 AM, Amit Kapila
>> >>
On Mon, Mar 6, 2017 at 1:29 PM, David Rowley
wrote:
> On 6 March 2017 at 18:51, Etsuro Fujita wrote:
>> On 2017/03/06 11:05, David Rowley wrote:
>>> The attached patch, based on 9.6, fixes the problem by properly
>>> processing the foreign server options in
>>> postgresGetForeignJoinPaths().
>>
On 3/6/17 03:33, Michael Banck wrote:
> Would this be a candidate for backpatching, or is the behaviour change
> in pg_dump trumping the issues it solves?
Unless someone literally has a materialized view on pg_policy, it
wouldn't make a difference, so I'm not very keen on bothering to
backpatch th
On 3/5/17 16:10, Jim Nasby wrote:
> BTW, did you backpatch as well? The function was added in 9.5.
> Presumably we wouldn't normally do that, but if we think this is unused
> enough maybe it's worth it.
It's a catalog change, so we can't backpatch it.
--
Peter Eisentraut http://ww
Simon Riggs writes:
> On 1 March 2017 at 01:58, David Steele wrote:
>> PostgreSQL currently requires the file mode mask (umask) to be 0077.
>> However, this precludes the possibility of a user in the postgres group
>> performing a backup (or whatever). Now that
>> pg_start_backup()/pg_stop_backu
On Fri, Mar 3, 2017 at 10:50 PM, Simon Riggs wrote:
> Allow vacuums to report oldestxmin
>
> Allow VACUUM and Autovacuum to report the oldestxmin value they
> used while cleaning tables, helping to make better sense out of
> the other statistics we report in various cases.
>
> Branch
> --
> ma
Re: Daniel Verite 2017-03-03
<4d84079e-325b-48c5-83e6-bb54bb567...@manitou-mail.org>
> - tab-completion: works but the list in tab-complete.c:backslash_commands[]
> is sorted alphabetically so "\\gx" should come after "\\gset"
Good catch, it was still in that place from when it was named \G.
In
Hi hackers,
I've seen that pg_dump execute the dump of an eventual comment of a
TSDictionary without
specifying the namespace where it is defined:
https://github.com/postgres/postgres/blob/master/src/bin/pg_dump/pg_dump.c#L13542
This is actually a problem if a new TSDictionary is created, in a d
On Fri, Mar 3, 2017 at 3:57 PM, Robert Haas wrote:
> I'm not happy with the way this patch can just happen to latch on to a
> path that's not parallel-safe rather than one that is and then just
> give up on a merge join in that case. I already made this argument in
> https://www.postgresql.org/me
On Mon, Mar 6, 2017 at 7:38 AM, Tom Lane wrote:
> Simon Riggs writes:
>> On 1 March 2017 at 01:58, David Steele wrote:
>>> PostgreSQL currently requires the file mode mask (umask) to be 0077.
>>> However, this precludes the possibility of a user in the postgres group
>>> performing a backup (or
On Mon, Mar 6, 2017 at 6:33 AM, Amit Kapila wrote:
> On Mon, Mar 6, 2017 at 4:57 PM, Michael Banck
> wrote:
>> Hi,
>>
>> On Thu, Feb 16, 2017 at 08:14:28AM +0530, Amit Kapila wrote:
>>> On Thu, Feb 16, 2017 at 12:27 AM, Robert Haas wrote:
>>> > On Wed, Feb 15, 2017 at 1:39 PM, Robert Haas
>>>
On Mon, Mar 6, 2017 at 6:49 PM, Robert Haas wrote:
> On Mon, Mar 6, 2017 at 6:33 AM, Amit Kapila wrote:
>
> I was going to do it after index and index-only scans and parallel
> bitmap heap scan were committed, but I've been holding off on
> committing parallel bitmap heap scan waiting for Andres
Greetings,
* Simon Riggs (si...@2ndquadrant.com) wrote:
> On 1 March 2017 at 01:58, David Steele wrote:
> > PostgreSQL currently requires the file mode mask (umask) to be 0077.
> > However, this precludes the possibility of a user in the postgres group
> > performing a backup (or whatever). Now
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Simon Riggs writes:
> > On 1 March 2017 at 01:58, David Steele wrote:
> >> PostgreSQL currently requires the file mode mask (umask) to be 0077.
> >> However, this precludes the possibility of a user in the postgres group
> >> performing a backup (or
On 2/28/17 9:42 PM, Jim Nasby wrote:
I'll post a plpython patch that doesn't add the output format control.
I've attached the results of that. Unfortunately the speed improvement
is only 27% at this point (with 999 tuples). Presumably that's
because it's constructing a brand new dictionary
On 3/1/17 9:24 AM, Peter Eisentraut wrote:
On 3/1/17 09:51, Alvaro Herrera wrote:
Peter Eisentraut wrote:
On 2/22/17 19:35, Jim Nasby wrote:
pg_get_object_address() currently returns a field called subobjid, while
pg_depend calls that objsubid. I'm guessing that wasn't on purpose
(especially b
On 3/2/17 8:03 AM, Peter Eisentraut wrote:
On 12/20/16 23:14, Jim Nasby wrote:
I've been looking at the performance of SPI calls within plpython.
There's a roughly 1.5x difference from equivalent python code just in
pulling data out of the SPI tuplestore. Some of that is due to an
inefficiency i
On 3/4/17 11:49 AM, Peter Eisentraut wrote:
I wonder whether we should emphasize this change by assigning
DO_REFRESH_MATVIEW a higher number, like 100?
Since there wasn't any interest in that idea, I have committed Jim's
patch as is.
Thanks. Something else that seems somewhat useful would be t
On Wed, Mar 1, 2017 at 10:40 PM, Thomas Munro
wrote:
> I'm testing a new version which incorporates feedback from Andres and
> Ashutosh, and is refactored to use a new SharedBufFileSet component to
> handle batch files, replacing the straw-man implementation from the v5
> patch series. I've set t
On Wed, Mar 1, 2017 at 10:29 PM, Thomas Munro
wrote:
> I'm testing a patch that lets you set up a fixed sized
> SharedBufFileSet object in a DSM segment, with its own refcount for
> the reason you explained. It supports a dynamically expandable set of
> numbered files, so each participant gets to
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 3/6/17 03:33, Michael Banck wrote:
> > Would this be a candidate for backpatching, or is the behaviour change
> > in pg_dump trumping the issues it solves?
>
> Unless someone literally has a materialized view on pg_policy, it
> woul
On Mon, Mar 6, 2017 at 1:37 PM, Kyotaro HORIGUCHI
wrote:
> Ok, I think I understand the complete picture.
>
> At Mon, 06 Mar 2017 15:58:56 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
> wrote in
> <20170306.155856.198084190.horiguchi.kyot...@lab.ntt.co.jp>
>> > I can guess two ways to fix thi
On 3/6/17 8:50 AM, Stephen Frost wrote:
> * Simon Riggs (si...@2ndquadrant.com) wrote:
>>> to allow the default mode of files and directories
>>> in the $PGDATA directory to be modified.
>>
>> Are you saying if this is changed all files/directories will be
>> changed to the new mode?
>
> No, new
Greetings,
* Amos Bird (amosb...@gmail.com) wrote:
> psql currently supports \di+ to view indexes,
>
> List of relations
> Schema |Name| Type | Owner | Table | Size | Description
> ++---+---+-+
Greeting,s
* Giuseppe Broccolo (giuseppe.brocc...@2ndquadrant.it) wrote:
> I've seen that pg_dump execute the dump of an eventual comment of a
> TSDictionary without
> specifying the namespace where it is defined:
Great catch!
> This is actually a problem if a new TSDictionary is created, in a d
On 3/6/17 8:17 AM, Robert Haas wrote:
> On Mon, Mar 6, 2017 at 7:38 AM, Tom Lane wrote:
>> Simon Riggs writes:
>>> On 1 March 2017 at 01:58, David Steele wrote:
PostgreSQL currently requires the file mode mask (umask) to be 0077.
However, this precludes the possibility of a user in the
On 3/6/17 1:58 AM, Andres Freund wrote:
> On 2017-03-03 15:33:15 -0500, David Steele wrote:
>
>> I propose we move this to the 2017-07 CF so the idea can be more fully
>> developed.
>
> I don't see that being warranted in this case, we're really not talking
> about something complicated:
<...>
Hello Stephen,
Well, the prefix is used to differentiate other \d commands, like
this,
amos=# \ditv
List of relations
Schema |Name| Type | Owner | Table
++--+---+-
public | i | t
Amos,
* Amos Bird (amosb...@gmail.com) wrote:
> Well, the prefix is used to differentiate other \d commands, like
> this,
Ah, ok, fair enough.
Should we consider differentiating different table types also? I
suppose those are primairly just logged and unlogged, but I could see
that being useful
On 3/4/17 01:45, Petr Jelinek wrote:
> I can see one difference though (I didn't see this code before) and that
> is, the connectDBComplete starts with waiting for socket to become
> writable and only then calls PQconnectPoll, while my patch starts with
> PQconnectPoll call. And I see following com
On Sat, Mar 4, 2017 at 12:52 AM, Robert Haas wrote:
> On Thu, Mar 2, 2017 at 3:28 AM, Rader, David wrote:
> > Attached is a doc patch that updates the documentation for postgres-fdw
> to
> > include the actual values for the 4 session variables that are set. Does
> > that make sense to clarify?
Yeah, I'm thinking about that too. Here is a full list of the original
type values,
"Schema"
"Name"
"table"
"view"
"materialized view"
"index"
"sequence"
"special"
"foreign table"
"table"
What else do you think will benefit from extra type information?
regards,
Amos
Stephen Frost writes:
> A
On 2017-03-06 11:27, Petr Jelinek wrote:
Hi,
updated and rebased version of the patch attached.
I compiled with /only/ this one latest patch:
0001-Logical-replication-support-for-initial-data-copy-v6.patch
Is that correct, or are other patches still needed on top, or
underneath?
Anyway
Hi David,
Here's a review of your patch.
David Christensen writes:
> Throws a build error if we encounter a different number of fields in a
> DATA() line than we expect for the catalog in question.
The patch is a good idea, and as-is implements the suggested feature.
Tested by removing an attr
>> I wonder if removing the complexity of maintaining two separate lists
>> for the server and port would be a better/less complex approach. For
>> instance, why not go with a list of typical 'host:port' strings for
>> 'radiusservers'? If no port is specified, then simply use the default
>> for t
Hello.
OK, here is a patch.
Benchmark, before:
```
number of transactions actually processed: 1823
latency average = 1153.495 ms
latency stddev = 154.366 ms
tps = 6.061104 (including connections establishing)
tps = 6.061211 (excluding connections establishing)
```
Benchmark, after:
```
number
2017-03-05 14:02 GMT+01:00 Jan Michálek :
>
>
> 2017-03-05 13:39 GMT+01:00 Pavel Stehule :
>
>>
>>
>> 2017-03-05 13:22 GMT+01:00 Pavel Stehule :
>>
>>>
>>>
>>> 2017-03-05 13:08 GMT+01:00 Jan Michálek :
>>>
It is question if it is really new format, because formating is the
same as aligne
2017-03-06 16:25 GMT+01:00 Pavel Stehule :
>
>
> 2017-03-06 16:17 GMT+01:00 Jan Michálek :
>
>>
>>
>> 2017-03-06 15:19 GMT+01:00 Pavel Stehule :
>>
>>>
>>>
>>> 2017-03-06 0:26 GMT+01:00 Jan Michálek :
>>>
2017-03-05 14:02 GMT+01:00 Jan Michálek :
>
>
> 2017-03-05 13
Hello,
I would like to work on push-based executor [1] during GSoC, so I'm
writing to introduce myself and start the discussion of the project. I
think I should mention beforehand that the subject is my master's
thesis topic, and I have already started working on it. This letter is
not (obviously)
> Hi David,
>
> Here's a review of your patch.
Hi Ilmari, thanks for your time and review. I’m fine with the revised version.
Best,
David
--
David Christensen
End Point Corporation
da...@endpoint.com
785-727-1171
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
David Christensen writes:
>> Hi David,
>>
>> Here's a review of your patch.
>
> Hi Ilmari, thanks for your time and review. I’m fine with the revised
> version.
Okay, I've marked the patch as Ready For Committer.
Thanks,
Ilmari
--
"The surreality of the universe tends towards a maximum" -
ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
> Hi Peter,
>
> Peter Eisentraut writes:
>
>> I posted this about 18 months ago but then ran out of steam. [ ] Here
>> is an updated patch. The testing instructions below still apply.
>> Especially welcome would be ideas on how to address some
On Sat, Mar 4, 2017 at 1:52 PM, Peter Geoghegan wrote:
> On Sat, Mar 4, 2017 at 8:02 AM, Tom Lane wrote:
>>> Perhaps there could be a choice of behaviors. Even if we all agreed
>>> that parameter notation was better in theory, there's something to be
>>> said for maintaining backward compatibili
On Wed, Mar 1, 2017 at 5:55 PM, Andres Freund wrote:
> The issue was that on 32bit platforms the Datum returned by some
> functions (int2int4_sum in this case) isn't actually a separately
> allocated Datum, but rather just something embedded in a larger
> struct. That, combined with the following
On 2017-03-06 12:40:18 -0500, Robert Haas wrote:
> On Wed, Mar 1, 2017 at 5:55 PM, Andres Freund wrote:
> > The issue was that on 32bit platforms the Datum returned by some
> > functions (int2int4_sum in this case) isn't actually a separately
> > allocated Datum, but rather just something embedded
On Sat, Mar 4, 2017 at 9:12 AM, David Steele wrote:
> Yes, that makes sense. Attached are two patches as requested:
>
> 01 - Just marks pg_stop_backup() variants as parallel restricted
> 02 - Add the wait_for_archive param to pg_stop_backup().
>
> These apply cleanly on 272adf4.
Committed 01. N
Robert, all,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Sat, Mar 4, 2017 at 9:12 AM, David Steele wrote:
> > Yes, that makes sense. Attached are two patches as requested:
> >
> > 01 - Just marks pg_stop_backup() variants as parallel restricted
> > 02 - Add the wait_for_archive param to pg
On Mon, Mar 6, 2017 at 12:44 PM, Andres Freund wrote:
> On 2017-03-06 12:40:18 -0500, Robert Haas wrote:
>> On Wed, Mar 1, 2017 at 5:55 PM, Andres Freund wrote:
>> > The issue was that on 32bit platforms the Datum returned by some
>> > functions (int2int4_sum in this case) isn't actually a separa
On Mon, Mar 6, 2017 at 12:53 PM, Stephen Frost wrote:
> Regarding 02, I certainly see that as valuable for the reasons which
> David outlined in his initial email. I can certainly take point on
> getting it committed, but I wouldn't complain if someone else does
> either.
Sold, to the snowman in
On Tue, Feb 14, 2017 at 1:30 AM, Michael Paquier
wrote:
> Hm... It may be a good idea to be consistent on the whole system and
> refer to "partitioned table" as a table without storage and used as an
> entry point for partitions. The docs use this term in CREATE TABLE,
> and we would finish with
On Sat, Mar 4, 2017 at 10:32 AM, Tom Lane wrote:
> Without having actually looked at this patch, I would say that if it added
> a direct call of fopen() to backend-side code, that was already the wrong
> thing. Almost always, AllocateFile() would be a better choice, not only
> because it's tied i
On Fri, Mar 3, 2017 at 2:15 AM, Tsunakawa, Takayuki
wrote:
> From: pgsql-hackers-ow...@postgresql.org
>> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Peter Eisentraut
>> On 2/28/17 02:39, Tsunakawa, Takayuki wrote:
>> > I'd like to propose statement-level rollback feature. To repeat m
On 2/27/17 01:46, Michael Paquier wrote:
> On Sat, Feb 25, 2017 at 10:27 PM, Peter Eisentraut
> wrote:
>> Here is a new patch set that addresses your comments. The structure is
>> still the same, just a bunch of things have been renamed based on
>> suggestions.
> +
> + Drop multiple functions
On 3/5/17 05:40, Jan Michálek wrote:
> jelen=# \pset linestyle rst
> Line style is rst.
> jelen=# \pset format wrapped
> Output format is wrapped.
> jelen=# SELECT repeat('Goodnight Irene ', 30);
> +-+
> |
On 03/06/2017 07:05 PM, Robert Haas wrote:
On Mon, Mar 6, 2017 at 12:44 PM, Andres Freund wrote:
On 2017-03-06 12:40:18 -0500, Robert Haas wrote:
On Wed, Mar 1, 2017 at 5:55 PM, Andres Freund wrote:
The issue was that on 32bit platforms the Datum returned by some
functions (int2int4_sum in t
On 07/03/17 02:46, Amit Kapila wrote:
On Mon, Mar 6, 2017 at 6:49 PM, Robert Haas wrote:
On Mon, Mar 6, 2017 at 6:33 AM, Amit Kapila wrote:
I was going to do it after index and index-only scans and parallel
bitmap heap scan were committed, but I've been holding off on
committing parallel bitm
Hi,
On 2017-03-06 19:49:56 +0100, Tomas Vondra wrote:
> On 03/06/2017 07:05 PM, Robert Haas wrote:
> > On Mon, Mar 6, 2017 at 12:44 PM, Andres Freund wrote:
> > > On 2017-03-06 12:40:18 -0500, Robert Haas wrote:
> > > > On Wed, Mar 1, 2017 at 5:55 PM, Andres Freund
> > > > wrote:
> > > > > The
On Mon, Mar 6, 2017 at 10:24 AM, Adam Brightwell
wrote:
>>> I wonder if removing the complexity of maintaining two separate lists
>>> for the server and port would be a better/less complex approach. For
>>> instance, why not go with a list of typical 'host:port' strings for
>>> 'radiusservers'?
Hi,
This issue has bothered me in non-partitioned use-cases recently, so
thanks for taking it up.
On 2017-03-06 18:22:17 +0300, Aleksander Alekseev wrote:
> diff --git a/src/backend/postmaster/pgstat.c b/src/backend/postmaster/pgstat.c
> index 2fb9a8bf58..fa906e7930 100644
> --- a/src/backend/po
On Mon, Mar 6, 2017 at 9:36 AM, Robert Haas wrote:
> On Sat, Mar 4, 2017 at 1:52 PM, Peter Geoghegan wrote:
> > In my opinion, we expose query id (and dbid, and userid) as the
> > canonical identifier for each pg_stat_statements entry, and have done
> > so for some time. That's the stable API --
On 3/3/17 20:30, Michael Paquier wrote:
> Yeah, it looks sensible to me to keep "replication" for physical
> replication, and switch logical replication checks to match a database
> name in hba comparisons.
I think we are OK to move ahead with this.
Another question would be why only enable conne
On 03/01/2017 05:49 AM, Peter Eisentraut wrote:
On 2/27/17 09:51, Tom Lane wrote:
No objection to the basic point, but "log" seems perhaps a little too
generic to me. Would something like "server_log" be better?
Well, "log" is pretty well established. There is /var/log, and if you
unpack a,
On 3/5/17 16:07, Jim Nasby wrote:
>> There is nothing that requires us to materialize the results into an
>> actual list of actual rows. We could wrap the SPI_tuptable into a
>> Python object and implement __getitem__ or __iter__ to emulate sequence
>> or mapping access.
> Would it be possible to
Andreas Karlsson writes:
> On 03/01/2017 05:49 AM, Peter Eisentraut wrote:
>> On 2/27/17 09:51, Tom Lane wrote:
>>> No objection to the basic point, but "log" seems perhaps a little too
>>> generic to me. Would something like "server_log" be better?
>> Well, "log" is pretty well established. Th
2017-03-06 19:45 GMT+01:00 Peter Eisentraut :
> On 3/5/17 05:40, Jan Michálek wrote:
> > jelen=# \pset linestyle rst
> > Line style is rst.
> > jelen=# \pset format wrapped
> > Output format is wrapped.
> > jelen=# SELECT repeat('Goodnight Irene ', 30);
> > +---
On 3/4/17 02:09, Michael Paquier wrote:
> Well, that's one reason why I was thinking that having an independent
> in-core option to clean up the tail of the oldest segments is
> interesting: users don't need to maintain their own infra logic to do
> anything. Now this end-segment command can as wel
On 2017-03-04 11:09:40 +0530, Robert Haas wrote:
> On Sat, Mar 4, 2017 at 5:56 AM, Andres Freund wrote:
> > attached is a patch to address this problem, and the one reported by
> > Dilip. I ran a lot of TPC-H and other benchmarks, and so far this
> > addresses all the performance issues, often be
Stephen Frost writes:
> * Giuseppe Broccolo (giuseppe.brocc...@2ndquadrant.it) wrote:
>> I've seen that pg_dump execute the dump of an eventual comment of a
>> TSDictionary without specifying the namespace where it is defined:
> Great catch!
One of my smarter CS professors taught me that wheneve
On 3/3/17 09:03, Tomas Vondra wrote:
> Attached is v2, fixing both issues.
I wonder if
+ bytea *raw_page = PG_GETARG_BYTEA_P(0);
+ uargs->page = VARDATA(raw_page);
is expected to work reliably, without copying the argument to a
different memory context.
I think it would be better
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Giuseppe Broccolo (giuseppe.brocc...@2ndquadrant.it) wrote:
> >> I've seen that pg_dump execute the dump of an eventual comment of a
> >> TSDictionary without specifying the namespace where it is defined:
>
> > Great catch!
>
>
[original message held up for review -- should be along eventualy...]
On Mon, Mar 6, 2017 at 3:11 PM, Kevin Grittner wrote:
> With e434ad39ae7316bcf35fd578dd34ad7e1ff3c25f I did a `make world`,
> `make install-world`, a fresh default initdb, a start with default
> config, `make installcheck`, con
With e434ad39ae7316bcf35fd578dd34ad7e1ff3c25f I did a `make world`,
`make install-world`, a fresh default initdb, a start with default
config, `make installcheck`, connected to the regression database
with psql as the initial superuser, and ran:
regression=# vacuum freeze analyze;
WARNING: relcac
On 03/06/2017 10:13 PM, Peter Eisentraut wrote:
On 3/3/17 09:03, Tomas Vondra wrote:
Attached is v2, fixing both issues.
I wonder if
+ bytea *raw_page = PG_GETARG_BYTEA_P(0);
+ uargs->page = VARDATA(raw_page);
is expected to work reliably, without copying the argument to a
diff
On Sun, Mar 5, 2017 at 9:41 PM, Amit Kapila wrote:
>> RCA:
>>
>> From "Replace min_parallel_relation_size with two new GUCs" commit
>> onwards, we are not assigning parallel workers for the child rel with
>> zero heap pages. This means we won't be able to create a partial
>> append path as th
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Do you want to deal with this whole mess, or shall I have a go at it?
> I'm just about to push the pg_upgrade fixes for large object comments
> and security labels, followed not too far behind by the fix for the
> public ACL in pg_
On Mon, Mar 6, 2017 at 3:32 PM, Andres Freund wrote:
>> I think DEBUG1 is far too high for something that could occur with
>> some frequency on a busy system; I'm fairly strongly of the opinion
>> that you ought to downgrade that by a couple of levels, say to DEBUG3
>> or so.
>
> I actually planne
1 - 100 of 161 matches
Mail list logo
