Re: [HACKERS] More stats about skipped vacuums

This is just a repost as a (true) new thread. At Mon, 30 Oct 2017 20:57:50 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20171030.205750.246076862.horiguchi.kyot...@lab.ntt.co.jp> > At Fri, 20 Oct 2017 19:15:16 +0900, Masahiko Sawada

Re: [HACKERS] More stats about skipped vacuums

At Thu, 26 Oct 2017 15:06:30 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20171026.150630.115694437.horiguchi.kyot...@lab.ntt.co.jp> > At Fri, 20 Oct 2017 19:15:16 +0900, Masahiko Sawada > wrote in

Re: [HACKERS] More stats about skipped vacuums

Mmm. I've failed to create a brand-new thread.. Thank you for the comment. At Fri, 20 Oct 2017 19:15:16 +0900, Masahiko Sawada wrote in

Re: [HACKERS] More stats about skipped vacuums

On Tue, Oct 10, 2017 at 7:26 PM, Kyotaro HORIGUCHI wrote: > Hello. > Once in a while I am asked about table bloat. In most cases the > cause is long lasting transactions and vacuum canceling in some > cases. Whatever the case users don't have enough clues to why >

[HACKERS] More stats about skipped vacuums

Hello. Once in a while I am asked about table bloat. In most cases the cause is long lasting transactions and vacuum canceling in some cases. Whatever the case users don't have enough clues to why they have bloated tables. At the top of the annoyances list for users would be that they cannot know

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

Hi, On 2017-09-15 17:43:35 +0530, Kuntal Ghosh wrote: > The patch looks good to me. I've done some regression testing with a > custom script on my local system. The script contains the following > statement: > SELECT 'aaa..' as col; > > Test 1 > --- > duration:

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

On Fri, Sep 15, 2017 at 4:49 PM, Andres Freund wrote: > On 2017-09-15 16:45:47 -0400, Tom Lane wrote: >> Andres Freund writes: >> > Version correcting these is attached. Thanks! >> >> I'd vote for undoing the s/st_activity/st_activity_raw/g business. >>

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

On 2017-09-15 16:45:47 -0400, Tom Lane wrote: > Andres Freund writes: > > Version correcting these is attached. Thanks! > > I'd vote for undoing the s/st_activity/st_activity_raw/g business. > That may have been useful while writing the patch, to ensure you > found all the

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

Andres Freund writes: > Version correcting these is attached. Thanks! I'd vote for undoing the s/st_activity/st_activity_raw/g business. That may have been useful while writing the patch, to ensure you found all the references; but it's just creating a lot of unnecessary

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

On 2017-09-15 08:25:09 -0400, Robert Haas wrote: > On Thu, Sep 14, 2017 at 2:03 AM, Andres Freund wrote: > > Here's a patch that implements that idea. > > From the department of cosmetic nitpicking: > > + * All supported server-encodings allow to determine the length of

Re: [HACKERS] More flexible LDAP auth search filters?

On 9/12/17 19:04, Thomas Munro wrote: >> Any further thoughts on the test suite? Otherwise I'll commit it as we >> have it, for manual use. done > I wonder if there is a reasonable way to indicate or determine whether > you have slapd installed so that check-world could run this test... The

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

On Thu, Sep 14, 2017 at 2:03 AM, Andres Freund wrote: > Here's a patch that implements that idea. >From the department of cosmetic nitpicking: + * All supported server-encodings allow to determine the length of a make it possible to determine + * multi-byte

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

On Thu, Sep 14, 2017 at 11:33 AM, Andres Freund wrote: > On 2017-09-12 00:19:48 -0700, Andres Freund wrote: >> Hi, >> >> I've recently seen a benchmark in which pg_mbcliplen() showed up >> prominently. Which it will basically in any benchmark with longer query >> strings, but

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

On 2017-09-12 00:19:48 -0700, Andres Freund wrote: > Hi, > > I've recently seen a benchmark in which pg_mbcliplen() showed up > prominently. Which it will basically in any benchmark with longer query > strings, but fast queries. That's not that uncommon. > > I wonder if we could avoid the cost

