-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/22/2014 01:35 PM, Craig Ringer wrote:
> A way to put UNLOGGED objects in such a space and have them
> recovered if they vanish would also be valuable, IMO.
By which I mean "re-created empty, as if after a crash".
- --
Craig Ringer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/18/2014 08:00 PM, Stephen Frost wrote:
> PG would need to enforce that it's only used for temporary objects
> as well, of course.. Or at least, that was my thinking on this.
A way to put UNLOGGED objects in such a space and have them recovered
2014-06-22 2:26 GMT+02:00 MauMau :
> From: "Pavel Stehule"
>
> I am not sure in this point. It is aligned left with all long options:
>>
>> -?, --help show this help, then exit
>> --help-variables list of available configuration variables
>> (options), then exit
>>
>
> pg
At 2014-06-21 23:54:58 +0200, vik.fear...@dalibo.com wrote:
>
> > I'll flip this to Waiting on Author for those changes.
>
> And back to Needs Review.
I've marked it Ready for Committer after a quick read-through.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
From: "Pavel Stehule"
I am not sure in this point. It is aligned left with all long options:
-?, --help show this help, then exit
--help-variables list of available configuration variables
(options), then exit
pg_dumpall aligns all options left with each other, whether
On Sun, June 22, 2014 00:10, Pavel Stehule wrote:
> [help-variables-01.patch ]
+1. This patch is a very useful improvement, IMHO.
I edited the text somewhat; and removed some obvious typos.
thanks,
Erik Rijkers--- src/bin/psql/help.c.orig 2014-06-22 00:31:55.450860460 +0200
+++ src/bin/psql/h
2014-06-21 23:14 GMT+02:00 Vik Fearing :
> On 06/21/2014 10:11 PM, Pavel Stehule wrote:
> > Hello
> >
> > I am looking createdb_alterdb_grammar_refactoring.v1.patch
> >
> > http://www.postgresql.org/message-id/53868e57.3030...@dalibo.com
>
> Thank you for looking at this.
>
> > Is any reason or is
Hello
2014-06-21 15:51 GMT+02:00 MauMau :
> eFrom: "Pavel Stehule"
>
>> here is a prototype:
>>
>
> The patch applied and built with success. There are a few minor things:
>
>
> (1)
> help_variables() lacks description of some variables such as SINGLELINE
> and SINGLESTEP. I think this help s
On 06/21/2014 08:23 PM, Kevin Grittner wrote:
> OK, so I think we want to see a patch based on v1 (FATAL approach)
> with a change of the name to idle_in_transaction_session_timeout
> and the units changed to milliseconds. I don't see why the
> remoteversion test shouldn't be changed to use 90500
On 06/21/2014 10:21 PM, Pavel Stehule wrote:
> Second question related to second patch:
>
> Must be new syntax ALLOW_CONNECTIONS?
It doesn't *have* to be called that, but that's what the corresponding
column in pg_database is called so why add confusion? (Actually, it's
called datallowconn but
On 06/21/2014 10:11 PM, Pavel Stehule wrote:
> Hello
>
> I am looking createdb_alterdb_grammar_refactoring.v1.patch
>
> http://www.postgresql.org/message-id/53868e57.3030...@dalibo.com
Thank you for looking at this.
> Is any reason or is acceptable incompatible change CONNECTION_LIMIT
> instead
Second question related to second patch:
Must be new syntax ALLOW_CONNECTIONS? Should not be (ENABLE | DISABLE)
CONNECTION ? This doesn't need any new keyword.
Regards
Pavel
2014-06-21 22:11 GMT+02:00 Pavel Stehule :
> Hello
>
> I am looking createdb_alterdb_grammar_refactoring.v1.patch
>
>
Hello
I am looking createdb_alterdb_grammar_refactoring.v1.patch
http://www.postgresql.org/message-id/53868e57.3030...@dalibo.com
Is any reason or is acceptable incompatible change CONNECTION_LIMIT instead
CONNECTION LIMIT? Is decreasing parser size about 1% good enough for
breaking compatibilit
review: https://commitfest.postgresql.org/action/patch_view?id=1484
Hello
I did review of this patch, that add three functions varwidth_bucket for
types: anyelement, double and bigint
* This patch respects PostgreSQL coding rules
* it can applied without any issues
* there are no new compile war
Andrew Dunstan wrote:
> On 06/19/2014 06:33 PM, Josh Berkus wrote:
>>> ISTM our realistic options are for seconds or msec as the unit. If it's
>>> msec, we'd be limited to INT_MAX msec or around 600 hours at the top end,
>>> which seems like enough to me but maybe somebody thinks differently?
I'm sorry if I missed something, but ISTM this is beginning to look a
lot like GiST. This was pointed out by Robert Haas last year.
On Wed, Jun 18, 2014 at 12:09:42PM -0300, Claudio Freire wrote:
> So, you have:
>
> An aggregate to generate a "compressed set" from several values
Which GiST does
Hello,
this patch https://commitfest.postgresql.org/action/patch_view?id=1443 is
trivial with zero risk.
Patch is applicable without any issues, compilation was without any issues
too.
Only one open question is there - should by system schemas visible for
autocompleation or not.
There was not
eFrom: "Pavel Stehule"
here is a prototype:
The patch applied and built with success. There are a few minor things:
(1)
help_variables() lacks description of some variables such as SINGLELINE and
SINGLESTEP. I think this help should list all available variables, because
users may want to
On 21 June 2014 01:38, Vik Fearing wrote:
> I've had a chance to look at this and here is my review.
>
> On 04/14/2014 01:19 PM, David Rowley wrote:
> > I've included the updated patch with some regression tests.
>
> The first thing I noticed is there is no documentation, but I don't
> think we d
On 06/15/2014 12:26 AM, Alvaro Herrera wrote:
Andres Freund wrote:
On 2014-06-14 16:57:33 -0400, Tom Lane wrote:
Alvaro Herrera writes:
I noticed that HEAD crashes at startup with assertions disabled and
WAL_DEBUG turned on:
I'm beginning to think we're going to have to give up on that
no-p
20 matches
Mail list logo
