On Tue, Oct 25, 2016 at 10:57:24AM -0400, Noah Misch wrote:
> When commit 3e23b68dac006e8deb0afa327e855258df8de064 introduced single-byte
> varlena headers, its fmgr.h changes presented PG_GETARG_TEXT_PP() and
> PG_GETARG_TEXT_P() as equals. Its postgres.h changes presented
> PG_DETOAST_DATUM_PACK
Thank you for the comment.
At Wed, 22 Feb 2017 16:06:14 +0900, Michael Paquier
wrote in
> Thanks for the rebase. I have been spending sore time looking at this
> patch. The new stuff in convutils.pm is by far the interesting part of
> the patch, where the building of the radix trees using a byt
On 15.02.2017 15:26, Amul Sul wrote:
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: tested, passed
Spec compliant: not tested
Documentation:tested, passed
Review of v7 patch:
- Patch ap
Thank you for your kind advise!
Michael Meskes wrote:
> The other option I can see, albeit without looking into details, is
> allowing all comments and then testing it for the right syntax after
> parsing. This could potentially also solve the above mentioned option
> problem.
This idea sounds gre
Hi,
I'd like to propose to support parameterized foreign joins. Attached is
a patch for that, which has been created on top of [1].
In [2], I said that postgres_fdw could create parameterized paths from
joinable combinations of the cheapest-parameterized paths for the
inner/outer relatio
With these patches:
-- 0416d87c-09a5-182e-4901-236aec103...@2ndquadrant.com
Subject: Re: Logical Replication WIP
48.
https://www.postgresql.org/message-id/attachment/49886/0001-Use-asynchronous-connect-API-in-libpqwalreceiver.patch
49.
https://www.postgresql.org/message-id/attachment/498
On 2017/02/15 12:00, Robert Haas wrote:
> On Fri, Feb 10, 2017 at 3:00 AM, Simon Riggs wrote:
>
>> Without claiming I'm happy about this, I think the best way to improve
>> the number of eyeballs on this is to commit these docs as is.
>>
>> For me, the most important thing is understanding the fe
2017-02-24 21:25 GMT+01:00 Jim Nasby :
> On 2/24/17 6:40 AM, Peter Moser wrote:
>>
>> Do you think it is better to remove the syntax for ranges expressed in
>> different columns?
>
>
> It's not that hard to construct a range type on-the-fly from 2 columns, so
> (without having looked at the patch o
Hi,
On 2017-02-24 14:10:38 -0800, Andres Freund wrote:
> I've not yet looked a lot at the next type of context - I want to get
> this much committed first...
>
> I plan to give this another pass sometime this weekend and then push
> soon.
Before committing I wanted to make sure that
http://archiv
ilm...@ilmari.org (Dagfinn Ilmari Manns�ker) writes:
> Here's an updated patch wich adds it as a separate stanza.
I've added this to the current commit fest:
https://commitfest.postgresql.org/13/1043/
--
"I use RMS as a guide in the same way that a boat captain would use
a lighthouse. It's go
> Michael Meskes wrote:
> > The other option I can see, albeit without looking into details, is
> > allowing all comments and then testing it for the right syntax
> > after
> > parsing. This could potentially also solve the above mentioned
> > option
> > problem.
>
> This idea sounds great. But I
On 27 February 2017 at 10:12, Amit Langote
wrote:
> I agree that my patch failed to de-emphasize the old partitioning method
> enough. The examples in 5.11 Partitioning chapter also did not highlight
> the new partitioning feature as much as it should have been, so it indeed
> reads like a descr
On 2017-02-24 15:18:04 -0800, Andres Freund wrote:
> On 2017-02-24 15:12:37 -0800, Andres Freund wrote:
> > On 2017-02-24 18:04:18 -0500, Tom Lane wrote:
> > > Concretely, something like the attached. This passes regression tests
> > > but I've not pushed on it any harder than that.
> >
> > Heh,
Hi,
On 2017-02-27 03:17:32 -0800, Andres Freund wrote:
> I'll work on getting slab committed first, and then review / edit /
> commit generation.c later. One first note there is that I'm wondering
> if generation.c is a too generic filename.
And pushed slab and its usage. Will have a look at ge
Robert Haas writes:
> On Mon, Feb 27, 2017 at 1:24 AM, Tom Lane wrote:
>> * I'm not terribly comfortable about what the permissions levels of the
>> GUCs ought to be. ... Maybe we'd better make them both SUSET.
> Making them SUSET sounds like a usability fail to me. I'm not sure
> how bad the s
Kevin Grittner writes:
> It occurred to me that it would make sense to allow these settings
> to be attached to a database or table (though *not* a role). I'll
> look at that when I get back if you don't get to it first.
Attached is a draft patch (no docs or tests) on top of the previous one,
a
On 2/26/17 05:05, Robert Haas wrote:
> That having been said, I do agree with Tom's point that we already
> have one more bytea_output format than would be ideal. To justify
> implementing base64 as a third choice, it would have to not only be
> better than hex, but enough better to justify the mi
On 2/16/17 08:13, Anastasia Lubennikova wrote:
> @@ -629,7 +630,7 @@ static Node *makeRecursiveViewSelect(char *relname, List
> *aliases, Node *query);
>
> HANDLER HAVING HEADER_P HOLD HOUR_P
>
> - IDENTITY_P IF_P ILIKE IMMEDIATE IMMUTABLE IMPLICIT_P IMPORT_P IN_P
> + IDENTITY_P
On 2/26/17 11:46, Robert Haas wrote:
> I don't see
> a solution other than launching a separate worker for each database,
> which seems like it could be extremely expensive if there are many
> databases.
You don't have to start all these workers at once. Starting one and not
starting the next one
On 2/8/17 11:00, Tom Lane wrote:
> Peter Eisentraut writes:
>> Here is a patch to systematically trim the trailing newlines off
>> PQerrorMessage() results in backend uses (dblink, postgres_fdw,
>> libpqwalreceiver).
>
> +1
committed
>> I noticed that there are some inconsistent assumptions abo
How about changing the default for log_directory from 'pg_log' to, say,
'log'?
We have been emphasizing that the prefix "pg_" is for things reserved to
PostgreSQL, whereas the pg_log directory is entirely an arbitrary
user-space name. Also, with a different name, the directory would stand
out mor
On 27/02/17 11:07, Erik Rijkers wrote:
> With these patches:
>
> -- 0416d87c-09a5-182e-4901-236aec103...@2ndquadrant.com
>Subject: Re: Logical Replication WIP
> 48.
> https://www.postgresql.org/message-id/attachment/49886/0001-Use-asynchronous-connect-API-in-libpqwalreceiver.patch
>
> 49.
Hi,
I've found the (AIUI) previous discussion about this, it's Bug #13907:
https://www.postgresql.org/message-id/flat/20160202161407.2778.24659%40wrigleys.postgresql.org#20160202161407.2778.24...@wrigleys.postgresql.org
On Wed, Feb 22, 2017 at 05:24:49PM -0600, Jim Nasby wrote:
> On 2/22/17 12:29
On 02/27/2017 12:17 PM, Andres Freund wrote:
Hi,
On 2017-02-24 14:10:38 -0800, Andres Freund wrote:
I've not yet looked a lot at the next type of context - I want to get
this much committed first...
I plan to give this another pass sometime this weekend and then push
soon.
Before committing
On 02/27/2017 01:02 PM, Andres Freund wrote:
Hi,
On 2017-02-27 03:17:32 -0800, Andres Freund wrote:
I'll work on getting slab committed first, and then review / edit /
commit generation.c later. One first note there is that I'm wondering
if generation.c is a too generic filename.
And pushed
On 02/26/2017 02:54 PM, Tom Lane wrote:
> * I'm not terribly comfortable about what the permissions levels of the
> GUCs ought to be. The call permissions check means that you can't use
> either GUC to call a function you couldn't have called anyway. However
> there's a separate risk of trojan-
On Mon, Feb 27, 2017 at 09:05:16AM -0500, Peter Eisentraut wrote:
> How about changing the default for log_directory from 'pg_log' to, say,
> 'log'?
+1
A lot of work has already gone into this release to clarify what
things are PostgreSQL internals and which ones are not. This will
help.
Yes, m
Peter Eisentraut writes:
> How about changing the default for log_directory from 'pg_log' to, say,
> 'log'?
> We have been emphasizing that the prefix "pg_" is for things reserved to
> PostgreSQL, whereas the pg_log directory is entirely an arbitrary
> user-space name. Also, with a different nam
Sun, Feb 26, 2017 at 12:24 AM, Michael Paquier
wrote:
> On Sun, Feb 26, 2017 at 12:41 AM, Magnus Hagander
> wrote:
> > On Feb 25, 2017 15:00, "Michael Paquier"
> wrote:
> >
> > On Sat, Feb 25, 2017 at 10:32 PM, Magnus Hagander
> > wrote:
> >> Oh, I definitely think such a command should be ab
On Sun, Feb 26, 2017 at 10:46 AM, Robert Haas wrote:
> On Thu, Feb 23, 2017 at 9:40 PM, Magnus Hagander
> wrote:
> > I'm not sure this logic belongs in pg_receivexlog. If we put the decision
> > making there, then we lock ourselves into one "type of policy".
>
> That's not really true. We can a
On Mon, Feb 27, 2017 at 7:18 PM, Peter Eisentraut
wrote:
> On 2/26/17 11:46, Robert Haas wrote:
>> I don't see
>> a solution other than launching a separate worker for each database,
>> which seems like it could be extremely expensive if there are many
>> databases.
>
> You don't have to start all
On February 27, 2017 6:14:20 AM PST, Tomas Vondra
wrote:
>On 02/27/2017 01:02 PM, Andres Freund wrote:
>> Hi,
>>
>> On 2017-02-27 03:17:32 -0800, Andres Freund wrote:
>>> I'll work on getting slab committed first, and then review / edit /
>>> commit generation.c later. One first note there is
On Sun, Feb 26, 2017 at 9:59 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > On Sun, Feb 26, 2017 at 8:27 PM, Michael Banck <
> michael.ba...@credativ.de>
> > wrote:
> >> ISTM the consensus is that there should be no output in regular mode,
> >> but a message should be displayed in verbose and
Magnus Hagander writes:
> On Sun, Feb 26, 2017 at 9:59 PM, Tom Lane wrote:
>> Is there an argument for back-patching this?
> I'm considering it, but not swayed in either direction. Should I take your
> comment as a vote that we should back-patch it?
Yeah, I'd vote for it.
On Mon, Feb 27, 2017 at 7:03 AM, Andres Freund wrote:
> Hi,
>
> On 2017-02-27 14:43:49 +0900, Michael Paquier wrote:
> > I bumped into a case where it would have been rather useful to specify
> > a service file path in a connection string with a service name. In my
> > case, I have finished by se
Andres Freund writes:
> And pushed slab and its usage. Will have a look at generation.c
> tomorrow.
Perhaps first you need to find out why so much of the buildfarm
is unhappy.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
On 2017-02-27 10:32:25 -0500, Tom Lane wrote:
> Andres Freund writes:
> > And pushed slab and its usage. Will have a look at generation.c
> > tomorrow.
>
> Perhaps first you need to find out why so much of the buildfarm
> is unhappy.
Will do, after a morning coffee.
- Andres
--
Sent via pgs
On Mon, Feb 27, 2017 at 7:08 PM, Peter Eisentraut
wrote:
> On 2/26/17 05:05, Robert Haas wrote:
>> That having been said, I do agree with Tom's point that we already
>> have one more bytea_output format than would be ideal. To justify
>> implementing base64 as a third choice, it would have to not
Hi hackers,
Working on vectorized extension for Postgres (VOPS) I faced with two
things in Postgres compiler which break my expectations and force me to
abandon my original implementation plan. I wonder if it is really
principle and correct that:
1. Moving-aggregate implementation should ret
On 2/27/17 2:54 AM, Robert Haas wrote:
> On Mon, Feb 27, 2017 at 12:23 PM, Michael Paquier
> wrote:
>> On Mon, Feb 27, 2017 at 3:46 PM, Robert Haas wrote:
>>> Do we, ah, have a CommitFest manager for this final CommitFest?
>>
>> No, victims found yet.
>>
>>> /me takes two quick steps backward.
>>
On 2017-02-27 16:23:46 +0100, Magnus Hagander wrote:
> On Mon, Feb 27, 2017 at 7:03 AM, Andres Freund wrote:
> > On 2017-02-27 14:43:49 +0900, Michael Paquier wrote:
> > > I bumped into a case where it would have been rather useful to specify
> > > a service file path in a connection string with a
Konstantin Knizhnik writes:
> 1. Moving-aggregate implementation should return the same type as plain
> implementation. Yes, in most cases it is hard to find arguments why them
> should return different types. But it is not true for vectorized
> operations...
I can't see a reason why we would
On 2017-02-27 07:55:32 -0800, Andres Freund wrote:
> On 2017-02-27 10:32:25 -0500, Tom Lane wrote:
> > Andres Freund writes:
> > > And pushed slab and its usage. Will have a look at generation.c
> > > tomorrow.
> >
> > Perhaps first you need to find out why so much of the buildfarm
> > is unhapp
Hi,
On 2017-02-27 15:11:40 +0100, Tomas Vondra wrote:
> > I've not yet reviewed the generational allocator yet, but during these
> > measurements I get:
> > postgres[3970][1]=# select count(*) FROM pg_logical_slot_get_changes('ttt',
> > NULL, NULL);
> > WARNING: 01000: problem in Generation Tupl
On 02/27/2017 05:48 PM, Andres Freund wrote:
On 2017-02-27 07:55:32 -0800, Andres Freund wrote:
On 2017-02-27 10:32:25 -0500, Tom Lane wrote:
Andres Freund writes:
And pushed slab and its usage. Will have a look at generation.c
tomorrow.
Perhaps first you need to find out why so much of th
Hi,
On 2017-02-27 17:56:08 +0100, Tomas Vondra wrote:
> No, I don't, but I'll ping Craig. I might ping him, but it's ~4AM in
> Australia, though, so it'll take time.
Did the same... ;)
> FWIW I think the ppc64 machines are failing because of unrelated issue
> (changes to integer timestamps). We
On 27/02/17 18:00, Andres Freund wrote:
>
>> FWIW I think the ppc64 machines are failing because of unrelated issue
>> (changes to integer timestamps). We should probably look at 32bit machines
>> first.
>
> Don't think so - termite is ppc64 afaics, and the failure doesn't look
> integer timestam
Andres Freund writes:
>> FWIW I think the ppc64 machines are failing because of unrelated issue
>> (changes to integer timestamps). We should probably look at 32bit machines
>> first.
> Don't think so - termite is ppc64 afaics, and the failure doesn't look
> integer timestamp related (assert fail
On Thu, Feb 16, 2017 at 8:16 PM, Amit Kapila wrote:
> Attached are refactoring patches. WAL patch needs some changes based
> on above comments, so will post it later.
After some study, I have committed 0001, and also committed 0002 and
0003 as a single commit, with only minor tweaks.
I haven't
On Mon, Feb 27, 2017 at 9:39 PM, David Steele wrote:
> I'm happy to be CFM. Somehow I doubt there will be a lot of objections!
No. Aren't you the guy who did a good job with it last year and just
about perished in the process?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enter
On Mon, Feb 27, 2017 at 11:09 PM, Robert Haas wrote:
> On Mon, Feb 27, 2017 at 9:39 PM, David Steele wrote:
>> I'm happy to be CFM. Somehow I doubt there will be a lot of objections!
>
> No. Aren't you the guy who did a good job with it last year and just
> about perished in the process?
(Just
On 2017-02-27 18:04:41 +0100, Petr Jelinek wrote:
> On 27/02/17 18:00, Andres Freund wrote:
> >
> >> FWIW I think the ppc64 machines are failing because of unrelated issue
> >> (changes to integer timestamps). We should probably look at 32bit machines
> >> first.
> >
> > Don't think so - termite
Andres Freund writes:
> The best theory I have so far that I have is that slab.c's idea of
> StandardChunkHeader's size doesn't match what mcxt.c think it is
> (because slab.c simply embeds StandardChunkHeader, but mcxt uses
> MAXALIGN(sizeof(StandardChunkHeader))). That's not good, but I don't
>
On 2017-02-27 12:27:48 -0500, Tom Lane wrote:
> Andres Freund writes:
> > The best theory I have so far that I have is that slab.c's idea of
> > StandardChunkHeader's size doesn't match what mcxt.c think it is
> > (because slab.c simply embeds StandardChunkHeader, but mcxt uses
> > MAXALIGN(sizeof
On 2017-02-27 23:09:40 +0530, Robert Haas wrote:
> On Mon, Feb 27, 2017 at 9:39 PM, David Steele wrote:
> > I'm happy to be CFM. Somehow I doubt there will be a lot of objections!
>
> No. Aren't you the guy who did a good job with it last year and just
> about perished in the process?
Yea, I w
On 2/27/17 12:40 PM, Robert Haas wrote:
> On Mon, Feb 27, 2017 at 11:09 PM, Robert Haas wrote:
>> On Mon, Feb 27, 2017 at 9:39 PM, David Steele wrote:
>>> I'm happy to be CFM. Somehow I doubt there will be a lot of objections!
>>
>> No. Aren't you the guy who did a good job with it last year an
On 02/27/2017 06:40 PM, Andres Freund wrote:
On 2017-02-27 18:04:41 +0100, Petr Jelinek wrote:
On 27/02/17 18:00, Andres Freund wrote:
FWIW I think the ppc64 machines are failing because of unrelated issue
(changes to integer timestamps). We should probably look at 32bit machines
first.
Don
On Sat, Feb 25, 2017 at 10:51 PM, Robert Haas wrote:
> The thing that strikes me based on what you wrote is that our page
> recycling seems to admit of long delays even as things stand. There's
> no bound on how much time could pass between one index vacuum and the
> next, and RecentGlobalXmin co
On 26 February 2017 at 20:55, Magnus Hagander wrote:
> What do others think?
Changing the output behaviour of a command isn't something we usually
do as a backpatch.
This change doesn't affect the default behaviour so probably wouldn't
make a difference to the outcome of the situation that gene
On 02/27/2017 04:07 PM, Andres Freund wrote:
On February 27, 2017 6:14:20 AM PST, Tomas Vondra
wrote:
On 02/27/2017 01:02 PM, Andres Freund wrote:
Hi,
On 2017-02-27 03:17:32 -0800, Andres Freund wrote:
I'll work on getting slab committed first, and then review /
edit / commit generation.c
On 2017-02-27 19:20:56 +0100, Tomas Vondra wrote:
> On 02/27/2017 12:55 PM, Andres Freund wrote:
> > On 2017-02-24 15:18:04 -0800, Andres Freund wrote:
> > > On 2017-02-24 15:12:37 -0800, Andres Freund wrote:
> > > > On 2017-02-24 18:04:18 -0500, Tom Lane wrote:
> > > > > Concretely, something like
On 02/27/2017 12:55 PM, Andres Freund wrote:
On 2017-02-24 15:18:04 -0800, Andres Freund wrote:
On 2017-02-24 15:12:37 -0800, Andres Freund wrote:
On 2017-02-24 18:04:18 -0500, Tom Lane wrote:
Concretely, something like the attached. This passes regression tests
but I've not pushed on it any
On Sun, Feb 26, 2017 at 12:32 PM, Magnus Hagander
wrote:
>
> On Sun, Feb 26, 2017 at 8:27 PM, Michael Banck
> wrote:
>
>> Hi,
>>
>> Am Dienstag, den 14.02.2017, 18:18 -0500 schrieb Robert Haas:
>> > On Tue, Feb 14, 2017 at 4:06 PM, Alvaro Herrera
>> > wrote:
>> > > I'd rather have a --quiet mod
+Vladimir
On 27 February 2017 at 11:36, Andres Freund wrote:
> On 2017-02-27 16:23:46 +0100, Magnus Hagander wrote:
> > On Mon, Feb 27, 2017 at 7:03 AM, Andres Freund
> wrote:
> > > On 2017-02-27 14:43:49 +0900, Michael Paquier wrote:
> > > > I bumped into a case where it would have been rather
On Fri, Feb 10, 2017 at 03:19:47PM +0900, Amit Langote wrote:
> The new partitioned tables do not contain any data by themselves. Any
> data inserted into a partitioned table is routed to and stored in one of
> its partitions. In fact, it is impossible to insert *any* data before a
> partition (t
On Fri, Feb 17, 2017 at 09:54:37AM +0100, Magnus Hagander wrote:
> If we could somehow integrate PGXN with both the RPM build process, the DEB
> build process and a Windows build process (whether driven by PGXN or just "fed
> enough data" by PGXN is a different question), I think that would go a lo
On Fri, Feb 17, 2017 at 11:05:31PM +0900, Michael Paquier wrote:
> On Fri, Feb 17, 2017 at 10:43 PM, Andreas Karlsson wrote:
> > Thinking about this makes me wonder about why you decided to use a
> > transaction per index in many of the steps rather than a transaction per
> > step. Most steps shou
Andrew Dunstan writes:
> On 02/26/2017 02:54 PM, Tom Lane wrote:
>> * I'm not terribly comfortable about what the permissions levels of the
>> GUCs ought to be.
> plperl's on_plperl_init and on_plperlu_init settings are both SUSET.
> In practice with PLv8 this is usually set in the config file in
On Thu, Feb 23, 2017 at 3:08 AM, Thom Brown wrote:
> On 23 January 2017 at 11:56, Ivan Kartyshov
> wrote:
>>
>> Thank you for reading, will be glad to get your feedback.
>
> Could you please rebase your patch as it no longer applies cleanly.
+1
--
Thomas Munro
http://www.enterprisedb.com
--
On Feb 27, 2017, at 12:04 PM, Bruce Momjian wrote:
> Just stating the obvious, but one of the reasons CPAN works so well is
> that most of the modules are written in Perl and hence don't need
> per-platform compilation.
There are a *lot* of C-baded modules on CPAN; and my guess is that, more oft
On 02/26/2017 04:09 PM, Andrew Dunstan wrote:
>
> On 02/26/2017 03:26 PM, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> This works for the btree_gin case. However, there's a difficulty for
>>> btree_gist - in the puicksplit routine the cmp function is passed to
>>> qsort() so there is no chance
On 27/02/17 07:59, Amit Langote wrote:
> On 2017/02/27 3:18, Petr Jelinek wrote:
>> On 24/02/17 07:15, Robert Haas wrote:
>>> On Fri, Feb 24, 2017 at 9:53 AM, Simon Riggs wrote:
The good news is that logical replication DOES work with partitioning,
but only for a Publication with PUBLISH
Andrew Dunstan writes:
> OK, here's the whole series of patches.
I've not tested it at all, but this looks generally sane in a quick
once-over.
A minor quibble is that in 0003, you weren't terribly consistent about
argument order --- in some places you have the FmgrInfo argument added
before the
On Mon, Feb 27, 2017 at 01:00:20PM -0800, David E. Wheeler wrote:
> On Feb 27, 2017, at 12:04 PM, Bruce Momjian wrote:
>
> > Just stating the obvious, but one of the reasons CPAN works so well is
> > that most of the modules are written in Perl and hence don't need
> > per-platform compilation.
>
On Feb 27, 2017, at 1:53 PM, Bruce Momjian wrote:
> Oh, does CPAN distribute compiled modules or requires users to compile
> them.
Like PGXN, it formally does not care, but its implementation expects source
code distributions what will be built and installed by users. Note that the
vast majori
There is also a mechanism for the results of the Perl module's "make test"
to be reported to a site which aggregates and reports them by Perl version
and OS - a sort of distributed build farm. See for example
http://matrix.cpantesters.org/?dist=DBD-Pg+3.5.3
__
On Tue, Feb 28, 2017 at 5:29 AM, Bruce Momjian wrote:
> On Fri, Feb 17, 2017 at 11:05:31PM +0900, Michael Paquier wrote:
>> On Fri, Feb 17, 2017 at 10:43 PM, Andreas Karlsson wrote:
>> > Thinking about this makes me wonder about why you decided to use a
>> > transaction per index in many of the s
Michael Paquier writes:
> I don't object to the addition of this patch in next CF as this
> presents no new concept. Still per the complications this patch and
> because it is a complicated patch I was wondering if people are fine
> to include it in this last CF.
The March CF is already looking p
On Mon, Feb 27, 2017 at 05:31:21PM -0500, Tom Lane wrote:
> Michael Paquier writes:
> > I don't object to the addition of this patch in next CF as this
> > presents no new concept. Still per the complications this patch and
> > because it is a complicated patch I was wondering if people are fine
>
Hi all!
It seems that PostgreSQL has passed to GSoC mentoring organizations this
year!
https://summerofcode.withgoogle.com/organizations/4558465230962688/
Congratulations!
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Mon, Jan 16, 2017 at 5:56 PM, Peter Geoghegan wrote:
> On Wed, Oct 12, 2016 at 10:16 AM, Heikki Linnakangas wrote:
>> The number of *input* tapes we can use in each merge pass is still limited,
>> by the memory needed for the tape buffers and the merge heap, but only one
>> output tape is acti
On Tue, Feb 28, 2017 at 11:42 AM, Alexander Korotkov
wrote:
> Hi all!
>
> It seems that PostgreSQL has passed to GSoC mentoring organizations this
> year!
> https://summerofcode.withgoogle.com/organizations/4558465230962688/
> Congratulations!
Very cool!
By the way, that page claims that Postgre
On Tue, Feb 28, 2017 at 2:43 AM, Andres Freund wrote:
> On 2017-02-27 23:09:40 +0530, Robert Haas wrote:
>> On Mon, Feb 27, 2017 at 9:39 PM, David Steele wrote:
>> > I'm happy to be CFM. Somehow I doubt there will be a lot of objections!
>>
>> No. Aren't you the guy who did a good job with it l
On 2/27/17 6:40 PM, Michael Paquier wrote:
> On Tue, Feb 28, 2017 at 2:43 AM, Andres Freund wrote:
>> On 2017-02-27 23:09:40 +0530, Robert Haas wrote:
>>> On Mon, Feb 27, 2017 at 9:39 PM, David Steele wrote:
I'm happy to be CFM. Somehow I doubt there will be a lot of objections!
>>>
>>> No.
Currently pg_stop_backup() will wait for all WAL to be archived before
returning. If there is a problem with the archive command or a large
backlog it may not return for a very long time (if ever). Backup
software is faced with the choice of cancelling the query and hoping the
stop backup record
on 2017-02-24 04:41:09 Simon Riggs wrote:
> ...you didn't comment at all on the accuracy and usefulness of the
> gathered statistics, when the sample is biased towards non-updated
> data.
In my understanding, the sample for statistics is not biased at least in our
use case because the conversion
On Tue, Feb 28, 2017 at 9:21 AM, David Steele wrote:
> Looks like it's me, then. I don't seem to have admin privileges to
> close the commitfest or I don't know where the option is located.
>
> Can somebody grant privileges or close the CF at 3/1 12AM AoE (UTC-12)
> for me?
I have no way to give
On 2/27/17 7:27 PM, Michael Paquier wrote:
> On Tue, Feb 28, 2017 at 9:21 AM, David Steele wrote:
>> Looks like it's me, then. I don't seem to have admin privileges to
>> close the commitfest or I don't know where the option is located.
>>
>> Can somebody grant privileges or close the CF at 3/1 1
On Tue, Feb 28, 2017 at 9:25 AM, David Steele wrote:
> I also marked the pg_stop_* functions as parallel restricted, the same
> as pg_start_backup(). Previously they were parallel safe which I don't
> believe is accurate for the non-exclusive version at the very least,
> since it is tied to a par
On 2/27/17 7:38 PM, Michael Paquier wrote:
> On Tue, Feb 28, 2017 at 9:25 AM, David Steele wrote:
>> I also marked the pg_stop_* functions as parallel restricted, the same
>> as pg_start_backup(). Previously they were parallel safe which I don't
>> believe is accurate for the non-exclusive versio
On 02/27/2017 06:42 PM, Andres Freund wrote:
On 2017-02-27 12:27:48 -0500, Tom Lane wrote:
Andres Freund writes:
The best theory I have so far that I have is that slab.c's idea of
StandardChunkHeader's size doesn't match what mcxt.c think it is
(because slab.c simply embeds StandardChunkHeader
On Tue, Feb 28, 2017 at 9:42 AM, David Steele wrote:
> On 2/27/17 7:38 PM, Michael Paquier wrote:
>> On Tue, Feb 28, 2017 at 9:25 AM, David Steele wrote:
>>> I also marked the pg_stop_* functions as parallel restricted, the same
>>> as pg_start_backup(). Previously they were parallel safe which
On 2/27/17 7:50 PM, Michael Paquier wrote:
> On Tue, Feb 28, 2017 at 9:42 AM, David Steele wrote:
>> On 2/27/17 7:38 PM, Michael Paquier wrote:
>>> On Tue, Feb 28, 2017 at 9:25 AM, David Steele wrote:
I also marked the pg_stop_* functions as parallel restricted, the same
as pg_start_bac
On Mon, Feb 20, 2017 at 09:07:33AM -0500, Tom Lane wrote:
> The question to be asked is whether there is still anybody out there
> using float timestamps. I'm starting to get dubious about it myself.
> Certainly, no packager that I'm aware of has shipped a float-timestamp
> build since we switched
On 02/22/2017 02:45 PM, Tom Lane wrote:
Andres Freund writes:
On 2017-02-22 08:43:28 -0500, Tom Lane wrote:
(To be concrete, I'm suggesting dropping --disable-integer-datetimes
in HEAD, and just agreeing that in the back branches, use of replication
protocol with float-timestamp servers is not
On 2017-02-27 17:00:23 -0800, Joshua D. Drake wrote:
> On 02/22/2017 02:45 PM, Tom Lane wrote:
> > Andres Freund writes:
> > > On 2017-02-22 08:43:28 -0500, Tom Lane wrote:
> > > > (To be concrete, I'm suggesting dropping --disable-integer-datetimes
> > > > in HEAD, and just agreeing that in the b
On Sat, Feb 25, 2017 at 2:45 AM, Dilip Kumar wrote:
> On Fri, Feb 24, 2017 at 11:43 AM, Haribabu Kommi
> wrote:
> > Here I attached an implementation patch that allows
> > utility statements that have queries underneath such as
> > CREATE TABLE AS, CREATE MATERIALIZED VIEW
> > and REFRESH comman
On Thu, Feb 23, 2017 at 10:36:37AM -0500, Stephen Frost wrote:
> All,
>
> * Stephen Frost (sfr...@snowman.net) wrote:
> > Just wanted to get a note out to -hackers about the issue, I'll see
> > about getting a fix written up for it soon.
>
> Attached is a patch which addresses this issue. I'm no
On Sat, Feb 25, 2017 at 3:21 AM, Robert Haas wrote:
> On Fri, Feb 24, 2017 at 11:43 AM, Haribabu Kommi
> wrote:
> > Here I attached an implementation patch that allows
> > utility statements that have queries underneath such as
> > CREATE TABLE AS, CREATE MATERIALIZED VIEW
> > and REFRESH comman
Hello, I found a variable definition with wrong type
specification in KeepLogSeg, which doesn't harm anything.
> static void
> KeepLogSeg(XLogRecPtr recptr, XLogSegNo *logSegNo)
> {
> ...
> /* then check whether slots limit removal further */
> if (max_replication_slots > 0 && keep != Inva
1 - 100 of 148 matches
Mail list logo
