cannot drop replication slot if server is running in single-user mode

On Tue, Mar 6, 2018 at 06:59:33PM +0530, tushar wrote:

Hi,

I found that if server is running in single-user mode , there we can create
replication slot but cannot drop it .

backend> SELECT * FROM pg_create_physical_replication_slot('p');
2018-03-06 13:20:03.441 GMT [14869] LOG:� statement: SELECT * FROM
pg_create_physical_replication_slot('p');

��� �1: slot_name��� (typeid = 19, len = 64, typmod = -1, byval = f)
��� �2: lsn��� (typeid = 3220, len = 8, typmod = -1, byval = t)
��� ----
��� �1: slot_name = "p"��� (typeid = 19, len = 64, typmod = -1, byval = f)
��� ----
backend> select pg_drop_replication_slot('p');
2018-03-06 13:20:24.390 GMT [14869] LOG:� statement: select
pg_drop_replication_slot('p');

��� �1: pg_drop_replication_slot��� (typeid = 2278, len = 4, typmod = -1,
byval = t)
��� ----
2018-03-06 13:20:24.391 GMT [14869] ERROR:� epoll_ctl() failed: Bad file
descriptor
2018-03-06 13:20:24.391 GMT [14869] STATEMENT:� select
pg_drop_replication_slot('p');

I can confirm this bug exists in single-user mode.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

On 2018-03-29 17:42:57 -0400, Bruce Momjian wrote:

On Tue, Mar 6, 2018 at 06:59:33PM +0530, tushar wrote:

Hi,

I found that if server is running in single-user mode , there we can create
replication slot but cannot drop it .

backend> SELECT * FROM pg_create_physical_replication_slot('p');
2018-03-06 13:20:03.441 GMT [14869] LOG:� statement: SELECT * FROM
pg_create_physical_replication_slot('p');

��� �1: slot_name��� (typeid = 19, len = 64, typmod = -1, byval = f)
��� �2: lsn��� (typeid = 3220, len = 8, typmod = -1, byval = t)
��� ----
��� �1: slot_name = "p"��� (typeid = 19, len = 64, typmod = -1, byval = f)
��� ----
backend> select pg_drop_replication_slot('p');
2018-03-06 13:20:24.390 GMT [14869] LOG:� statement: select
pg_drop_replication_slot('p');

��� �1: pg_drop_replication_slot��� (typeid = 2278, len = 4, typmod = -1,
byval = t)
��� ----
2018-03-06 13:20:24.391 GMT [14869] ERROR:� epoll_ctl() failed: Bad file
descriptor
2018-03-06 13:20:24.391 GMT [14869] STATEMENT:� select
pg_drop_replication_slot('p');

I can confirm this bug exists in single-user mode.

I'm not sure we need to do anything about this, personally. This seems
like a fairly rare thing to do in a mode that's definitely not intended
to be general purpose.

Greetings,

Andres Freund

On Thu, Mar 29, 2018 at 02:51:24PM -0700, Andres Freund wrote:

On 2018-03-29 17:42:57 -0400, Bruce Momjian wrote:

On Tue, Mar 6, 2018 at 06:59:33PM +0530, tushar wrote:

Hi,

I found that if server is running in single-user mode , there we can create
replication slot but cannot drop it .

backend> SELECT * FROM pg_create_physical_replication_slot('p');
2018-03-06 13:20:03.441 GMT [14869] LOG:� statement: SELECT * FROM
pg_create_physical_replication_slot('p');

��� �1: slot_name��� (typeid = 19, len = 64, typmod = -1, byval = f)
��� �2: lsn��� (typeid = 3220, len = 8, typmod = -1, byval = t)
��� ----
��� �1: slot_name = "p"��� (typeid = 19, len = 64, typmod = -1, byval = f)
��� ----
backend> select pg_drop_replication_slot('p');
2018-03-06 13:20:24.390 GMT [14869] LOG:� statement: select
pg_drop_replication_slot('p');

