I'll give using TRUNCATE to clear the tables a try and see what happens.
Dominic Jones
Quoting Sergey Konoplev :
On Tue, Apr 23, 2013 at 8:50 AM, wrote:
Good morning. I'm seeing several of the following log messages each morning
(for example, there were five this morning, spaced approxim
Good morning. I'm seeing several of the following log messages each
morning (for example, there were five this morning, spaced
approximately one minute apart, with the closest interval between
messages being 44 seconds). They're occurring during a daily cycle of
deleting all rows from a t
I'm looking at a database design for tracking the movement/routing of
documents through a workflow using PostgreSQL (version 9.1).
Basically, I have a state diagram for the possible routings and came
up with two different designs for how to implement the tables. As a
quick advance note, n
I just ran the upgrade process for updating my PostgreSQL installation
(running on Windows XP) from 8.3.14 to 8.3.16. I used pgInstaller's
UPGRADE script to conduct the upgrade. It appeared to work without
problems.
When I tried to verify that the upgrade took place, I noticed
something
Seems like you would be a lot better off enforcing this with a unique
index on (submitter_id, date_trunc('month',entry_timestamp)). The above
not only doesn't provide any feedback, it's got serious race-condition
problems.
Unfortunately, it didn't work.
CREATE UNIQUE INDEX one_entry_per_submit
Seems like you would be a lot better off enforcing this with a unique
index on (submitter_id, date_trunc('month',entry_timestamp)). The above
not only doesn't provide any feedback, it's got serious race-condition
problems.
I'll take a look at using an index to do this. The trigger is an ugly
Greetings. I noticed an interesting behavior when using a PL/pgSQL
trigger. I'm running PostgreSQL 8.3. The trigger function checks a
newly inserted or updated row for a type of uniqueness. Specifically,
each row in the table has a submitter id and an entry timestamp. No
two rows can h
