Обсуждение: unsubscribe

Ryan <rlichtenwalter@gmail.com> writes:
> All right, so not for lack of trying, I cannot figure out how to
> unsubscribe. I've tried three different things, but they've either been
> ineffective or result in me getting an automatic email that the attempt
> failed. Kindly help? I enjoyed my daily digest of PostgreSQL messages, but
> this has been a bit difficult to manage.

Well, you didn't say what you tried exactly, so it's hard to say why it
did not work.  But the way that I think has the fewest chances of going
wrong is to find the List-Unsubscribe header in any message you get from
the new list server, and visit the web page it links to, and confirm there
that you want to unsubscribe.

Depending on what mail software you use, you might have to use some
command like "View raw headers" or "View original message" to see
commonly-hidden headers like List-Unsubscribe.

(If you indeed did that, and it failed to work, our list admins
would definitely want to know about it; but they'd want a lot
more details than you've provided.)
        regards, tom lane

Danyelle Davis <ladynikon@gmail.com> writes:
> https://lists.postgresql.org/manage/

But note that that's only going to help if you've set up a "PG community
account", which up to now nobody has needed unless they wanted to edit
our wiki or work in our commitfest app, so it's a good bet that most
subscribers to our lists haven't got one.  The List-Unsubscribe link
is supposed to work without needing a community account.  It disturbs
me that Ryan says he's not seeing one in traffic from the list.
I certainly am getting one in all the mail I get from the new server.

I wonder whether there are complicating factors Ryan hasn't mentioned,
like maybe his traffic is getting forwarded from some other account
on some other email provider.  If so, maybe the List-Unsubscribe
header is getting dropped in forwarding?  That's a reach, but it's
hard to explain otherwise.
        regards, tom lane

On 11/20/2017 7:40 PM, Tom Lane wrote:
> Depending on what mail software you use, you might have to use some
> command like "View raw headers" or "View original message" to see
> commonly-hidden headers like List-Unsubscribe.


in gmail, its Show Original, on the down-tick menu next to the 'Reply' 
button.


-- 
john r pierce, recycling bits in santa cruz

Hi all,

Have anyone noticed, that last couple of days on the list, can become a
nice example of HOWTO turn the best list on the planet into a nightmare?

Pls forgive rudeness, but IMHO, whoever made the "upgrade" should
manually take all the "unsubscribe" messages from archive and do that
"unsubscription" by hand .... instead of giving not always helpfull
guidance.

I do system maintenance for money. I do that when I screwup.

Regards,

-R

W dniu 21.11.2017 o 04:16, Ryan pisze:
> Hi,
> 
> All right, so not for lack of trying, I cannot figure out how to
> unsubscribe. I've tried three different things, but they've either been
> ineffective or result in me getting an automatic email that the attempt
> failed. Kindly help? I enjoyed my daily digest of PostgreSQL messages,
> but this has been a bit difficult to manage.
> 
> Best regards.
> 
> On Mon, Nov 20, 2017 at 9:37 PM, Danyelle Davis <ladynikon@gmail.com
> <mailto:ladynikon@gmail.com>> wrote:
> 
> 
>     On Mon, Nov 20, 2017 at 9:29 PM, Amila Jayasooriya
>     <amilajayasooriya@gmail.com <mailto:amilajayasooriya@gmail.com>> wrote:
> 
>         Please unsubscribe me from the list.
> 
>         Thanks and Regards
>          Amila Jayasooriya
> 
>         On Tue, Nov 21, 2017 at 3:48 AM, Ibram Remzi
>         <remzi.ibram@yahoo.com <mailto:remzi.ibram@yahoo.com>> wrote:
> 
>             Please unsubscribe me from the list.
> 
>     Please look at the listserv for options on how to unsub.  Yall are
>     clogging the list with these.  
> 
> 
>
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
>         Virus-free. www.avast.com
>
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
> 
> 
>     <#m_4396185798928146462_m_941694909827362166_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> 
> 

On 21 November 2017 at 15:17, Rafal Pietrak <rafal@ztk-rp.eu> wrote:

Hi all,

Have anyone noticed, that last couple of days on the list, can become a
nice example of HOWTO turn the best list on the planet into a nightmare?

Pls forgive rudeness, but IMHO, whoever made the "upgrade" should
manually take all the "unsubscribe" messages from archive and do that
"unsubscription" by hand .... instead of giving not always helpfull
guidance.

The list used to have a filter that blocked messages with "unsubscribe" in the subject or forced them into moderation the moderation queue. 

I thought that'd be preserved with the PgLister migration. 

But really, a nightmare? Yeah, it's a pain, but I think that's laying it on a bit strong. Personally I appreciate the hard and usually thankless work the infrastructure and admin team do.

--

 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

-- 
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt

I'm very very sorry for my rude words. I do understand and truelly appreciate continues availability of the list. I know (from my own experence) it takes signifficant effort to maintain.

Nonetheless, I do stand by opinion, that it would annoy less if the infant state of the new list servar was babysitted for a while.

Regards

R

Greetings Rafal and Craig,

* Craig Ringer (craig@2ndquadrant.com) wrote:
> On 21 November 2017 at 15:17, Rafal Pietrak <rafal@ztk-rp.eu> wrote:
> > Pls forgive rudeness, but IMHO, whoever made the "upgrade" should
> > manually take all the "unsubscribe" messages from archive and do that
> > "unsubscription" by hand .... instead of giving not always helpfull
> > guidance.

I have been doing exactly that, thanks.

> The list used to have a filter that blocked messages with "unsubscribe" in
> the subject or forced them into moderation the moderation queue.

It does again.

> I thought that'd be preserved with the PgLister migration.

We had it on the body but didn't have it on the subject.  Hindsight is
ever perfect.

Let's try to not continue to complain on-list.  If you have a complaint
or concern regarding the list, please email me directly and I'll do the
best I can to address it.

Thanks!

Stephen

On Tue, Nov 21, 2017 at 10:34:27AM +0100, Magnus Hagander wrote:
> On Tue, Nov 21, 2017 at 8:17 AM, Rafal Pietrak <rafal@ztk-rp.eu> wrote:
> 
>     Hi all,
> 
>     Have anyone noticed, that last couple of days on the list, can become a
>     nice example of HOWTO turn the best list on the planet into a nightmare?
> 
>     Pls forgive rudeness, but IMHO, whoever made the "upgrade" should
>     manually take all the "unsubscribe" messages from archive and do that
>     "unsubscription" by hand .... instead of giving not always helpfull
>     guidance.
> 
> 
> So what makes you think that's not what they're doing?
> 
> Note that the majority of the advice posted have not been from the people who
> actually are doing the system upgrade. It's from fellow users.
> 
> So to show some numbers, since the migration, 57 unsubscriptions have been
> processed manually by the people who were involved in the migration. This is a
> mix of people who posted unsubscribe requests that ended up getting moderated,
> and people who posted publicly. 
> 
> During this time, the systems have also processed 282 unsubscriptions from
> people who managed to read and work with the instructions.

Maybe we need an "unsubscribe" email list.  ;-)

