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 related
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 on
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
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 spam_ea...@gmx.net 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
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
Thomas Kellerer spam_ea...@gmx.net 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
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 code
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
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
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
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
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
On Tue, 11 Nov 2014 14:38:16 -0800
Robert DiFalco robert.difa...@gmail.com 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
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)
seems
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
