вт, 24 апр. 2018 г., 8:04 Andrey Borodin :
> Hi, Thomas!
>
> > 24 апр. 2018 г., в 2:41, Thomas Munro
> написал(а):
> >
> > On Fri, Feb 12, 2016 at 10:02 AM, Konstantin Knizhnik
> > wrote:
> >> Are there some well known drawbacks of this approach or it will be
> >> interesting to adopt this algor
On 24. 04. 2018 06:22, Charles Cui wrote:
> Hi PostgreSQL community and mentors:
>
> Thanks for selecting my project as one of GSoC student projects!
> Pretty exciting and honor to join the development for PostgreSQL (the
> best database in the world :)). So for the first phase of this project
> (
Currently the behavior of bit-string extensions is pretty insane.
SELECT b'01'::bit(2)::bit(4),
b'01'::bit(2)::int::bit(4);
bit | bit
--+--
0100 | 0001
(1 row)
I'd like propose we standardize this a bit. Previously, in version 8
compatibility was broke. From the Version 8 release not
Hi, Thomas!
> 24 апр. 2018 г., в 2:41, Thomas Munro
> написал(а):
>
> On Fri, Feb 12, 2016 at 10:02 AM, Konstantin Knizhnik
> wrote:
>> Are there some well known drawbacks of this approach or it will be
>> interesting to adopt this algorithm to PostgreSQL and measure it impact om
>> performanc
On Mon, Apr 23, 2018 at 05:29:59PM -0700, Peter Geoghegan wrote:
> It looks like local partitioned indexes are a problem for pageinspect:
>
> pg@regression[28736]=# select bt_metap('at_partitioned_b_idx');
> ERROR: relation "at_partitioned_b_idx" is not a btree index
Okay, I can see the point yo
On 2018/04/24 13:29, Ashutosh Bapat wrote:
> On Mon, Apr 23, 2018 at 6:45 PM, Amit Langote wrote:
>> On Mon, Apr 23, 2018 at 8:25 PM, Ashutosh Bapat wrote:
>>> On Mon, Apr 23, 2018 at 3:44 PM, Amit Langote wrote:
Hi.
acquire_inherited_sample_rows() currently uses equalTupleDescs() b
On Mon, Apr 23, 2018 at 8:46 PM, Alvaro Herrera wrote:
> Hello Amit
>
> Amit Langote wrote:
>
>> acquire_inherited_sample_rows() currently uses equalTupleDescs() being
>> false as the condition for going to tupconv.c to determine whether tuple
>> conversion is needed. But equalTupleDescs() will a
On Mon, Apr 23, 2018 at 6:45 PM, Amit Langote wrote:
> Thanks for the review.
>
> On Mon, Apr 23, 2018 at 8:25 PM, Ashutosh Bapat
> wrote:
>> On Mon, Apr 23, 2018 at 3:44 PM, Amit Langote
>> wrote:
>>> Hi.
>>>
>>> acquire_inherited_sample_rows() currently uses equalTupleDescs() being
>>> false a
Hi PostgreSQL community and mentors:
Thanks for selecting my project as one of GSoC student projects! Pretty
exciting and honor to join the development for PostgreSQL (the best
database in the world :)). So for the first phase of this project
(community bonding), I am planning to go ahead to set u
On Mon, Apr 23, 2018 at 07:58:30AM -0700, Andres Freund wrote:
> On 2018-04-23 13:22:21 +0300, Heikki Linnakangas wrote:
>> Why does HeapTupleHeaderSetMovedPartitions() leave the offset number
>> unchanged? The old offset number is meaningless without the block number.
>> Also, bits and magic value
On 2018-04-20 19:55:26 -0400, Stephen Frost wrote:
> Greetings,
>
> * Andres Freund (and...@anarazel.de) wrote:
> > It's common that half the buildfarm has reported back before a single
> > windows buildfarm animal reports. And if they report a failure one often
> > has to wait for hours for the n
On Mon, Apr 23, 2018 at 1:34 PM, Andrew Gierth
wrote:
>> "Amit" == Amit Kapila writes:
>
> >> Your patch would actually be needed if (and only if) autovacuum was
> >> changed back to its old behavior of never vacuuming toast tables
> >> independently, and if manual VACUUM pg_toast.*; was d
On Mon, 23 Apr 2018 20:09:21 -0500
Justin Pryzby wrote:
> Just want to add for the archive that I happened to run across what appears to
> be a 7-year old report of (I think) both of these vacuum/analyze bugs:
>
> Re: [patch] BUG #15005: ANALYZE can make pg_class.reltuples inaccurate.
>
At Fri, 20 Apr 2018 21:51:49 +0300, Alexander Kuzmenkov
wrote in
> On 04/16/2018 05:54 AM, Kyotaro HORIGUCHI wrote:
> > We can provide a new command "pg_ctl logrotate" to hide the
> > details. (It cannot be executed by root, though.)
>
> I like this approach.
Thanks. I found that the SIGUSR1
On 2018/04/24 6:10, Alvaro Herrera wrote:
>> BTW, while we're at it, would it also be a good idea to consider the patch
>> you had proposed, which I then posted an updated version of, to adjust the
>> documentation in ddl.sgml (in the section 5.10. Table Partitioning)
>> regarding the relationship
Anybody wanna argue against pushing this patch now? I'm inclined to
push it on the grounds of being closure for already committed work, but
there are possible arguments about this being new development after
feature freeze.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL
On Mon, Apr 23, 2018 at 09:53:37PM -0400, Bruce Momjian wrote:
> On Mon, Apr 23, 2018 at 09:47:07PM -0400, Robert Haas wrote:
> > On Mon, Apr 23, 2018 at 7:59 PM, Bruce Momjian wrote:
> > > So, instead of trying to multiplex multiple sessions in a single
> > > operating system process, why don't w
On Mon, Apr 23, 2018 at 09:47:07PM -0400, Robert Haas wrote:
> On Mon, Apr 23, 2018 at 7:59 PM, Bruce Momjian wrote:
> > So, instead of trying to multiplex multiple sessions in a single
> > operating system process, why don't we try to reduce the overhead of
> > idle sessions that each have an ope
At Tue, 24 Apr 2018 09:23:03 +0900, Amit Langote
wrote in
> On 2018/04/24 4:33, Tom Lane wrote:
> > Amit Langote writes:
> >> On 2018/04/22 2:29, Tom Lane wrote:
> >>> I propose the attached slightly-less-invasive version of Amit's original
> >>> patch as what we should do in v10 and v11, and
On Mon, Apr 23, 2018 at 7:59 PM, Bruce Momjian wrote:
> So, instead of trying to multiplex multiple sessions in a single
> operating system process, why don't we try to reduce the overhead of
> idle sessions that each have an operating system process? We already
> use procArray to reduce the numb
At Tue, 24 Apr 2018 08:52:17 +0900, Michael Paquier wrote
in <20180423235217.gb1...@paquier.xyz>
> On Mon, Apr 23, 2018 at 12:21:04PM -0400, Robert Haas wrote:
> > Fine, but that doesn't answer the question of whether we actually need
> > to or should change the behavior in the first place.
>
>
On Sat, Apr 21, 2018 at 6:02 PM, Peter Geoghegan wrote:
> I refined the amcheck enhancement quite a bit today. It will not just
> check that a downlink is not missing; It will also confirm that it
> wasn't a legitimately interrupted multi-level deletion, by descending
> to the leaf page to match t
On 2018/04/15 11:58, Amit Langote wrote:
> On Sun, Apr 15, 2018 at 11:57 AM, Amit Langote
> wrote:
>> On Sun, Apr 15, 2018 at 9:17 AM, Alvaro Herrera
>> wrote:
>>> Thanks! I pushed this now, putting back the enum in parsenodes and
>>> including this delta patch of yours.
>>
>> Thank you. Do y
Just want to add for the archive that I happened to run across what appears to
be a 7-year old report of (I think) both of these vacuum/analyze bugs:
Re: [patch] BUG #15005: ANALYZE can make pg_class.reltuples inaccurate.
It looks like local partitioned indexes are a problem for pageinspect:
pg@regression[28736]=# select bt_metap('at_partitioned_b_idx');
ERROR: relation "at_partitioned_b_idx" is not a btree index
I gather that pageinspect simply didn't get the memo about the new
RELKIND_PARTITIONED_INDEX "placeho
On 2018/04/24 4:33, Tom Lane wrote:
> Amit Langote writes:
>> On 2018/04/22 2:29, Tom Lane wrote:
>>> I propose the attached slightly-less-invasive version of Amit's original
>>> patch as what we should do in v10 and v11, and push the patch currently
>>> under discussion out to v12.
>
>> Here too
On Mon, Apr 23, 2018 at 01:14:48PM -0700, Andres Freund wrote:
> Hi,
>
> On 2018-03-28 10:23:46 +0800, Craig Ringer wrote:
> > TL;DR: Pg should PANIC on fsync() EIO return. Retrying fsync() is not OK at
> > least on Linux. When fsync() returns success it means "all writes since the
> > last fsync
On Fri, Apr 20, 2018 at 11:40:59AM +0300, Konstantin Knizhnik wrote:
>
> Sorry, may we do not understand each other.
> There are the following facts:
> 1. There are some entities in Postgres which are local to a backend:
> temporary tables, GUCs, prepared statement, relation and catalog caches,...
On Mon, Apr 23, 2018 at 12:40:00PM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
>> I still vote we use 20170521 which is recent enough that we won't have
>> to change it in a few years.
That's the version available on Debian sid, so from the prospective of
any Debian user this is a handy versi
On Mon, Apr 23, 2018 at 12:21:04PM -0400, Robert Haas wrote:
> Fine, but that doesn't answer the question of whether we actually need
> to or should change the behavior in the first place.
Per the last arguments that would be "No, we don't want to change it as
it would surprise some users":
https:
On Mon, Apr 23, 2018 at 01:02:16PM -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > On 2018-04-23 12:37:20 -0300, Alvaro Herrera wrote:
> > > Me too. Should we consider this for pg11? My vote is yes, with no
> > > backpatch (might break scripts reading pg_{wal,xlog}dump output.
> > > Thoug
On Tue, Apr 24, 2018 at 11:18 AM, Stephen Frost wrote:
> Greetings,
>
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> So far, dory has failed three times with essentially identical symptoms:
>>
>> 2018-04-23 19:57:10.624 GMT [2240] FATAL: could not reattach to shared
>> memory (key=0190,
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> So far, dory has failed three times with essentially identical symptoms:
>
> 2018-04-23 19:57:10.624 GMT [2240] FATAL: could not reattach to shared
> memory (key=0190, addr=018E): error code 487
> 2018-04-23 15:57:10.65
> On Apr 23, 2018, at 12:33 PM, Tom Lane wrote:
>
> Amit Langote writes:
>> On 2018/04/22 2:29, Tom Lane wrote:
>>> I propose the attached slightly-less-invasive version of Amit's original
>>> patch as what we should do in v10 and v11, and push the patch currently
>>> under discussion out to v1
On Fri, Feb 12, 2016 at 10:02 AM, Konstantin Knizhnik
wrote:
> Hi hackers,
>
> What do you think about improving cache replacement clock-sweep algorithm in
> PostgreSQL with adaptive version proposed in this article:
>
> http://www-cs.stanford.edu/~sbansal/pubs/fast04.pdf
>
> Are there some we
On 24 April 2018 at 03:00, Teodor Sigaev wrote:
> Thank you, pushed
Thanks!
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Hi,
I just pushed David patch, with some pretty minor changes. I hope not
to have broken anything.
Amit Langote wrote:
> Your proposed changes to inheritance_planner() look fine to me. In the
> comment added by the patch in relation_excluded_by_constraints():
>
> + /*
> + * When constraint_ex
So far, dory has failed three times with essentially identical symptoms:
2018-04-23 19:57:10.624 GMT [2240] FATAL: could not reattach to shared memory
(key=0190, addr=018E): error code 487
2018-04-23 15:57:10.657 EDT [8836] ERROR: lost connection to parallel worker
2018-
On Wed, Apr 18, 2018 at 9:41 AM, Heikki Linnakangas wrote:
>> Well, may be I missed something, but i do not know how to efficiently
>> support
>> 1. Temporary tables
>> 2. Prepared statements
>> 3. Sessoin GUCs
>> with any external connection pooler (with pooling level other than
>> session).
>
>
Hi,
On 2018-03-28 10:23:46 +0800, Craig Ringer wrote:
> TL;DR: Pg should PANIC on fsync() EIO return. Retrying fsync() is not OK at
> least on Linux. When fsync() returns success it means "all writes since the
> last fsync have hit disk" but we assume it means "all writes since the last
> SUCCESSF
Amit Langote writes:
> On 2018/04/22 2:29, Tom Lane wrote:
>> I propose the attached slightly-less-invasive version of Amit's original
>> patch as what we should do in v10 and v11, and push the patch currently
>> under discussion out to v12.
> Here too.
Pushed. It occurred to me at the last mom
On Fri, Jan 19, 2018 at 11:59 AM, Tomas Vondra
wrote:
> Hmmm, that's unfortunate. I guess you'll have process the startup packet
> in the main process, before it gets forked. At least partially.
I'm not keen on a design that would involve doing more stuff in the
postmaster, because that would inc
On Mon, 23 Apr 2018 19:34:38 +0300
Konstantin Knizhnik wrote:
> >
> Sorry, I really looking at this patch under the different angle.
> And this is why I have some doubts about general idea.
> Postgres allows to defined custom types, access methods,...
> But do you know any production system usi
> 19 апр. 2018 г., в 23:59, Andres Freund написал(а):
>
> I think there's plenty things that don't really make sense solving
> outside of postgres:
> - additional added hop / context switches due to external pooler
> - temporary tables
> - prepared statements
> - GUCs and other session state
+
On Mon, Apr 23, 2018 at 12:54:40PM +0300, Liudmila Mantrova wrote:
> Hi everyone,
>
> Reading this thread, I got an impression that everyone would benefit from
> converting back branches to XML, but the main concern is lack of resources to
> complete this task. Are there any other issues that affe
Alvaro Herrera writes:
> Peter Eisentraut wrote:
>> Did we decide on this?
> No agreement yet apparently :-)
> I still vote we use 20170521 which is recent enough that we won't have
> to change it in a few years.
> I further vote that we change the URL in pgindent/README from
> sourceforge to m
On 23.04.2018 18:32, Alexander Korotkov wrote:
But that the main goal of this patch: let somebody implement own
compression
algorithm which best fit for particular dataset.
Hmmm...Frankly speaking I don't believe in this "somebody".
From my point of view the main value of this patch i
On Wed, Apr 18, 2018 at 9:49 PM, Michael Paquier wrote:
> On Wed, Apr 18, 2018 at 10:52:51AM -0400, Robert Haas wrote:
>> I would just document the risks. If the documentation says that you
>> can't rely on the value until after the next checkpoint, or whatever
>> the rule is, then I think we're
Hello
Andres Freund wrote:
> On 2018-04-23 12:37:20 -0300, Alvaro Herrera wrote:
> > Michael Paquier wrote:
> > > On Thu, Apr 12, 2018 at 08:49:03PM -0700, Andres Freund wrote:
> > > > OTOH, that also kinda bloats the output noticeably... I'm
> > > > somewhat inclined to just put the hex value or
Peter Eisentraut wrote:
> On 3/5/18 09:02, Magnus Hagander wrote:
> > I think we should just pick some recent one and use it for X years; use
> > that one for all backbranches. I propose X=3. I propose 20170521
> > (newer ones seem to cater for stuff that I think we mostly don't use).
On 3/5/18 09:02, Magnus Hagander wrote:
> I think we should just pick some recent one and use it for X years; use
> that one for all backbranches. I propose X=3. I propose 20170521
> (newer ones seem to cater for stuff that I think we mostly don't use).
>
>
> 20140328 seems to cover
Hi,
On 2018-04-23 12:37:20 -0300, Alvaro Herrera wrote:
> Michael Paquier wrote:
> > On Thu, Apr 12, 2018 at 08:49:03PM -0700, Andres Freund wrote:
> > > OTOH, that also kinda bloats the output noticeably... I'm somewhat
> > > inclined to just put the hex value or such there?
> >
> > That would d
On 23/04/18 18:35, Andres Freund wrote:
Hi,
On 2018-04-23 18:33:30 +0300, Heikki Linnakangas wrote:
To add to the story: I installed clang 3.9, but I still got the same error.
I now had both clang 3.8 and 3.9 installed, but /usr/bin/clang still pointed
to clang-3.8, so autoconf still picked tha
Michael Paquier wrote:
> On Thu, Apr 12, 2018 at 08:49:03PM -0700, Andres Freund wrote:
> > OTOH, that also kinda bloats the output noticeably... I'm somewhat
> > inclined to just put the hex value or such there?
>
> That would do as well for me.
Me too. Should we consider this for pg11? My vot
Hi,
On 2018-04-23 18:33:30 +0300, Heikki Linnakangas wrote:
> To add to the story: I installed clang 3.9, but I still got the same error.
> I now had both clang 3.8 and 3.9 installed, but /usr/bin/clang still pointed
> to clang-3.8, so autoconf still picked that up. Only after removing
> clang-3.8
On 23/04/18 18:28, Andres Freund wrote:
Hi,
On 2018-04-23 04:33:04 -0400, Heikki Linnakangas wrote:
So, I have LLVM 3.9 installed, but no clang 3.9. Only clang 3.8.
Any specific reason, or just happenstance?
Just happenstance. I had clang and llvm 3.8 installed previously. But
PostgreSQL n
On Mon, Apr 23, 2018 at 12:40 PM, Konstantin Knizhnik <
k.knizh...@postgrespro.ru> wrote:
> On 22.04.2018 16:21, Alexander Korotkov wrote:
>
> On Fri, Apr 20, 2018 at 7:45 PM, Konstantin Knizhnik <
> k.knizh...@postgrespro.ru> wrote:
>
>> On 30.03.2018 19:50, Ildus Kurbangaliev wrote:
>>
>>> On Mo
Hi,
On 2018-04-23 04:33:04 -0400, Heikki Linnakangas wrote:
> So, I have LLVM 3.9 installed, but no clang 3.9. Only clang 3.8.
Any specific reason, or just happenstance?
> Googling around, the LLVM bitcode format is supposed to be compatible across
> versions, but I'm not sure I trust that. Per
Robert, I think this is your turf, per 3d956d9562aa. Are you looking
into it?
Thanks,
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hello Amit
Amit Langote wrote:
> acquire_inherited_sample_rows() currently uses equalTupleDescs() being
> false as the condition for going to tupconv.c to determine whether tuple
> conversion is needed. But equalTupleDescs() will always return false if
> it's passed TupleDesc's of two different
Amit Langote wrote:
> Hi.
>
> I think we should apply the attached patch so that a CreateTriggerStmt
> that CloneRowTriggersToPartition creates for a partition doesn't contain
> pointers that point to the information in the parent table's relcache,
> which may go stale before the pointers in quest
Thank you, pushed
David Rowley wrote:
bms_prev_member mistakenly has a hardcoded 24 in the function. This
should really be BITS_PER_BITMAPWORD - 8 so that it is properly set to
56 if someone compiles with 64-bit bitmapwords.
The attached fixes this and also adds a test to exercise the function
On 2018-04-23 13:22:21 +0300, Heikki Linnakangas wrote:
> On 13/04/18 13:08, Michael Paquier wrote:
> > On Fri, Apr 13, 2018 at 02:15:35PM +0530, amul sul wrote:
> > > I have looked into this and found that the issue is in heap_xlog_delete
> > > -- we
> > > have missed to set the correct offset nu
Hi,
On 2018-04-23 04:49:17 -0400, Heikki Linnakangas wrote:
> On 22/04/18 23:21, David Rowley wrote:
> > Patch attached.
>
> Fixed, thanks!
Thanks David, Heikki.
- Andres
On 2/27/17 10:55, Peter Eisentraut wrote:
> It appears we need pandoc 1.13 to get the good output. This won't be
> available until Debian stretch.
I understand that borka is updated to stretch now. So we could give
this another try. Updated patch attached.
--
Peter Eisentraut htt
On Thu, Apr 19, 2018 at 10:16 AM, Tom Lane wrote:
> The other side of that argument is that allowing a build system we haven't
> even adopted yet to dictate which platforms we can support is definitely
> letting the tail wag the dog.
>
> My gut reaction to Catalin's list is that requiring C+11 is
>
> Therefore, I propose the attached patch, which simply sees to it that
> we discard any partial query result at the start of error message
> collection not the end. This makes the behavior very much better,
> at least on Linux.
>
I have tested the build of Postgres with attached patch and conf
Thanks for the review.
On Mon, Apr 23, 2018 at 8:25 PM, Ashutosh Bapat
wrote:
> On Mon, Apr 23, 2018 at 3:44 PM, Amit Langote
> wrote:
>> Hi.
>>
>> acquire_inherited_sample_rows() currently uses equalTupleDescs() being
>> false as the condition for going to tupconv.c to determine whether tuple
>
Thank you, pushed
I see your point. Maybe don't have the newline between the get and
set, though, to match the existing style. And, the note about the
assertion seems unnecessary.
Removed newline and note
"Get/set leaf page highkey's link. During the second phase of
deletion, the target leaf
On Mon, Apr 23, 2018 at 3:44 PM, Amit Langote
wrote:
> Hi.
>
> acquire_inherited_sample_rows() currently uses equalTupleDescs() being
> false as the condition for going to tupconv.c to determine whether tuple
> conversion is needed. But equalTupleDescs() will always return false if
> it's passed
I noticed one in the SPI docs and tried to look for more. The attached
patch is an attempt at removing the remaining references. The original
SPI example returned a uint64 as a signed int8 SQL type, so I'm not
sure if I handled that correctly.
However, I didn't touch the documentation of the confi
On 13/04/18 13:08, Michael Paquier wrote:
On Fri, Apr 13, 2018 at 02:15:35PM +0530, amul sul wrote:
I have looked into this and found that the issue is in heap_xlog_delete -- we
have missed to set the correct offset number from the target_tid when
XLH_DELETE_IS_PARTITION_MOVE flag is set.
Oh,
Hi.
acquire_inherited_sample_rows() currently uses equalTupleDescs() being
false as the condition for going to tupconv.c to determine whether tuple
conversion is needed. But equalTupleDescs() will always return false if
it's passed TupleDesc's of two different tables, which is the most common
cas
Hi everyone,
Reading this thread, I got an impression that everyone would benefit
from converting back branches to XML, but the main concern is lack of
resources to complete this task. Are there any other issues that affect
this decision? Looks like Aleksander Lakhin's offer to prepare patches
Hi.
I think we should apply the attached patch so that a CreateTriggerStmt
that CloneRowTriggersToPartition creates for a partition doesn't contain
pointers that point to the information in the parent table's relcache,
which may go stale before the pointers in question are used.
Thanks,
Amit
diff
On 22.04.2018 16:21, Alexander Korotkov wrote:
On Fri, Apr 20, 2018 at 7:45 PM, Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> wrote:
On 30.03.2018 19:50, Ildus Kurbangaliev wrote:
On Mon, 26 Mar 2018 20:38:25 +0300
Ildus Kurbangaliev mailto:i.kurbangal...@postgre
On Sun, 22 Apr 2018 16:21:31 +0300
Alexander Korotkov wrote:
> On Fri, Apr 20, 2018 at 7:45 PM, Konstantin Knizhnik <
> k.knizh...@postgrespro.ru> wrote:
>
> > On 30.03.2018 19:50, Ildus Kurbangaliev wrote:
> >
> >> On Mon, 26 Mar 2018 20:38:25 +0300
> >> Ildus Kurbangaliev wrote:
> >>
> >>
On Mon, Apr 23, 2018 at 10:31:43AM +0200, Magnus Hagander wrote:
> Yeah, that makes sense. Will add as well.
Thanks for the addition!
--
Michael
signature.asc
Description: PGP signature
On 22/04/18 23:21, David Rowley wrote:
Looks like the JIT flags definitions are not properly parenthesized.
It might not matter too much for their current usage, but it might
save a bit of confusion later.
git grep "^#define .*<<.*[^)]$" indicates these are the only offenders.
Patch attached.
On Monday, April 23, 2018 10:33:04 AM CEST Heikki Linnakangas wrote:
> Hi!
>
> I tried compiling with --with-llvm on my laptop, and got this:
> > $ make -s
> > All of PostgreSQL successfully made. Ready to install.
> > $ make -s install
> > Invalid Summary Block: version expected
> > error: can't
Hi!
I tried compiling with --with-llvm on my laptop, and got this:
$ make -s
All of PostgreSQL successfully made. Ready to install.
$ make -s install
Invalid Summary Block: version expected
error: can't create ModuleSummaryIndexObjectFile for buffer: Corrupted bitcode
#0 0x7fbe98032085 llv
On Mon, Apr 23, 2018 at 9:25 AM, Michael Paquier
wrote:
> On Sun, Apr 22, 2018 at 03:56:32PM +0200, Daniel Gustafsson wrote:
> > +1, I think this is worth keeping in for 11.
>
> Okay, that's fine for me. Thanks for updating the documentation.
> Perhaps it would be nicer for plugin developers to
> "Amit" == Amit Kapila writes:
>> Your patch would actually be needed if (and only if) autovacuum was
>> changed back to its old behavior of never vacuuming toast tables
>> independently, and if manual VACUUM pg_toast.*; was disabled. But in
>> the presence of either of those two possibi
On 18/01/18 20:54, Kyotaro HORIGUCHI wrote:
At Thu, 18 Jan 2018 11:52:52 -0800, Andres Freund wrote in
<20180118195252.hyxgkb3krcqjz...@alap3.anarazel.de>
On 2018-01-18 20:58:27 +0900, Michael Paquier wrote:
b) The second patch that I would like to mention is doing things on the
standby side
On Sun, Apr 22, 2018 at 03:56:32PM +0200, Daniel Gustafsson wrote:
> +1, I think this is worth keeping in for 11.
Okay, that's fine for me. Thanks for updating the documentation.
Perhaps it would be nicer for plugin developers to add a comment in
bgworker.h as well about what BGWORKER_BYPASS_ALLO
85 matches
Mail list logo