--  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 Tue, 21 Nov 2017 10:36:11 +0100
Magnus Hagander <magnus@hagander.net> wrote:

> On Tue, Nov 21, 2017 at 8:19 AM, Craig Ringer <craig@2ndquadrant.com>
> wrote:

> 
> > But really, a nightmare? Yeah, it's a pain, but I think that's
> > laying it on a bit strong. Personally I appreciate the hard and
> > usually thankless work the infrastructure and admin team do.
> >  
> 
> Thanks!
> 

I agree with Craig Ringer: This is no nightmare. Heartbleed was a
nightmare; this thing was barely a bump in the road from the
perspective of an ordinary list member.

It would have been barely noticible, except for the avalanche of people
sending emails subjected "unsubscribe". Who does that? Yeah, the
unsubscribe link was missing from the emails, but it's easy enough to
go back to the 10/27 email to get that link, or look it up in a search
engine.

I'm on more than 50 lists, so this kind of thing happens all the time.
You notice that go into your inbox instead of the correct folder,  so
you investigate and adjust your filters (.procmailrc in my case) and
move on.

Thanks to all of you who have kept this list going for years and are
continuing to do so!

SteveT

Steve Litt 
November 2017 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust

Hi,
I'm curious - what was the problem in the first place?
Why people who performed the change couldn't create a mail template
where the "Subscribe/Unsubscribe"
links would be visible at the bottom of the e-mail?

There has to be a way of doing this sort of things. Especially if you
as a user have multiple ML subscriptions and
want to an easily in-subscribe.

Thank you.


