Hello Justin,
llvmjit_inline.cpp:59:10: fatal error: llvm/IR/CallSite.h: No such file or
directory
Seems to be the same as here:
https://www.postgresql.org/message-id/flat/CAGf%2BfX4sDP5%2B43HBz_3fjchawO6boqwgbYVfuFc1D4gbA6qQxw%40mail.gmail.com#540c3746c79c0f13360b35c9c369a887
On Wed, May 27, 2020 at 12:53 PM Amit Langote
wrote:
> On Fri, May 22, 2020 at 9:09 PM amul sul wrote:
> > I tried similar things on inherit partitioning as follow and that looks
> fine:
> >
> > DROP TABLE tbl;
> > CREATE TABLE tbl (c1 INT,c2 TEXT);
> > CREATE TABLE tbl_null(check (c1 is NULL))
On Wed, May 27, 2020 at 5:31 PM Tom Lane wrote:
> Robert Haas writes:
> > I think the only way to make the effects of an EXPLAIN ANALYZE
> > statement be automatically rolled back would be to wrap the entire
> > operation in a subtransaction. While we could certainly implement
> > that, it
I've attached the latest patches after further review from Justin Pryzby.
--
David Gilman :DG<
https://gilslotd.com
>From 90e06cbb724f6f6a244dfc69f3d59ca2e7d29c01 Mon Sep 17 00:00:00 2001
From: David Gilman
Date: Wed, 20 May 2020 22:49:28 -0400
Subject: [PATCH 1/4] Scan all TOCs when restoring
Robert Haas writes:
> I think the only way to make the effects of an EXPLAIN ANALYZE
> statement be automatically rolled back would be to wrap the entire
> operation in a subtransaction. While we could certainly implement
> that, it might have its own share of surprises; for example, it would
>
At Wed, 27 May 2020 07:57:38 -0400, Robert Haas wrote
in
> On Wed, May 13, 2020 at 10:43 PM Kyotaro Horiguchi
> wrote:
> > About 0002,
> >
> > + boolsendtblspclinks = true;
> >
> > The boolean seems to me useless since it is always the inverse of
> >
> On May 27, 2020, at 2:42 PM, Christopher Browne wrote:
>
> There is merit to having a new, harmonious set of "pg commands." But it's
> eminently easy to get into trouble (and get people mad) by changing things
> that have been working fine for many years. Half the battle (against the
>
On 2020-May-28, Thomas Munro wrote:
> My indecision on the back-patching question has been resolved by your
> crash report and a search on codesearch.debian.org.
Great news!
> BufFileRead() and BufFileWrite() aren't referenced by any of the
> extensions they package, so by that standard it's OK
On Thu, May 28, 2020 at 4:16 AM Alvaro Herrera wrote:
> On 2020-Jan-27, Robert Haas wrote:
> > OK, now that I've waxed eloquent on that topic, let me have a go at
> > your actual questions. Regarding back-patching, I don't mind
> > back-patching error handling patches like this, but I don't feel
On Wed, 27 May 2020 at 16:49, Isaac Morland wrote:
> On Wed, 27 May 2020 at 16:00, Peter Eisentraut <
> peter.eisentr...@2ndquadrant.com> wrote:
>
>
>> Also consider some practical concerns with the command structure you
>> describe: Tab completion of commands wouldn't work anymore, unless you
On Wed, 27 May 2020 at 16:00, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> Also consider some practical concerns with the command structure you
> describe: Tab completion of commands wouldn't work anymore, unless you
> supply custom tab completion setups. The direct association
On Wed, May 27, 2020 at 07:40:27PM +0200, Fabien COELHO wrote:
> llvmjit_inline.cpp:59:10: fatal error: llvm/IR/CallSite.h: No such file or
Seems to be the same as here:
On 2020-05-27 01:19, Mark Dilger wrote:
Attached is a patch for a `pg' command that consolidates various PostgreSQL
functionality into a single command, along the lines of how `git' commands are
run from a single 'git' executable. In other words,
`pg upgrade` # instead of `pg_upgrade`
пн, 25 мая 2020 г. в 18:25, Justin Pryzby :
> I wonder if/how that fails if you create the index before adding data:
>
> CREATE TABLE test_path(path ltree);
> CREATE INDEX ON test_path USING GIST(path);
> INSERT INTO test_path SELECT * FROM comments.mp_comments;
>
> Does that fail on a particular
Hello devs,
commit 2c24051bacd2d0eb7141fc4adb870281aec4e714
Author: Craig Topper
Date: Fri Apr 24 22:12:21 2020 -0700
[CallSite removal] Rename CallSite.h to AbstractCallSite.h. NFC
The CallSite and ImmutableCallSite were removed in a previous
commit. So rename the file to
On Wed, 27 May 2020 at 12:35, Robert Haas wrote:
> Ugh, yeah, please don't do that. Renaming them just to make it "look more
> modern" helps nobody, really. Especially if the suggestion is people should
> be using the shared-launcher binary anyway.
>
> The way things like 'git' work is that 'git
On 2020-May-26, Michael Paquier wrote:
> On Mon, May 25, 2020 at 06:29:10PM +0900, Michael Paquier wrote:
> > Perhaps you are right though, and that we don't need to spend this
> > much energy into improving the error messages so I am fine to discard
> > this part. At the end, in order to remove
On Wed, May 27, 2020 at 4:51 AM Magnus Hagander wrote:
>> For that reason, I did not change the names of the executables, merely their
>> location. During conversations with Robert off-list, we discussed renaming
>> the executables to things like 'pg-ctl' (hyphen rather than underscore),
>>
On Wed, May 27, 2020 at 12:16 PM Alvaro Herrera
wrote:
> I do have evidence of postgres crashes because of a problem that could
> be explained by this bug, so I +1 backpatching this to all supported
> branches.
>
> (The problem I saw is a hash-join spilling data to temp tablespace,
> which fills
On 2020-Jan-27, Robert Haas wrote:
> OK, now that I've waxed eloquent on that topic, let me have a go at
> your actual questions. Regarding back-patching, I don't mind
> back-patching error handling patches like this, but I don't feel it's
> necessary if we have no evidence that data is actually
On Wed, May 27, 2020 at 10:48 AM David G. Johnston
wrote:
> The recent discussion about EXPLAIN and the possible inclusion of
> default-specifying GUCs raised a behavior that I did not fully appreciate nor
> find to be self-evident. Running EXPLAIN ANALYZE results in any side-effects
> of the
On 2020-Jan-29, Michael Paquier wrote:
> On Tue, Jan 28, 2020 at 03:51:54PM -0500, Robert Haas wrote:
> > I quickly reread that thread and I don't see that there's any firm
> > consensus there in favor of "read %d of %zu" over "read only %d of %zu
> > bytes". Now, if most people prefer the
On Wed, May 27, 2020 at 4:51 AM Magnus Hagander wrote:
> As mentioned at least once before, the "pg" name is already taken in posix.
> Granted it has been removed now, but it was removed from posix in 2018, which
> I think is nowhere near soon enough to "steal. See for example
>
## Magnus Hagander (mag...@hagander.net):
> Ugh, yeah, please don't do that. Renaming them just to make it "look more
> modern" helps nobody, really. Especially if the suggestion is people should
> be using the shared-launcher binary anyway.
Quick, let's invent a fancy name like "microcommand"
Hi Andres,
On the mensiversary of the last response, what can I do to help move
this along (aside from heeding the advice "don't use LLVM HEAD")?
Michael Paquier expressed concerns over flippant churn upthread:
On Mon, Apr 27, 2020 at 10:19 PM Andres Freund wrote:
AF> On 2020-04-28 13:56:23
The recent discussion about EXPLAIN and the possible inclusion of
default-specifying GUCs raised a behavior that I did not fully appreciate
nor find to be self-evident. Running EXPLAIN ANALYZE results in any
side-effects of the explained and analyzed statement being permanently
written to the
On Wed, May 27, 2020 at 3:00 PM Mark Dilger
wrote:
>
>
> > On May 26, 2020, at 4:59 PM, David G. Johnston <
> david.g.johns...@gmail.com> wrote:
> >
> > On Tue, May 26, 2020 at 4:19 PM Mark Dilger <
> mark.dil...@enterprisedb.com> wrote:
> > I'd also appreciate +1 and -1 votes on the overall
> On May 27, 2020, at 1:50 AM, Magnus Hagander wrote:
>
> On Wed, May 27, 2020 at 1:19 AM Mark Dilger
> wrote:
> Hackers,
>
> Attached is a patch for a `pg' command that consolidates various PostgreSQL
> functionality into a single command, along the lines of how `git' commands
> are run
> On May 27, 2020, at 1:13 AM, Dave Page wrote:
>
> Hi
>
> On Wed, May 27, 2020 at 12:19 AM Mark Dilger
> wrote:
>
> I think it makes sense that packagers could put the LIBEXECDIR in the PATH so
> that 3rd-party scripts which call pg_ctl, initdb, etc. continue to work.
>
> Having
> On May 26, 2020, at 4:59 PM, David G. Johnston
> wrote:
>
> On Tue, May 26, 2020 at 4:19 PM Mark Dilger
> wrote:
> I'd also appreciate +1 and -1 votes on the overall idea, in case this entire
> feature, regardless of implementation, is simply something the community does
> not want.
>
Greetings,
* Jonathan S. Katz (jk...@postgresql.org) wrote:
> On 5/27/20 9:13 AM, Michael Paquier wrote:
> > On Wed, May 27, 2020 at 02:56:34PM +0200, Magnus Hagander wrote:
> >> Seems like the better choice yeah. Since we're changing the default anyway,
> >> maybe now is the time to do that? Or
On Wed, May 27, 2020 at 8:01 PM Ashutosh Bapat <
ashutosh.ba...@2ndquadrant.com> wrote:
>
>
> On Wed, 27 May 2020 at 04:43, Andy Fan wrote:
>
>> You can use the attached sql to reproduce this issue, but I'm not sure
>> you can
>> get the above result at the first time that is because when
On 5/27/20 9:13 AM, Michael Paquier wrote:
> On Wed, May 27, 2020 at 02:56:34PM +0200, Magnus Hagander wrote:
>> Seems like the better choice yeah. Since we're changing the default anyway,
>> maybe now is the time to do that? Or if not, maybe have it log an explicit
>> deprecation warning when it
On 5/26/20 4:25 AM, Peter Eisentraut wrote:
> On 2020-05-25 17:57, Jonathan S. Katz wrote:
>> I took a look over, it looks good. One question on the initdb.c diff:
>>
>> - if (strcmp(authmethodlocal, "scram-sha-256") == 0 ||
>> - strcmp(authmethodhost, "scram-sha-256") == 0)
>> - {
>>
On Wed, May 27, 2020 at 9:11 PM Ashutosh Bapat
wrote:
> On Wed, May 27, 2020 at 12:53 PM Amit Langote wrote:
> > On Fri, May 22, 2020 at 9:09 PM amul sul wrote:
> > > I tried similar things on inherit partitioning as follow and that looks
> > > fine:
> > >
> > > DROP TABLE tbl;
> > > CREATE
On Wed, May 27, 2020 at 02:56:34PM +0200, Magnus Hagander wrote:
> Seems like the better choice yeah. Since we're changing the default anyway,
> maybe now is the time to do that? Or if not, maybe have it log an explicit
> deprecation warning when it loads a config with it?
Not sure that's worth
On Wed, May 27, 2020 at 8:29 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2020-05-27 08:00, Michael Paquier wrote:
> > On Tue, May 26, 2020 at 10:25:25AM +0200, Peter Eisentraut wrote:
> >> Yeah, I was too enthusiastic about removing that. Here is a better
> patch.
> >
> >
On Wed, May 27, 2020 at 12:53 PM Amit Langote wrote:
>
> On Fri, May 22, 2020 at 9:09 PM amul sul wrote:
> > I tried similar things on inherit partitioning as follow and that looks
> > fine:
> >
> > DROP TABLE tbl;
> > CREATE TABLE tbl (c1 INT,c2 TEXT);
> > CREATE TABLE tbl_null(check (c1 is
On Wed, 27 May 2020 at 04:43, Andy Fan wrote:
> You can use the attached sql to reproduce this issue, but I'm not sure you
> can
> get the above result at the first time that is because when optimizer
> think the
> 2 index scan have the same cost, it will choose the first one it found,
> the
On Wed, May 13, 2020 at 10:43 PM Kyotaro Horiguchi
wrote:
> About 0002,
>
> + boolsendtblspclinks = true;
>
> The boolean seems to me useless since it is always the inverse of
> opt->sendtblspcmapfile when it is used.
Well, I think it might have some
On Tue, 26 May 2020 at 16:46, Amit Kapila wrote:
>
> On Tue, May 26, 2020 at 2:44 PM Dilip Kumar wrote:
> >
> > On Tue, May 26, 2020 at 10:27 AM Amit Kapila
wrote:
> > >
> > > >
> > > > 2. There is a bug fix in handling the stream abort in 0008 (earlier
it
> > > > was 0006).
> > > >
> > >
> > >
On Tue, 26 May 2020 at 09:06, Amit Khandekar wrote:
>
> On Sat, 23 May 2020 at 23:24, Pavel Stehule wrote:
> >
> >FOR counter IN 1..180 LOOP
> > id = 0; id = 0; id1 = 0;
> > id2 = 0; id3 = 0; id1 = 0; id2 = 0;
> > id3 = 0; id = 0; id = 0; id1 = 0;
> > id2 = 0; id3
On 5/27/20 7:27 AM, David G. Johnston wrote:
> On Tuesday, May 26, 2020, David Rowley wrote:
>
>> On Tue, 26 May 2020 at 23:59, Vik Fearing wrote:
>>> Are you saying we should have all new EXPLAIN options off forever into
>>> the future because apps won't know about the new data? I guess we
On Tue, May 26, 2020 at 06:42:50PM -0700, Melanie Plageman wrote:
On Tue, May 26, 2020 at 5:40 PM Jeff Davis wrote:
On Tue, 2020-05-26 at 21:15 +0200, Tomas Vondra wrote:
>
> As for the tlist fix, I think that's mostly ready too - the one thing
> we
> should do is probably only doing it for
On Wed, May 27, 2020 at 1:19 AM Mark Dilger
wrote:
> Hackers,
>
> Attached is a patch for a `pg' command that consolidates various
> PostgreSQL functionality into a single command, along the lines of how
> `git' commands are run from a single 'git' executable. In other words,
>
> `pg upgrade`
Hi
On Wed, May 27, 2020 at 12:19 AM Mark Dilger
wrote:
>
> I think it makes sense that packagers could put the LIBEXECDIR in the PATH
> so that 3rd-party scripts which call pg_ctl, initdb, etc. continue to
> work.
Having packages that futz with the PATH is generally a bad idea, especially
On Wed, May 27, 2020 at 04:21:59PM +0900, Kyotaro Horiguchi wrote:
> I don't oppose to full-spelling. How about the attached?
No problem from me.
--
Michael
signature.asc
Description: PGP signature
On Mon, May 25, 2020 at 11:14:39AM -0400, Tom Lane wrote:
> Perhaps I'm an optimist, but I think that eventually we will figure out
> how to make unlikely() work for MSVC. In the meantime we might as well
> let it work for gcc-on-Windows builds.
I am less optimistic than that, but there is hope.
On Fri, May 22, 2020 at 9:09 PM amul sul wrote:
> I tried similar things on inherit partitioning as follow and that looks fine:
>
> DROP TABLE tbl;
> CREATE TABLE tbl (c1 INT,c2 TEXT);
> CREATE TABLE tbl_null(check (c1 is NULL)) INHERITS (tbl);
> CREATE TABLE tbl_1 (check (c1 > 0 and c1 < 4))
At Wed, 27 May 2020 15:11:00 +0900, Michael Paquier wrote
in
> On Wed, May 27, 2020 at 10:46:27AM +0900, Kyotaro Horiguchi wrote:
> > Agreed. It should be a leftover at the time the unit was changed
> > (before committed) to MB from bytes. The default value makes the
> > confusion worse.
> >
On Tue, May 26, 2020 at 07:30:54PM +, Bossart, Nathan wrote:
> While an assertion in UpdateControlFile() would not have helped us
> catch the problem I initially reported, it does seem worthwhile to add
> it. I have attached a patch that adds this assertion and also
> attempts to fix
On 2020/05/27 15:11, Michael Paquier wrote:
On Wed, May 27, 2020 at 10:46:27AM +0900, Kyotaro Horiguchi wrote:
Agreed. It should be a leftover at the time the unit was changed
(before committed) to MB from bytes. The default value makes the
confusion worse.
Is the following works?
At Tue, 26 May 2020 22:56:39 -0400, Isaac Morland
wrote in
> On Tue, 26 May 2020 at 21:46, Kyotaro Horiguchi
> wrote:
>
> > At Tue, 26 May 2020 09:10:40 -0400, Jeff Janes
> > wrote in
> > > In postgresql.conf, it says:
> > >
> > > #max_slot_wal_keep_size = -1 # measured in bytes; -1
On 2020-05-27 08:00, Michael Paquier wrote:
On Tue, May 26, 2020 at 10:25:25AM +0200, Peter Eisentraut wrote:
Yeah, I was too enthusiastic about removing that. Here is a better patch.
+as an MD5 hash. (on is also accepted, as an alias
+for md5.) The default is
+
On Wed, May 27, 2020 at 10:46:27AM +0900, Kyotaro Horiguchi wrote:
> Agreed. It should be a leftover at the time the unit was changed
> (before committed) to MB from bytes. The default value makes the
> confusion worse.
>
> Is the following works?
>
> #max_slot_wal_keep_size = -1 # in MB; -1
On Wed, May 27, 2020 at 12:29:39AM -0500, Jaime Casanova wrote:
> so, currently the patch just installs protections on both currtid_*
> functions and adds some tests... therefore we can consider it as a bug
> fix and let it go in 13? actually also backpatch in 12...
Yes, and it has the advantage
On Tue, May 26, 2020 at 10:25:25AM +0200, Peter Eisentraut wrote:
> Yeah, I was too enthusiastic about removing that. Here is a better patch.
+as an MD5 hash. (on is also accepted, as an alias
+for md5.) The default is
+scram-sha-256.
Shouldn't password_encryption =
57 matches
Mail list logo
