On 10/19/2017 11:26 PM, Tom Lane wrote:
> Vik Fearing <vik.fear...@2ndquadrant.com> writes:
>> On 10/19/2017 10:54 PM, Tom Lane wrote:
>>> Uh ... recommended by whom? pg_statistic has exactly the same reliability
>>> guarantees as the rest of the system catalogs
d crash when there are
199,999,999 dead tuples, you currently get to wait for another 200
million to die before anything gets cleaned up.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
aster. We should finish merging recovery.conf into
>>>> postgresql.conf.
>>>
>>> Definitely.
>>
>> There's a patch from Abhijit Menon-Sen you could adopt for PostgreSQL
>> 11 for that.
>
> Do you have a link to this?
https://commitfest.postgresql
vidually, but you obviously disagree. Fair enough.>
> I guess it is that simple.
FWIW, my opinion falls in line with Robert's.
Also, whichever way it goes, this is a patch I've been wanting for a
long time.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadr
want to hijack the thread, but you can do that with exclusion
constraints.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
in 6ef2eba3f57.
Attached is a one-liner fix. I realize how imminent we are from
releasing v10 but I hope there is still time for such a minor issue as this.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
diff
ould be good if the 'main' partitioned table and
> its 'partitions' showed up as a different type in some way.
I've just read through this thread, and I'm wondering why we can't just
have something like \set SHOW_PARTITIONS true or something, and that
would default to false.
; ERROR: syntax error at or near "4.2"
> LINE 1: set random_page_cost = +4.2;
> ^
> Any objections to allowing "+ FCONST" here? I'm inclined to
> fix this and back-patch it as well.
Seems like the right thing to do; no objections here.
On 05/26/2017 03:20 PM, Tom Lane wrote:
> Vik Fearing <vik.fear...@2ndquadrant.com> writes:
>> On 05/25/2017 05:24 PM, Tom Lane wrote:
>>> After some experimentation, I came up with the attached, which simply
>>> skips the "recursive" step if it would
On 05/25/2017 05:24 PM, Tom Lane wrote:
> Vik Fearing <vik.fear...@2ndquadrant.com> writes:
>> In commit 9aa3c782c93, Tom fixed a bug in which creating a table _foo
>> when an array type of that name already existed would make the array
>> type change its name to get ou
ray's name (which was my case when I found this bug), the new
array name will be ___foo instead of just __foo. I don't know if it's
worth worrying about that.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Su
, in which case they can easily figure where to add the
> MATERIALIZED option and regain the original performance.
I am overwhelmingly in favor of this option.
I am in favor of an enable_inlinedcte guc in the same spirit as the
other enable_* gucs, but violently opposed to any "comp
Backwards" is not plural, it's a regional variation of "backward" (or
vice versa depending on which region you come from). Both are correct.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
-
sider the need to update BRIN indexes.
> >
> > Another possible advantage of tracking INSERTs is for hash indexes
> > where after split we need to remove tuples from buckets that underwent
> > split recently.
>
> That's a good point also, and for clearing GIN pending lists too, now
> that I think about it.
>
As much as I want my patch to go in, this is not an argument for it. The
GIN pending lists will be handled by autoanalyze.
> We really need to get this fixed for PG10.
>
I'm not sure what more I'm supposed to be doing, if anything.
--
Vik Fearing +33 6 46 75 15
36http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et
Support
On 01/07/2017 11:05 PM, Tom Lane wrote:
> Vik Fearing <v...@2ndquadrant.fr> writes:
>> On 01/07/2017 08:15 PM, Tom Lane wrote:
>>> No, and TBH I would vote strongly against including that much detail in
>>> this error message anyway. That info cou
HINT line
could be emitted with the entire column definition (or close to it)?
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On 12/30/2016 06:46 PM, David Fetter wrote:
> On Fri, Dec 30, 2016 at 09:57:25AM -0500, Stephen Frost wrote:
>
>> Let's make this a clean break/change.
>
> +1
+1
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr Post
texts;
That produces:
ERROR: index row requires 12024 bytes, maximum size is 8191
It seems to me the index should not be allowed to be created if it won't
be usable.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise
ers, less 2 if you remove the <> delimiters. I
> think the extra usability makes the slight increase in ugliness worth
> it. Can we just agree or disagree on this?
If non-committers are voting, I'll add my +1 to this.
--
Vik Fearing +33 6 46 75
per time/size and whatnot.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postg
_subxact.
>>>
>>> Nice suggestion, good naming for consistency with the rest.
>>
>> Agreed.
>
> +1
+1 from me, too.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
On 10/01/2016 09:28 AM, Thomas Munro wrote:
> On Mon, Aug 29, 2016 at 1:26 PM, Vik Fearing <v...@2ndquadrant.fr> wrote:
>> The attached two patches scratch two itches I've been having for a
>> while. I'm attaching them together because the second depends on the f
esql.conf would include_dir by default. These
could then live in there and all I would have had to do is uncomment the
values I wanted.
This patch doesn't do that, of course, but I could easily write a patch
that does. Would that go over better with the -1ers?
--
Vik Fearing
what I did
understand, namely that 'k (...)' should mean 'any k (...)'. It's much
more natural than having it mean 'first k (...)' and I also think it
will be more frequent in practice.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Exp
I often see mention of project policies for various things (the one
triggering this email is in commit 967a7b0).
Where can I find documentation for these policies?
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise
d like a good idea to me for a new feature that is going to be
> GA soon.
Indeed. I'll vote for pulling a fast one on 9.6 for this.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgs
On 08/29/2016 03:34 AM, Vik Fearing wrote:
> We have sample configuration files for postgresql.conf and
> recovery.conf, but we do not have them for contrib modules. This patch
> attempts to add them.
>
> Although the patch puts the sample configuration files in the tree, i
On 09/08/2016 01:05 AM, Tom Lane wrote:
> Vik Fearing <v...@2ndquadrant.fr> writes:
>> On 09/07/2016 11:39 PM, Gavin Flower wrote:
>>> Possibly generate warningswhen the non hyphenated form is used?
>
>> I'm not quite sure how I got volunteered to do this work, b
On 09/07/2016 11:39 PM, Gavin Flower wrote:
> On 08/09/16 09:08, Vik Fearing wrote:
>> On 09/07/2016 10:41 PM, Alvaro Herrera wrote:
>>> Gavin Flower wrote:
>>>
>>>> possibly '--nosync' (& any similar) should have a '--no-sync' variation
>>&
--no-sync only and
> keeping the --nosync one working with minimal (if any) visibility in
> docs.
Okay, here's a patch to do that. I don't think it's the other patch's
job to do it.
I also changed --noclean to --no-clean, and --no-locale was already correct.
--
Vik Fearing
ould be Returned With Feedback.
You're probably right (even though you're quoting the wrong message), so
I've changed it to that.
Marko, please resubmit an updated patch.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Forma
On 09/05/2016 01:54 PM, Grigory Smolkin wrote:
> What is the purpose of keeping orphan tables around and not dropping
> them on the spot?
You can read the discussion about it here:
https://www.postgresql.org/message-id/flat/3507.1214581513%40sss.pgh.pa.us
--
Vik F
(and --no-wait) aren't a thing.
Trivial patch attached.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
pg_ctl_wait-01.patch
Description: invalid/octet-stream
--
Sent via pgsql-hackers mailing list
On 08/31/2016 06:22 AM, Peter Eisentraut wrote:
> Here is a patch that adds the notion of a data type to a sequence. So
> it might be CREATE SEQUENCE foo AS integer. The types are restricted to
> int{2,4,8} as now.
This patch does not apply cleanly to current master (=600dc4c).
--
Vi
hing like it) is MySQL.
However, I can see how it would be a huge win for very wide tables and
so my personal opinion is to accept this syntax as a PostgreSQL
extension to the standard.
Marking ready for committer, the minor gripes above notwithstanding.
--
Vik Fearing
On 09/02/2016 08:58 AM, Robert Haas wrote:
> On Mon, Aug 29, 2016 at 7:04 AM, Vik Fearing <v...@2ndquadrant.fr> wrote:
>> We have sample configuration files for postgresql.conf and
>> recovery.conf, but we do not have them for contrib modules. This patch
>> attempts
d.
Part of what people want this for is to audit what people *try* to do.
We can already audit what they've actually done.
With your solution, we still wouldn't know when an unauthorized attempt
to do something happened.
--
Vik Fearing +33 6 46 75 15 36
http:
global temporary"
relpersistence (I don't care which letter it gets) and when a backend
tries to access it, it uses its own private relfilenode instead of
whatever is in pg_class, creating one if necessary. That way the
structure of the table is fixed, with all the dependencies and whatnot,
but the
.
Current as of 26fa446, added to next commitfest.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
sample_confs_v01.patch
Description: invalid/octet-stream
--
Sent via pgsql-hackers mailing list (pgsql
that some of the documentation in the
first patch gets removed by the second patch, in case they both don't
get committed.
I have added this to the imminent commitfest. These patches are rebased
as of 26fa446.
--
Vik Fearing +33 6 46 75 15 36
http:
oes this. I haven't submitted
it yet because the documentation is lacking. I will post it over the
weekend (I had planned to do it before the commitfest anyway).
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et S
ally and then
> retry changing the value of the setting.
This is my preferred action.
> Alternatively, I also think it would be sensible to issue an immediate
> COMMIT when the autocommit setting is changed from off to on. That
> was my first reaction.
I don't care for this very much.
gt;> propertyname) with properties like "sortable", "desc", "nulls first".
>
>> This seems simple enough, on the surface. Why not run with this design?
>
> Well, the next step is to fill in the blanks: what properties need to be
> queryable?
That's
On 27/07/16 06:11, David Fetter wrote:
> On Wed, Jul 27, 2016 at 03:24:28AM +0200, Vik Fearing wrote:
>> On 27/07/16 03:15, Peter Eisentraut wrote:
>>> On 7/26/16 6:14 PM, Vik Fearing wrote:
>>>> As mentioned elsewhere in the thread, you can just do WHERE true
. I'm not saying we shouldn't take their bad
> experience seriously - we clearly should - but I don't feel like it's
> as clear as it could be about exactly where the breakdowns happened.
There is some more detailed information in this 30-minute talk:
https://vimeo.com/145842299
--
Vik Fearing
On 27/07/16 03:15, Peter Eisentraut wrote:
> On 7/26/16 6:14 PM, Vik Fearing wrote:
>> As mentioned elsewhere in the thread, you can just do WHERE true to get
>> around it, so why on Earth have it PGC_SUSET?
>
> I'm not sure whether it's supposed to guard against typos and
at all.
As mentioned elsewhere in the thread, you can just do WHERE true to get
around it, so why on Earth have it PGC_SUSET?
I would rather, if we need nannying at all, have a threshold of number
of rows affected. So if your update or delete exceeds that threshold,
the query will be canc
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 : Exp
On 19/06/16 13:02, Michael Paquier wrote:
> On Sun, Jun 19, 2016 at 7:38 PM, Vik Fearing <v...@2ndquadrant.fr> wrote:
>> On 19/06/16 12:28, Michael Paquier wrote:
>>> On Sun, Jun 19, 2016 at 5:56 PM, Michael Paquier
>>> Or in short the attached.
>&g
On 19/06/16 13:02, Michael Paquier wrote:
> On Sun, Jun 19, 2016 at 7:38 PM, Vik Fearing <v...@2ndquadrant.fr> wrote:
>> On 19/06/16 12:28, Michael Paquier wrote:
>>> On Sun, Jun 19, 2016 at 5:56 PM, Michael Paquier
>>> Or in short the attached.
>&g
3Dd%2BfPGw%40mail.gmail.com
Whether it goes into 9.6 or 10 is not for me to say.
> Or in short the attached.
The code looks good to me but why no documentation?
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation
t; blocking which PID. After that, most everything else is just window
> dressing.
We already have that second one: pg_blocking_pids(integer)
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
On 15/06/16 02:08, Cat wrote:
> is it possible to introduce a JSONB output to it.
No thanks.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hack
ly says we make the former equivalence succeed
> and have the later one fail.
>
> The rewrite would be unaware of the cardinality of the SRF and so it
> cannot conditionally rewrite the query. One of the two must be chosen
> and the incompatible behavior turned into an error.
--
d be good to not break that
> effort.
We could always accept it like we do for archive/hot_standby->replica.
I like synchronous_standby_config, so I vote for changing it.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Exp
_TEMPLATE.
> How about COMPLETE, TOTAL, or WHOLE?
Sure, I'll play this game. I like EXHAUSTIVE.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (p
; in.
+1
Let's even stamp it 10.0devel from the get-go.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On 03/16/2016 05:32 PM, Robert Haas wrote:
> Committed with slight changes to the docs, and I added a flag variable
> instead of relying on IdleInTransactionSessionTimeout not changing at
> an inopportune time.
Thank you!
--
Vik Fearing +33 6 46
On 03/08/2016 10:42 PM, Robert Haas wrote:
> On Sun, Jan 31, 2016 at 8:33 AM, Vik Fearing <v...@2ndquadrant.fr> wrote:
>> Attached is a rebased and revised version of my
>> idle_in_transaction_session_timeout patch from last year.
>>
>> This version does not su
now
represents a full 50% of the available AMs. I submit it should be
removed altogether.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
dding this missing function.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.
t;
> * updated the docs to include new syntax and clarify behavior
>
> * no hashtable in AsyncExistsPendingNotify
> (I don't see much sense in that part; and it can be well done
> separately from this)
Please add this to the next commitfest:
https://commitfes
On 02/07/2016 04:00 PM, Filip Rembiałkowski wrote:
> On Sun, Feb 7, 2016 at 11:54 AM, Vik Fearing <v...@2ndquadrant.fr> wrote:
>> I seem to remember some discussion about not using DEFAULT parameters in
>> system functions so you should leave the old function alone and cre
cumentation about what happens if I do:
NOTIFY ALL chan, 'msg';
NOTIFY ALL chan, 'msg';
NOTIFY DISTINCT chan, 'msg';
NOTIFY ALL chan, 'msg';
Without testing, I'd say I'd get two messages, but it should be
explicitly mentioned somewhere.
--
Vik Fearing
On 02/04/2016 02:24 PM, Fujii Masao wrote:
> On Sun, Jan 31, 2016 at 10:33 PM, Vik Fearing <v...@2ndquadrant.fr> wrote:
>> Attached is a rebased and revised version of my
>> idle_in_transaction_session_timeout patch from last year.
>>
>> This version does not su
d be a PITA.
>
> I wouldn't put a bunch of effort into it though. Dropping the connection
> is certainly better than nothing.
You could always put SET idle_in_transaction_session_timeout = 0; in
your .psqlrc file to exempt your manual sessions from it. Or change it
just for your us
size of those data structures isn't much,
> and we may have other uses for such an ability later.
>
> Anybody have an objection or better idea?
No objections to this, but my "better idea" is simply to allow INSTEAD
OF triggers on tables like discussed last year.
http://www.postgre
is if a session remains idle in a transaction for longer
than the configured time, that connection will be dropped thus releasing
the connection slot and any locks that may have been held by the broken
client.
Added to the March commitfest.
--
Vik Fearing +33 6
On 01/22/2016 04:28 AM, Tom Lane wrote:
> Vik Fearing <v...@2ndquadrant.fr> writes:
>> I looked around for other places where this code should be used and
>> didn't find any. I am marking this patch Ready for Committer.
>
> I pushed this with some adjus
by consensus.
The documentation is a little light, but I don't see what else needs to
be said.
The code is clean and well commented. All extraction options are supported.
Regression tests are present and seemingly complete.
I looked around for other places where this code should be used and
did
gt; =# \pset false FALSE
> Boolean FALSE display is "FALSE".
> =# select true, false;
> bool | bool
> --+---
> TRUE | FALSE
> (1 row)
I think the battle is already lost, but I'm casting my vote in favor of
this patch anyway.
--
Vik Fearing
gt; +1 for a GUC that changes the behaviour of boolout.
>
> -1 for changing boolout(). It will break anything that receives boolean
> values from the server. How a client is going to display values (of any type)
> is logic that should belong in the client, not in the protocol.
I fully agre
On 11/05/2015 09:01 PM, Merlin Moncure wrote:
> Tom noted earlier some caveats with the 'idle' timeout in terms of
> implementation. Maybe that needs to be zeroed in on.
AFAIK, those issues have already been solved by Andres some time ago.
--
Vik F
st week at PGConf.EU to pick my patch back up.
I am planning on resubmitting it for the next commitfest. I will also
take into account the things said on this thread.
[1] http://www.postgresql.org/message-id/538dc843.2070...@dalibo.com
--
Vik Fearing
f4 or as
>> > as unique index (f1, f2, f3, f4), because uniqueness on (f1, f2, f3) gives
>> > warranty of uniqueness on (f1, f2, f3, f4)
>> >
>> >
> I'd vote for this too. However, INCLUDE does not seem to be a reserved word
> at the moment.
What
On 09/15/2015 12:45 PM, Anastasia Lubennikova wrote:
> 15.09.2015 12:11, Vik Fearing:
>> On 09/15/2015 10:57 AM, David Rowley wrote:
>>>> I agree, that form
>>>>> CREATE UNIQUE INDEX i ON t (f1, f2, f3) INCLUDE (f4)
>>>>> is clear.
compiler happy.
Committed with those changes.
Thank you, Brendan, Michael, and Robert for taking care of this while I
was away.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql
bug grant all on tables to postgres;
hangs
Session 1:
commit;
Session 2:
ERROR: tuple concurrently updated
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list
While reviewing the seqam patches, I noticed that psql has tab
completion for ALTER SEQUENCE, but not for CREATE SEQUENCE.
The attached trivial patch fixes that.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation
On 09/18/2014 10:16 PM, Hannu Krosing wrote:
On 09/18/2014 02:37 PM, Pavel Stehule wrote:
if we would to need a single use function, then we should to
implement it, and we should not to rape some different objects. Some,
what has behave like function should be function.
After some thinking,
On 09/16/2014 10:09 AM, Heikki Linnakangas wrote:
On 09/16/2014 10:57 AM, Craig Ringer wrote:
On 09/16/2014 03:15 PM, Pavel Stehule wrote:
Why we don't introduce a temporary functions instead?
I think that'd be a lot cleaner and simpler. It's something I've
frequently wanted, and as Hekki
On 09/08/2014 06:17 AM, Stephen Frost wrote:
* Vik Fearing (vik.fear...@dalibo.com) wrote:
On 09/02/2014 10:17 PM, Marko Tiikkaja wrote:
Yeah, I think I like this better than allowing all of them without the
database name.
Why? It's just a noise word!
Eh, because it ends up reindexing
On 09/02/2014 10:17 PM, Marko Tiikkaja wrote:
On 2014-08-29 01:00, Alvaro Herrera wrote:
Vik Fearing wrote:
Here are two patches for this.
The first one, reindex_user_tables.v1.patch, implements the variant that
only hits user tables, as suggested by you.
The second one
On 08/20/2014 02:43 AM, Michael Paquier wrote:
On Thu, Jun 19, 2014 at 6:40 PM, Vik Fearing vik.fear...@dalibo.com
mailto:vik.fear...@dalibo.com wrote:
On 04/30/2014 11:41 PM, Tom Lane wrote:
We really oughta fix the WAL situation, not just band-aid around it.
After re
On 09/02/2014 04:12 PM, Alvaro Herrera wrote:
Fujii Masao wrote:
On Mon, Sep 1, 2014 at 10:54 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Mon, Sep 1, 2014 at 3:57 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Sat, Aug 30, 2014 at 12:27 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
On 07/30/2014 07:46 PM, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Wed, Jul 30, 2014 at 01:29:31PM -0400, Tom Lane wrote:
I don't find it all that odd. We should not be encouraging routine
database-wide reindexes.
Uh, do we encourage database-wide VACUUM FULL or CLUSTER, as
On 07/10/2014 09:32 PM, Magnus Hagander wrote:
It seems psql is missing autocomplete entries for LC_COLLATE and
LC_CTYPE for the CREATE DATABASE command. Attached patch adds that.
I doubt this is important enough to backpatch - thoughts?
It won't apply to current head, but otherwise I see no
On 07/04/2014 08:50 AM, Fujii Masao wrote:
On Wed, Jul 2, 2014 at 3:45 AM, Vik Fearing vik.fear...@dalibo.com wrote:
Is there a reason for not using this in synchronous_standby_names,
perhaps falling back to application_name if not set?
You mean that if synchronous_standby_names is an empty
On 07/05/2014 02:17 AM, Thomas Munro wrote:
As an exercise I hacked up the simplest code I could think of that would
demonstrate a faster DISTINCT based on skipping ahead to the next
distinct value in an index-only scan. Please see the attached (extremely
buggy) patch, and the example session
On 07/02/2014 10:15 PM, Andrew Gierth wrote:
(Had one request so far for a mode() variant that returns the unique
modal value if one exists, otherwise null; so the current set of
ordered-set aggs by no means exhausts the possible applications.)
I resemble that remark. :)
But seriously, am I
On 06/29/2014 02:25 PM, Andres Freund wrote:
On 2014-06-29 11:11:14 +0100, Thomas Munro wrote:
On 29 June 2014 10:55, Andres Freund and...@2ndquadrant.com wrote:
So, I'd looked at it with an eye towards committing it and found some
more things. I've now
* added the restriction that the
On 06/27/2014 06:22 AM, Amit Kapila wrote:
On Thu, Jun 26, 2014 at 8:17 PM, Vik Fearing vik.fear...@dalibo.com
mailto:vik.fear...@dalibo.com wrote:
On 06/26/2014 05:07 AM, Amit Kapila wrote:
I think it will make sense if we support RESET ALL as well similar
to Alter Database .. RESET ALL
On 06/27/2014 08:49 AM, Vik Fearing wrote:
This third patch reformats the documentation in the way I expected it to
be committed.
Amit,
I added this to the next commitfest with your name as reviewer.
https://commitfest.postgresql.org/action/patch_view?id=1495
Please update the status as you
On 06/19/2014 07:18 PM, Tom Lane wrote:
Jov am...@amutu.com writes:
the doc say:
ALTER USER is now an alias for ALTER
ROLEhttp://www.postgresql.org/docs/devel/static/sql-alterrole.html
but alter user lack the following format:
...
If we're going to have a policy that these commands be
On 06/26/2014 06:45 AM, Fujii Masao wrote:
The point of this feature, AFAICS, is to detect clients that are failing
to issue another query or close their transaction as a result of bad
client logic. It's not to protect against network glitches.
If so, the document should explain that
On 06/26/2014 05:07 AM, Amit Kapila wrote:
On Wed, Jun 25, 2014 at 9:56 PM, Vik Fearing vik.fear...@dalibo.com
mailto:vik.fear...@dalibo.com wrote:
On 06/25/2014 03:04 PM, Amit Kapila wrote:
Currently you can achieve that by
ALTER SYSTEM RESET guc = Default;.
However it will be good
On 06/23/2014 06:45 PM, Pavel Stehule wrote:
2014-06-23 18:39 GMT+02:00 Vik Fearing vik.fear...@dalibo.com
mailto:vik.fear...@dalibo.com:
On 06/23/2014 06:21 PM, Robert Haas wrote:
On Sun, Jun 22, 2014 at 2:59 PM, Pavel Stehule
pavel.steh...@gmail.com mailto:pavel.steh
On 06/21/2014 02:03 PM, David Rowley wrote:
I'm marking this Waiting on Author pending discussion on pushing down
entire expressions, but on the whole I think this is pretty much ready.
As I said above, I don't think playing around with that code is really
work for this patch. It
On 06/27/2014 02:49 AM, Tom Lane wrote:
Vik Fearing vik.fear...@dalibo.com writes:
This latest patch is ready for a committer to look at now. The weird
comments have been changed, superfluous regression tests removed, and
nothing done about expression pushdown per (brief) discussion.
I
On 06/25/2014 03:04 PM, Amit Kapila wrote:
On Wed, Jun 25, 2014 at 6:20 PM, Christoph Berg c...@df7cb.de
mailto:c...@df7cb.de wrote:
Hi,
is there a reason there's no ALTER SYSTEM RESET?
The natural idiom to reset SET statements is RESET guc;, I don't
think SET guc = default; is in use
1 - 100 of 202 matches
Mail list logo