On Tue, Nov 21, 2017 at 12:06 PM, Steve Litt <slitt@troubleshooters.com> wrote:
> On Tue, 21 Nov 2017 10:36:11 +0100
> Magnus Hagander <magnus@hagander.net> wrote:
>
>> On Tue, Nov 21, 2017 at 8:19 AM, Craig Ringer <craig@2ndquadrant.com>
>> wrote:
>
>>
>> > But really, a nightmare? Yeah, it's a pain, but I think that's
>> > laying it on a bit strong. Personally I appreciate the hard and
>> > usually thankless work the infrastructure and admin team do.
>> >
>>
>> Thanks!
>>
>
> I agree with Craig Ringer: This is no nightmare. Heartbleed was a
> nightmare; this thing was barely a bump in the road from the
> perspective of an ordinary list member.
>
> It would have been barely noticible, except for the avalanche of people
> sending emails subjected "unsubscribe". Who does that? Yeah, the
> unsubscribe link was missing from the emails, but it's easy enough to
> go back to the 10/27 email to get that link, or look it up in a search
> engine.
>
> I'm on more than 50 lists, so this kind of thing happens all the time.
> You notice that go into your inbox instead of the correct folder,  so
> you investigate and adjust your filters (.procmailrc in my case) and
> move on.
>
> Thanks to all of you who have kept this list going for years and are
> continuing to do so!
>
> SteveT
>
> Steve Litt
> November 2017 featured book: Troubleshooting: Just the Facts
> http://www.troubleshooters.com/tjust
>

Greetings Igor,

* Igor Korot (ikorot01@gmail.com) wrote:
> I'm curious - what was the problem in the first place?

Please review the details provided here:

https://wiki.postgresql.org/wiki/PGLister_Announce

They answer the questions you're asking.

Thanks!

Stephen

Hi,

On Tue, Nov 21, 2017 at 12:44:48PM -0600, Igor Korot wrote:
> Why people who performed the change couldn't create a mail template
> where the "Subscribe/Unsubscribe"
> links would be visible at the bottom of the e-mail?

That would change the body of the mail.  Mail that is DKIM signed (or
worse conforms to DMARC) cannot be so changed, or it will fail
validation and will be bounced.  The bouncing system is then doing the
correct thing, and yet it will create "excessive bounces" to the list,
which will cause the _validating_ user to become a problem on the
list.  Users don't control their mail server validation policies, so
lists have to conform.  Tom Lane explained this upthread somewhere.

If you think this is all the consequence of having something like <20
(or <5, depending on how you count) important email services in the
universe, plus "everybody else", you're right.

A


-- 
Andrew Sullivan
ajs@crankycanuck.ca

Andrew,

On Tue, Nov 21, 2017 at 12:50 PM, Andrew Sullivan <ajs@crankycanuck.ca> wrote:
> Hi,
>
> On Tue, Nov 21, 2017 at 12:44:48PM -0600, Igor Korot wrote:
>> Why people who performed the change couldn't create a mail template
>> where the "Subscribe/Unsubscribe"
>> links would be visible at the bottom of the e-mail?
>
> That would change the body of the mail.  Mail that is DKIM signed (or
> worse conforms to DMARC) cannot be so changed, or it will fail
> validation and will be bounced.  The bouncing system is then doing the
> correct thing, and yet it will create "excessive bounces" to the list,
> which will cause the _validating_ user to become a problem on the
> list.  Users don't control their mail server validation policies, so
> lists have to conform.  Tom Lane explained this upthread somewhere.
>
> If you think this is all the consequence of having something like <20
> (or <5, depending on how you count) important email services in the
> universe, plus "everybody else", you're right.

But then... How all other lists doing so?
I do subscribe to few and almost all have a links at the bottom of the email.

I don't have a mailer and use WebMail from Gmail and it nicely
displays those links.
But nothing is displayed in the latest PG list threads.

Thank you.

>
> A
>
>
> --
> Andrew Sullivan
> ajs@crankycanuck.ca
>

Andrew Sullivan wrote:

> That would change the body of the mail.  Mail that is DKIM signed (or
> worse conforms to DMARC) cannot be so changed, or it will fail
> validation and will be bounced.  The bouncing system is then doing the
> correct thing, and yet it will create "excessive bounces" to the list,
> which will cause the _validating_ user to become a problem on the
> list.  Users don't control their mail server validation policies, so
> lists have to conform.  Tom Lane explained this upthread somewhere.

This was already happening and it already had had a very ugly
consequence: we had to ban Yahoo addresses from subscribing to the list,
because since the emails sent by the list from Yahoo subscribers were
"invalid" per DMARC, the postgresql.org servers were being flagged as
spammers, causing all sorts of trouble.  I think we'll be able to accept
Yahoo subscribers to the lists after the migration ... assuming they
still exist, of course.

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

Yuri Budilov <yuri.budilov@hotmail.com> writes:
> Posted on Stack Overflow, sadly no replies, so trying here....
> CREATE TABLE X AS
> SELECT json_array_elements(json_rmq -> 'orders'::text) AS order
> FROM table_name
> WHERE blah;
> I get out of memory error.
> The JSON column is about ~5 MB and it has about ~150,000 array row elements in 'orders' above.

I tried to reproduce that, and couldn't, given the available info.
I made a JSON value of more or less that size with

perl -e 'print "{\"orders\": [0"; for($i=1;$i<=150000;$i++){print ",$i"}; print "]}\n";' >jsonval

