Re: [HACKERS] GSoC 2017: weekly progress reports (week 6) - Mailing list pgsql-hackers

From Shubham Barai
Subject Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)
Date
Msg-id CALxAEPs9cNsjGCqkKM0CTpMExOSViRMBcWZQdquXA-iPqoxutA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Responses Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)  (Teodor Sigaev <teodor@sigaev.ru>)
List pgsql-hackers


On 16 March 2018 at 03:57, Alexander Korotkov <a.korotkov@postgrespro.ru> wrote:
On Tue, Mar 13, 2018 at 3:25 PM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
Alexander Korotkov wrote:

> And what happen if somebody concurrently set (fastupdate = on)?
> Can we miss conflicts because of that?

I think it'd be better to have that option require AccessExclusive lock,
so that it can never be changed concurrently with readers.  Seems to me
that penalizing every single read to cope with this case would be a bad
trade-off.

As Andrey Borodin mentioned, we already do.  Sorry for buzz :)



I have updated the patch based on suggestions.

Regards,
Shubham
Attachment

pgsql-hackers by date:

Previous
From: Pavan Deolasee
Date:
Subject: Re: ON CONFLICT DO UPDATE for partitioned tables
Next
From: Michael Paquier
Date:
Subject: Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs