Hi
On Russian PgConf I had a talk with Oleg about missing features in PLpgSQL,
that can complicates a migrations from Oracle to PostgreSQL. Currently I
see only one blocker - missing protected session variables. PL/SQL has
package variables with possible only package scope and session life cycle.
Hello, I am one who wants waiting on many sockets at once.
At Thu, 14 Jan 2016 18:55:51 +0100, Andres Freund wrote in
<20160114175551.gm10...@awork2.anarazel.de>
> On 2016-01-14 18:14:21 +0100, Andres Freund wrote:
> > On 2016-01-14 12:07:23 -0500, Robert Haas wrote:
> > > > Do we want to provid
On 2016-02-08 15:58:49 +0900, Michael Paquier wrote:
> On Sun, Feb 7, 2016 at 2:49 AM, Andres Freund wrote:
> > On 2016-02-06 22:03:15 +0900, Michael Paquier wrote:
> >> The patch attached will apply on master, on 9.5 there is one minor
> >> conflict. For older versions we will need another rework
Hi,
I think this fixed is also required for REL9_4_STABLE.
Please confirm the attached patch.
Thanks and best regards,
Dang Minh Huong
NEC Solution Innovators, Ltd.
http://www.nec-solutioninnovators.co.jp/en/
ecpg.9.4.patch
Description: ecpg.9.4.patch
--
Sent via pgsql-hackers mailing list (
On 05.02.2016 um 18:40 Jason Petersen wrote:
On Feb 3, 2016, at 2:38 AM, Peter Moser wrote:
Does anyone had similar problems? Do I have to configure Eclipse to understand
the PG_RMGR macro or is there another possibility to teach Eclipse these macros?
Hi,
I just built 9.6 under Eclipse CD
On 2/7/16, Vitaly Burovoy wrote:
> Hello, Hackers!
>
> TODO list has an entry "Move NOT NULL constraint information to
> pg_constraint" with four links and without two with the newest
> work[1][2].
>
> I rebased the patch from [2] (in attachment). At least it applies
> cleanly on top of c477e84fe2
On Mon, Feb 8, 2016 at 9:01 AM, Robert Haas wrote:
> On Thu, Jan 21, 2016 at 11:25 PM, Haribabu Kommi
> wrote:
>> [ new patch ]
>
> This patch contains a number of irrelevant hunks that really ought not
> to be here and make the patch harder to understand, like this:
>
> -
On Mon, Feb 8, 2016 at 8:20 PM, Huong Dangminh
wrote:
> Hi,
>
> I think this fixed is also required for REL9_4_STABLE.
> Please confirm the attached patch.
Yes, this fix was missed for 9.4 stable branch during back patch
and it is available on all other supported branches.
Regards,
Hari Babu
Fuj
On 2016-02-08 20:59:25 +1100, Haribabu Kommi wrote:
> On Mon, Feb 8, 2016 at 8:20 PM, Huong Dangminh
> wrote:
> > Hi,
> >
> > I think this fixed is also required for REL9_4_STABLE.
> > Please confirm the attached patch.
>
> Yes, this fix was missed for 9.4 stable branch during back patch
> and it
Hello, Robert.
> So: do we have clear evidence that we need 128 partitions here, or
> might, say, 16 work just fine?
Yes, this number of partitions was chosen based on this benchmark (see
"spinlock array" column):
http://www.postgresql.org/message-id/20151229184851.1bb7d1bd@fujitsu
In fact we c
On 2016/02/05 17:50, Ashutosh Bapat wrote:
Btw, IIUC, I think the patch fails to adjust the targetlist of the
top plan created that way, to output the fdw_scan_tlist, as
discussed in [1] (ie, I think the attached patch is needed, which is
created on top of your patch pg_fdw_join_
Here is a patch to use %u not %d to print umid and userid.
Best regards,
Etsuro Fujita
*** a/contrib/postgres_fdw/connection.c
--- b/contrib/postgres_fdw/connection.c
***
*** 159,165 GetConnection(UserMapping *user, bool will_prep_stmt)
entry->have_error = false;
entry->co
On Mon, Feb 8, 2016 at 6:18 PM, Andres Freund wrote:
> On 2016-02-08 15:58:49 +0900, Michael Paquier wrote:
>> On Sun, Feb 7, 2016 at 2:49 AM, Andres Freund wrote:
>> /*
>> + * XLogInsert
>> + *
>> + * A shorthand for XLogInsertExtended, to update the progress of WAL
>> + * activity by default.
On Mon, Feb 08, 2016 at 09:20:46AM +, Huong Dangminh wrote:
> I think this fixed is also required for REL9_4_STABLE.
> Please confirm the attached patch.
Sure thing, no idea where that cherry-pick got lost.
Thanks.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes d
On 08/02/16 09:16, Pavel Stehule wrote:
Usage
=
DROP SCHEMA IF EXISTS test_schema CASCADE;
SET SCHEMA test_schema;
CREATE SCHEMA VARIABLE local_counter AS int DEFAULT 0;
CREATE OR REPLACE FUNCTION increment_counter()
RETURNS void AS $$
BEGIN
local_counter := local_counter + 1;
END;
$$ L
2016-02-08 13:03 GMT+01:00 Marko Tiikkaja :
> On 08/02/16 09:16, Pavel Stehule wrote:
>
>> Usage
>> =
>>
>> DROP SCHEMA IF EXISTS test_schema CASCADE;
>> SET SCHEMA test_schema;
>>
>> CREATE SCHEMA VARIABLE local_counter AS int DEFAULT 0;
>>
>> CREATE OR REPLACE FUNCTION increment_counter()
>>
On 08/02/16 13:17, Pavel Stehule wrote:
2016-02-08 13:03 GMT+01:00 Marko Tiikkaja :
How does this function know which schema variables are visible?
function see all schema variables from same schema as function's schema
Personally I find that undesirable. I don't know what oracle does, but
On Mon, Feb 8, 2016 at 6:47 AM, Peter Eisentraut wrote:
> On 1/26/16 10:56 AM, Simon Riggs wrote:
>> Removing one of "archive" or "hot standby" will just cause confusion and
>> breakage, so neither is a good choice for removal.
>>
>> What we should do is
>> 1. Map "archive" and "hot_standby" to on
2016-02-08 13:22 GMT+01:00 Marko Tiikkaja :
> On 08/02/16 13:17, Pavel Stehule wrote:
>
>> 2016-02-08 13:03 GMT+01:00 Marko Tiikkaja :
>>
>>> How does this function know which schema variables are visible?
>>>
>>
>> function see all schema variables from same schema as function's schema
>>
>
> Per
On Mon, Feb 8, 2016 at 5:45 AM, Etsuro Fujita
wrote:
> Maybe my explanation was not correct, but I'm saying that the targertlist of
> the above outer_plan should be set to the fdw_scan_tlist, to avoid
> misbehavior.
Yeah, I think you're right. So in this hunk:
+ if (foreignrel->reloptkind
On 8 February 2016 at 09:37, Filip Rembiałkowski <
filip.rembialkow...@gmail.com> wrote:
> On Sun, Feb 7, 2016 at 4:37 PM, Vik Fearing wrote:
>
> >>> There is also no mention in the documentation about what happens if I
> do:
> >>>
> >>> NOTIFY ALL chan, 'msg';
> >>> NOTIFY ALL chan, 'msg
On 08/02/16 13:41, Pavel Stehule wrote:
2016-02-08 13:22 GMT+01:00 Marko Tiikkaja :
Personally I find that undesirable. I don't know what oracle does, but
variables being visible without schema-qualifying them can introduce
variable conflicts in PL/PgSQL. I'd prefer if you could only refer to
On Fri, Feb 5, 2016 at 12:53 AM, Fabien COELHO wrote:
>> Something is wrong with patch d. I noticed two things,
>> 1. the total_weight stuff can overflow,
>
> It can generate an error on overflow by checking the total_weight while it
> is being computed. I've switched total_weight to int64 so it
2016-02-08 13:53 GMT+01:00 Marko Tiikkaja :
> On 08/02/16 13:41, Pavel Stehule wrote:
>
>> 2016-02-08 13:22 GMT+01:00 Marko Tiikkaja :
>>
>>> Personally I find that undesirable. I don't know what oracle does, but
>>> variables being visible without schema-qualifying them can introduce
>>> variabl
On 02/08/2016 03:16 AM, Pavel Stehule wrote:
Hi
On Russian PgConf I had a talk with Oleg about missing features in
PLpgSQL, that can complicates a migrations from Oracle to PostgreSQL.
Currently I see only one blocker - missing protected session
variables. PL/SQL has package variables with
On Mon, Jan 25, 2016 at 5:11 PM, Shulgin, Oleksandr <
oleksandr.shul...@zalando.de> wrote:
>
> On Sat, Jan 23, 2016 at 11:22 AM, Tomas Vondra <
tomas.von...@2ndquadrant.com> wrote:
>>
>>
>> Overall, I think this is really about deciding when to cut-off the MCV,
so that it does not grow needlessly l
Hi,
(x-posting to -hackers, more relevant audience)
On 2016-01-29 22:19:45 -0800, Evan Rempel wrote:
> Now that there is a setting to give a cluster a "name", it would be nice to
> have an escape sequence in the log_line_prefix setting that could reference
> the cluster_name.
I've argued[1][2] f
On Mon, Feb 8, 2016 at 12:28 PM, Michael Paquier
wrote:
>
>
> >> /*
> >> + * Fetch the progress position before taking any WAL insert
lock. This
> >> + * is normally an operation that does not take long, but leaving
this
> >> + * lookup out of the section taken an exclusive lo
Hi,
Frequently when reading postgres logs to do some post mortem analysis
I'm left wondering what process emitted an error/log message. After the
fact it's often hard to know wether an error message was emitted by a
user backend or by something internal, say the checkpointer or
autovacuum. Loggin
On 2/7/16 4:47 PM, Peter Eisentraut wrote:
> On 1/26/16 10:56 AM, Simon Riggs wrote:
>> Removing one of "archive" or "hot standby" will just cause confusion and
>> breakage, so neither is a good choice for removal.
>>
>> What we should do is
>> 1. Map "archive" and "hot_standby" to one level with
On Mon, Feb 8, 2016 at 5:39 AM, Aleksander Alekseev
wrote:
>> So: do we have clear evidence that we need 128 partitions here, or
>> might, say, 16 work just fine?
>
> Yes, this number of partitions was chosen based on this benchmark (see
> "spinlock array" column):
>
> http://www.postgresql.org/me
On Mon, Feb 8, 2016 at 12:08 AM, Amit Kapila wrote:
> I think deciding it automatically without user require to configure it,
> certainly has merits, but what about some cases where user can get
> benefits by configuring themselves like the cases where we use
> PG_O_DIRECT flag for WAL (with o_dir
On 7/02/2016 4:14 am, "Tom Lane" wrote:
>
> David Rowley writes:
> [ timestamp_out_speedup_2015-11-05.patch ]
>
> Pushed with a bunch of cosmetic tweaks.
Great. Thanks for pushing this.
David
On 2016-02-08 10:38:55 +0530, Amit Kapila wrote:
> I think deciding it automatically without user require to configure it,
> certainly has merits, but what about some cases where user can get
> benefits by configuring themselves like the cases where we use
> PG_O_DIRECT flag for WAL (with o_direct,
Hi Fabien,
On 2016-02-04 16:54:58 +0100, Andres Freund wrote:
> I don't want to post a full series right now, but my working state is
> available on
> http://git.postgresql.org/gitweb/?p=users/andresfreund/postgres.git;a=shortlog;h=refs/heads/checkpoint-flush
> git://git.postgresql.org/git/users/a
On Sun, Feb 7, 2016 at 7:28 PM, Kouhei Kaigai wrote:
> The new callbacks of T_ExtensibleNode will replace the necessity to
> form and deform process of private values, like as:
> https://github.com/pg-strom/devel/blob/master/src/gpujoin.c#L114
Yeah.
> It transforms a bunch of internal data of
On 2016-02-02 15:41:45 -0500, Robert Haas wrote:
> group-locking-v1.patch is a vastly improved version of the group
> locking patch that we discussed, uh, extensively last year. I realize
> that there was a lot of doubt about this approach, but I still believe
> it's the right approach, I have put
Hi!
Interesting feature, but it's not very obvious how to use it. I'd like to see
some example(s) in documentation.
And I see an implementation of AVL tree in psql source code
(src/bin/psql/crosstabview.c). Postgres already has a Red-Black tree
implementation in
src/include/lib/rbtree.h and
On Fri, Feb 5, 2016 at 5:36 PM, Michael Paquier
wrote:
> On Thu, Feb 4, 2016 at 11:06 PM, Michael Paquier
> wrote:
>> On Thu, Feb 4, 2016 at 10:49 PM, Michael Paquier
>> wrote:
>>> On Thu, Feb 4, 2016 at 10:40 PM, Robert Haas wrote:
On Thu, Feb 4, 2016 at 2:21 PM, Michael Paquier
wro
[resending because thunderbird helpfully defaulted my sender
address to the one that -isn't- subscribed to -hackers, sorry]
On 02/08/2016 03:16 AM, Pavel Stehule wrote:
> Only a owner of schema can edit functions inside schema
Can't anyone granted CREATE on the schema do that? Would
that be cha
rebased, messages changes per Tom's proposal
Cool feature and sometimes I needed it a lot.
But, seems, there are some bugs in error processing.
1
Following query is okay:
# select * from parse_ident(E'"Some \r Schema".someTable');
parse_ident
--
{"Some \r S
2016-02-08 16:45 GMT+01:00 jflack :
> On 02/08/2016 03:16 AM, Pavel Stehule wrote:
>
> > Only a owner of schema can edit functions inside schema
>
> Can't anyone granted CREATE on the schema do that? Would
> that be changed by this proposal?
>
yes, anybody with necessary rights can do it.
regard
2016-02-08 16:55 GMT+01:00 Teodor Sigaev :
> rebased, messages changes per Tom's proposal
>>
> Cool feature and sometimes I needed it a lot.
>
> But, seems, there are some bugs in error processing.
>
I am looking on it
Regards
Pavel
Etsuro Fujita writes:
> Here is a patch to use %u not %d to print umid and userid.
Pushed, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hac
Hi
>> I propose really basic functionality, that can be enhanced in future -
>> step by step. This proposal doesn't contain any controversial feature or
>> syntax, I hope. It is related to PLpgSQL only, but described feature can be
>> used from any PL languages with implemented interface.
>>
>
>
Shulgin, Oleksandr wrote:
> Added to the Open commitfest: https://commitfest.postgresql.org/9/475/
Here's a review. Note that the patch tested and submitted
is not the initial one in the thread, so it doesn't exactly
match $subject now.
What's tested here is a client-side approach, sugge
On 02/08/2016 06:24 AM, Andres Freund wrote:
> On 2016-01-29 22:19:45 -0800, Evan Rempel wrote:
>> Now that there is a setting to give a cluster a "name", it would be nice to
>> have an escape sequence in the log_line_prefix setting that could reference
>> the cluster_name.
>
> I've argued[1][2] f
Teodor Sigaev wrote:
> Interesting feature, but it's not very obvious how to use it. I'd like to
> see some example(s) in documentation.
I'm thinking of making a wiki page, because examples pretty much
require showing resultsets, and I'm not sure this would fly
with our current psql docu
On Mon, Feb 8, 2016 at 10:17 AM, Andres Freund wrote:
> On 2016-02-02 15:41:45 -0500, Robert Haas wrote:
>> group-locking-v1.patch is a vastly improved version of the group
>> locking patch that we discussed, uh, extensively last year. I realize
>> that there was a lot of doubt about this approac
Hello Andres,
Any comments before I spend more time polishing this?
I'm running tests on various settings, I'll send a report when it is done.
Up to now the performance seems as good as with the previous version.
I'm currently updating docs and comments to actually describe the
current stat
On 02/08/2016 10:45 AM, Robert Haas wrote:
On Mon, Feb 8, 2016 at 10:17 AM, Andres Freund wrote:
On 2016-02-02 15:41:45 -0500, Robert Haas wrote:
I realize that this stuff has all been brewing long, and that there's
still a lot to do. So you gotta keep moving. And I'm not sure that
there's a
I don't think we need to preserve absolutely all the existing behavior
to the letter. We do need to preserve the behavior for sensible cases
that people might be reasonably be using currently; and if there's
anything somewhat obscure but really useful that you currently get by
using some clever tr
Fabien COELHO wrote:
>
> Hello Michaël,
>
> v23 attached, which does not change the message but does the other fixes.
This doesn't apply anymore -- please rebase and submit to the next CF.
I closed it here as returned with feedback.
Thanks!
--
Álvaro Herrerahttp://www.2ndQuadr
I closed this one as "committed", since we pushed a bunch of parts.
Please submit the two remaining ones to the next commitfest.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing
Since things are clearly still moving here, I closed it as
returned-with-feedback. Please submit to the next CF so that we don't
lose it.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hacker
Of late, by far the majority of the random-noise failures we see in the
buildfarm have come from failure to shut down the postmaster in a
reasonable timeframe. An example is this current failure on hornet:
http://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=hornet&dt=2016-02-08%2013%3A41
Hello Michaël,
+ /* compute total_weight */
+ for (i = 0; i < num_scripts; i++)
+ {
+ total_weight += sql_script[i].weight;
+
+ /* detect overflow... */
If let as int64, you may want to remove this overflow check, or keep
it as int32.
I'd rather k
On Mon, Feb 8, 2016 at 2:00 PM, Joshua D. Drake wrote:
> If I am off base, please feel free to yell Latin at me again but isn't this
> exactly what different trees are for in Git? Would it be possible to say:
>
> Robert says, "Hey pull XYZ, run ABC tests. They are what the parallelism
> fixes do"?
I've closed this as returned-with-feedback. Please resubmit once you
have found answers to the questions posed; from the submitted benchmark
numbers this looks very exciting, but it needs a bit more work. You
don't necessarily have to agree with everything Robert says, but you
need to have well r
Robert Haas writes:
> Oh: another thing that I would like to do is commit the isolation
> tests I wrote for the deadlock detector a while back, which nobody has
> reviewed either, though Tom and Alvaro seemed reasonably positive
> about the concept.
Possibly the reason that wasn't reviewed is tha
Peter Eisentraut wrote:
> On 1/26/16 10:56 AM, Simon Riggs wrote:
> > Removing one of "archive" or "hot standby" will just cause confusion and
> > breakage, so neither is a good choice for removal.
> >
> > What we should do is
> > 1. Map "archive" and "hot_standby" to one level with a new name th
On 02/08/2016 11:24 AM, Robert Haas wrote:
On Mon, Feb 8, 2016 at 2:00 PM, Joshua D. Drake wrote:
If I am off base, please feel free to yell Latin at me again but isn't this
exactly what different trees are for in Git? Would it be possible to say:
Robert says, "Hey pull XYZ, run ABC tests. The
I've closed this as returned-with-feedback.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.
Hello,
v23 attached, which does not change the message but does the other fixes.
This doesn't apply anymore
Indeed, but the latest version was really v25.
-- please rebase and submit to the next CF.
I already provided it as v25 on Feb 1st.
I closed it here as returned with feedback.
On Mon, Feb 8, 2016 at 10:45 AM, Robert Haas wrote:
> And, by the way, the patch, aside from the deadlock.c portion, was
> posted back in October, admittedly without much fanfare, but nobody
> reviewed that or any other patch on this thread. If I'd waited for
> those reviews to come in, parallel
On Mon, Feb 8, 2016 at 2:36 PM, Joshua D. Drake wrote:
> I have no problem running any test cases you wish on a branch in a loop for
> the next week and reporting back any errors.
>
> Where this gets tricky is the tooling itself. For me to be able to do so
> (and others really) I need to be able t
On Sun, Feb 7, 2016 at 7:47 AM, Tom Lane wrote:
> Works for me.
Attached patch is what I came up with. It required only minimal
additional changes for consistency.
--
Peter Geoghegan
From 01d8cb278cecb995ecc30cda0125d10c98f4d05c Mon Sep 17 00:00:00 2001
From: Peter Geoghegan
Date: Sun, 7 Feb 2
I'm closing this as returned-with-feedback; AFAICS even the last version
submitted is still in research stage. Please resubmit once you make
further progress.
Thanks,
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Servic
On 2016-02-08 19:52:30 +0100, Fabien COELHO wrote:
> I think I would appreciate comments to understand why/how the ringbuffer is
> used, and more comments in general, so it is fine if you improve this part.
I'd suggest to leave out the ringbuffer/new bgwriter parts. I think
they'd be committed sep
Fabien COELHO wrote:
>
> Hello,
>
> >>v23 attached, which does not change the message but does the other fixes.
> >
> >This doesn't apply anymore
>
> Indeed, but the latest version was really v25.
>
> >-- please rebase and submit to the next CF.
>
> I already provided it as v25 on Feb 1st.
>
Robert Haas wrote:
> Oh: another thing that I would like to do is commit the isolation
> tests I wrote for the deadlock detector a while back, which nobody has
> reviewed either, though Tom and Alvaro seemed reasonably positive
> about the concept. Right now, the deadlock.c part of this patch isn
On Fri, Feb 5, 2016 at 5:06 PM, Tom Lane wrote:
> I wrote:
>> Pavel Stehule writes:
>>> [ num_nulls_v6.patch ]
>
>> I started looking through this. It seems generally okay, but I'm not
>> very pleased with the function name "num_notnulls". I think it would
>> be better as "num_nonnulls", as I s
On Mon, Feb 8, 2016 at 2:48 PM, Peter Geoghegan wrote:
> FWIW, I appreciate your candor. However, I think that you could have
> done a better job of making things easier for reviewers, even if that
> might not have made an enormous difference. I suspect I would have not
> been able to get UPSERT d
Peter Geoghegan writes:
> On Sun, Feb 7, 2016 at 7:47 AM, Tom Lane wrote:
>> Works for me.
> Attached patch is what I came up with. It required only minimal
> additional changes for consistency.
I'd already run into some trouble with pgindent messing up on "string",
so I went ahead and pushed t
Thomas Munro writes:
> Would num_values be a better name than num_nonnulls?
If "value" is a term that excludes null values, it's news to me.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
ht
On Mon, Feb 8, 2016 at 1:52 PM, Craig Ringer wrote:
> Would it be correct to say that if ALL is specified then a message is queued
> no matter what. If DISTINCT is specified then it is only queued if no
> message with the same channel and argument is already queued for delivery.
Yes, exactly.
>
On Tue, Feb 9, 2016 at 5:30 AM, Joe Conway wrote:
> On 02/08/2016 06:24 AM, Andres Freund wrote:
>> On 2016-01-29 22:19:45 -0800, Evan Rempel wrote:
>>> Now that there is a setting to give a cluster a "name", it would be nice to
>>> have an escape sequence in the log_line_prefix setting that could
Tom Lane wrote:
> Of late, by far the majority of the random-noise failures we see in the
> buildfarm have come from failure to shut down the postmaster in a
> reasonable timeframe.
I noticed that.
> An example is this current failure on hornet:
>
> http://buildfarm.postgresql.org/cgi-bin/show_s
Thomas,
* Thomas Munro (thomas.mu...@enterprisedb.com) wrote:
> On Tue, Feb 9, 2016 at 5:30 AM, Joe Conway wrote:
> > On 02/08/2016 06:24 AM, Andres Freund wrote:
> >> On 2016-01-29 22:19:45 -0800, Evan Rempel wrote:
> >>> Now that there is a setting to give a cluster a "name", it would be nice
Alvaro Herrera writes:
> Tom Lane wrote:
>> What I'd like to do to investigate this is put in a temporary HEAD-only
>> patch that makes ShutdownXLOG() and its subroutines much chattier about
>> how far they've gotten and what time it is, and also makes pg_ctl print
>> out the current time if it gi
Joe Conway wrote:
> On 01/06/2016 10:36 AM, Tom Lane wrote:
> > I think a design that was actually somewhat robust would require two
> > hooks, one at check_role and one at assign_role, wherein the first one
> > would do any potentially-failing work and package all required info into
> > a blob tha
On 02/08/2016 09:33 PM, Filip Rembiałkowski wrote:
> Here is my next try, after suggestions from -perf and -hackers list:
>
> * no GUC
>
> * small addition to NOTIFY grammar: NOTIFY ALL/DISTINCT
>
> * corresponding, 3-argument version of pg_notify(text,text,bool)
>
> * updated the docs to inclu
On 02/08/2016 02:15 PM, Tom Lane wrote:
Of late, by far the majority of the random-noise failures we see in the
buildfarm have come from failure to shut down the postmaster in a
reasonable timeframe. An example is this current failure on hornet:
http://buildfarm.postgresql.org/cgi-bin/show_st
Daniel Verite wrote:
> Teodor Sigaev wrote:
>
> > Interesting feature, but it's not very obvious how to use it. I'd like to
> > see some example(s) in documentation.
>
> I'm thinking of making a wiki page, because examples pretty much
> require showing resultsets, and I'm not sure this wou
Pavel Stehule wrote:
> I am looking on it
Thanks, closing as returned-with-feedback.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
Hi,
One of the questions I have about parallel query is whether it should
be enabled by default. That is, should we make the default value of
max_parallel_degree to a value higher than 0? Perhaps 1, say?
There are some good reasons why this might be a bad idea, such as:
- As discussed on a nea
On Mon, Feb 8, 2016 at 12:18 PM, Robert Haas wrote:
> So, there may be a person who knows how to do all of that
> work and get it done in a reasonable time frame and also knows how to
> make sure that everybody has the opportunity to be as involved in the
> process as they want to be and that ther
On 02/08/2016 01:07 PM, Robert Haas wrote:
Hi,
One of the questions I have about parallel query is whether it should
be enabled by default. That is, should we make the default value of
max_parallel_degree to a value higher than 0? Perhaps 1, say?
O.k. after some googling where I found your f
Hi everybody,
I just closed the last few remaining items in the commitfest. This is
the final summary:
Committed: 32.
Moved to next CF: 32.
Rejected: 2.
Returned with Feedback: 33.
Total: 99.
I think we did a fairly decent job this time around: we only passed a
third of the patches to the
Hi
> FWIW I think the general idea of this feature (client-side resultset
> "pivoting") is a good one, but I don't really have an opinion regarding
> your specific proposal. I think you should first seek some more
> consensus about the proposed design; in your original thread [1] several
> guys
Hi,
On 2016-02-08 16:07:05 -0500, Robert Haas wrote:
> One of the questions I have about parallel query is whether it should
> be enabled by default. That is, should we make the default value of
> max_parallel_degree to a value higher than 0? Perhaps 1, say?
>
> There are some good reasons why
On Tue, Feb 9, 2016 at 9:26 AM, Tom Lane wrote:
> Thomas Munro writes:
>> Would num_values be a better name than num_nonnulls?
>
> If "value" is a term that excludes null values, it's news to me.
Ah, right, I was thinking of null as the absence of a value. But in
fact it is a special value that
On 02/08/2016 01:11 PM, Peter Geoghegan wrote:
On Mon, Feb 8, 2016 at 12:18 PM, Robert Haas wrote:
I accept that this might have been a somewhat isolated incident (that
I couldn't easily get *at least* a little instant gratification), but
it still should be avoided. You've accused me of buryi
Robert Haas writes:
> One of the questions I have about parallel query is whether it should
> be enabled by default. That is, should we make the default value of
> max_parallel_degree to a value higher than 0? Perhaps 1, say?
I'm not sure I'm on board with that as a releaseable default, but the
On Mon, Feb 8, 2016 at 1:24 PM, Andres Freund wrote:
> I think that's an argument to enable it till at least beta1. Let's
> change the default, and add an item to the open items list to reconsider
> then.
+1.
Reminds me of what happened with the num_xloginsert_locks GUC (it was
eventually replac
Pavel Stehule wrote:
> > FWIW I think the general idea of this feature (client-side resultset
> > "pivoting") is a good one, but I don't really have an opinion regarding
> > your specific proposal. I think you should first seek some more
> > consensus about the proposed design; in your original t
On Mon, Feb 8, 2016 at 4:11 PM, Peter Geoghegan wrote:
> All that I wanted to do was look at EXPLAIN ANALYZE output that showed
> a parallel seq scan on my laptop, simply because I wanted to see a
> cool thing happen. I had to complain about it [1] to get clarification
> from you [2].
>
> I accept
On Mon, Feb 8, 2016 at 10:19 PM, Alvaro Herrera
wrote:
> Hi everybody,
>
> I just closed the last few remaining items in the commitfest. This is
> the final summary:
>
> Committed: 32.
> Moved to next CF: 32.
> Rejected: 2.
> Returned with Feedback: 33.
> Total: 99.
>
> I think we did a fair
On Monday, February 8, 2016, Andres Freund wrote:
> Hi,
>
> On 2016-02-08 16:07:05 -0500, Robert Haas wrote:
> > One of the questions I have about parallel query is whether it should
> > be enabled by default. That is, should we make the default value of
> > max_parallel_degree to a value higher
On Mon, Feb 8, 2016 at 1:45 PM, Robert Haas wrote:
> Far from the negligence that you seem to be implying, I think Amit was
> remarkably diligent about providing these kinds of updates.
I don't think I remotely implied negligence. That word has very severe
connotations (think "criminal negligence
1 - 100 of 132 matches
Mail list logo