and then did

regression=# create table table_name(json_rmq json);
CREATE TABLE
regression=# \copy table_name from jsonval
COPY 1
regression=# insert into table_name select * from table_name;
INSERT 0 1
regression=# insert into table_name select * from table_name;
INSERT 0 2
regression=# insert into table_name select * from table_name;
INSERT 0 4
regression=# insert into table_name select * from table_name;
INSERT 0 8
regression=# insert into table_name select * from table_name;
INSERT 0 16
regression=# insert into table_name select * from table_name;
INSERT 0 32
regression=# insert into table_name select * from table_name;
INSERT 0 64
regression=# insert into table_name select * from table_name;
INSERT 0 128
regression=# CREATE TABLE X AS
SELECT json_array_elements(json_rmq -> 'orders'::text) AS order
FROM table_name;
SELECT 38400256

Watching the process with "top", its memory consumption stayed
rock-steady.  If there's a leak in there, this example doesn't
show it.  There could be a leak related to some detail you
failed to mention, but ...

            regards, tom lane

On Sun, 2017-12-03 at 23:18 +0000, Yuri Budilov wrote:
> Posted on Stack Overflow, sadly no replies, so trying here....
> 
>  CREATE TABLE X AS
> SELECT json_array_elements(json_rmq -> 'orders'::text) AS order
> FROM table_name
> WHERE blah;
> I get out of memory error.
> 
> Is there anything I can do to unpack the above?
> 
> The JSON column is about ~5 MB and it has about ~150,000 array
> row elements in 'orders' above.
> 
> I tried work_mem values up to ~250MB and it did not help, the query
> takes about same time to fail.
> 
> I guess this parameter does not help JSON processing.
> 
> If there another parameter I can try? Something else?
> 
> I don't have control of the size of the JSON payload, it arrives, we
> store it in a JSON column and then we need to crack it open.
> 
> Many thanks!
> 



Hello,

It would help if you advised:-
(a) version of PostgreSql being used.
(b) is column json_rmq defined as json or jsonb?
(c) OS.

Cheers,
Rob

Yuri Budilov <yuri.budilov@hotmail.com> writes:
> The out-of-memory error happens if I also retrieve another JSON Column like so:

> CREATE TABLE csnbi_stg.junk4
> AS
> SELECT
>        json_rmq->>'totalSize' as totalSize, -- this plus array below causes out of memory error
>        json_array_elements(json_rmq -> 'orders'::text) AS orders
>   FROM csnbi_stg.stg_rmq_prod_test_json_raw_jmcn stg_rmq_json_raw

Ah.  The problem here is that "json_rmq->>'totalSize'" leaks some memory
on each execution, and it's executed again for each row produced by the
json_array_elements() SRF, and the memory can't be reclaimed until we've
finished the full output cycle for the SRF.  So the leakage (which is
more or less of the size of the JSON value, I think) accumulates across
150K executions in this example.

This is fixed as of v10.  It seems impractical to do anything about it
in previous release branches, although you could reformulate your query to
avoid it by not having any other expression evaluations occurring in the
same tlist as the SRF.  Something like this should work:

SELECT totalSize, json_array_elements(json_rmq -> 'orders'::text) AS orders
FROM
 (SELECT
       json_rmq->>'totalSize' as totalSize, json_rmq
  FROM csnbi_stg.stg_rmq_prod_test_json_raw_jmcn stg_rmq_json_raw
  WHERE ...
  OFFSET 0) ss;

            regards, tom lane

On Mon, Dec 4, 2017 at 9:39 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Ah.  The problem here is that "json_rmq->>'totalSize'" leaks some memory
> on each execution, and it's executed again for each row produced by the
> json_array_elements() SRF, and the memory can't be reclaimed until we've
> finished the full output cycle for the SRF.  So the leakage (which is
> more or less of the size of the JSON value, I think) accumulates across
> 150K executions in this example.
>
> This is fixed as of v10.  It seems impractical to do anything about it
> in previous release branches, although you could reformulate your query to
> avoid it by not having any other expression evaluations occurring in the
> same tlist as the SRF.  Something like this should work:

Yeah, I agree with that. One similar leak has actually been fixed with
this commit, and the infrastructure of v10 has made this fix dead
simple:
commit: 0c25e9652461c08b5caef259a6af27a38707e07a
author: Tom Lane <tgl@sss.pgh.pa.us>
date: Fri, 6 Oct 2017 14:28:42 -0400
Fix intra-query memory leakage in nodeProjectSet.c.
https://www.postgresql.org/message-id/20171005230321.28561.15927@wrigleys.postgresql.org

nodeProjectSet.c really makes tuple-level memory handling way easier
based on my studies of this code.
-- 
Michael