Improve logical decoding error message (was wal_level > WAL_LEVEL_LOGICAL)
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t36760psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 28, 2026 at 06:39 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t36760_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t36760_1 && git checkout t36760_1Patchset v1 (message #1) is on t36760_1
On Mon, May 22, 2017 at 11:08 PM, Neha Khatri <nehakhatri5@gmail.com> wrote:
As per my understabding, current postgres server supports only three
values for wal_level i.e. 'minimal' , 'replica' or 'logical'. But
following error message brought to notice that there are various code
spots that try to look for wal_level >= WAL_LEVEL_LOGICAL:select * from pg_create_logical_replication_slot('regression_slot',
'test_decoding');
ERROR: logical decoding requires wal_level >= logical
The Logical Decoding example in the documentation says:
"Before you can use logical decoding, you must set wal_level
<https://www.postgresql.org/docs/10/static/runtime-config-wal.html#guc-wal-level>
to logical and max_replication_slots
<https://www.postgresql.org/docs/10/static/runtime-config-replication.html#guc-max-replication-slots>
to
at least 1."
But above error message is not exactly consistent with this documentation.
Would it make sense to keep the error message and the documentation
consistent like the attached.
Regards,
Neha
On Tue, May 23, 2017 at 8:08 AM, Neha Khatri <nehakhatri5@gmail.com> wrote:
The Logical Decoding example in the documentation says:
"Before you can use logical decoding, you must set wal_level to logical
and max_replication_slots to at least 1."But above error message is not exactly consistent with this documentation.
Would it make sense to keep the error message and the documentation
consistent like the attached.
There is no wal_level higher than logical, so the current sense looks
perfectly fine to me.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, May 23, 2017 at 10:26 AM, Michael Paquier <michael.paquier@gmail.com
wrote:
On Tue, May 23, 2017 at 8:08 AM, Neha Khatri <nehakhatri5@gmail.com>
wrote:The Logical Decoding example in the documentation says:
"Before you can use logical decoding, you must set wal_level to logical
and max_replication_slots to at least 1."But above error message is not exactly consistent with this
documentation.
Would it make sense to keep the error message and the documentation
consistent like the attached.There is no wal_level higher than logical, so the current sense looks
perfectly fine to me.
If there is no wal_level higher than logical, should the following error
message indicate to set it >= logical.
select * from
pg_create_logical_replication_slot('regression_slot','test_decoding');
ERROR: logical decoding requires wal_level >= logical
Regards,
Neha
Neha Khatri wrote:
On Tue, May 23, 2017 at 10:26 AM, Michael Paquier <michael.paquier@gmail.com
There is no wal_level higher than logical, so the current sense looks
perfectly fine to me.If there is no wal_level higher than logical, should the following error
message indicate to set it >= logical.select * from
pg_create_logical_replication_slot('regression_slot','test_decoding');
ERROR: logical decoding requires wal_level >= logical
I think it's purposefully ambiguous to cover a possible future
extension.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, 23 May 2017 at 10:55 am, Alvaro Herrera <alvherre@2ndquadrant.com>
wrote:
Neha Khatri wrote:
On Tue, May 23, 2017 at 10:26 AM, Michael Paquier <
michael.paquier@gmail.com
There is no wal_level higher than logical, so the current sense looks
perfectly fine to me.If there is no wal_level higher than logical, should the following error
message indicate to set it >= logical.select * from
pg_create_logical_replication_slot('regression_slot','test_decoding');
ERROR: logical decoding requires wal_level >= logicalI think it's purposefully ambiguous to cover a possible future
extension.
Should documentation also have similar statement and indicate future
possibility.
What is the benefit of having it just in error message.
Regards,
Neha
--
Cheers,
Neha
On 2017-05-23 10:49:54 +0000, Neha Khatri wrote:
On Tue, 23 May 2017 at 10:55 am, Alvaro Herrera <alvherre@2ndquadrant.com>
wrote:Neha Khatri wrote:
On Tue, May 23, 2017 at 10:26 AM, Michael Paquier <
michael.paquier@gmail.com
There is no wal_level higher than logical, so the current sense looks
perfectly fine to me.If there is no wal_level higher than logical, should the following error
message indicate to set it >= logical.select * from
pg_create_logical_replication_slot('regression_slot','test_decoding');
ERROR: logical decoding requires wal_level >= logicalI think it's purposefully ambiguous to cover a possible future
extension.
Right, IIRC that's how this notion started.
Should documentation also have similar statement and indicate future
possibility.What is the benefit of having it just in error message.
I personally wouldn't do anything here, it doesn't seem an issue.
- Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers