I wrote:
> I spent some time hacking on this today, and I think it's committable
> now, but I'm putting it back up in case anyone wants to have another
> look (and also so the cfbot can check it on Windows).
... and indeed, the cfbot doesn't like it. Here's v8, with the
missing addition to
John Naylor writes:
> [ v6-0001-Use-offset-based-keyword-lookup.patch ]
I spent some time hacking on this today, and I think it's committable
now, but I'm putting it back up in case anyone wants to have another
look (and also so the cfbot can check it on Windows).
Given the discussion about
On Thu, 20 Dec 2018 at 18:20, Julien Rouhaud wrote:
>
> On Wed, Dec 19, 2018 at 11:08 PM David Rowley
> wrote:
> > create table listp (a int) partition by list (a);
> > create table listp12 partition of listp for values in(1,2);
> > create table listp03 partition of listp for vlaues in(0,3);
> >
On Sat, 5 Jan 2019 at 08:48, Tom Lane wrote:
> v5 attached; this responds to your comments plus Alexander's earlier
> gripe about not getting a clean build with --disable-cassert.
> No really substantive changes though.
I ran a few benchmarks on an AWS m5d.large instance based on top of
On 04/01/2019 17:05, Daniel Verite wrote:
> When using GROUP BY and ORDER BY on a field with a non-deterministic
> collation, this pops out:
>
> CREATE COLLATION myfr (locale='fr-u-ks-level1',
> provider='icu', deterministic=false);
>
> =# select n from (values ('été' collate "myfr"), ('ete'))
On 20/12/2018 11:42, Christoph Berg wrote:
> de.po's error message when you try to "REINDEX DATABASE otherdb" has
> been the wrong way round since 2011:
Fixes committed to the translations repository.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
On Wed, Dec 05, 2018 at 11:20:52PM -0800, Noah Misch wrote:
> On Thu, Aug 30, 2018 at 12:06:09AM -0700, Noah Misch wrote:
> > On Sat, Aug 11, 2018 at 12:47:05PM -0700, Noah Misch wrote:
> > > On Wed, Aug 08, 2018 at 09:58:38AM -0400, Tom Lane wrote:
> > > > When the security team was discussing
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > ... Definitely a +1 from me, but I'd like us to be thinking about the other
> > things we should be doing in this area to bring our password-based
> > authentication mechanism kicking-and-screaming into the current
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> On 12/27/18 11:43 AM, Magnus Hagander wrote:
> > Plus, the majority of people *should* want them on :) We don't run with
> > say synchronous_commit=off by default either to make it easier on those
> > that don't want to pay the
Hi!
On Sat, Jan 5, 2019 at 2:53 AM Nguyễn Trần Quốc Vinh
wrote:
> You can try https://github.com/ntqvinh/PgMvIncrementalUpdate to generate
> triggers in C for incremental updates of matviews.
>
> For asynchronous updates, the tool does generate the triggers for collecting
>
Greetings,
* Andrew Alsup (bluesbrea...@gmail.com) wrote:
> Contrary to popular understanding, in classified environments it is common
> to have data marked with a variety of combinations that make it difficult
> to create roles and labels that match the various permutations. As a simple
>
On Sat, Jan 5, 2019 at 5:21 PM Tomas Vondra
wrote:
> On 1/5/19 1:11 AM, Alexander Korotkov wrote:
> > On Tue, Dec 4, 2018 at 2:23 AM Nikita Glukhov
> > wrote:
> >> 2) We define both DCH_FF# and DCH_ff#, but we never ever use the
> >> lower-case version. Heck, it's not mentioned even in
Greetings,
* Hubert Zhang (hzh...@pivotal.io) wrote:
> For very large databases, the dbsize function `pg_database_size_name()`
> etc. could be quite slow, since it needs to call `stat()` system call on
> every file in the target database.
I agree, it'd be nice to improve this.
> We proposed a
Greetings Lætitia!
* Lætitia Avrot (laetitia.av...@gmail.com) wrote:
> When you look at Postgres' SQL reference documentation for `GRANT`, the
> `ALL TABLES` clause is explained as :
>
> > ALL TABLES also affects views and foreign tables, just like
> the specific-object GRANT command.
>
> A
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> This has all the same practical problems as recording object creation
>> times, which we're not going to do either. (You can consult the
>> archives for details, but from memory, the stickiest aspects revolve
>> around what to do
Stephen Frost writes:
> ... Definitely a +1 from me, but I'd like us to be thinking about the other
> things we should be doing in this area to bring our password-based
> authentication mechanism kicking-and-screaming into the current decade.
I'm not really excited about reinventing the whole of
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Michael Banck writes:
> > The same was requested in https://dba.stackexchange.com/questions/91252/
> > how-to-know-when-postgresql-password-is-changed so I was wondering
> > whether this would be a welcome change/addition, or whether people
Greetings,
* Michael Banck (michael.ba...@credativ.de) wrote:
> a customer recently mentioned that they'd like to be able to see when a
> (md5, scram) role had their password last changed.
There is an awful lot here that we really should be doing. For a long
time, that felt prettty stalled
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Dec 11, 2018 at 11:47 PM Tom Lane wrote:
> > Andres Freund writes:
> > > I don't quite get why we don't instead just represent "never vacuumed"
> > > by storing a more meaningful value in relpages?
> >
> > Mostly, not wanting to
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2018-12-10 15:38:55 -0500, Tom Lane wrote:
> > Also, I'm not entirely sure whether there's anything in our various
> > replication logic that's dependent on vacuum truncation taking AEL.
> > Offhand I'd expect the reduced use of AEL to
12dev and 11.1:
postgres=# CREATE TABLE t(i int)PARTITION BY RANGE(i);
postgres=# CREATE INDEX ON t(i) WITH(fillfactor=11);
postgres=# ALTER INDEX t_i_idx SET (fillfactor=12);
ERROR: 42809: "t_i_idx" is not a table, view, materialized view, or index
LOCATION: ATWrongRelkindError,
Greetings,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> Clearly, not having to do that at all is better, but if this is all
> there is to it, then I'm confused by the characterizations of how awful
> and terrible this feature is and how we must rush to remove it.
It's not all
Greetings,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 12/12/2018 05:31, Robert Haas wrote:
> > Most of the features I've been involved in removing have been
> > deprecated for 5+ years. The first release where this one was
> > deprecated was only 2 years ago. So it feels
Greetings,
* Laurenz Albe (laurenz.a...@cybertec.at) wrote:
> I too only learned about this recently, while the problem with exclusive
> backups has been known at least since 2008 (c979a1fe), and nobody felt
> this to be a terrible problem back then.
My recollection was that back then it wasn't
On Sat, Jan 5, 2019 at 1:35 AM Tatsuo Ishii wrote:
> PostgreSQL includes an implementation of the
> standard btree (multi-way binary tree) index data
> structure.
>
> I think the term "btree" here means "multi-way balanced tree", rather
> than "multi-way binary tree". In fact in our btree,
Peter Eisentraut writes:
> Why are you not including a test for \set VERBOSITY verbose?
Stability of the output would be a problem ...
regards, tom lane
On 2019-Jan-05, Peter Eisentraut wrote:
> On 04/01/2019 20:35, Alvaro Herrera wrote:
> >> + /* prevent cleanup */
> >> + made_new_pgdata = found_existing_pgdata = made_new_xlogdir =
> >> found_existing_xlogdir = false;
> >> +
> >>return 0;
> >> }
> >
> > This is a bit ugly, but meh.
>
On 04/01/2019 00:05, Alvaro Herrera wrote:
> Besides that, I have a hard time considering this patch committable.
> There are some good additions, but they are mixed with some wording
> changes that seem to be there just because the author doesn't like the
> original, not because they're actual
On 04/12/2018 13:18, didier wrote:
> diff --git a/src/test/regress/sql/psql.sql b/src/test/regress/sql/psql.sql
> index 1bb2a6e16d..64628f29a3 100644
> --- a/src/test/regress/sql/psql.sql
> +++ b/src/test/regress/sql/psql.sql
> @@ -1016,3 +1016,22 @@ select 1/(15-unique2) from tenk1 order by
On 21/11/2018 15:46, Christoph Berg wrote:
> A startup looks like this:
>
> 2018-11-21 15:19:47.259 CET [24453] LOG: listening on IPv6 address "::1",
> port 5431
> 2018-11-21 15:19:47.259 CET [24453] LOG: listening on IPv4 address
> "127.0.0.1", port 5431
> 2018-11-21 15:19:47.315 CET [24453]
On 04/01/2019 20:35, Alvaro Herrera wrote:
> Seems you're registering the atexit cb twice here; you should only do so
> in the first "!conn" block.
OK, fixed.
>> @@ -3438,5 +3437,8 @@ main(int argc, char *argv[])
>>
>> destroyPQExpBuffer(start_db_cmd);
>>
>> +/* prevent cleanup */
On 1/5/19 1:11 AM, Alexander Korotkov wrote:
> On Tue, Dec 4, 2018 at 2:23 AM Nikita Glukhov wrote:
>> 2) We define both DCH_FF# and DCH_ff#, but we never ever use the
>> lower-case version. Heck, it's not mentioned even in DCH_keywords, which
>> does this:
>>
>> ...
>> {"FF1", 3, DCH_FF1,
Dear,
You can try https://github.com/ntqvinh/PgMvIncrementalUpdate to generate
triggers in C for incremental updates of matviews.
For asynchronous updates, the tool does generate the triggers for
collecting updated/inserted/deleted rows and then the codes for doing
incremental updating as well.
On Fri, 21 Dec 2018 at 02:02, Surafel Temesgen wrote:
> Currently we can skip header line on COPY FROM but having the ability to skip
> and stop copying at any line can use to divide long copy operation and enable
> to copy a subset of the file and skipping footer. Attach is a patch for it
I'm
There is a sentence in btree.sgml:
PostgreSQL includes an implementation of the
standard btree (multi-way binary tree) index data
structure.
I think the term "btree" here means "multi-way balanced tree", rather
than "multi-way binary tree". In fact in our btree, there could be
more than
Hi,
On Fri, Jan 4, 2019 at 5:37 PM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> It seems a bit fragile to me if I want to skip a footer and need to
> figure out the total line count, subtract one, and then oh, was it zero-
> or one-based.
>
>
But normally we don't say start
36 matches
Mail list logo
