Extending a bit string

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

Re: minor fix for acquire_inherited_sample_rows

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()

Re: minor fix for acquire_inherited_sample_rows

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.

Re: minor fix for acquire_inherited_sample_rows

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.

community bonding

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

Re: wal_consistency_checking reports an inconsistency on master branch

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

Re: Searching for: Fast windows buildfarm animal

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

Re: Toast issues with OldestXmin going backwards

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 >

Re: [patch] BUG #15005: ANALYZE can make pg_class.reltuples inaccurate.

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

Re: Reopen logfile on SIGHUP

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

Re: Should we add GUCs to allow partition pruning to be disabled?

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

Re: [HACKERS] Runtime Partition Pruning

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/

Re: Built-in connection pooling

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

Re: Built-in connection pooling

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

Re: Boolean partitions syntax

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

Re: Built-in connection pooling

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

Re: Problem while setting the fpw with SIGHUP

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

Re: Corrupted btree index on HEAD because of covering indexes

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

Re: [patch] BUG #15005: ANALYZE can make pg_class.reltuples inaccurate.

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.

Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS

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

Re: Built-in connection pooling

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

Re: perltidy version

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

Re: Make description of heap records more talkative for flags

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. > > >

Re: "could not reattach to shared memory" on buildfarm member dory

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

Re: Boolean partitions syntax

> 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

Re: [HACKERS] Clock with Adaptive Replacement

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: > >

Re: bms_prev_member won't work correctly if bitmapword is 64-bits

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

Re: Should we add GUCs to allow partition pruning to be disabled?

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

"could not reattach to shared memory" on buildfarm member dory

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

Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS

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 >

Re: Boolean partitions syntax

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.

Re: Built-in connection pooling

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

Re: [HACKERS] Custom compression methods

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

Re: Built-in connection pooling

> 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

Re: documentation is now XML

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

Re: perltidy version

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

Re: [HACKERS] Custom compression methods

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

Re: Problem while setting the fpw with SIGHUP

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

Re: Make description of heap records more talkative for flags

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

Re: perltidy version

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

Re: perltidy version

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

Re: Make description of heap records more talkative for flags

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

Re: Build fails with different versions of clang and LLVM

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

Re: Make description of heap records more talkative for flags

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

Re: Build fails with different versions of clang and LLVM

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 >

Re: Build fails with different versions of clang and LLVM

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

Re: [HACKERS] Custom compression methods

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

Re: Build fails with different versions of clang and LLVM

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.

Re: Oddity in tuple routing for foreign partitions

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

Re: minor fix for acquire_inherited_sample_rows

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

Re: minor fix for CloneRowTriggersToPartition

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

Re: bms_prev_member won't work correctly if bitmapword is 64-bits

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

Re: wal_consistency_checking reports an inconsistency on master branch

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

Re: JIT flag definitions not parenthesized

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

Re: [HACKERS] port of INSTALL file generation to XSLT

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

Re: Is a modern build system acceptable for older platforms

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

Re: psql leaks memory on query cancellation

> > 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

Re: minor fix for acquire_inherited_sample_rows

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

Re: Corrupted btree index on HEAD because of covering indexes

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

Re: minor fix for acquire_inherited_sample_rows

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

lingering references to V0 calling convention

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

Re: wal_consistency_checking reports an inconsistency on master branch

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,

minor fix for acquire_inherited_sample_rows

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

Re: documentation is now XML

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

minor fix for CloneRowTriggersToPartition

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

Re: [HACKERS] Custom compression methods

On 22.04.2018 16:21, Alexander Korotkov wrote: On Fri, Apr 20, 2018 at 7:45 PM, Konstantin Knizhnik > wrote: On 30.03.2018 19:50, Ildus Kurbangaliev wrote: On Mon, 26 Mar 2018 20:38:25 +0300 Ildus Kurbangaliev

Re: [HACKERS] Custom compression methods

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

Re: BGWORKER_BYPASS_ALLOWCONN used nowhere (infra part of on-line checksum switcher)

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

Re: JIT flag definitions not parenthesized

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.

Re: Build fails with different versions of clang and LLVM

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

Build fails with different versions of clang and LLVM

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

Re: BGWORKER_BYPASS_ALLOWCONN used nowhere (infra part of on-line checksum switcher)

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

Re: Toast issues with OldestXmin going backwards

> "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

Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least 9.5)?

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

Re: BGWORKER_BYPASS_ALLOWCONN used nowhere (infra part of on-line checksum switcher)

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