��� �1: pg_drop_replication_slot��� (typeid = 2278, len = 4, typmod = -1,
byval = t)
��� ----
2018-03-06 13:20:24.391 GMT [14869] ERROR:� epoll_ctl() failed: Bad file
descriptor
2018-03-06 13:20:24.391 GMT [14869] STATEMENT:� select
pg_drop_replication_slot('p');

I can confirm this bug exists in single-user mode.

I'm not sure we need to do anything about this, personally. This seems
like a fairly rare thing to do in a mode that's definitely not intended
to be general purpose.

I think the question is whether this is exposing a bug or is expected
behavior.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

On 2018-03-29 21:07:36 -0400, Bruce Momjian wrote:

I think the question is whether this is exposing a bug or is expected
behavior.

It's unsurprising. Acquiring a slot uses a condition variable, which
uses latches to sleep. Latches don't work in single user mode. Boom.

Greetings,

Andres Freund

On Thu, Mar 29, 2018 at 06:09:28PM -0700, Andres Freund wrote:

On 2018-03-29 21:07:36 -0400, Bruce Momjian wrote:

I think the question is whether this is exposing a bug or is expected
behavior.

It's unsurprising. Acquiring a slot uses a condition variable, which
uses latches to sleep. Latches don't work in single user mode. Boom.

OK, thanks for confirming.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

On Thu, Mar 29, 2018 at 5:51 PM, Andres Freund <andres@anarazel.de> wrote:

2018-03-06 13:20:24.391 GMT [14869] ERROR: epoll_ctl() failed: Bad file
descriptor

I can confirm this bug exists in single-user mode.

I'm not sure we need to do anything about this, personally. This seems
like a fairly rare thing to do in a mode that's definitely not intended
to be general purpose.

Mmmph. I don't really think it's possible to view a user-visible
EBADF as anything other than a coding error.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Robert Haas <robertmhaas@gmail.com> writes:

On Thu, Mar 29, 2018 at 5:51 PM, Andres Freund <andres@anarazel.de> wrote:

I'm not sure we need to do anything about this, personally. This seems
like a fairly rare thing to do in a mode that's definitely not intended
to be general purpose.

Mmmph. I don't really think it's possible to view a user-visible
EBADF as anything other than a coding error.

If we think this is worth spending any code at all on, what I'd suggest
is to reject replication-related commands at some early stage if not
IsUnderPostmaster.

regards, tom lane

Robert Haas wrote:

On Thu, Mar 29, 2018 at 5:51 PM, Andres Freund <andres@anarazel.de> wrote:

2018-03-06 13:20:24.391 GMT [14869] ERROR: epoll_ctl() failed: Bad file
descriptor

I can confirm this bug exists in single-user mode.

I'm not sure we need to do anything about this, personally. This seems
like a fairly rare thing to do in a mode that's definitely not intended
to be general purpose.

Mmmph. I don't really think it's possible to view a user-visible
EBADF as anything other than a coding error.

IMO the problem is not the user-visible EBADF -- the problem is that the
user might be attempting to clean up from some previous mistake by
removing a replication slot. Using single-user mode might be a strange
tool, but it's not completely unreasonable. Is it really all that
difficult to fix slot acquisition for it?

I agree with Tom that for any other operation we can just reject it
early if not under postmaster, but dropping a slot seems a special case.

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Alvaro Herrera wrote:

Robert Haas wrote:

On Thu, Mar 29, 2018 at 5:51 PM, Andres Freund <andres@anarazel.de> wrote:

2018-03-06 13:20:24.391 GMT [14869] ERROR: epoll_ctl() failed: Bad file
descriptor

I can confirm this bug exists in single-user mode.

I'm not sure we need to do anything about this, personally. This seems
like a fairly rare thing to do in a mode that's definitely not intended
to be general purpose.

Mmmph. I don't really think it's possible to view a user-visible
EBADF as anything other than a coding error.

IMO the problem is not the user-visible EBADF -- the problem is that the
user might be attempting to clean up from some previous mistake by
removing a replication slot. Using single-user mode might be a strange
tool, but it's not completely unreasonable. Is it really all that
difficult to fix slot acquisition for it?

Here's a patch (against pg10) to fix this problem.

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services