On 07/22/2015 06:24 AM, Tim Smith wrote:
Adrian,
It still doesn't make much sense, especially as given the rather
obscure and questionable design decision of allowing triggers to refer
to truncate ops, but not allowing rules to refer to truncate ops !!!
Actually it makes perfect sense
hi!
from master:
pg_xlogfile_name -- right!
from standby:
using replication prtotocol (example from version 92)
psql -h $host -F' ' -c 'IDENTIFY_SYSTEM' 'dbname=replication replication=true'
-- misha
Понедельник, 20 июля 2015, 11:13 +03:00 от Vladimir Borodin r...@simply.name:
Hi all.
What
On 22 July 2015 at 16:32, Joshua D. Drake j...@commandprompt.com wrote:
This is actually wrong. The end result is the same but it does not in any
way have the same effect.
in any way?
I'd say in the primary way it has the same effect: all rows are removed
from the table.
And I will
On 22 July 2015 at 16:55, Joshua D. Drake j...@commandprompt.com wrote:
On 07/22/2015 08:42 AM, Geoff Winkless wrote:
On 22 July 2015 at 16:32, Joshua D. Drake j...@commandprompt.com
mailto:j...@commandprompt.comwrote:
This is actually wrong. The end result is the same but it does not
On 07/22/2015 06:13 AM, Tim Smith wrote:
Melvin,
May I point out that the manual states :
TRUNCATE quickly removes all rows from a set of tables. It has the same
effect as an unqualified DELETE on each table
This is actually wrong. The end result is the same but it does not in
any way have
On 07/22/2015 08:42 AM, Geoff Winkless wrote:
On 22 July 2015 at 16:32, Joshua D. Drake j...@commandprompt.com
mailto:j...@commandprompt.comwrote:
This is actually wrong. The end result is the same but it does not
in any way have the same effect.
in any way?
I'd say in the
This is interesting, I tried nc a few times. Inconsistent results:
- most of the time the first line doesn't get through, even after a long wait
- on sending a second line from the client both lines appear
instantly, and it's 100% from there on
- or I can send a line from the server. The
Logging at debug5, hopefully it will mean more to you than to me.
Local connection connects and I quit in a few seconds. -h localhost
takes 90+ seconds to be closed by the server. In the longer duration
there is a lot more logged, seems like unrelated auto chatter.
I turned autovacuum off in
Hello,
We've just upgraded some productive servers from 9.3.6 to 9.3.9, and it seems
that the time to get a connection (or possibly to disconnect) has become much
slower.
These tests are consistent when run against different servers.
tests with 9.4.1 show fast times, but we don't have a later
Marc Mamin wrote:
We've just upgraded some productive servers from 9.3.6 to 9.3.9, and it seems
that the time to get a
connection (or possibly to disconnect) has become much slower.
These tests are consistent when run against different servers.
tests with 9.4.1 show fast times, but we
SOLVED!
With firewall off and pf disabled I spotted a process intended to keep
an audit trail of Internet access. I uninstalled it and hey presto.
Thanks for your help, everyone! Glad to see my macbook is not haunted.
Regards,
Fritz
On Wed, Jul 22, 2015 at 9:23 AM, Chris Mair ch...@1006.org
No,
I am saying if you
CREATE PROCEDURE do_nothing()
RETURNS VOID
$BODY$
BEGIN
RETURN;
END
LANGUAGE plpgsql;
CREATE TRIGGER no_trunc INSTEAD OF TRUNCATE ON your_table
EXECUTE PROCEDURE do_nothing;
Then you can handle the problem.
You should also create a TRIGGER for DELETE to do the same.
On 07/22/2015 06:13 AM, Tim Smith wrote:
Melvin,
May I point out that the manual states :
TRUNCATE quickly removes all rows from a set of tables. It has the same
effect as an unqualified DELETE on each table
Thus, if you are telling me to effectively think of TRUNCATE as an alias
to DELETE,
Adrian,
It still doesn't make much sense, especially as given the rather
obscure and questionable design decision of allowing triggers to refer
to truncate ops, but not allowing rules to refer to truncate ops !!!
Surely either you say look, truncate is truncate, its there for one
purpose and one
On 07/22/2015 06:24 AM, Tim Smith wrote:
Adrian,
It still doesn't make much sense, especially as given the rather
obscure and questionable design decision of allowing triggers to refer
to truncate ops, but not allowing rules to refer to truncate ops !!!
Surely either you say look, truncate is
Actually, if you use a TRIGGER instead of rule, you can handle this.
The manual states event can be:
INSERT
UPDATE [ OF column_name [, ... ] ]
DELETE*TRUNCATE -*
http://www.postgresql.org/docs/9.4/interactive/sql-createtrigger.html
I suggest you review carefully.
On Wed, Jul 22, 2015 at
Melvin,
May I point out that the manual states :
TRUNCATE quickly removes all rows from a set of tables. It has the same
effect as an unqualified DELETE on each table
Thus, if you are telling me to effectively think of TRUNCATE as an alias to
DELETE, then I would think its not entirely
On 15 July 2015 at 09:34, Andreas Kretschmer akretsch...@spamfence.net wrote:
test= explain select * from rls_test ;
QUERY PLAN
-
Seq Scan on rls_test (cost=0.00..630.00 rows=91 width=335)
Filter: (name
SOLVED!
Glad to see my macbook is not haunted.
Calling a priest would have been my next suggestion... ;)
Bye,
Chris.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Hi,
I very much hope this is an accidental bug rather than a deliberate feature !
PostgreSQL 9.4.4
create rule no_auditupd as on update to app_security.app_audit do
instead nothing;
create rule no_auditdel as on delete to app_security.app_audit do
instead nothing;
\d+ app_security.app_audit
20 matches
Mail list logo
