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 dec
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.
B
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 w
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 installcheck-paralle
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 cre
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 partbo
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
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 architect
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. K
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 tha
(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
*/
Yea
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 co
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 an
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 Herrerahttps://www.2ndQuadrant
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 pr
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 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 know
> "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 th
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
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 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
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 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
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
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:
> >>>
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
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
>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
> "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
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
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
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
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
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:
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 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
> >
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
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/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
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 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
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 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
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
=?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
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
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
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
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 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
=?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 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.
> "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 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
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, 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 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
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 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
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 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
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 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
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
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 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
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
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
ú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 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
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
=
> 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
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
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-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
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
> 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
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
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
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, 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",
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.
> >>
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
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
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
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
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
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 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!
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
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,
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
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
"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
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
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
> "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
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
1 - 100 of 119 matches
Mail list logo
