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,
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 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
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:
> 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 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
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
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
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
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 =
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
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
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
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,
> 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
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 ?
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
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
>
>
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 &
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
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
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
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
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 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
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
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
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
ú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
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
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
> "Michael" == Michael Paquier writes:
>> So while there _probably_ isn't any data corruption, the standby can
>> get into a state that isn't restartable unless you know to block
>> client connections to it until it has caught up. Rebuilding the
>> standby from the master will work but
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:
>
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
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
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
On Mon, Nov 05, 2018 at 10:49:30PM -0500, Jonathan S. Katz wrote:
> On 11/5/18 9:58 PM, Amit Langote wrote:
> > On 2018/11/06 11:25, Noah Misch wrote:
> >> On Mon, Nov 05, 2018 at 04:01:59PM -0500, Jonathan S. Katz wrote:
> >>> Attached is a draft of the press release for review. Please let me
On 2018-Nov-06, Alvaro Herrera wrote:
> On 2018-Nov-06, Robert Haas wrote:
> > Throw tuples destined for that partition away?
>
> Surely not. (/me doesn't beat straw men anyway.)
Hmm, apparently this can indeed happen with my patch :-(
--
Álvaro Herrera
On Tue, Sep 25, 2018 at 2:09 PM Thomas Munro
wrote:
> Some people like to use DNS SRV records to advertise LDAP servers on
> their network. Microsoft Active Directory is usually (always?) set up
> that way. Here is a patch to allow our LDAP auth module to support
> that kind of discovery. It
(2018/11/06 19:50), Thomas Munro wrote:
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
*/
On 11/6/18 9:35 PM, Amit Langote wrote:
> On 2018/11/07 11:28, Noah Misch wrote:
>> On Mon, Nov 05, 2018 at 10:49:30PM -0500, Jonathan S. Katz wrote:
>>> On 11/5/18 9:58 PM, Amit Langote wrote:
On 2018/11/06 11:25, Noah Misch wrote:
> On Mon, Nov 05, 2018 at 04:01:59PM -0500, Jonathan S.
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
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
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
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
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
>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
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
Hi,
Related to my development (putting relcache and catcache onto shared memory)[1],
I have some questions about how to copy variables into shared memory,
especially DSA area, and its implementation way.
Under the current architecture when initializing some data, we sometimes copy
certain data
On 2018/11/07 11:28, Noah Misch wrote:
> On Mon, Nov 05, 2018 at 10:49:30PM -0500, Jonathan S. Katz wrote:
>> On 11/5/18 9:58 PM, Amit Langote wrote:
>>> On 2018/11/06 11:25, Noah Misch wrote:
On Mon, Nov 05, 2018 at 04:01:59PM -0500, Jonathan S. Katz wrote:
> Attached is a draft of the
ISTM patch 0004 is impossible to review just because of size -- I
suppose the bulk of it is just code that moves from one file to another,
but that there are also code changes in it. Maybe it would be better to
split it so that one patch moves the code to the new files without
changing it, then
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
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
> >
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
Thanks for looking.
On 2018/11/07 12:32, Alvaro Herrera wrote:
> ISTM patch 0004 is impossible to review just because of size -- I
> suppose the bulk of it is just code that moves from one file to another,
> but that there are also code changes in it. Maybe it would be better to
> split it so
Hi,
Thank your for taking a look.
On 2018/11/05 16:21, Michael Paquier wrote:
> On Thu, Nov 01, 2018 at 01:03:00PM +0900, Amit Langote wrote:
>> Done a few moments ago. :)
>
> From the file size this move is actually negative. From what I can see
> partcache decreases to 400 lines, while
On 09/10/2018 15:09, Daniel Gustafsson wrote:
> Having hit the maximum socketdir length error a number of times in pg_upgrade,
> especially when running tests in a deep directory hierarchy, I figured it was
> time to see if anyone else has had the same problem? The attached patch is
> what I run
On 05/11/2018 20:54, Andres Freund wrote:
> What mechanism are you referring to? Expected files and resultmap don't
> really fit that bill?
We can add test files on the pg_regress command line based on makefile
conditionals.
>> But some of those tests are used for testing that the unsupported
>>
On 05/11/2018 22:00, Andres Freund wrote:
> The test I'm most commonly waiting for when doing a parallel make check
> is pg_upgrade. And to a significant degree that's because it uses the
> serial installcheck rather than installcheck-parallel.
>
> Is there a reason to not use
On Wed, Nov 7, 2018 at 3:34 PM Ideriha, Takeshi
wrote:
> Related to my development (putting relcache and catcache onto shared
> memory)[1],
>
> I have some questions about how to copy variables into shared memory,
> especially DSA area, and its implementation way.
>
> Under the current
On Wed, Nov 07, 2018 at 02:06:13AM +, Andrew Gierth wrote:
> So the minimum recovery location is recorded as 0x201FCFE0, but there
> are data pages on disk with LSNs as recent as 0x25BAFE80. That's a whole
> lot of daylight that could contain a btree delete.
Sorry for the time it took. I was
Hi,
On 2018/11/07 13:08, Jonathan S. Katz wrote:
> Thanks. I left it as "Fix several crashes with triggers" - please see
> attached.
Thank you. Just one more comment on the top sentence.
* Ensure that if a parent partition has an index created in a tablespace,
then all child indexes will be
Hi,
On 2018-11-07 08:21:09 +0100, Peter Eisentraut wrote:
> On 05/11/2018 20:54, Andres Freund wrote:
> > What mechanism are you referring to? Expected files and resultmap don't
> > really fit that bill?
>
> We can add test files on the pg_regress command line based on makefile
> conditionals.
On Wed, Nov 07, 2018 at 03:34:38PM +0900, Amit Langote wrote:
> On 2018/11/05 16:21, Michael Paquier wrote:
>> On Thu, Nov 01, 2018 at 01:03:00PM +0900, Amit Langote wrote:
>>> Done a few moments ago. :)
>>
>> From the file size this move is actually negative. From what I can see
>> partcache
> "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
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
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
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
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
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
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 =
>
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
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
=?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
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
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
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
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
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
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
=?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 (
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
> "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
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
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:
>>
>>
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
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
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
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
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
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
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
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
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
(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
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
>
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
1 - 100 of 117 matches
Mail list logo
