Starting a new thread to discuss the proposal I put forward in [1] to stop
creating explicit NOT NULL constraint on range partition keys that are
simple columns. I said the following:
On 2017/05/12 11:20, Robert Haas wrote:
> On Thu, May 11, 2017 at 10:15 PM, Amit Langote
> wrote:
>> On 2017/05/
On 2017/05/14 12:03, Mark Dilger wrote:
> Hackers,
>
> I discovered a reproducible crash using event triggers in the current
> development version, 29c7d5e483acaa74a0d06dd6c70b320bb315.
> I was getting a crash before this version, and cloned a fresh copy of
> the sources to be sure I was up to
On Mon, May 15, 2017 at 2:04 PM, Dilip Kumar wrote:
> On Sun, May 14, 2017 at 9:54 PM, Dilip Kumar wrote:
>> After your fix, now tupleid is invalid which is expected, but seems
>> like we need to do something more. As per the comments seems like it
>> is expected to get the oldtuple from planSlot
On Thu, May 11, 2017 at 1:09 PM, Kyotaro HORIGUCHI
wrote:
> If we can accept multiple server versions share a tablespace
> directory, pg_basebackup also can allow that situation. The
> attached patch does that. Similary to the server code, it
> correctly fails if the same version subdirectory exis
On Tue, May 2, 2017 at 2:28 AM, Pierre Ducroquet wrote:
> I didn't have much time to spend on that issue until today, and I found a
> way to solve it that seems acceptable to me.
>
> The biggest drawback will be that if the backup is interrupted, previous
> tablespaces already copied will stay on
On Sun, May 14, 2017 at 9:54 PM, Dilip Kumar wrote:
> After your fix, now tupleid is invalid which is expected, but seems
> like we need to do something more. As per the comments seems like it
> is expected to get the oldtuple from planSlot. But I don't see any
> code for handling that part.
May
Hi all,
Found $subject while working on the area. A patch is attached.
Thanks,
--
Michael
basebackup-typo.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, May 10, 2017 at 11:25:22AM +0530, Amit Kapila wrote:
> On Tue, Apr 11, 2017 at 11:53 PM, Bruce Momjian wrote:
> > On Fri, Mar 31, 2017 at 02:48:05PM -0400, Tom Lane wrote:
> >> +1, as long as we're clear on what will happen when pg_upgrade'ing
> >> an installation containing hash indexes.
On Thu, May 11, 2017 at 10:08:30AM +0900, Michael Paquier wrote:
> On Wed, May 10, 2017 at 10:22 PM, Michael Paquier
> wrote:
> > On Wed, May 10, 2017 at 10:01 PM, Tom Lane wrote:
> >> Heikki Linnakangas writes:
> >>> Also note that changing the signature check_password_hook_type would
> >>> br
On Fri, May 12, 2017 at 11:58 PM, Petr Jelinek wrote:
> On 11/05/17 15:43, Petr Jelinek wrote:
> > Hi,
>
> >
> > We do check for this, but only during replication which we have to do
> > because the fact that relation 't' was foreign table during ALTER
> > SUBSCRIPTION does not mean that it won't
On Mon, May 08, 2017 at 12:28:38PM -0400, Peter Eisentraut wrote:
> On 5/8/17 02:58, Noah Misch wrote:
> > IMMEDIATE ATTENTION REQUIRED. This PostgreSQL 10 open item is long past due
> > for your status update. Please reacquaint yourself with the policy on open
> > item ownership[1] and then repl
On Fri, May 12, 2017 at 08:54:13AM +, Tsunakawa, Takayuki wrote:
> From: pgsql-hackers-ow...@postgresql.org
> > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tsunakawa,
> > Takayuki
> > I found a wrong sentence here in the doc. I'm sorry, this is what I asked
> > you to add...
> >
Hi,
Attached patch for $subject.
I think "that's" is correct word.
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
fix_typo_in_reorderbuffer_c.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
On 2017-05-14 14:54:37 +0200, Petr Jelinek wrote:
> On 13/05/17 22:23, Andres Freund wrote:
> >> And wait for session 3 to finish slot creation, takes about 20 mins on
> >> my laptop without patches, minute and half with your patches for 0004
> >> and 0005 (or with your 0004 and my 0005) and about
On Thu, May 11, 2017 at 05:55:02PM +0530, tushar wrote:
> I observed that -we cannot publish "foreign table" in Publication
>
> postgres=# create foreign table t (n int) server db1_server options
> (table_name 't1');
> CREATE FOREIGN TABLE
>
> postgres=# create publication pub for table t;
> ERRO
On Mon, May 08, 2017 at 06:27:30PM +0900, Masahiko Sawada wrote:
> I encountered a situation where DROP SUBSCRIPTION got stuck when
> initial table sync is in progress. In my environment, I created
> several tables with some data on publisher. I created subscription on
> subscriber and drop subscri
At Fri, 12 May 2017 11:44:19 +0900, Masahiko Sawada
wrote in
> On Thu, May 11, 2017 at 10:48 AM, Michael Paquier
> wrote:
> > Hi all,
> >
> > I had my eyes on the WAL sender code this morning, and I have noticed
> > that walsender.c is not completely consistent with the PID lookups it
> > does
On Sun, May 14, 2017 at 01:06:03PM -0700, Andres Freund wrote:
> On 2017-05-14 15:59:09 -0400, Greg Stark wrote:
> > Personally while I would like to avoid code that actively crashes or
> > fails basic tests on Vax
>
> I personally vote for simply refusing to run/compile on non-IEEE
> platforms, i
On Thu, May 11, 2017 at 11:50:03PM -0400, Tom Lane wrote:
> Michael Paquier writes:
> > Bruce, the release notes do not mention yet that support for cleartext
> > passwords is removed. This has been done recently by Heikki in
> > eb61136d. This has as consequence that CREATE ROLE PASSWORD
> > UNEN
On 2017/05/14 1:07, Robert Haas wrote:
> On Sat, May 13, 2017 at 12:42 AM, Amit Langote
> wrote:
>> Attached is the correct version.
>
> Thank you! I committed 0001 with a couple of cosmetic tweaks and with
> the change I previously suggested around partexprs_item. You argued
> that wouldn't w
From: Michael Paquier [mailto:michael.paqu...@gmail.com]
> On Fri, May 12, 2017 at 10:44 PM, Tom Lane wrote:
> > I would not really expect that reconnection would retry after
> > arbitrary failure cases. Should it retry for "wrong database name", for
> instance?
> > It's not hard to imagine that
Hi,
On 2017-05-14 21:22:58 -0400, Robert Haas wrote:
> but wanting a CHECK constraint that applies to only one partition
> seems pretty reasonable (e.g. CHECK that records for older years are
> all in the 'inactive' state, or whatever).
On a hash-partitioned table?
> Now that's not to say that
On Sun, May 14, 2017 at 9:19 PM, Michael Paquier
wrote:
> On Fri, May 12, 2017 at 10:44 PM, Tom Lane wrote:
>> Michael Paquier writes:
>>> On Fri, May 12, 2017 at 1:28 PM, Tsunakawa, Takayuki
>>> wrote:
Likewise, when the first host has already reached max_connections, libpq
doesn't
On Sun, May 14, 2017 at 6:29 PM, Andres Freund wrote:
> On 2017-05-14 18:25:08 -0400, Tom Lane wrote:
>> It may well be that we can get away with saying "we're not going
>> to make it simple to move hash-partitioned tables with float
>> partition keys between architectures with different float
>>
On Fri, May 12, 2017 at 10:44 PM, Tom Lane wrote:
> Michael Paquier writes:
>> On Fri, May 12, 2017 at 1:28 PM, Tsunakawa, Takayuki
>> wrote:
>>> Likewise, when the first host has already reached max_connections, libpq
>>> doesn't attempt the connection aginst later hosts.
>
>> It seems to me t
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tsunakawa,> Takayuki
> Instead, I think we should fix the program to match the documented behavior.
> Otherwise, if the first database machine is down, libpq might wait for about
> 2 hours (depending
On Sun, May 14, 2017 at 3:30 PM, Tom Lane wrote:
> I agree that the Far Eastern systems that can't easily be replaced
> by Unicode are that way mostly because they're a mess. But I'm
> still of the opinion that locking ourselves into Unicode is a choice
> we might regret, far down the road.
It's
On Mon, May 15, 2017 at 10:08 AM, Thomas Munro
wrote:
> [2]
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.cbcux01/flotcop.htm#flotcop
Though looking more closely I see that the default is IEEE in 64 bit
builds, which seems like a good way to kill the older format
Andres Freund writes:
> On 2017-05-14 17:22:16 -0400, Stephen Frost wrote:
>> Releasing alpha/beta is not the same as branching, which I didn't expect
>> us to do for a while yet..
> Well, tagging then. Imo it still should be done before we tag
> beta1/alpha1.
Too late, IMO. Yeah, I'd have pre
Peter Geoghegan writes:
> The express goal of the Unicode consortium is to replace all existing
> encodings with Unicode. My personal opinion is that a Unicode
> monoculture would be a good thing, provided reasonable differences can
> be accommodated.
Can't help remembering Randall Munroe's take
On 2017-05-14 18:25:08 -0400, Tom Lane wrote:
> It may well be that we can get away with saying "we're not going
> to make it simple to move hash-partitioned tables with float
> partition keys between architectures with different float
> representations". But there's a whole lot of daylight betwee
Andres Freund writes:
> On 2017-05-14 15:59:09 -0400, Greg Stark wrote:
>> Personally while I would like to avoid code that actively crashes or
>> fails basic tests on Vax
> I personally vote for simply refusing to run/compile on non-IEEE
> platforms, including VAX.
The point of wanting that is
On Mon, May 15, 2017 at 7:59 AM, Greg Stark wrote:
> On 13 May 2017 at 10:29, Robert Haas wrote:
>> - Floats. There may be different representations in use on different
>> hardware, which could be a problem. Tom didn't answer my question
>> about whether any even-vaguely-modern hardware is stil
* Andres Freund (and...@anarazel.de) wrote:
> On 2017-05-14 17:22:16 -0400, Stephen Frost wrote:
> > * Andres Freund (and...@anarazel.de) wrote:
> > > On 2017-05-14 09:53:17 -0400, Bruce Momjian wrote:
> > > > I would like to run pgindent on the head source tree this Wednesday
> > > > afternoon, UT
On 2017-05-14 17:22:16 -0400, Stephen Frost wrote:
> * Andres Freund (and...@anarazel.de) wrote:
> > On 2017-05-14 09:53:17 -0400, Bruce Momjian wrote:
> > > I would like to run pgindent on the head source tree this Wednesday
> > > afternoon, UTC. Is that OK for everyone?
> >
> > Shouldn't we do
* Andres Freund (and...@anarazel.de) wrote:
> On 2017-05-14 09:53:17 -0400, Bruce Momjian wrote:
> > I would like to run pgindent on the head source tree this Wednesday
> > afternoon, UTC. Is that OK for everyone?
>
> Shouldn't we do that before we branch? And if Thursday still is the
> intended
Jan Nieuwenhuizen writes:
> Roel Janssen writes:
>
>> So, it would be something like:
>> postgres pg_upgrade \
>> ...
>
> It's great to have a recipe `that works', so thanks!
>
> However, whether or not we automate this, I cannot help to wonder if
> we should support downgrading -- at least to the
On Sat, May 13, 2017 at 9:11 PM, Robert Haas wrote:
> The latter is
> generally false already. Maybe LATIN1 -> UTF8 is no-fail, but what
> about UTF8 -> LATIN1 or SJIS -> anything? Based on previous mailing
> list discussions, I'm under the impression that it is sometimes
> debatable how a chara
On 2017-05-14 15:59:09 -0400, Greg Stark wrote:
> Personally while I would like to avoid code that actively crashes or
> fails basic tests on Vax
I personally vote for simply refusing to run/compile on non-IEEE
platforms, including VAX. The benefit of even trying to get that right,
not to speak o
2017-05-14 5:04 GMT+02:00 Pavel Stehule :
>
>
> 2017-05-13 22:20 GMT+02:00 Tom Lane :
>
>> Pavel Stehule writes:
>> > I am working on migration large Oracle application to Postgres. When I
>> > started migration procedures with OUT parameters I found following limit
>>
>> > "record or row variabl
On 13 May 2017 at 10:29, Robert Haas wrote:
> - Floats. There may be different representations in use on different
> hardware, which could be a problem. Tom didn't answer my question
> about whether any even-vaguely-modern hardware is still using non-IEEE
> floats, which I suspect means that the
On 2017-05-14 09:53:17 -0400, Bruce Momjian wrote:
> I would like to run pgindent on the head source tree this Wednesday
> afternoon, UTC. Is that OK for everyone?
Shouldn't we do that before we branch? And if Thursday still is the
intended alpha/beta release date, Wednesday would be too late, n
So I put in the patch I'd proposed to reduce sleep delays in the stats
regression test, and I see that frogmouth has now failed that test twice,
with symptoms suggesting that it's dropping the last stats report ---
but not all of the stats reports --- from the test's first session.
I considered rev
Good day, everyone.
I've been playing a bit with unlogged tables - just random updates on
simple
key-value table. I've noticed amount of cpu spent in a compactify_tuples
(called by PageRepareFragmentaion). Most of time were spent in qsort of
itemidbase items.
itemidbase array is bounded by num
On Sun, May 14, 2017 at 5:35 PM, Ildus Kurbangaliev
wrote:
> TRAP: FailedAssertion("!(((const void*)(fdw_trigtuple) != ((void *)0))
> ^ ((bool) (((const void*)(tupleid) != ((void *)0)) &&
> ((tupleid)->ip_posid != 0", File: "trigger.c", Line: 2428)
>
> I'm not sure how it should be fixed, beca
Roel Janssen writes:
> So, it would be something like:
> postgres pg_upgrade \
> ...
It's great to have a recipe `that works', so thanks!
However, whether or not we automate this, I cannot help to wonder if
we should support downgrading -- at least to the previous version
in this case?
If I'm n
I would like to run pgindent on the head source tree this Wednesday
afternoon, UTC. Is that OK for everyone?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+
On 13/05/17 22:23, Andres Freund wrote:
> On 2017-05-12 10:57:55 +0200, Petr Jelinek wrote:
>> Hmm, well it helps but actually now that we don't track individual
>> running transactions anymore it got much less effective (my version of
>> 0005 does as well).
>>
>> The example workload I test with i
Hello hackers,
i was experimenting with fdw tables recently, and discovered two bugs
in postgres core code (tested on stable 9.6 and master).
Steps to reproduce:
1) create parent table
2) create child local table
3) create child foreign table
4) create 'before row update` trigger at foreign table
On Sat, May 13, 2017 at 12:11 PM, Dilip Kumar wrote:
> On Fri, May 12, 2017 at 6:08 PM, amul sul wrote:
>> Hi,
>>
>> Please find the following updated patches attached:
>
> I have done some testing with the new patch, most of the cases worked
> as per the expectation except below
>
> I expect the
On Fri, May 12, 2017 at 10:39 PM, Ashutosh Bapat
wrote:
> On Fri, May 12, 2017 at 6:08 PM, amul sul wrote:
>> Hi,
>>
>> Please find the following updated patches attached:
>>
>> 0001-Cleanup.patch : Does some cleanup and code refactoring required
>> for hash partition patch. Otherwise, there will
51 matches
Mail list logo
