This discussion really questioned my understanding of concurrency in
PostgreSQL, thanks a lot.
I gave the corresponding part of the doc some more read, and I’m now in the
option that insolation level has no effect on CTEs, but please correct me if
I’m wrong.
If notionally all queries execute a
> here ?
>
> Dave Cramer
> www.postgres.rocks
>
>
>> On Thu, 1 Apr 2021 at 11:20, Glen Huang wrote:
>> Sorry, my mistake. I misunderstood serializable. Are queries in a CTE
>> equivalent to those in a repeatable read transaction?
>>
>>>> On A
Ah, I see what you mean. You still have to wrap a CTE inside a transaction to
specify the isolation level? By default, queries in a CTE run with the read
committed isolation level?
> On Apr 1, 2021, at 11:10 PM, Dave Cramer wrote:
>
>
>
>
>> On Thu, 1 Apr 2021 at 11:
Sorry, my mistake. I misunderstood serializable. Are queries in a CTE
equivalent to those in a repeatable read transaction?
> On Apr 1, 2021, at 11:10 PM, Dave Cramer wrote:
>
>
>
>
>> On Thu, 1 Apr 2021 at 11:09, Glen Huang wrote:
>> No, but are they
No, but are they equivalent to serializable transactions?
> On Apr 1, 2021, at 11:04 PM, Dave Cramer wrote:
>
>
>
>
>
>> On Thu, 1 Apr 2021 at 10:50, Glen Huang wrote:
>> Hi all,
>>
>> From application’s standpoint, it seems using CTE saves a
> When you deal with updates/deletes, things can be trickier
Care to expand why they are tricker? I presume they run the risk of being
referenced more than once?
> On Apr 1, 2021, at 10:58 PM, Brian Dunavant wrote:
>
>
>> On Thu, Apr 1, 2021 at 10:49 AM Glen Huang wrote:
Hi all,
From application’s standpoint, it seems using CTE saves a lot work. You no
longer need to parse values out only to pass them back in, and only one
round-trip to the db server.
If I’m not wrong, CTE is equivalent to serializable transactions? So I guess
the downsize is that quarries can
Hmm, maybe letting people linger on for a couple more minutes isn’t
unacceptable. And it simplifies the code a lot.
Good idea, thanks.
> On Apr 1, 2021, at 10:31 PM, Tim Clarke wrote:
>
>
> On 01/04/2021 15:23, Glen Huang wrote:
>> I wish one cron job could rule them all,
> I'd say that was onerous and you could get the same effect with a
well-crafted query that targetted only those that might possibly expire.
I wish one cron job could rule them all, but since a person can decide to join
at any time, her expiration (e.g., after 1 hour) can also happen at any time.
Good suggestion, thanks.
I ended up running the cron jobs in my app, one for each newly joined member,
to get the smallest granularity possible.
> On Apr 1, 2021, at 9:43 PM, Tim Clarke wrote:
>
> On 01/04/2021 14:28, Glen Huang wrote:
>>> Possibly keep your count of mem
> Possibly keep your count of members updated via a trigger?
But how to evoke the trigger when the count of members should be updated by a
timeout, i.e., the person’s pay is due?
Hi,
I guess this question has been asked a million times, but all solutions I can
find online don’t really work well for my case. I’ll list them here and hope
someone can shed some light.
My use case is to implement joining clubs that require entrance fee:
1. Each clubs only allows maximum num
12 matches
Mail list logo
