avpro avpro wrote:
> in the pgsql documentation
> (http://www.postgresql.org/docs/9.1/static/sql-createtrigger.html)
>
>
> i haven't seen anything referring to: how is affected the data inserted in
> the new table by a trigger
> Before Insert compared with a trigger After Insert? and anything re
El vie, 07-11-2014 a las 10:02 -0500, Dan H escribió:
> Hi,
>
> I encountered a deadlock while running 'reindex table TABLE1' in
> postgresql version 9.2.4
> The postgresql logs shows the two offending processes.
>
> 1st process was running reindex table TABLE1
> waiting for AccessExclusiveLock o
Hello,
I noticed the following behaviour in the JDBC driver:
In one transaction run an ALTER TABLE ADD COLUMN ... statement with auto-commit
off, but don't commit the statement
In another transcation, call DatabaseMetaData.getColumns() for this table -
this call will wait until the first trans
On 11/10/2014 10:38 PM, avpro avpro wrote:
hi,
in the pgsql documentation
(http://www.postgresql.org/docs/9.1/static/sql-createtrigger.html)
i haven't seen anything referring to: how is affected the data inserted
in the new table by a trigger Before Insert compared with a trigger
After Insert?
Thomas Kellerer writes:
> Is there a reason why pg_catalog.pg_get_expr() will wait until the exclusive
> lock on the table is released?
Yes. It needs to extract attribute names, data types, etc for the target
table and it would also like to be sure that that data is self-consistent.
So it take
Tom Lane schrieb am 11.11.2014 um 16:35:
>> Is there a reason why pg_catalog.pg_get_expr() will wait until the exclusive
>> lock on the table is released?
>
> Yes. It needs to extract attribute names, data types, etc for the target
> table and it would also like to be sure that that data is sel
Thomas Kellerer writes:
> Does this mean that pg_get_expr() selects additional data from the table,
> instead of just using the values that are provided by the caller?
No, it means it depends on backend code that is also used when accessing
the table "for real", and that code doesn't work safely
Tom Lane schrieb am 11.11.2014 um 17:08:
>> Does this mean that pg_get_expr() selects additional data from the table,
>> instead of just using the values that are provided by the caller?
>
> No, it means it depends on backend code that is also used when accessing
> the table "for real", and that
I have a question about modeling a mutual relationship. It seems basic but
I can't decide, maybe it is 6 of one a half dozen of the other.
In my system any user might be friends with another user, that means they
have a reciprocal friend relationship.
It seems I have two choices for modeling it.
Hello People,
Before the question, this is the scenario:
I have a postgresql 9.1 cluster with a size of 1.5 TB and composed of 70
databases.
In every database I have 50 tables (master partition), each one have an
associated trigger that insert the record into a child table of its own.
The parti
On 11/11/2014 03:38 PM, Robert DiFalco wrote:
I have a question about modeling a mutual relationship. It seems basic
but I can't decide, maybe it is 6 of one a half dozen of the other.
In my system any user might be friends with another user, that means
they have a reciprocal friend relationsh
On 11/11/2014 02:38 PM, Robert DiFalco wrote:
I have a question about modeling a mutual relationship. It seems basic
but I can't decide, maybe it is 6 of one a half dozen of the other.
In my system any user might be friends with another user, that means
they have a reciprocal friend relationsh
I set up repmgr and its working. I confirmed that using:
select * from pg_stat_replication;
select pg_is_in_recovery();
However, on both master and slave there is only one entry
in repmgr_cane.repl_nodes : the master.
Is that expected?
On Mon, Nov 10, 2014 at 4:29 PM, John R Pierce wrote:
TL;DR - the interaction of ANALYZE and inheritance hierarchies seems to be
broken for the uncommon use case where the inserts temporarily remain on the
master table in order to allow RETURNING to work.
Note - I have not played with this scenario personally but
http://www.postgresql.org/message-i
On Tue, 11 Nov 2014 14:38:16 -0800
Robert DiFalco wrote:
> I have a question about modeling a mutual relationship. It seems basic but
> I can't decide, maybe it is 6 of one a half dozen of the other.
>
> In my system any user might be friends with another user, that means they
> have a reciproca
a difficulty of the single entry for joe<->bob is that its hard to have
a unique constraint across two fields. you'd want to ensure that
joe+bob is unique and that there's no bob+joe
--
john r pierce 37N 122W
somewhere on the middle of the left coast
John R Pierce wrote
> a difficulty of the single entry for joe<->bob is that its hard to have
> a unique constraint across two fields. you'd want to ensure that
> joe+bob is unique and that there's no bob+joe
Bill's solution:
PRIMARY KEY (person1, person2),
CHECK (person1 < person2)
s
On 11/11/2014 5:32 PM, David G Johnston wrote:
Bill's solution:
PRIMARY KEY (person1, person2),
CHECK (person1 < person2)
seems to make this constraint fairly simple...am I missing something?
oh, I guess I missed that part. of course, you'll have to make sure
you swap any relation into
18 matches
Mail list logo
