Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On Thu, Apr 27, 2017 at 4:01 AM, Tom Lane wrote: > Jeff Janes writes: > > This gives me compiler warning: > > launcher.c: In function 'logicalrep_worker_launch': > > launcher.c:257: warning: 'slot' may be used uninitialized in this > function > > Yeah,

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

Jeff Janes writes: > This gives me compiler warning: > launcher.c: In function 'logicalrep_worker_launch': > launcher.c:257: warning: 'slot' may be used uninitialized in this function Yeah, me too. Fix pushed. regards, tom lane -- Sent via

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On Wed, Apr 26, 2017 at 8:00 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 4/25/17 15:42, Petr Jelinek wrote: > >> Here is the patch doing just that. > > > > And one more revision which also checks in_use when attaching shared > > memory. This is mainly to improve the user

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On 4/25/17 15:42, Petr Jelinek wrote: >> Here is the patch doing just that. > > And one more revision which also checks in_use when attaching shared > memory. This is mainly to improve the user visible behavior in > theoretical corner case when the worker is supposed to be cleaned up but >

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On 22/04/17 22:09, Petr Jelinek wrote: > On 21/04/17 16:31, Petr Jelinek wrote: >> On 21/04/17 16:23, Peter Eisentraut wrote: >>> On 4/21/17 10:11, Petr Jelinek wrote: On 21/04/17 16:09, Peter Eisentraut wrote: > On 4/20/17 14:29, Petr Jelinek wrote: >> +/* Find unused

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On 21/04/17 16:31, Petr Jelinek wrote: > On 21/04/17 16:23, Peter Eisentraut wrote: >> On 4/21/17 10:11, Petr Jelinek wrote: >>> On 21/04/17 16:09, Peter Eisentraut wrote: On 4/20/17 14:29, Petr Jelinek wrote: > + /* Find unused worker slot. */ > + if (!w->in_use)

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On 21/04/17 16:23, Peter Eisentraut wrote: > On 4/21/17 10:11, Petr Jelinek wrote: >> On 21/04/17 16:09, Peter Eisentraut wrote: >>> On 4/20/17 14:29, Petr Jelinek wrote: + /* Find unused worker slot. */ + if (!w->in_use) { - worker

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On 4/21/17 10:11, Petr Jelinek wrote: > On 21/04/17 16:09, Peter Eisentraut wrote: >> On 4/20/17 14:29, Petr Jelinek wrote: >>> + /* Find unused worker slot. */ >>> + if (!w->in_use) >>> { >>> - worker = >workers[slot]; >>> -

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On 21/04/17 16:09, Peter Eisentraut wrote: > On 4/20/17 14:29, Petr Jelinek wrote: >> +/* Find unused worker slot. */ >> +if (!w->in_use) >> { >> -worker = >workers[slot]; >> -break; >> +worker = w; >>

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On 4/20/17 22:24, Noah Misch wrote: > On Mon, Apr 17, 2017 at 02:09:54PM -0400, Peter Eisentraut wrote: >> I think we're not really sure yet what to do about this. Discussion is >> ongoing. I'll report back on Wednesday. > > This PostgreSQL 10 open item is past due for your status update, and

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On 4/20/17 14:29, Petr Jelinek wrote: > + /* Find unused worker slot. */ > + if (!w->in_use) > { > - worker = >workers[slot]; > - break; > + worker = w; > + slot = i; > +

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On Mon, Apr 17, 2017 at 02:09:54PM -0400, Peter Eisentraut wrote: > I think we're not really sure yet what to do about this. Discussion is > ongoing. I'll report back on Wednesday. This PostgreSQL 10 open item is past due for your status update, and this is overall the seventh time you have you

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On 20/04/17 18:58, Peter Eisentraut wrote: > On 4/18/17 22:13, Petr Jelinek wrote: >> So my idea was to add some kind of inuse flag. This turned out to be bit >> more complicated in terms of how to clean it than I would have hoped. >> This is due to the fact that there is no way to reliably tell

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On 4/18/17 22:13, Petr Jelinek wrote: > So my idea was to add some kind of inuse flag. This turned out to be bit > more complicated in terms of how to clean it than I would have hoped. > This is due to the fact that there is no way to reliably tell if worker > has failed to start if the parent

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On 17/04/17 20:09, Peter Eisentraut wrote: > On 4/16/17 22:01, Noah Misch wrote: >> This PostgreSQL 10 open item is past due for your status update. Kindly send >> a status update within 24 hours, and include a date for your subsequent >> status >> update. Refer to the policy on open item

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On 4/16/17 22:01, Noah Misch wrote: > This PostgreSQL 10 open item is past due for your status update. Kindly send > a status update within 24 hours, and include a date for your subsequent status > update. Refer to the policy on open item ownership: >

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On Thu, Apr 13, 2017 at 04:56:05AM +, Noah Misch wrote: > On Tue, Apr 11, 2017 at 02:28:44AM +0900, Fujii Masao wrote: > > src/backend/replication/logical/launcher.c > > * Worker started and attached to our shmem. This check is safe > > * because only launcher ever

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On 16/04/17 21:27, Steve Singer wrote: > On 04/10/2017 01:28 PM, Fujii Masao wrote: >> Hi, >> >> src/backend/replication/logical/launcher.c >> * Worker started and attached to our shmem. This check is safe >> * because only launcher ever starts the workers, so nobody

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On 04/10/2017 01:28 PM, Fujii Masao wrote: Hi, src/backend/replication/logical/launcher.c * Worker started and attached to our shmem. This check is safe * because only launcher ever starts the workers, so nobody can steal * the worker slot. The tablesync

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On 13/04/17 19:31, Fujii Masao wrote: > On Fri, Apr 14, 2017 at 1:28 AM, Peter Eisentraut > wrote: >> On 4/10/17 13:28, Fujii Masao wrote: >>> src/backend/replication/logical/launcher.c >>> * Worker started and attached to our shmem. This check

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On Fri, Apr 14, 2017 at 1:28 AM, Peter Eisentraut wrote: > On 4/10/17 13:28, Fujii Masao wrote: >> src/backend/replication/logical/launcher.c >> * Worker started and attached to our shmem. This check is safe >> * because only launcher

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On 4/10/17 13:28, Fujii Masao wrote: > src/backend/replication/logical/launcher.c > * Worker started and attached to our shmem. This check is safe > * because only launcher ever starts the workers, so nobody can steal > * the worker slot. > > The tablesync

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On Tue, Apr 11, 2017 at 02:28:44AM +0900, Fujii Masao wrote: > src/backend/replication/logical/launcher.c > * Worker started and attached to our shmem. This check is safe > * because only launcher ever starts the workers, so nobody can steal > * the worker slot.

[HACKERS] tablesync patch broke the assumption that logical rep depends on?

Hi, src/backend/replication/logical/launcher.c * Worker started and attached to our shmem. This check is safe * because only launcher ever starts the workers, so nobody can steal * the worker slot. The tablesync patch enabled even worker to start another