Re: [HACKERS] More flexible LDAP auth search filters?

On Wed, Sep 13, 2017 at 8:04 AM, Thomas Munro wrote: > I wonder if there is a reasonable way to indicate or determine whether > you have slapd installed so that check-world could run this test... Module::Install's requires_external_bin is one:

Re: [HACKERS] More flexible LDAP auth search filters?

On Wed, Sep 13, 2017 at 1:55 AM, Peter Eisentraut wrote: > On 9/11/17 23:58, Thomas Munro wrote: >> Sounds good. Here it is with $username. It's nice not to have to >> escape any characters in URLs. I suppose more keywords could be added >> in follow-up

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

Robert Haas writes: > On Tue, Sep 12, 2017 at 3:19 AM, Andres Freund wrote: >> Therefore I wonder if we couldn't just store a querystring that's >> essentially just a memcpy()ed prefix, and do a pg_mbcliplen() on the >> read side. > Interesting idea.

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

On Tue, Sep 12, 2017 at 3:19 AM, Andres Freund wrote: > Therefore I wonder if we couldn't just store a querystring that's > essentially just a memcpy()ed prefix, and do a pg_mbcliplen() on the > read side. I think that should work because all *server side* encodings > store

Re: [HACKERS] More flexible LDAP auth search filters?

On 9/11/17 23:58, Thomas Munro wrote: > Sounds good. Here it is with $username. It's nice not to have to > escape any characters in URLs. I suppose more keywords could be added > in follow-up patches if someone thinks that would be useful > ($hostname, $dbname, ...?). I got sick of that buffer

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

