Sorry for the absense.
At Sun, 4 Nov 2018 16:26:12 +0100, Dmitry Dolgov <9erthali...@gmail.com> wrote
in
> > On Sun, 4 Nov 2018 at 15:48, Andrew Gierth
> > wrote:
> >
> > > "Dmitry" == Dmitry Dolgov <9erthali...@gmail.com> writes:
> >
> > Dmitry> This patch went through the last tree comm
On Wed, Oct 10, 2018 at 9:27 AM Daniel Gustafsson wrote:
> > On 9 Oct 2018, at 16:22, Tom Lane wrote:
> > Daniel Gustafsson writes:
> >> Having hit the maximum socketdir length error a number of times in
> >> pg_upgrade,
> >> especially when running tests in a deep directory hierarchy, I figure
Hi,
Thank you for looking at this.
On 2018/11/06 7:25, Alvaro Herrera wrote:
> On 2018-Aug-07, Amit Langote wrote:
>
>>> But in
>>> case of partitioning there is only one parent and hence
>>> coldef->constraints is NULL and hence just overwriting it works. I
>>> think we need comments mentioning
From: Dmitry Dolgov [mailto:9erthali...@gmail.com]
> Thanks for the patches. Unfortunately, judging from the cfbot.cputube.org they
> can't be applied anymore to the current master, could you please rebase them?
Thank you for checking!
I rebased patches on the current master, so I attach them.
Hi,
I want to discuss performance improvements of INSERTs to a partitioned table.
When an application inserts records into a table partitioned into thousands,
find_all_inheritors() locks all of the partitions.
Updating partition key locks in the same way.
So, Execution time becomes longer as th
Hi,
On 2018/11/06 12:03, Michael Paquier wrote:
> On Mon, Nov 05, 2018 at 02:37:05PM +0900, Amit Langote wrote:
>> Michael pointed out a problem with specifying different ON COMMIT actions
>> on a temporary inheritance parent and its children:
>>
>> https://www.postgresql.org/message-id/2018110205
On 11/1/18, Andrew Gierth wrote:
> So (with 8k blocks) the limit on the number of non-null external-toasted
> columns is about 450, while you can have the full 1600 columns if they
> are integers or smaller, or just over 1015 bigints. But you can have
> 1600 text columns if they average 4 bytes or
On Wed, Oct 24, 2018 at 1:21 AM Tom Lane wrote:
> I wrote:
> > =?utf-8?q?PG_Bug_reporting_form?= writes:
> >> SELECT * FROM test_file_fdw_program_limit LIMIT 0;
> >> /*
> >> [38000] ERROR: program "echo "test"" failed Detail: child process exited
> >> with exit code 1
> >> */
>
> > Yeah, I can re
On 11/1/18, David Rowley wrote:
> I've attached an updated patch, again it's just intended as an aid for
> discussions at this stage. Also included the rendered html.
Looks good so far. Based on experimentation with toasted columns, it
seems the largest row size is 452GB, but I haven't tried tha
(2018/11/06 12:53), Kyotaro HORIGUCHI wrote:
At Fri, 02 Nov 2018 22:05:36 +0900, Etsuro Fujita wrote
in<5bdc4ba0.7050...@lab.ntt.co.jp>
(2018/10/29 15:58), Kyotaro HORIGUCHI wrote:
At Tue, 23 Oct 2018 13:21:31 +0100, Tom Lane wrote
in<18397.1540297...@sss.pgh.pa.us>
It's just a POC because
Hello. Thank you for the new version.
At Thu, 1 Nov 2018 11:58:52 +0100, Alexander Kukushkin
wrote in
> Hi,
>
> Attached rebased version patch to the current HEAD and created commit fest
> entry
> On Fri, 21 Sep 2018 at 13:43, Alexander Kukushkin wrote:
> >
> > Hi,
> >
> > On 20 September 20
On 30/10/2018 16:14, Sergei Kornilov wrote:
> Hi
>
> I applied this patch on top 2fe42baf7c1ad96b5f9eb898161e258315298351 commit
> and found a bug while adding STORED column:
>
> postgres=# create table test(i int);
> CREATE TABLE
> postgres=# insert into test values (1),(2);
> INSERT 0 2
> post
On 31/10/2018 08:58, Erikjan Rijkers wrote:
> I have also noticed that logical replication isn't possible on tables
> with a generated column. That's a shame but I suppsoe that is as
> expected.
This is an issue we need to discuss. How should this work?
The simplest solution would be to exclu
On Monday, November 5, 2018 9:06:41 PM CET Robert Haas wrote:
> On Sat, Nov 3, 2018 at 2:20 PM Tom Lane wrote:
> > > Is it realistic we could rename red-black tree methods from 'rb_*' to e.g.
> > > 'rbt_*' to avoid this clash?
> >
> > That's not terribly appetizing, because it essentially means we
While you're there -- I think the CCI after the heap_truncate is not
needed. Could as well get rid of it ...
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Tue, 6 Nov 2018 at 04:31, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 31/10/2018 08:58, Erikjan Rijkers wrote:
> > I have also noticed that logical replication isn't possible on tables
> > with a generated column. That's a shame but I suppsoe that is as
> > expected.
>
> T
Michael Paquier wrote:
> Ordering them in alphabetical order is a good idea due to the high
> number of options available, and more would pile up even if this
> separates a bit "aligned" and "unaligned", so I have have separated
> those diffs from the core patch and committed it, leaving t
> On Tue, 6 Nov 2018 at 10:19, Higuchi, Daisuke
> wrote:
>
> Thank you for checking!
> I rebased patches on the current master, so I attach them.
After adding 'EXEC SQL ALLOCATE DESCRIPTOR sqlda' I've managed to reproduce the
problem you're talking about, and indeed it looks strange:
=# table t
> "Kyotaro" == Kyotaro HORIGUCHI writes:
Kyotaro> My last comment was the while() loop does nothing. Ashutosh
Kyotaro> said that it is on the model of RelabelType.
Kyotaro> I examined the code for T_RelabelType again and it is
Kyotaro> intending that the ece_mutator can convert something
po 29. 10. 2018 v 11:45 odesílatel Pavel Stehule
napsal:
>
>
> po 29. 10. 2018 v 10:11 odesílatel Pavel Stehule
> napsal:
>
>> Hi
>>
>> čt 25. 10. 2018 v 21:47 odesílatel Alvaro Herrera <
>> alvhe...@2ndquadrant.com> napsal:
>>
>>> On 2018-Oct-25, Pavel Stehule wrote:
>>>
>>> > I am thinking so
> "Andrew" == Andrew Gierth writes:
Andrew> I'm going to pull all this together and commit it shortly.
Here's the patch with my edits (more comments and the while/if change).
I'll commit this in due course unless I hear otherwise.
--
Andrew (irc:RhodiumToad)
>From 9cc81cea6de41140fe361b
Hi,
psql's documentation has this mention about output formats:
"Unique abbreviations are allowed. (That would mean one letter is enough.)"
but "one letter is enough" is not true since 9.3 that added
"latex-longtable" sharing the same start as "latex", and then
9.5 added "asciidoc" with the s
Pavel Raiskup writes:
> On Monday, November 5, 2018 9:06:41 PM CET Robert Haas wrote:
>> On Sat, Nov 3, 2018 at 2:20 PM Tom Lane wrote:
Is it realistic we could rename red-black tree methods from 'rb_*' to e.g.
'rbt_*' to avoid this clash?
>>> I don't have a huge objection to renaming
"Daniel Verite" writes:
> psql's documentation has this mention about output formats:
> "Unique abbreviations are allowed. (That would mean one letter is enough.)"
> but "one letter is enough" is not true since 9.3 that added
> "latex-longtable" sharing the same start as "latex", and then
> 9.5
Looking over the stuff in gram.y (to make sure there's nothing that
could be lost), I noticed that we're losing the COLLATE clause when they
are added to columns in partitions. I would expect part1 to end up with
collation es_CL, or alternatively that the command throws an error:
55462 10.6 13885
hi,
On Sun, Nov 4, 2018 at 1:18 PM Fabien COELHO wrote:
> Patch does not seem to apply anymore, could you rebase?
>
>
The attached patch is a rebased version and work by ‘inserts=100’ as
Stephen suggest
regards
Surafel
diff --git a/doc/src/sgml/ref/pg_dump.sgml b/doc/src/sgml/ref/pg_dump.sgml
Thomas Munro writes:
> On Tue, Nov 6, 2018 at 6:23 AM Tom Lane wrote:
>> What I suggest is that we *not* try to make this a completely transparent
>> substitute. Instead, make the functions exported by src/port/ be
>> "pg_pread" and "pg_pwrite", ...
> OK. But since we're using this from both f
Hi!
As a first step I suggest we allow CREATE SUBSCRIPTION for table owner only.
03.11.2018, 19:20, "Stephen Frost" :
> Greetings,
>
> * Evgeniy Efimkin (efim...@yandex-team.ru) wrote:
>> In postgresql 10 and 11 only superuser can create/alter subscriptions.
>> If there was a special role (like
On Tuesday, November 6, 2018 3:49:46 PM CET Tom Lane wrote:
> Pavel Raiskup writes:
> > On Monday, November 5, 2018 9:06:41 PM CET Robert Haas wrote:
> >> On Sat, Nov 3, 2018 at 2:20 PM Tom Lane wrote:
> Is it realistic we could rename red-black tree methods from 'rb_*' to
> e.g.
> >>>
Hi,
On 11/5/18 9:10 PM, Thomas Munro wrote:
On Tue, Nov 6, 2018 at 5:07 AM Alvaro Herrera wrote:
Please remove Tell from line 18 in fd.h. To Küssnacht with him!
Thanks, done. But what is this arrow sticking through my Mac laptop's
screen...?
On Tue, Nov 6, 2018 at 6:23 AM Tom Lane wrote:
On 11/6/18 3:31 PM, Nikita Glukhov wrote:
On 29.10.2018 2:20, Tomas Vondra wrote:>
>
> ...>
Thank you for your review.
1) There are no docs, which makes it pretty much non-committable for
now. I know there is [1] and it was a good intro for the review, but we
need something as a part of our s
There's a thread on the ODBC list[1] complaining about the fact that
it's possible to set client_min_messages to FATAL or PANIC, because
that makes ODBC misbehave. This is not terribly surprising, because
doing so arguably breaks the frontend protocol. The simple-query
section says this:
In
Hi,
I'm building PostgreSQL v11.0 on AIX (6.1, 7.1, & 7.2).
The 2 new tests jsonb_plperl fail in 32bit, not in 64bit.
All other tests are OK.
- Same issue for all 3 versions of AIX
- Version of Perl : 5.24.0
- Version of Python: 2.7.12
I have traced details, but it is still uncle
Hi,
On 2018-11-06 11:19:40 -0500, Tom Lane wrote:
> Hence, I propose that we should disallow setting client_min_messages
> any higher than ERROR, and that this probably even amounts to a
> back-patchable bug fix.
>
> Thoughts?
Seems reasonable. I do think it's probably sensible to backpatch,
alt
Andres Freund writes:
> On 2018-11-06 11:19:40 -0500, Tom Lane wrote:
>> Hence, I propose that we should disallow setting client_min_messages
>> any higher than ERROR, and that this probably even amounts to a
>> back-patchable bug fix.
>>
>> Thoughts?
> Seems reasonable. I do think it's probably
On 2018-11-06 11:37:40 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-11-06 11:19:40 -0500, Tom Lane wrote:
> >> Hence, I propose that we should disallow setting client_min_messages
> >> any higher than ERROR, and that this probably even amounts to a
> >> back-patchable bug fix.
> >>
On 2018-Nov-06, Andres Freund wrote:
> On 2018-11-06 11:37:40 -0500, Tom Lane wrote:
> > Hm, do you really think there is any?
>
> I'm not sure. But it sounds like it'd possibly slow adoption of the
> minor releases if we said "hey, make sure that you nowhere set
> client_min_messages > ERROR",
Here's the patch I intend to push to branches 10 and 11. The patch in
master is almost identical -- the only difference is that
ColumnDef->is_from_parent is removed.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Service
On 2018-Nov-06, Surafel Temesgen wrote:
> hi,
>
> On Sun, Nov 4, 2018 at 1:18 PM Fabien COELHO wrote:
>
> > Patch does not seem to apply anymore, could you rebase?
> >
> The attached patch is a rebased version and work by ‘inserts=100’ as
> Stephen suggest
I thought the suggestion was that the
Tom Lane wrote:
> > When a non-unique abbreviation is used, psql uses the first
> > match in an arbitrary order defined in do_pset() by
> > a cascade of pg_strncasecmp().
>
> Ugh. Should we not fix the code so that it complains if there's
> not a unique match? I would bet that the code
> Good idea. I haven't though about that, but now such names makes more
> sense to me. I will prepare another patch to improve the naming and
> comments to be applied on top of my current patches.
The patch is attached to improve the comments and variable names. I
explained the functions with t
On 2018-Nov-06, Emre Hasegeli wrote:
> The patch is attached to improve the comments and variable names. I
> explained the functions with the same signature on the file header. I
> can duplicate those on the function headers if you find that better.
Surely the comment in line 3839 deserves an u
On 2018-11-06 18:24:55 +0100, Tomas Vondra wrote:
> I've recently updated to Fedora 28, and in that environment I get quite a
> few new valgrind issues (see the attached log).
>
> Essentially, all the reports start with either
>
> ==5971== Invalid read of size 32
> ==5971==at 0x5957EB1: __wcs
Hummm The buildfarm does show that these tests are OK on AIX machines in 32bit,
with GCC 4.8.1 .
Nuts !
Attached is the full diff between the expected results and the real results.
Cordialement,
Tony Reix
tony.r...@atos.net
ATOS / Bull SAS
ATOS Expert
IBM Coop Architect & Technical Leader
On 2018-Nov-06, Tomas Vondra wrote:
> Hi,
>
> I've recently updated to Fedora 28, and in that environment I get quite a
> few new valgrind issues (see the attached log).
Hmm, related to https://postgr.es/m/20180220150838.GD18315@e733.localdomain ?
Apparently the right answer is to add local supp
On 2018-Nov-06, REIX, Tony wrote:
> Hummm The buildfarm does show that these tests are OK on AIX machines in
> 32bit, with GCC 4.8.1 .
>
> Nuts !
>
>
> Attached is the full diff between the expected results and the real results.
Standard diffs are awful to read. Would you mind using context
> Surely the comment in line 3839 deserves an update :-)
Done.
> This seems good material. I would put the detailed conventions comment
> separately from the head of the file, like this (where I also changed
> "Type1 *type1" into "Type1 *obj1", and a few "has" to "have")
Looks better to me. I
On 11/6/18 6:35 PM, Andres Freund wrote:
On 2018-11-06 18:24:55 +0100, Tomas Vondra wrote:
I've recently updated to Fedora 28, and in that environment I get quite a
few new valgrind issues (see the attached log).
Essentially, all the reports start with either
==5971== Invalid read of size 32
=
On 11/6/18 6:35 PM, Alvaro Herrera wrote:
On 2018-Nov-06, Tomas Vondra wrote:
Hi,
I've recently updated to Fedora 28, and in that environment I get quite a
few new valgrind issues (see the attached log).
Hmm, related to https://postgr.es/m/20180220150838.GD18315@e733.localdomain ?
Apparently
út 6. 11. 2018 v 18:18 odesílatel Alvaro Herrera
napsal:
> On 2018-Nov-06, Surafel Temesgen wrote:
>
> > hi,
> >
> > On Sun, Nov 4, 2018 at 1:18 PM Fabien COELHO
> wrote:
> >
> > > Patch does not seem to apply anymore, could you rebase?
> > >
> > The attached patch is a rebased version and work
Hi,all
I analyzed the btree block where lwlock deadlock occurred, as follows:
## insert process(ginInsertValue())
644(root blkno)
|
7054(2. held LWLock:0x2aaac587ae64) rightlink>(3.
Acquire LWLock:0x2aaab4009564,buffer = 2119
On Thu, Oct 25, 2018 at 4:26 PM Alvaro Herrera wrote:
> Firstly, I took Robert's advice and removed the CONCURRENTLY keyword
> from the syntax. We just do it that way always. When there's a default
> partition, only that partition is locked with an AEL; all the rest is
> locked with ShareUpdateE
On 2018-Nov-06, Robert Haas wrote:
> If you're not hacking on this patch set too actively right at the
> moment, I'd like to spend some time hacking on the CREATE/ATTACH side
> of things and see if I can produce something committable for that
> portion of the problem.
I'm not -- feel free to hack
I wrote:
> Yeah. The long and short of this is that we're trampling on namespace
> that reasonably belongs to Ruby --- if they had some functions named
> "pg_something" and complained about a collision with libpq, would we
> change? Nope. So really we should rename these.
> Barring objections I
On Tue, 6 Nov 2018 at 10:10, Robert Haas wrote:
> With this
> approach, already-running queries won't take into account the fact
> that new partitions have been added, but that seems at least tolerable
> and perhaps desirable.
>
Desirable, imho. No data added after a query starts would be visib
On 11/4/18 5:07 AM, David Rowley wrote:
I've attached v13 which hopefully addresses these.
I ran a test against the INSERT case using a 64 hash partition.
Non-partitioned table: ~73k TPS
Master: ~25k TPS
0001: ~26k TPS
0001 + 0002: ~68k TPS
The profile of 0001 shows that almost all of
ExecS
Andrew Gierth writes:
> Here's the patch with my edits (more comments and the while/if change).
A couple minor thoughts:
* I dislike using castNode() in places where the code has just explicitly
verified the node type, which is true in both places where you used it
here. The assertion is just b
On Tue, Nov 6, 2018 at 1:54 PM Simon Riggs wrote:
> Error in the COPY or in the DDL? COPY preferred. Somebody with insert rights
> shouldn't be able to prevent a table-owner level action. People normally drop
> partitions to save space, so it could be annoying if that was interrupted.
Yeah, the
On Tue, 6 Nov 2018 at 10:56, Robert Haas wrote:
> On Tue, Nov 6, 2018 at 1:54 PM Simon Riggs wrote:
> > Error in the COPY or in the DDL? COPY preferred. Somebody with insert
> rights shouldn't be able to prevent a table-owner level action. People
> normally drop partitions to save space, so it c
On Tue, Nov 6, 2018 at 2:01 PM Simon Riggs wrote:
> If you can remove the ERROR without any other adverse effects, that sounds
> great.
>
> Please let us know what, if any, adverse effects would be caused so we can
> discuss. Thanks
Well, I've already written about this in two previous emails o
Two options presented:
- Hard patch removes FATAL/PANIC from client_message_level_options in
guc.c, which also seems to make sense in regard to it's double-usage
with trace_recovery_messages.
- Soft patch keeps FATAL/PANIC in client_message_level_options but coerces
client_min_messages to ERROR w
On 2018-Nov-06, Robert Haas wrote:
> If you don't throw an error when a partition is concurrently detached
> and then someone routes a tuple to that portion of the key space, what
> DO you do? Continue inserting tuples into the table even though it's
> no longer a partition?
Yes -- the table was
On Tue, Nov 6, 2018 at 2:10 PM Alvaro Herrera wrote:
> On 2018-Nov-06, Robert Haas wrote:
> > If you don't throw an error when a partition is concurrently detached
> > and then someone routes a tuple to that portion of the key space, what
> > DO you do? Continue inserting tuples into the table ev
On Tue, 6 Nov 2018 at 11:06, Robert Haas wrote:
> On Tue, Nov 6, 2018 at 2:01 PM Simon Riggs wrote:
> > If you can remove the ERROR without any other adverse effects, that
> sounds great.
> >
> > Please let us know what, if any, adverse effects would be caused so we
> can discuss. Thanks
>
> Wel
On Tue, 6 Nov 2018 at 14:07, Jonah H. Harris wrote:
> Two options presented:
>
> - Hard patch removes FATAL/PANIC from client_message_level_options in
> guc.c, which also seems to make sense in regard to it's double-usage
> with trace_recovery_messages.
>
> - Soft patch keeps FATAL/PANIC in clien
> "Tom" == Tom Lane writes:
Tom> * I dislike using castNode() in places where the code has just
Tom> explicitly verified the node type, which is true in both places
Tom> where you used it here. The assertion is just bulking the code up
Tom> to no purpose, and it creates an unnecessary dis
On Wed, Nov 7, 2018 at 4:42 AM Jesper Pedersen
wrote:
> Passes check-world, and includes the feedback on this thread.
>
> New status: Ready for Committer
Thanks! Pushed. I'll keep an eye on the build farm to see if
anything breaks on Cygwin or some other frankenOS.
--
Thomas Munro
http://www.
=?UTF-8?Q?Ond=c5=99ej_Bouda?= writes:
>>> Hm, what are the data types of those columns?
> scheduletemplate_id bigint NOT NULL,
> period_day smallint NOT NULL,
> timerange timerange NOT NULL,
OK, so here's a minimal reproducer:
drop table schedulecard;
create table schedulecard (
scheduletemp
On 06/11/2018 14:28, Simon Riggs wrote:
> The simplest solution would be to exclude generated columns from the
> replication stream altogether.
>
>
> IMHO...
>
> Virtual generated columns need not be WAL-logged, or sent.
right
> Stored generated columns should be treated just like we'd
I wrote:
> Interestingly, it doesn't crash if I change the index type to btree,
> which I was not expecting because the crashing code seems pretty
> independent of the index type.
Oh ... duh. The problem here is that ProjIndexIsUnchanged thinks that
the type of the index column is identical to th
On Tue, Nov 6, 2018 at 2:46 PM Isaac Morland
wrote:
> On Tue, 6 Nov 2018 at 14:07, Jonah H. Harris
> wrote:
>
>> Two options presented:
>>
>> - Hard patch removes FATAL/PANIC from client_message_level_options in
>> guc.c, which also seems to make sense in regard to it's double-usage
>> with trac
Ondřej, as a short-term workaround you could prevent the crash
by setting that index's recheck_on_update property to false.
Thanks for the tip. I am unsuccessful using it, though:
# ALTER INDEX public.schedulecard_overlap_idx SET (recheck_on_update =
FALSE);
ERROR: unrecognized parameter "r
Do we need to add anything in the release notes about possible
complications in upgrading caused by the 65f39408ee71 / 56535dcdc9e2
issue?
If upgrading from the immediately prior point releases to this one, then
the shutdown of the previous version might have left an incorrect min
recovery point i
=?UTF-8?Q?Ond=c5=99ej_Bouda?= writes:
>> Ondřej, as a short-term workaround you could prevent the crash
>> by setting that index's recheck_on_update property to false.
> Thanks for the tip. I am unsuccessful using it, though:
> # ALTER INDEX public.schedulecard_overlap_idx SET (recheck_on_update
Greetings,
* Evgeniy Efimkin (efim...@yandex-team.ru) wrote:
> As a first step I suggest we allow CREATE SUBSCRIPTION for table owner only.
That's a nice idea but seems like we would want to have a way to filter
what tables a subscription follows then..? Just failing if the
publication publishes
On 2018-Nov-06, Tom Lane wrote:
> =?UTF-8?Q?Ond=c5=99ej_Bouda?= writes:
> >> Ondřej, as a short-term workaround you could prevent the crash
> >> by setting that index's recheck_on_update property to false.
>
> > Thanks for the tip. I am unsuccessful using it, though:
> > # ALTER INDEX public.sch
On 2018-11-06 16:47:20 -0500, Tom Lane wrote:
> =?UTF-8?Q?Ond=c5=99ej_Bouda?= writes:
> >> Ondřej, as a short-term workaround you could prevent the crash
> >> by setting that index's recheck_on_update property to false.
>
> > Thanks for the tip. I am unsuccessful using it, though:
> > # ALTER IND
On Tue, Aug 7, 2018 at 9:29 AM Andres Freund wrote:
> One approach would be to make sure that everything relying on
> rt_partdesc staying the same stores its value in a local variable, and
> then *not* free the old version of rt_partdesc (etc) when the refcount >
> 0, but delay that to the Relatio
Andres Freund writes:
> On 2018-11-06 16:47:20 -0500, Tom Lane wrote:
>> Looks like somebody forgot to list
>> RELOPT_KIND_GIST in RELOPT_KIND_INDEX, but is that the
>> fault of commit c203d6cf8 or was it busted before?
> Looks new:
> + RELOPT_KIND_INDEX =
> RELOPT_KIND_BTREE|RELOPT_KIND_HASH|
On 11/6/18 10:54 PM, Andres Freund wrote:
> On 2018-11-06 16:47:20 -0500, Tom Lane wrote:
>> =?UTF-8?Q?Ond=c5=99ej_Bouda?= writes:
Ondřej, as a short-term workaround you could prevent the crash
by setting that index's recheck_on_update property to false.
>>
>>> Thanks for the tip. I am u
On Tue, 6 Nov 2018 at 13:16, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> > Stored generated columns should be treated just like we'd treat a column
> > value added by a trigger.
> >
> > e.g. if we had a Timestamp column called LastUpdateTimestamp we would
> > want to send that v
On 11/5/18 11:10 PM, Amit Langote wrote:
> Hi,
>
> On 2018/11/06 12:49, Jonathan S. Katz wrote:
>>
>> I still feel inclined to elaborate on the "Prevent creation of a
>> partition in a trigger attached to its parent table" but perhaps in
>> future release we will just mention that this behavior is
Hi,
On 2018-11-06 23:11:29 +0100, Tomas Vondra wrote:
> On 11/6/18 10:54 PM, Andres Freund wrote:
> > Looks new:
> > + RELOPT_KIND_INDEX =
> > RELOPT_KIND_BTREE|RELOPT_KIND_HASH|RELOPT_KIND_GIN|RELOPT_KIND_SPGIST,
> >
> > there aren't any other "for all indexes" type options, so the whole
> >
Greetings,
* Andrew Gierth (and...@tao11.riddles.org.uk) wrote:
> Do we need to add anything in the release notes about possible
> complications in upgrading caused by the 65f39408ee71 / 56535dcdc9e2
> issue?
>
> If upgrading from the immediately prior point releases to this one, then
> the shutd
Hi,
On 2018-11-06 17:11:40 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-11-06 16:47:20 -0500, Tom Lane wrote:
> >> Looks like somebody forgot to list
> >> RELOPT_KIND_GIST in RELOPT_KIND_INDEX, but is that the
> >> fault of commit c203d6cf8 or was it busted before?
>
> > Looks new:
Stephen Frost writes:
> * Andrew Gierth (and...@tao11.riddles.org.uk) wrote:
>> Do we need to add anything in the release notes about possible
>> complications in upgrading caused by the 65f39408ee71 / 56535dcdc9e2
>> issue?
>>
>> If upgrading from the immediately prior point releases to this one
On Tue, Nov 6, 2018 at 11:48 AM Alvaro Herrera wrote:
> I agree -- it seems better to have a benign no-op and prevent this kind
> of silly rationale from preventing upgrades.
+1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Hello,
PostgreSQL likes to probe the size of relations with lseek(SEEK_END) a
lot. For example, a fully prewarmed pgbench -S transaction consists
of recvfrom(), lseek(SEEK_END), lseek(SEEK_END), sendto(). I think
lseek() is probably about as cheap as a syscall can be so I doubt it
really costs u
Hi,
On 2018-11-07 11:40:22 +1300, Thomas Munro wrote:
> PostgreSQL likes to probe the size of relations with lseek(SEEK_END) a
> lot. For example, a fully prewarmed pgbench -S transaction consists
> of recvfrom(), lseek(SEEK_END), lseek(SEEK_END), sendto(). I think
> lseek() is probably about as
> "Tom" == Tom Lane writes:
Tom> You could be bit by any shutdown of the old code, no, whether it's
Tom> part of a pg_upgrade or not?
Nothing to do with pg_upgrade, this is likely to bite people just doing
an update from the previous minor release.
Tom> Also, it looks like the bug only a
>From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp]
>> This would cause some waste of memory on DSA because some partitions
>> (buckets)
>is allocated but not used.
>>
>> So I'm thinking that current dshash design is still ok but flexible
>> size of partition is appropriate for some
On Tue, Nov 06, 2018 at 09:53:37AM -0300, Alvaro Herrera wrote:
> While you're there -- I think the CCI after the heap_truncate is not
> needed. Could as well get rid of it ...
Yes, I have noticed the comment saying so. I did not really want to
bother about that part yet for this patch as that c
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
This is a documentation update, no code changes. The initial idea came from t
At Tue, 06 Nov 2018 21:07:37 +0900, Etsuro Fujita
wrote in <5be18409.2070...@lab.ntt.co.jp>
> (2018/11/06 12:53), Kyotaro HORIGUCHI wrote:
> > At Fri, 02 Nov 2018 22:05:36 +0900, Etsuro
> > Fujita wrote
> > in<5bdc4ba0.7050...@lab.ntt.co.jp>
> >> (2018/10/29 15:58), Kyotaro HORIGUCHI wrote:
> >>>
Thank you for the comments, Antonin, Tomas.
At Tue, 30 Oct 2018 13:35:23 +0100, Tomas Vondra
wrote in
>
>
> On 10/05/2018 10:30 AM, Kyotaro HORIGUCHI wrote:
> > Hello.
> >
> > At Tue, 02 Oct 2018 16:06:51 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
> > wrote in
> > <20181002.160651.117
On Tue, Nov 06, 2018 at 07:04:17PM +0900, Amit Langote wrote:
> Agree with keeping it simple. Maybe, we could (should?) document that the
> only ON COMMIT action that works when specified with partitioned parent
> table is DROP (other actions are essentially ignored)?
I have been thinking about t
About inheritance_make_rel_from_joinlist(), I considered how it processes
joins for sub-partitioned-table.
sub-partitioned-table image:
part
sub1
leaf1
leaf2
inheritance_make_rel_from_joinlist() translates join_list and join_info_list
for each leafs(leaf1, leaf2 in above image). To tran
On Tue, Nov 06, 2018 at 11:44:56PM +, Andrew Gierth wrote:
> The commit message doesn't really show the severity of the problem at
> all.
I take the blame for that. And my apologies for what it's worth.
> The users whose case I was diagnosing on IRC were finding that their
> monitoring syste
Hi,
On 2018/11/07 0:10, Alvaro Herrera wrote:
> Looking over the stuff in gram.y (to make sure there's nothing that
> could be lost), I noticed that we're losing the COLLATE clause when they
> are added to columns in partitions. I would expect part1 to end up with
> collation es_CL, or alternativ
On Tue, Nov 06, 2018 at 06:18:37PM +0100, Daniel Verite wrote:
> In both cases using abbreviations in scripts is not a great
> idea. Anyway I will look into the changes required in do_pset to
> implement the error on multiple matches, if that's the preferred
> behavior.
You would also break the co
1 - 100 of 119 matches
Mail list logo