2016-07-30 3:47 GMT+02:00 David G. Johnston :
> On Fri, Jul 29, 2016 at 8:18 PM, Bruce Momjian wrote:
>
>> On Tue, Jul 12, 2016 at 01:36:38PM +, thomas.ber...@1und1.de wrote:
>> > The following bug has been logged on the website:
>> >
>> > Bug reference: 14244
>> > Logged by: Th
2016-07-30 1:46 GMT+02:00 Tomas Vondra :
> Hi,
>
> On 07/29/2016 01:15 PM, Aleksander Alekseev wrote:
>
>> Hello
>>
>> Some time ago we discussed an idea of "fast temporary tables":
>>
>> https://www.postgresql.org/message-id/20160301182500.2c81c3dc%40fujitsu
>>
>> In two words the idea is followi
On Fri, Jul 29, 2016 at 8:18 PM, Bruce Momjian wrote:
> On Tue, Jul 12, 2016 at 01:36:38PM +, thomas.ber...@1und1.de wrote:
> > The following bug has been logged on the website:
> >
> > Bug reference: 14244
> > Logged by: Thomas Berger
> > Email address: thomas.ber...@1und1
On Fri, Jul 29, 2016 at 08:18:38PM -0400, Bruce Momjian wrote:
> However, that is not the end of the story. Things have moved forward
> since 2006 and there is now firm support for either KB or KiB to be
> 1024-based units. This blog post explains the current state of prefix
> specification:
>
>
On Tue, Jul 12, 2016 at 01:36:38PM +, thomas.ber...@1und1.de wrote:
> The following bug has been logged on the website:
>
> Bug reference: 14244
> Logged by: Thomas Berger
> Email address: thomas.ber...@1und1.de
> PostgreSQL version: 9.5.3
> Operating system: any
> Descrip
Hi,
On 07/29/2016 01:15 PM, Aleksander Alekseev wrote:
Hello
Some time ago we discussed an idea of "fast temporary tables":
https://www.postgresql.org/message-id/20160301182500.2c81c3dc%40fujitsu
In two words the idea is following.
PostgreSQL stores information about all relations in pg_ca
On Sat, Jul 30, 2016 at 1:17 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jul 26, 2016 at 9:27 PM, Michael Paquier
>> wrote:
>>> While looking at the series of functions pg_get_*, I have noticed as
>>> well that pg_get_userbyid() returns "unknown (OID=%u)" when it does
>>> not know a use
On Fri, Jul 29, 2016 at 4:13 PM, Bruce Momjian wrote:
> Yes, I am thinking of a case where Postgres is down but a malevolent
> user starts a Postgres server on 5432 to gather passwords.
Or someone spoofs your DNS lookup, which is an attack that can
actually be done remotely in some cases.
For wh
Michael,
(dropping -general, not sure why that list was included...)
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Wed, Jul 27, 2016 at 8:07 AM, Stephen Frost wrote:
> > That'd be great. It's definitely on my list of things to look into, but
> > I'm extremely busy this week. I hope
On 7/29/16 1:33 PM, Andreas 'ads' Scherbaum wrote:
On 27.07.2016 05:00, Joshua D. Drake wrote:
On 07/26/2016 06:25 PM, Peter Eisentraut wrote:
On 7/5/16 4:24 AM, Albe Laurenz wrote:
But notwithstanding your feeling that you would like your application
to break if it makes use of this behaviour
Robert Haas wrote:
> One minor comment is that this document makes extensive use of Terms
> With Initial Capitals, which seems stylistically odd, although I'm not
> precisely sure what would be better.
We use publication on the first use only, which is turned
into italics.
--
Álvaro Herrera
On 7/29/16 3:13 PM, David Fetter wrote:
> I expect this kind of blather from MySQL, but you've brought up
> something that's been bothering me for awhile. PostgreSQL's response
> should look more like this:
>
> ERROR: month field value out of range: "2016-99-99"
> LINE 1: select cast('2016-99-99
$SUBJECT sucks.
Create a table containing lots of composite arrays:
regression=# create table foo (f1 int8_tbl[]);
CREATE TABLE
regression=# insert into foo select array[row(1,2),row(3,4)]::int8_tbl[] from
generate_series (1,1000);
INSERT 0 1000
regression=# vacuum analyze foo;
VACUUM
E
On Fri, Jul 29, 2016 at 09:20:12PM +0300, Nikolay Samokhvalov wrote:
> On Fri, Jul 29, 2016 at 5:28 PM, Jim Nasby wrote:
> >
> > The way I sum up MySQL vs PG for people that ask is to recount how they
> > "fixed" the Feb. 31st bug when they released strict mode (something that
> > they actually ca
* Bruce Momjian (br...@momjian.us) wrote:
> On Fri, Jul 29, 2016 at 10:44:29AM -0400, Stephen Frost wrote:
> > Another thought that was kicking around in my head related to that is if
> > we could have indexes that only provide page-level information (similar
> > to BRIN, but maybe a btree) and whi
On 27.07.2016 05:00, Joshua D. Drake wrote:
On 07/26/2016 06:25 PM, Peter Eisentraut wrote:
On 7/5/16 4:24 AM, Albe Laurenz wrote:
But notwithstanding your feeling that you would like your application
to break if it makes use of this behaviour, it is a change that might
make some people pretty
On Fri, Jul 29, 2016 at 5:28 PM, Jim Nasby wrote:
>
> The way I sum up MySQL vs PG for people that ask is to recount how they
> "fixed" the Feb. 31st bug when they released strict mode (something that
> they actually called out in the release PR). With strict mode enabled, Feb.
> 30th and 31st wou
I wrote:
> Kyotaro HORIGUCHI writes:
>> Any work in this area is likely 10.0 material at this point.
> I'm not really happy with that, since refactoring it again will create
> back-patch hazards. But I see that a lot of the mess here was created
> in 9.5, which means we're probably stuck with ba
Robert Haas writes:
> On Tue, Jul 26, 2016 at 9:27 PM, Michael Paquier
> wrote:
>> While looking at the series of functions pg_get_*, I have noticed as
>> well that pg_get_userbyid() returns "unknown (OID=%u)" when it does
>> not know a user. Perhaps we'd want to change that to NULL for
>> consis
On Wed, Jul 27, 2016 at 2:24 AM, Michael Paquier
wrote:
> On Wed, Jul 27, 2016 at 8:07 AM, Stephen Frost wrote:
>> That'd be great. It's definitely on my list of things to look into, but
>> I'm extremely busy this week. I hope to look into it on Friday, would
>> be great to see what you find.
>
On Tue, Jul 26, 2016 at 9:27 PM, Michael Paquier
wrote:
> On Wed, Jul 27, 2016 at 5:11 AM, Robert Haas wrote:
>> Committed with minor kibitizing: you don't need an "else" after a
>> statement that transfers control out of the function.
>
> Thanks. Right, I forgot that.
>
>> Shouldn't
>> pg_get_fu
Kyotaro HORIGUCHI writes:
> At Fri, 29 Jul 2016 12:47:53 +0900, Michael Paquier
> wrote in
>
>>> At Thu, 28 Jul 2016 10:46:00 -0400, Tom Lane wrote in
>>> <4313.1469717...@sss.pgh.pa.us>
>>> I dunno, this seems like it's doubling down on some extremely poor
>>> decisions. Why is it that you
On Wed, Jul 20, 2016 at 4:08 AM, Simon Riggs wrote:
> In this post, Petr and I present a joint view on a design for how this
> should work in-core, based upon our implementation experiences with physical
> replication, pglogical and various comments so far.
>
> Note that this has substantial user-
On 7/29/16 11:13 AM, Bruce Momjian wrote:
> Yes, I am thinking of a case where Postgres is down but a malevolent
> user starts a Postgres server on 5432 to gather passwords. Verifying
> against an SSL certificate would avoid this problem, so there is some
> value in using SSL on localhost. (There
On Fri, Jul 29, 2016 at 10:44:29AM -0400, Stephen Frost wrote:
> Another thought that was kicking around in my head related to that is if
> we could have indexes that only provide page-level information (similar
> to BRIN, but maybe a btree) and which also would allow HOT updates.
> Those indexes w
On Tue, Jul 19, 2016 at 03:24:26PM -0400, Peter Eisentraut wrote:
> On 7/19/16 10:00 AM, Magnus Hagander wrote:
> > What could actually be useful there is to explicitly put hostnossl on
> > the localhost entries. With the current defaults on the clients, that
> > wouldn't break anything, and it wou
On Mon, Jul 25, 2016 at 4:18 AM, Amit Langote
wrote:
> The comment seems to have been copied from ATExecAddColumn, which says:
>
> /*
> * If we are told not to recurse, there had better not be any
> - * child tables; else the addition would put them out of step.
>
> For ATExecValidateConstraint
On 7/29/16 8:17 AM, Kevin Grittner wrote:
On Thu, Jul 28, 2016 at 8:39 PM, Tatsuo Ishii wrote:
> BTW, is there any opposite information, i.e. showing the
> limitation of MySQL comparing with PostgreSQL?
I'm not aware of a general list on the topic, but in reviewing
academic papers regarding t
* Jim Nasby (jim.na...@bluetreble.com) wrote:
> On 7/28/16 10:05 AM, Alex Ignatov wrote:
> >>Just curious: what if PostgreSQL supported index that stores "primary
> >>key" (or unique key) instead of tids?
> >
> >You mean IOT like Oracle have?
>
> IIRC, IOT either stores the table in index order, w
On 7/28/16 10:05 AM, Alex Ignatov wrote:
Just curious: what if PostgreSQL supported index that stores "primary
key" (or unique key) instead of tids?
You mean IOT like Oracle have?
IIRC, IOT either stores the table in index order, which is something
different.
What Alex is proposing is an i
On Thu, Jul 28, 2016 at 7:34 PM, Fujii Masao wrote:
> On Thu, Jul 28, 2016 at 10:16 PM, Amit Kapila wrote:
>
>> I think there is some value in providing
>> .tar for -Z 0,
>
> I was thinking that "-Ft -Z0" is something like an alias of "-Ft".
> That is, the backup is taken in uncompressed tar form
On Thu, Jul 28, 2016 at 8:39 PM, Tatsuo Ishii wrote:
> BTW, is there any opposite information, i.e. showing the
> limitation of MySQL comparing with PostgreSQL?
I'm not aware of a general list on the topic, but in reviewing
academic papers regarding transaction isolation I did find (and
confirm)
I've tested patch with this query
https://gist.github.com/x4m/fee16ed1a55217528f036983d88771b4
Test specs were: Ubuntu 14 LTS VM, dynamic RAM, hypervisor Windows
Server 2016, SSD disk, core i5-2500. Configuration: out of the box
master make.
On 10 test runs timing of select statement: AVG 3739.8 m
Hello
Some time ago we discussed an idea of "fast temporary tables":
https://www.postgresql.org/message-id/20160301182500.2c81c3dc%40fujitsu
In two words the idea is following.
PostgreSQL stores information about all relations in pg_catalog. Some
applications create and delete a lot of tempor
On Fri, Jul 29, 2016 at 11:26 AM, Haribabu Kommi
wrote:
> we observed that spawning the specified number of parallel workers for
> every query that satisfies for parallelism is sometimes leading to
> performance drop compared to improvement during the peak system load
> with other processes. Addin
On Thu, Jul 28, 2016 at 4:59 PM, Michael Paquier
wrote:
> On Wed, Apr 6, 2016 at 3:11 PM, Michael Paquier
> wrote:
>> On Wed, Mar 23, 2016 at 12:45 PM, Michael Paquier
>> wrote:
>>> On Wed, Mar 23, 2016 at 11:11 AM, David Steele wrote:
I would prefer not to bump it to the next CF unless we
36 matches
Mail list logo