> Check the information the pg_*_mblen use / how the relevant encodings > work. Will be something like > int > pg_utf_mblen(const unsigned char *s) > { > int len; > > if ((*s & 0x80) == 0) > len = 1; > else if ((*s & 0xe0) == 0xc0) >

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

On 2017-09-12 16:53:49 +0900, Tatsuo Ishii wrote: > > read side. I think that should work because all *server side* encodings > > store character lengths in the *first* byte of a multibyte character > > What do you mean? I don't see such data in a multibyte string. Check the information the

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

> read side. I think that should work because all *server side* encodings > store character lengths in the *first* byte of a multibyte character What do you mean? I don't see such data in a multibyte string. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English:

[HACKERS] More efficient truncation of pg_stat_activity query strings

Hi, I've recently seen a benchmark in which pg_mbcliplen() showed up prominently. Which it will basically in any benchmark with longer query strings, but fast queries. That's not that uncommon. I wonder if we could avoid the cost of pg_mbcliplen() from within pgstat_report_activity(), by moving

Re: [HACKERS] More flexible LDAP auth search filters?

On Tue, Sep 12, 2017 at 7:21 AM, Peter Eisentraut wrote: > On 9/8/17 13:24, Mark Cave-Ayland wrote: >> My weapon of choice for LDAP deployments on POSIX-based systems is >> Arthur De Jong's nss-pam-ldapd (https://arthurdejong.org/nss-pam-ldapd) >> which is far

Re: [HACKERS] More flexible LDAP auth search filters?

On 9/8/17 21:31, Thomas Munro wrote: > +if ($^O eq 'darwin') > +{ > + $slapd = '/usr/local/opt/openldap/libexec/slapd'; > + $ldap_schema_dir = '/usr/local/etc/openldap/schema'; > +} > > I'm guessing this is the MacPorts location, and someone from that > other tribe that uses Brew can

Re: [HACKERS] More flexible LDAP auth search filters?

On 9/8/17 13:24, Mark Cave-Ayland wrote: > My weapon of choice for LDAP deployments on POSIX-based systems is > Arthur De Jong's nss-pam-ldapd (https://arthurdejong.org/nss-pam-ldapd) > which is far more flexible than pam_ldap and fixes a large number of > bugs, including the tendency for pam_ldap

Re: [HACKERS] More flexible LDAP auth search filters?

On Sat, Sep 9, 2017 at 3:33 AM, Peter Eisentraut wrote: > A couple of comments on this patch. I have attached a "fixup" patch on > top of your v4 that should address them. > > - I think the bracketing of the LDAP URL synopsis is wrong. +1 > - I have dropped

Re: [HACKERS] More flexible LDAP auth search filters?

On Sat, Sep 9, 2017 at 3:36 AM, Peter Eisentraut wrote: > For additional entertainment I have written a test suite for this LDAP > authentication functionality. It's not quite robust enough to be run by > default, because it needs a full OpenLDAP installation,

Re: [HACKERS] More flexible LDAP auth search filters?

On 08/09/17 16:33, Peter Eisentraut wrote: > A couple of comments on this patch. I have attached a "fixup" patch on > top of your v4 that should address them. > > - I think the bracketing of the LDAP URL synopsis is wrong. > > - I have dropped the sentence that LDAP URL extensions are not >

Re: [HACKERS] More flexible LDAP auth search filters?

For additional entertainment I have written a test suite for this LDAP authentication functionality. It's not quite robust enough to be run by default, because it needs a full OpenLDAP installation, but it's been very helpful for reviewing this patch. Here it is. -- Peter Eisentraut

Re: [HACKERS] More flexible LDAP auth search filters?

A couple of comments on this patch. I have attached a "fixup" patch on top of your v4 that should address them. - I think the bracketing of the LDAP URL synopsis is wrong. - I have dropped the sentence that LDAP URL extensions are not supported. That sentence was written mainly to point out

Re: [HACKERS] More replication race conditions

On Sat, Sep 2, 2017 at 12:03 AM, Alvaro Herrera wrote: > Michael Paquier wrote: >> On Mon, Aug 28, 2017 at 8:25 AM, Michael Paquier >> wrote: >> > Today's run has finished with the same failure: >> >

Re: [HACKERS] More replication race conditions

Michael Paquier wrote: > On Mon, Aug 28, 2017 at 8:25 AM, Michael Paquier > wrote: > > Today's run has finished with the same failure: > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dangomushi=2017-08-27%2018%3A00%3A13 > > Attached is a patch to make this

Re: [HACKERS] More replication race conditions

On 31 August 2017 at 12:54, Simon Riggs wrote: >> The above-described topic is currently a PostgreSQL 10 open item. Simon, >> since you committed the patch believed to have created it, you own this open >> item. If some other commit is more relevant or if this does not

Re: [HACKERS] More replication race conditions

On 27 August 2017 at 03:32, Noah Misch wrote: > On Fri, Aug 25, 2017 at 12:09:00PM +0200, Petr Jelinek wrote: >> On 24/08/17 19:54, Tom Lane wrote: >> > sungazer just failed with >> > >> > pg_recvlogical exited with code '256', stdout '' and stderr >> > 'pg_recvlogical: could

Re: [HACKERS] More replication race conditions

On Tue, Aug 29, 2017 at 08:44:42PM +0900, Michael Paquier wrote: > On Mon, Aug 28, 2017 at 8:25 AM, Michael Paquier > wrote: > > Today's run has finished with the same failure: > >

Re: [HACKERS] More replication race conditions

On Sun, Aug 27, 2017 at 02:32:49AM +, Noah Misch wrote: > On Fri, Aug 25, 2017 at 12:09:00PM +0200, Petr Jelinek wrote: > > On 24/08/17 19:54, Tom Lane wrote: > > > sungazer just failed with > > > > > > pg_recvlogical exited with code '256', stdout '' and stderr > > > 'pg_recvlogical: could

Re: [HACKERS] More replication race conditions

On Mon, Aug 28, 2017 at 8:25 AM, Michael Paquier wrote: > Today's run has finished with the same failure: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dangomushi=2017-08-27%2018%3A00%3A13 > Attached is a patch to make this code path wait that the

Re: [HACKERS] More replication race conditions

On 28/08/17 01:36, Michael Paquier wrote: > On Sun, Aug 27, 2017 at 6:32 PM, Petr Jelinek > wrote: >> Attached should fix this. > > +$node_master->poll_query_until('postgres', > +"SELECT EXISTS (SELECT 1 FROM pg_replication_slots WHERE slot_name = > 'test_slot' AND

Re: [HACKERS] More replication race conditions

On Mon, Aug 28, 2017 at 8:33 AM, Tom Lane wrote: > Michael Paquier writes: >> Attached is a patch to make this code path wait that the transaction >> has been replayed. We could use as well synchronous_commit = apply, >> but I prefer the solution of

Re: [HACKERS] More replication race conditions

On Sun, Aug 27, 2017 at 6:32 PM, Petr Jelinek wrote: > Attached should fix this. +$node_master->poll_query_until('postgres', +"SELECT EXISTS (SELECT 1 FROM pg_replication_slots WHERE slot_name = 'test_slot' AND active_pid IS NULL)" +) + or die "slot never became

Re: [HACKERS] More replication race conditions

Michael Paquier writes: > Attached is a patch to make this code path wait that the transaction > has been replayed. We could use as well synchronous_commit = apply, > but I prefer the solution of this patch with a wait query. Petr proposed a different patch to fix the

Re: [HACKERS] More replication race conditions

On Sun, Aug 27, 2017 at 3:34 PM, Michael Paquier wrote: > On Sun, Aug 27, 2017 at 12:03 PM, Tom Lane wrote: >> contains exactly no means of ensuring that the master's transaction has >> been replayed on the standby before we check for its results.

Re: [HACKERS] More replication race conditions

On 27/08/17 04:32, Noah Misch wrote: > On Fri, Aug 25, 2017 at 12:09:00PM +0200, Petr Jelinek wrote: >> On 24/08/17 19:54, Tom Lane wrote: >>> sungazer just failed with >>> >>> pg_recvlogical exited with code '256', stdout '' and stderr >>> 'pg_recvlogical: could not send replication command

Re: [HACKERS] More replication race conditions

On Sun, Aug 27, 2017 at 12:03 PM, Tom Lane wrote: > And *another* replication test race condition just now: > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dangomushi=2017-08-26%2019%3A37%3A08 > > As best I can interpret this, it's pointing out that this bit in >

Re: [HACKERS] More replication race conditions

And *another* replication test race condition just now: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dangomushi=2017-08-26%2019%3A37%3A08 As best I can interpret this, it's pointing out that this bit in src/test/recovery/t/009_twophase.pl: $cur_master->psql( 'postgres', "

Re: [HACKERS] More replication race conditions

On Fri, Aug 25, 2017 at 12:09:00PM +0200, Petr Jelinek wrote: > On 24/08/17 19:54, Tom Lane wrote: > > sungazer just failed with > > > > pg_recvlogical exited with code '256', stdout '' and stderr > > 'pg_recvlogical: could not send replication command "START_REPLICATION SLOT > > "test_slot"

Re: [HACKERS] More replication race conditions

On 24/08/17 19:54, Tom Lane wrote: > sungazer just failed with > > pg_recvlogical exited with code '256', stdout '' and stderr 'pg_recvlogical: > could not send replication command "START_REPLICATION SLOT "test_slot" > LOGICAL 0/0 ("include-xids" '0', "skip-empty-xacts" '1')": ERROR: >

[HACKERS] More replication race conditions

sungazer just failed with pg_recvlogical exited with code '256', stdout '' and stderr 'pg_recvlogical: could not send replication command "START_REPLICATION SLOT "test_slot" LOGICAL 0/0 ("include-xids" '0', "skip-empty-xacts" '1')": ERROR: replication slot "test_slot" is active for PID

Re: [HACKERS] More race conditions in logical replication

On Sun, Aug 13, 2017 at 10:25 AM, Noah Misch wrote: > Committed. These counts broke three times in the v10 release cycle. It's too > bad this defect doesn't cause an error when building the docs. That's another argument for generating the table dynamically. Thanks for the

Re: [HACKERS] More race conditions in logical replication

On Sat, Aug 12, 2017 at 05:38:29PM +0900, Michael Paquier wrote: > On Thu, Aug 10, 2017 at 4:22 PM, Michael Paquier > wrote: > > On Tue, Aug 8, 2017 at 8:11 PM, Alvaro Herrera > > wrote: > >> Here's a patch. It turned to be a bit larger than

Re: [HACKERS] More race conditions in logical replication

On Thu, Aug 10, 2017 at 4:22 PM, Michael Paquier wrote: > On Tue, Aug 8, 2017 at 8:11 PM, Alvaro Herrera > wrote: >> Here's a patch. It turned to be a bit larger than I initially expected. > > Álvaro, 030273b7 did not get things completely

Re: [HACKERS] More race conditions in logical replication

On Tue, Aug 8, 2017 at 8:11 PM, Alvaro Herrera wrote: > Robert Haas wrote: >> On Mon, Aug 7, 2017 at 8:14 PM, Alvaro Herrera >> wrote: >> > BTW, I noticed that the PG_WAIT_LOCK value that we're using for wait >> > event here (and in the

[HACKERS] More fun with container types

While poking at the arrays-of-domains TODO item, I found yet another area in which the existing code fails to handle existing supported cases. Specifically, although DefineRange will happily take domains or composites as a range subtype, and we already noticed that domains-over-array-of- composite

Re: [HACKERS] More race conditions in logical replication

Robert Haas wrote: > On Mon, Aug 7, 2017 at 8:14 PM, Alvaro Herrera > wrote: > > BTW, I noticed that the PG_WAIT_LOCK value that we're using for wait > > event here (and in the replication slot case) is bogus. We probably > > need something new here. > > Yeah, if

Re: [HACKERS] More race conditions in logical replication

On Mon, Aug 7, 2017 at 8:14 PM, Alvaro Herrera wrote: > BTW, I noticed that the PG_WAIT_LOCK value that we're using for wait > event here (and in the replication slot case) is bogus. We probably > need something new here. Yeah, if you're adding a new wait point, you

Re: [HACKERS] More race conditions in logical replication

Alvaro Herrera wrote: > Alvaro Herrera wrote: > > I just noticed that Jacana failed again in the subscription test, and it > > looks like it's related to this. I'll take a look tomorrow if no one > > beats me to it. > >

Re: [HACKERS] More flexible LDAP auth search filters?

On 01/08/17 23:17, Thomas Munro wrote: > On Wed, Aug 2, 2017 at 5:36 AM, Peter Eisentraut > wrote: >> On 7/16/17 19:09, Thomas Munro wrote: >>> On Mon, Jul 17, 2017 at 10:26 AM, Thomas Munro >>> wrote:

Re: [HACKERS] More flexible LDAP auth search filters?

On Wed, Aug 2, 2017 at 5:36 AM, Peter Eisentraut wrote: > On 7/16/17 19:09, Thomas Munro wrote: >> On Mon, Jul 17, 2017 at 10:26 AM, Thomas Munro >> wrote: >>> ldap-search-filters-v2.patch >> >> Gah, it would help if I could spell

Re: [HACKERS] More flexible LDAP auth search filters?

On 7/16/17 19:09, Thomas Munro wrote: > On Mon, Jul 17, 2017 at 10:26 AM, Thomas Munro > wrote: >> ldap-search-filters-v2.patch > > Gah, it would help if I could spell "occurrences" correctly. Fixed in > the attached. Please also add the corresponding support for

Re: [HACKERS] More race conditions in logical replication

Alvaro Herrera wrote: > Alvaro Herrera wrote: > > > Hmm, yeah, that's not good. However, I didn't like the idea of putting > > it inside the locked area, as it's too much code. Instead I added just > > before acquiring the spinlock. We cancel the sleep unconditionally > > later on if we didn't

Re: [HACKERS] More race conditions in logical replication

Alvaro Herrera wrote: > Hmm, yeah, that's not good. However, I didn't like the idea of putting > it inside the locked area, as it's too much code. Instead I added just > before acquiring the spinlock. We cancel the sleep unconditionally > later on if we didn't need to sleep after all. I just

Re: [HACKERS] More race conditions in logical replication

On Tue, Jul 25, 2017 at 5:47 AM, Petr Jelinek wrote: > As a side note, the ConditionVariablePrepareToSleep()'s comment could be > improved because currently it says the only advantage is that we skip > double-test in the beginning of ConditionVariableSleep(). But

Re: [HACKERS] More race conditions in logical replication

On Tue, Jul 25, 2017 at 1:42 PM, Alvaro Herrera wrote: > As I see it, we need to backpatch at least parts of this patch. I've > received reports that in earlier branches pglogical and BDR can > sometimes leave slots behind when removing nodes, and I have a hunch > that

Re: [HACKERS] More race conditions in logical replication

Petr Jelinek wrote: > On 25/07/17 01:33, Alvaro Herrera wrote: > > Alvaro Herrera wrote: > >> I'm back at looking into this again, after a rather exhausting week. I > >> think I have a better grasp of what is going on in this code now, > > > > Here's an updated patch, which I intend to push

Re: [HACKERS] More race conditions in logical replication

On 25/07/17 01:33, Alvaro Herrera wrote: > Alvaro Herrera wrote: >> I'm back at looking into this again, after a rather exhausting week. I >> think I have a better grasp of what is going on in this code now, > > Here's an updated patch, which I intend to push tomorrow. > I think the

Re: [HACKERS] More race conditions in logical replication

Alvaro Herrera wrote: > I'm back at looking into this again, after a rather exhausting week. I > think I have a better grasp of what is going on in this code now, Here's an updated patch, which I intend to push tomorrow. > and it > appears to me that we should change the locking so that

Re: [HACKERS] More race conditions in logical replication

I'm back at looking into this again, after a rather exhausting week. I think I have a better grasp of what is going on in this code now, and it appears to me that we should change the locking so that active_pid is protected by ReplicationSlotControlLock instead of the slot's spinlock; but I

Re: [HACKERS] More optimization effort?

On 21 July 2017 at 20:00, Tom Lane wrote: >> I have, however, decided not to volunteer to be the one who works on >> that project. > > Me either. Any one of these things would require a *lot* of work in > order to have a coherent feature that provided useful behavior across

Re: [HACKERS] More optimization effort?

Robert Haas writes: > Another very similar (but possibly easier) case is: > select * from pgbench_accounts where aid = 1.0; > This will use a sequential scan rather than an index scan, because the > query optimizer doesn't know that the only integer for which =(int4, >

Re: [HACKERS] More optimization effort?

On Fri, Jul 21, 2017 at 10:33 AM, Tom Lane wrote: > But the bigger picture is that doing something that helps to any > useful extent would require a really substantial amount of new, > datatype- and operator-specific knowledge that doesn't exist in the > system today. And as

Re: [HACKERS] More optimization effort?

Tatsuo Ishii writes: > Currently following query does not use an index: > test=# explain select * from pgbench_accounts where aid*100 < 1; > While following one does use the index. > test=# explain select * from pgbench_accounts where aid < 1/100; > Is it worth to

Re: [HACKERS] More optimization effort?

On 21 July 2017 at 07:11, Tatsuo Ishii wrote: > Currently following query does not use an index: > > t-ishii@localhost: psql -p 5433 test > Pager usage is off. > psql (9.6.3) > Type "help" for help. > > test=# explain select * from pgbench_accounts where aid*100 < 1; >

[HACKERS] More optimization effort?

Currently following query does not use an index: t-ishii@localhost: psql -p 5433 test Pager usage is off. psql (9.6.3) Type "help" for help. test=# explain select * from pgbench_accounts where aid*100 < 1; QUERY PLAN

Re: [HACKERS] More flexible LDAP auth search filters?

On Sun, Jul 16, 2017 at 7:23 PM, Stephen Frost wrote: >> Refusing to improve LDAP for the users who have no choice seems like a very >> unfriendly thing to do. > > I'm fine with improving LDAP in general, but, as I tried to point out, > having a way to make it easier to

Re: [HACKERS] More flexible LDAP auth search filters?

On 17/07/17 18:08, Magnus Hagander wrote: > On Mon, Jul 17, 2017 at 6:47 PM, Mark Cave-Ayland > > > wrote: > Great to hear from you! It has definitely been a while... > > Indeed. You should spend more time on these lists

Re: [HACKERS] More race conditions in logical replication

Alvaro Herrera wrote: > After going over this a bunch more times, I found other problems. For > example, I noticed that if I create a temporary slot in one session, > then another session would rightly go to sleep if it tries to drop that > slot. But the slot goes away when the first session

Re: [HACKERS] More flexible LDAP auth search filters?

On Mon, Jul 17, 2017 at 6:47 PM, Mark Cave-Ayland < mark.cave-ayl...@ilande.co.uk> wrote: > On 17/07/17 13:09, Magnus Hagander wrote: > > Hi Magnus, > > Great to hear from you! It has definitely been a while... > Indeed. You should spend more time on these lists :P > > > Generally you

Re: [HACKERS] More flexible LDAP auth search filters?

On 17/07/17 13:09, Magnus Hagander wrote: Hi Magnus, Great to hear from you! It has definitely been a while... > Generally you find that you will be given the option to set the > attribute for the default search filter of the form > "(attribute=username)" which defaults to uid for

Re: [HACKERS] More flexible LDAP auth search filters?

On Mon, Jul 17, 2017 at 1:23 AM, Stephen Frost wrote: > > * Magnus Hagander (mag...@hagander.net) wrote: > > On Sun, Jul 16, 2017 at 11:05 PM, Stephen Frost > wrote: > > > I'd suggest that we try to understand why Kerberos couldn't be used in > > > that

Re: [HACKERS] More flexible LDAP auth search filters?

On Sun, Jul 16, 2017 at 7:58 PM, Mark Cave-Ayland < mark.cave-ayl...@ilande.co.uk> wrote: > On 16/07/17 00:08, Thomas Munro wrote: > > > On Fri, Jul 14, 2017 at 11:04 PM, Magnus Hagander > wrote: > >> On Thu, Jul 13, 2017 at 9:31 AM, Thomas Munro > >>

Re: [HACKERS] More flexible LDAP auth search filters?

On 17/07/17 00:14, Stephen Frost wrote: >> If it helps, we normally recommend that clients use ldaps for both AD >> and UNIX environments, although this can be trickier from an >> administrative perspective in AD environments because it can require >> changes to the Windows firewall and

Re: [HACKERS] More flexible LDAP auth search filters?

Magnus, * Magnus Hagander (mag...@hagander.net) wrote: > On Sun, Jul 16, 2017 at 11:05 PM, Stephen Frost wrote: > > I'd suggest that we try to understand why Kerberos couldn't be used in > > that environment. I suspect in at least some cases what users would > > like is the

Re: [HACKERS] More flexible LDAP auth search filters?

Mark, * Mark Cave-Ayland (mark.cave-ayl...@ilande.co.uk) wrote: > On 16/07/17 23:26, Thomas Munro wrote: > > Thank you very much for this feedback and example, which I used in the > > documentation in the patch. I see similar examples in the > > documentation for other things on the web. > > >

Re: [HACKERS] More flexible LDAP auth search filters?

On Mon, Jul 17, 2017 at 10:26 AM, Thomas Munro wrote: > ldap-search-filters-v2.patch Gah, it would help if I could spell "occurrences" correctly. Fixed in the attached. -- Thomas Munro http://www.enterprisedb.com ldap-search-filters-v3.patch Description:

Re: [HACKERS] More flexible LDAP auth search filters?

On 16/07/17 23:26, Thomas Munro wrote: > Thank you very much for this feedback and example, which I used in the > documentation in the patch. I see similar examples in the > documentation for other things on the web. > > I'll leave it up to Magnus and Stephen to duke it out over whether we >

Re: [HACKERS] More flexible LDAP auth search filters?

On Mon, Jul 17, 2017 at 5:58 AM, Mark Cave-Ayland wrote: >> Any other views from LDAP-users? > > I've spent quite a bit of time integrating various bits of > non-PostgreSQL software to LDAP and in my experience option 3 tends to > be the standard. > > Generally you

Re: [HACKERS] More flexible LDAP auth search filters?

On Sun, Jul 16, 2017 at 11:05 PM, Stephen Frost wrote: > Magnus, all, > > * Magnus Hagander (mag...@hagander.net) wrote: > > (FWIW, a workaround I've applied more than once to this in AD > environments > > (where kerberos for one reason or other can't be done, sorry Stephen)

Re: [HACKERS] More flexible LDAP auth search filters?

Magnus, all, * Magnus Hagander (mag...@hagander.net) wrote: > (FWIW, a workaround I've applied more than once to this in AD environments > (where kerberos for one reason or other can't be done, sorry Stephen) is to > set up a RADIUS server and use that one as a "middle man". But it would be >

Re: [HACKERS] More flexible LDAP auth search filters?

On 16/07/17 00:08, Thomas Munro wrote: > On Fri, Jul 14, 2017 at 11:04 PM, Magnus Hagander wrote: >> On Thu, Jul 13, 2017 at 9:31 AM, Thomas Munro >> wrote: >>> A post on planet.postgresql.org today reminded me that a colleague had >>> asked

Re: [HACKERS] More flexible LDAP auth search filters?

On Sun, Jul 16, 2017 at 1:08 AM, Thomas Munro wrote: > On Fri, Jul 14, 2017 at 11:04 PM, Magnus Hagander > wrote: > > On Thu, Jul 13, 2017 at 9:31 AM, Thomas Munro > > wrote: > >> A post on

Re: [HACKERS] More flexible LDAP auth search filters?

On Fri, Jul 14, 2017 at 11:04 PM, Magnus Hagander wrote: > On Thu, Jul 13, 2017 at 9:31 AM, Thomas Munro > wrote: >> A post on planet.postgresql.org today reminded me that a colleague had >> asked me to post this POC patch here for discussion.

Re: [HACKERS] More race conditions in logical replication

After going over this a bunch more times, I found other problems. For example, I noticed that if I create a temporary slot in one session, then another session would rightly go to sleep if it tries to drop that slot. But the slot goes away when the first session disconnects, so I'd expect the

Re: [HACKERS] More race conditions in logical replication

On Wed, Jul 12, 2017 at 06:48:28PM -0400, Alvaro Herrera wrote: > Petr Jelinek wrote: > > > So best idea I could come up with is to make use of the new condition > > variable API. That lets us wait for variable which can be set per slot. > > Here's a cleaned up version of that patch, which I

Re: [HACKERS] More flexible LDAP auth search filters?

On Thu, Jul 13, 2017 at 9:31 AM, Thomas Munro wrote: > Hi hackers, > > A customer asked how to use pg_hba.conf LDAP search+bind > authentication to restrict logins to users in one of a small number of > groups. ldapsearchattribute only lets you make filters like

[HACKERS] More flexible LDAP auth search filters?

Hi hackers, A customer asked how to use pg_hba.conf LDAP search+bind authentication to restrict logins to users in one of a small number of groups. ldapsearchattribute only lets you make filters like "(foo=username)", so it couldn't be done. Is there any reason we should allow a more general

Re: [HACKERS] More race conditions in logical replication

Petr Jelinek wrote: > So best idea I could come up with is to make use of the new condition > variable API. That lets us wait for variable which can be set per slot. Here's a cleaned up version of that patch, which I intend to get in the tree tomorrow. I verified that this allows the

Re: [HACKERS] More race conditions in logical replication

Alvaro Herrera wrote: > I'll next update this on or before Monday 10th at 19:00 CLT. I couldn't get to this today as I wanted. Next update on Wednesday 12th, same time. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training &

Re: [HACKERS] More race conditions in logical replication

Alvaro Herrera writes: > I'll next update this on or before Monday 10th at 19:00 CLT. Schedule note --- we'll be wrapping beta2 on Monday, a couple hours before that. Although it'd be great to have this issue fixed before beta2, jamming in a patch just a few hours

Re: [HACKERS] More race conditions in logical replication

Petr Jelinek wrote: > So best idea I could come up with is to make use of the new condition > variable API. That lets us wait for variable which can be set per slot. > > It's not backportable however, I am not sure how big problem that is > considering the lack of complaints until now (maybe we

  1   2   3   4   5   6   7   8   9   10   >