On Thu, Oct 27, 2016 at 1:37 AM, Frank Millman wrote:
> As mentioned previously, I am trying to avoid using PostgreSQL-specific
> techniques, as I need to support sqlite3 and SQL Server as well.
The SERIALIZABLE transaction isolation level is portable. It it
part of the SQL standard (and has be
From: Frank Millman
Sent: Wednesday, October 26, 2016 10:42 AM
To: pgsql-general@postgresql.org
Subject: [GENERAL] Locking question
> I am designing an inventory application, and I want to ensure that the stock
> level of any item cannot go negative.
Thanks to all for some really
On Wed, Oct 26, 2016 at 3:42 AM, Frank Millman wrote:
> I am designing an inventory application, and I want to ensure
> that the stock level of any item cannot go negative.
One way to do this is to use only transactions at the SERIALIZABLE
transaction isolation level to maintain and query this d
On Wed, 2016-10-26 at 12:18 +0200, Frank Millman wrote:
>
> From: hubert depesz lubaczewski
> Sent: Wednesday, October 26, 2016 10:46 AM
> To: Frank Millman
> Cc: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Locking question
>
> On Wed, Oct 26, 2016 at 10:42:2
- Original Message -
> From: "Frank Millman"
> To: pgsql-general@postgresql.org
> Sent: Wednesday, October 26, 2016 4:42:29 AM
> Subject: [GENERAL] Locking question
> Hi all
> I am designing an inventory application, and I want to ensure that the stock
&
> *From:* hubert depesz lubaczewski
> *Sent:* Wednesday, October 26, 2016 10:46 AM
> *To:* Frank Millman
> *Cc:* pgsql-general@postgresql.org
> *Subject:* Re: [GENERAL] Locking question
>
> On Wed, Oct 26, 2016 at 10:42:29AM +0200, Frank Millman wrote:
> > Hi all
>
From: hubert depesz lubaczewski
Sent: Wednesday, October 26, 2016 10:46 AM
To: Frank Millman
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Locking question
On Wed, Oct 26, 2016 at 10:42:29AM +0200, Frank Millman wrote:
> Hi all
> >
> > I am designing an inventory app
On Wed, Oct 26, 2016 at 10:42:29AM +0200, Frank Millman wrote:
> Hi all
>
> I am designing an inventory application, and I want to ensure that the stock
> level of any item cannot go negative.
>
> Instead of maintaining a running balance per item, I store the original
> quantities received in o
Hi all
I am designing an inventory application, and I want to ensure that the stock
level of any item cannot go negative.
Instead of maintaining a running balance per item, I store the original
quantities received in one table (call it ‘inv_rec’), and any amounts removed
in another table (call
=?UTF-8?B?VG9yc3RlbiBGw7ZydHNjaA==?= writes:
> given a query like this:
> select *
> from account a
> cross join lateral (
>select rate
> from exchange
> where target='USD'
> and source=a.currency
> order by date desc
> limit 1) e
> where a.i
Hi,
given a query like this:
select *
from account a
cross join lateral (
select rate
from exchange
where target='USD'
and source=a.currency
order by date desc
limit 1) e
where a.id=19
for update;
If I understand the documentation correctl
Well... if the application crashes then normally the TCP connection
would drop as well.
The problem is that in many environments it can take a *long* time
for the backend to realize that the client went away. The
tcp_keepalives_* settings are intended to try and reduce that time to
a more
There is such timeout from the database server for the idle connections but
yes you can always use firewall settings in order to do that and kill idle
connections.
--
Shoaib Mir
EnterpriseDB (www.enterprisedb.com)
On 2/6/07, Gurjeet Singh <[EMAIL PROTECTED]> wrote:
On 1/30/07, Alvaro Herrera <
On 1/30/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
Shoaib Mir wrote:
> While debugging an application, I just wanted to confirm from the list
here:
>
> Suppose I have a long running transaction which has a few updates and
> inserts running on some specific tables which means it has acquired
>
Thank you Alvaro :)
-
Shoaib Mir
EnterpriseDB (www.enterprisedb.com)
On 1/30/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
Shoaib Mir wrote:
> While debugging an application, I just wanted to confirm from the list
here:
>
> Suppose I have a long running transaction which has a
Shoaib Mir wrote:
> While debugging an application, I just wanted to confirm from the list here:
>
> Suppose I have a long running transaction which has a few updates and
> inserts running on some specific tables which means it has acquired
> Exclusive locks too during the transaction on specific
While debugging an application, I just wanted to confirm from the list here:
Suppose I have a long running transaction which has a few updates and
inserts running on some specific tables which means it has acquired
Exclusive locks too during the transaction on specific table but if just
before co
On Jun 7, 2005, at 1:15 PM, Alvaro Herrera wrote:
I don't think it's a bug, nor a deadlock situation. The problem is
the
"idle in transaction" server process, which holds some lock but isn't
doing anything useful with it. Probably work would continue if the
transaction was closed.
This view
On Tue, Jun 07, 2005 at 10:26:00AM -0400, peter royal wrote:
> i am using PostgreSQL 7.4.1 (i am aware of my need to upgrade :)
>
> i have a situation where i *believe* postgresql should be detecting a
> deadlock, but it is not. in the locks view you see below, all of the
> processes waiting o
i am using PostgreSQL 7.4.1 (i am aware of my need to upgrade :)
i have a situation where i *believe* postgresql should be detecting a
deadlock, but it is not. in the locks view you see below, all of the
processes waiting on the 'numberfactory' table are blocked. (which
smells like a deadlo
I have a question about locks.
I have a stats table that get updated when some other table changes.
Sometimes that other table is updated a 2nd time before the first stats
update is finished which causes an error. I've tried using 'SET
TRANSACTION ISOLATION LEVEL SERIALIZABLE' but get 'could
21 matches
Mail list logo
