On Wed, Jul 13, 2016 at 3:06 AM, Jeff Janes wrote:
> On Tue, Jul 12, 2016 at 10:48 AM, Peter Eisentraut
> wrote:
>> On 7/12/16 12:53 PM, Jeff Janes wrote:
>>> The --help message for pg_basebackup says:
>>>
>>> -Z, --compress=0-9 compress tar output with given compression level
>>>
>>> But -Z0
Hello,
On 2016/07/26 11:05, Kyotaro HORIGUCHI wrote:
> At Mon, 25 Jul 2016 18:21:27 +0900, Amit Langote wrote:
>
>> So, apparently RelationClearRelation() does intend to discard a cached
>> TupleDesc if ccvalid changed in a transaction. Whereas,
>> acquire_inherited_sample_rows() does not seem
On Mon, Jul 25, 2016 at 11:12:24PM -0400, Robert Haas wrote:
> On Fri, Jul 22, 2016 at 2:38 AM, David Fetter wrote:
> > I've renamed it to require_where and contrib-ified.
>
> I'm not sure that the Authors section is entirely complete.
Does this suit?
Best,
David.
--
David Fetter http://fette
On 07/25/16 22:09, Michael Paquier wrote:
> This is over-complicating things for little gain. The new behavior of
> filling in with zeros the tail of a segment makes things far better
> when using gzip in archive_command.
Then how about filling with actual zeros, instead of with mostly-zeros
as i
On Fri, Jul 22, 2016 at 2:38 AM, David Fetter wrote:
> I've renamed it to require_where and contrib-ified.
I'm not sure that the Authors section is entirely complete.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing
On Mon, Jul 25, 2016 at 6:04 PM, Tom Lane wrote:
> I suppose that a fix based on putting PG_TRY blocks into all the affected
> functions might be simple enough that we'd risk back-patching it, but
> I don't really want to go that way.
try/catch blocks aren't completely free, either, and PL/pgsql
On Mon, Jul 25, 2016 at 11:21 PM, Chapman Flack wrote:
> The impression that leaves is of tools that relied too heavily
> on internal format knowledge to be viable outside of core, which
> have had at least periods of incompatibility with newer PG versions,
> and whose current status, if indeed an
Hello,
At Mon, 25 Jul 2016 18:21:27 +0900, Amit Langote
wrote in
<96fb8bca-57f5-e5a8-9630-79d4fc5b2...@lab.ntt.co.jp>
>
> Hello,
>
> On 2016/07/25 17:18, Kyotaro HORIGUCHI wrote:
> >
> > - Remove ccvalid condition from equalTupleDescs() to reduce
> >unnecessary cache invalidation or tup
On Tue, Jul 26, 2016 at 5:58 AM, Robbie Harwood wrote:
> Robbie Harwood writes:
Sorry for my late reply.
>> I think in order to satisfy Tom's (valid) concern, there does need to be
>> a separate handshake - i.e., GSSAPI support in pqsecure_open_client().
Having the communication layer in fe-se
On 7/22/16 7:01 PM, Andrew Gierth wrote:
> In light of the fact that it is an endless cause of bugs both in pg and
> potentially to applications, I propose that we cease attempting to
> conform to the spec's definition of IS NULL in favour of the following
> rules:
I can't see how we would incompa
On 25/07/16 21:20, Andrew Gierth wrote:
> Here is my proposed code (first cut; obviously it needs docs too).
> Opinions?
I support the future of this patch, for 9.6.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formati
On 07/20/2016 10:08 AM, Simon Riggs wrote:
>
> Monitoring
>
> pg_stat_replication
>
>
> pg_stat_subscription
>
>
and probably also `pg_stat_publication` or some other way to see, what
tables are currently in a PUBLICATION, who has subscribed etc.
>
> CREATE PUBLICATION my
Alvaro Herrera writes:
> Tom Lane wrote:
>> Although this is in principle a bug fix, it's invasive enough that I'd
>> be pretty hesitant to back-patch it, or even to stick it into HEAD
>> post-beta. I'm inclined to sign it up for the next commitfest instead.
> Do we have a backpatchable fix for
Alvaro Herrera wrote:
> Tom Lane wrote:
>
> > Although this is in principle a bug fix, it's invasive enough that I'd
> > be pretty hesitant to back-patch it, or even to stick it into HEAD
> > post-beta. I'm inclined to sign it up for the next commitfest instead.
>
> Do we have a backpatchable fi
Tom Lane wrote:
> Although this is in principle a bug fix, it's invasive enough that I'd
> be pretty hesitant to back-patch it, or even to stick it into HEAD
> post-beta. I'm inclined to sign it up for the next commitfest instead.
Do we have a backpatchable fix for the reported problem? If so,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> "Joshua D. Drake" writes:
> > On 07/25/2016 12:19 PM, Tom Lane wrote:
> >> Andrew still hasn't shown a concrete
> >> example of what he needs to do and why.
>
> > I think that Andrew and other people who have commented on this thread
> > made it pretty ob
Robbie Harwood writes:
> Michael Paquier writes:
>
>> On Thu, Apr 7, 2016 at 8:20 AM, Tom Lane wrote:
>>> Robbie Harwood writes:
Tom Lane writes:
> Wait a second. So the initial connection-request packet is
> necessarily unencrypted under this scheme?
>>>
Yes, by neces
"Joshua D. Drake" writes:
> On 07/25/2016 12:19 PM, Tom Lane wrote:
>> Andrew still hasn't shown a concrete
>> example of what he needs to do and why.
> I think that Andrew and other people who have commented on this thread
> made it pretty obvious why it is useful.
Both Andrew and Robert have
On 07/25/2016 12:19 PM, Tom Lane wrote:
Robert Haas writes:
On Mon, Jul 25, 2016 at 10:35 AM, Tom Lane wrote:
You missed the "compelling argument why it's needed" part. What is the
need for this?
It's self-evident that this thread wouldn't exist if it were not the
case that people had que
> "Tom" == Tom Lane writes:
Tom> Andrew still hasn't shown a concrete example of what he needs to
Tom> do and why.
The issue I ran into was the exact same one as in the JDBC thread I
linked to earlier: correctly interpreting pg_index.indoption (to get the
ASC / DESC and NULLS FIRST/LAST se
Here is my proposed code (first cut; obviously it needs docs too).
Opinions?
--
Andrew (irc:RhodiumToad)
diff --git a/src/backend/access/index/amapi.c b/src/backend/access/index/amapi.c
index d347ebc..3e7e084 100644
--- a/src/backend/access/index/amapi.c
+++ b/src/backend/access/index/amapi.c
@@
Robert Haas writes:
> On Mon, Jul 25, 2016 at 10:35 AM, Tom Lane wrote:
>> You missed the "compelling argument why it's needed" part. What is the
>> need for this?
> It's self-evident that this thread wouldn't exist if it were not the
> case that people had queries that no longer work because o
Attached is a draft patch for creating statement-level temporary memory
contexts in plpgsql. It creates such contexts only as needed, and there
are a lot of simpler plpgsql statements that don't need them, so I think
the performance impact should be pretty minimal --- though I've not tried
to meas
Hi,
On 2016-07-25 15:02:41 +1200, Thomas Munro wrote:
> > Any thoughts on this approach, or better ways to solve this problem?
> > How valuable is the branch-free property of the circular push and
> > delete operations?
I think it's generally valuable, but I suspect that it doesn't really
matter
On Sun, Jul 24, 2016 at 11:02 PM, Thomas Munro
wrote:
> On Sun, Jul 24, 2016 at 1:10 AM, Thomas Munro
> wrote:
>> One solution could be to provide a non-circular variant of the dlist
>> interface that uses NULL list termination. I've attached a quick
>> sketch of something like that which seems
On Mon, Jul 25, 2016 at 10:35 AM, Tom Lane wrote:
> You missed the "compelling argument why it's needed" part. What is the
> need for this?
It's self-evident that this thread wouldn't exist if it were not the
case that people had queries that no longer work because of these new
changes. You can
I was trying to look up the background of this error message:
"Ispell dictionary supports only \"default\", \"long\", and \"num\" flag
value"
(src/backend/tsearch/spell.c)
But I found that this actually talks about Hunspell format dictionaries.
(So the man page is hunspell(5) as opposed to ispe
> "Tom" == Tom Lane writes:
>> It could easily be exposed as a function interface of the form
>> index_has_capability(oid,name) or indexam_has_capability(oid,name)
>> without any initdb worries.
Tom> You missed the "compelling argument why it's needed" part. What
Tom> is the need for t
Example: I have a database cluster initialized with --locale=ru_RU.UTF-8
(built with NLS). Let's say for some reason, I have client encoding set
to LATIN1. All error messages come back like this:
test=> select * from notthere;
ERROR: character with byte sequence 0xd0 0x9e in encoding "UTF8" has
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> We could in theory expose a view to show the data --- but since a
> Tom> large part of the point of that change was to not need initdb for
> Tom> AM API changes, and to not be constrained to exactly
> Tom> SQL-compatible representations
On 07/23/2016 08:25 AM, Amit Kapila wrote:
> On Sat, Jul 23, 2016 at 3:32 AM, Chapman Flack wrote:
>>
>> Would it then be possible to go back to the old behavior (or make
>> it selectable) of not overwriting the full 16 MB every time?
>>
>
> I don't see going back to old behaviour is an improveme
* Andrew Gierth (and...@tao11.riddles.org.uk) wrote:
> > "Tom" == Tom Lane writes:
>
> >> With the gutting of pg_am in 9.6, there seems to be no longer any
> >> way for a query of the system catalogs to discover any of the index
> >> capabilities that were formerly columns in pg_am (notabl
> "Tom" == Tom Lane writes:
>> With the gutting of pg_am in 9.6, there seems to be no longer any
>> way for a query of the system catalogs to discover any of the index
>> capabilities that were formerly columns in pg_am (notably
>> amcanorder, amcanorderbyop, amclusterable, amsearcharray,
Andrew Gierth writes:
> With the gutting of pg_am in 9.6, there seems to be no longer any way
> for a query of the system catalogs to discover any of the index
> capabilities that were formerly columns in pg_am (notably amcanorder,
> amcanorderbyop, amclusterable, amsearcharray, amsearchnulls).
>
With the gutting of pg_am in 9.6, there seems to be no longer any way
for a query of the system catalogs to discover any of the index
capabilities that were formerly columns in pg_am (notably amcanorder,
amcanorderbyop, amclusterable, amsearcharray, amsearchnulls).
Am I missing something or is thi
On Mon, Jul 25, 2016 at 2:52 PM, Michael Paquier
wrote:
> Ah, yes, and that's a stupid mistake. We had better use
> replay_location instead of write_location. There is a risk that
> records have not been replayed yet even if they have been written on
> the standby, so it is possible that the query
On 7/20/16 8:55 AM, Daniel Verite wrote:
> Personally I think that TLS for local networking is wrong as a default, and
> it's unfortunate that distros like Debian/Ubuntu end up using that.
There is something to that, but I'm not sure that just giving up and
disabling SSL in the default configurati
On Mon, Jul 25, 2016 at 7:42 PM, Ildar Musin wrote:
> I was checking out TAP tests documentation. And I found confusing this part
> of src/test/perl/README file:
>
> my $ret = $node->psql('postgres', 'SELECT 1');
> is($ret, '1', 'SELECT 1 returns 1');
Good catch.
> The returning value of
On Sun, Jul 24, 2016 at 9:17 PM, Tom Lane wrote:
> Amit Kapila writes:
>
>> Wouldn't it be better, if each nested sub-block (which is having an
>> exception) has a separate "SPI Proc", "SPI Exec" contexts which would
>> be destroyed at sub-block end (either commit or rollback)?
>
> AFAICS that wo
Hi,
I spent some time profiling a simply query with a SUM() aggregate. We've
made some big improvements in this area in recent years, but it seems
there's still some room for improvement. A lot of CPU time is spent in
the numeric add_var() and friends. Which isn't that surprising, I guess.
I
Hi all,
I was checking out TAP tests documentation. And I found confusing this
part of src/test/perl/README file:
my $ret = $node->psql('postgres', 'SELECT 1');
is($ret, '1', 'SELECT 1 returns 1');
The returning value of psql() function is the exit code of the psql.
Hence this test w
>Can you please patch BRIN to use this new function too?
AFAIK Sergey Mirvoda was going to implement and test it.
It is easy to do this optimization for brin_samepage_update (see patch
draft in attachment, make check passes), but WAL of regular BRIN
update is not clear for me.
Best regards, Andrey
Hello,
On 2016/07/25 17:18, Kyotaro HORIGUCHI wrote:
>
> - Remove ccvalid condition from equalTupleDescs() to reduce
>unnecessary cache invalidation or tuple rebuilding.
The following commit introduced the ccvalid check:
"""
commit c31305de5f5a4880b0ba2f5983025ef0210a3b2a
Author: Noah Mis
On Thu, Jul 14, 2016 at 2:22 PM, Masahiko Sawada wrote:
> Hi all,
>
> Attached patch fixes small typo in contrib/postgres_fdw/deparse.c
>
> s/whenver/whenever/g
Applied. Thanks!
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
The comment seems to have been copied from ATExecAddColumn, which says:
/*
* If we are told not to recurse, there had better not be any
- * child tables; else the addition would put them out of step.
For ATExecValidateConstraint, it should say something like:
+ * child tables; else validating
Hello,
At Mon, 25 Jul 2016 15:57:00 +0900, Amit Langote
wrote in
> On 2016/07/25 12:44, Kyotaro HORIGUCHI wrote:
> > At Fri, 22 Jul 2016 17:35:48 +0900, Amit Langote wrote:
> >> On 2016/07/22 17:06, Kyotaro HORIGUCHI wrote:
> >>
> >>> By the way I have one question.
> >>>
> >>> Is it an expect
46 matches
Mail list logo
