Tom Lane wrote:
(eg how to run it up and feed it SQL ideally without running a
postmaster and execing a back end)
Why would you consider that ideal? Such a scenario would have
approximately zip to do with the real-world environment your patch
would face.
Your points what? If I'm
Background:
Firebird 2.1 allows:
CREATE TRIGGER name ON
(
CONNECT
| DISCONNECT
| TRANSACTION START
| TRANSACTION COMMIT
| TRANSACTION ROLLBACK
)
I want to allow syntax:
CREATE TRIGGER name event
event (3 variations, application can specify any number of them):
AFTER CONNECT
AFTER
On Wed, 2008-03-12 at 15:51 -0400, Bruce Momjian wrote:
Tom's comment on this from the patch queue is that the standard assume
autocommit off, which affect some of your analysis below.
This isn't an important area for me, but I don't think we follow the
standard in the way we do it now and we
On Tue, 2008-03-11 at 20:23 -0400, Bruce Momjian wrote:
Is this still a TODO?
I think so.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
I would like to propose new large object client side API for 8.4.
Currently we have:
Oid lo_import(PGconn *conn, const char *filename);
But we do not have an API which imports a large object specifying the
object id. This is inconvenient and inconsistent since we already have
On Wed, 2008-03-12 at 20:13 -0400, Bruce Momjian wrote:
Is this a TODO? Tom's reply was:
The general topic, yes. The caveats still apply.
Nonsense. Main transaction exit also takes an exclusive lock, and is
far more likely to be exercised in typical workloads than a
subtransaction
On Thu, Mar 13, 2008 at 10:23 AM, Tom Lane [EMAIL PROTECTED] wrote:
But we could push them out earlier, ie,
before making the actual page changes in heap_page_prune. This seems
safe since an unnecessary invalidation notice cannot break anything,
at worst it causes useless work.
If I
Simon Riggs wrote:
On Tue, 2008-03-11 at 20:23 -0400, Bruce Momjian wrote:
Is this still a TODO?
I think so.
How about this wording:
Review Simon's claims to improve performance
;-)
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company -
Alvaro Herrera wrote:
Simon Riggs wrote:
On Tue, 2008-03-11 at 20:23 -0400, Bruce Momjian wrote:
Is this still a TODO?
I think so.
How about this wording:
Review Simon's claims to improve performance
What sort of evidence is usually compelling? It seems to me that
On Wed, Mar 12, 2008 at 1:19 PM, Josh Berkus [EMAIL PROTECTED] wrote:
... with new ideas and projects appropriate for PostgreSQL 8.4/8.5.
Please make suggestions. Thanks!
How about optimizing the SQL used by pgsnmpd, as well as extending it
to support traps?
--
Jonah H. Harris, Sr.
Just noting what seems to me to be a bug, though perhaps not a consequential
one since we never dump out the contents of system tables and don't expect
people to be using aclitem for non-system tables.
The output of aclitem can't be read back back in as an aclitem:
postgres=# select
Meetesh Karia [EMAIL PROTECTED] writes:
Additionally, here's what I get when I run your test below (my server
encoding is UTF-8):
ltefull=# create table x (r varchar(255) unique);
NOTICE: CREATE TABLE / UNIQUE will create implicit index x_r_key for
table x
CREATE TABLE
ltefull=#
Pavan Deolasee [EMAIL PROTECTED] writes:
I wonder if we can have a separate list of non-transaction events in
InvalidationListHeader and broadcast those events irrespective of
transaction commit or abort.
Yeah, I started with that same idea. But AFAICS there is no percentage
in postponing the
Mark Mielke [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
How about this wording:
Review Simon's claims to improve performance
What sort of evidence is usually compelling? It seems to me that this
sort of change only benefits configurations with dozens or more CPUs/cores?
The main point
Tom Lane [EMAIL PROTECTED] writes:
I think this is a must fix bug for 8.3.1, anyone disagree?
Agreed.
It seems we should collect cases like this for the regression tests. The only
one I was aware of previously was the Turkish one.
--
Gregory Stark
EnterpriseDB
On Thu, Mar 13, 2008 at 9:22 PM, Tom Lane [EMAIL PROTECTED] wrote:
Yeah, I started with that same idea. But AFAICS there is no percentage
in postponing the broadcast until commit/abort; we may as well push the
messages out immediately.
Seems like a good plan to me.
Thanks,
Pavan
--
Thanks for the confirmation of this. For now I'll continue to use the C
locale and I'll switch with 8.3.1.
Meetesh
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
I think this is a must fix bug for 8.3.1, anyone disagree?
Agreed.
It seems we should collect cases like
Gregory Stark [EMAIL PROTECTED] writes:
The output of aclitem can't be read back back in as an aclitem:
postgres=# select relacl::text from pg_class limit 1;
relacl
{=r/stark}
(1 row)
postgres=# select relacl::text::aclitem from pg_class limit 1;
ERROR:
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
The output of aclitem can't be read back back in as an aclitem:
postgres=# select relacl::text from pg_class limit 1;
relacl
{=r/stark}
(1 row)
postgres=# select relacl::text::aclitem
James Mansion wrote:
In usage:
AFTER START clears counters and flags.
UPDATE triggers on data set counters and flags.
BEFORE COMMIT examines the counters and flags and performs any final
validation or
adjustments (or external events such as sending a MoM message)
I'd like to point out also
I found autovacuum can be canceled by blocked backends even if the vacuum
is for preventing XID wraparound in 8.3.0 and HEAD. Autovacuum sets
PROC_VACUUM_FOR_WRAPAROUND flag just before vacuum, but the flag will be
cleared at the beginning of vacuum; PROC_VACUUM_FOR_WRAPAROUND is not set
during
2008/3/12, Neil Conway [EMAIL PROTECTED]:
I don't see why creating index entries in bulk has anything to do with
COPY vs. INSERT: if a lot of rows are being loaded into the table in a
single command, it would be a win to create the index entries in bulk,
regardless of whether COPY or INSERT
Hi,
What are the Data Recovery feature available in postgreSQL apart from
pg_restore and PITR.
If my Database has corrupted its not starting which feature i can use for
Data Recovery ?
Any help willbe highly appreciated.
23 matches
Mail list logo
