Hi,
I'm wondering if following behavior of PostgreSQL regarding lock
conflict is an expected one. Here's a scenario:
Session A:
BEGIN;
SELECT * FROM pg_class limit 1; -- acquires access share lock
Session B:
BEGIN;
ALTER TABLE pg_class ; -- waits for
Tom Lane wrote:
I propose that this behaviour be changed such that 'terse' is ignored
for all log messages of FATAL or PANIC severity.
[ on the strength of a single example ]
[...]
It seems like it might be better to rephrase error messages to ensure
that anything really critical is
Albe == Albe Laurenz laurenz.a...@wien.gv.at writes:
Albe I *guess* it is the problem addressed by
Albe http://archives.postgresql.org/pgsql-committers/2008-04/msg00275.php
Albe and
Albe http://archives.postgresql.org/pgsql-committers/2008-04/msg00358.php
No; the problem is with stop
Tatsuo Ishii is...@postgresql.org writes:
I'm wondering if following behavior of PostgreSQL regarding lock
conflict is an expected one. Here's a scenario:
Session A:
BEGIN;
SELECT * FROM pg_class limit 1; -- acquires access share lock
Session B:
BEGIN;
ALTER
--On Mittwoch, November 26, 2008 10:54:01 +0100 Bernd Helmle
maili...@oopsware.de wrote:
--On Dienstag, November 25, 2008 23:43:02 -0500 Robert Haas
robertmh...@gmail.com wrote:
Do you intend to submit an updated version of this patch for this
commitfest?
I'll do asap, i've updated the
Tom Lane wrote:
Tatsuo Ishii is...@postgresql.org writes:
I'm wondering if following behavior of PostgreSQL regarding lock
conflict is an expected one. Here's a scenario:
Session A:
BEGIN;
SELECT * FROM pg_class limit 1; -- acquires access share lock
Session B:
BEGIN;
On Sun, Dec 21, 2008 at 10:25:59PM -0500, Robert Haas wrote:
[Some performance testing.]
I (finally!) have a chance to post my performance testing results... my
apologies for the really long delay. Excuses omitted
Unfortunately I'm not seeing wonderful speedups with the particular
queries I did
On 12/20/08, Alvaro Herrera alvhe...@commandprompt.com wrote:
ALTER TABLE foo SET (TOAST autovacuum_enabled = false);
...
ALTER TABLE foo SET TOAST (autovacuum_enabled = false);
i will be happy with any of this options (actually i prefer the second
one but don't have a strong argument against
I have cleaned up a couple of badly broken encodings in cvs commit
messages in:
src/backend/utils/error/Attic/exc.c,v
per discussion with Alvaro, by simply editing the RCS file directly in
the cvs repository. Only the commit message was changed (broken
character removed)
Should have no effect.
ITAGAKI Takahiro wrote:
Alvaro Herrera alvhe...@commandprompt.com wrote:
Here's a patch for improving the general reloptions mechanism. What
this patch does is add a table-based option parser. This allows adding
new options very easily, and stops the business of having to pass the
Tom Lane wrote:
Robert Lor robert@sun.com writes:
Tom Lane wrote:
I agree. If the probe is meant to track only *some* WAL writes
then it needs to be named something less generic than
TRACE_POSTGRESQL_WAL_BUFFER_WRITE.
How about change it to
After a couple of hours reading the SQL:2008 spec, I've come to some
conclusions about the semantics that are demanded for window functions.
Anyone want to to check my work?
* If window functions are used together with aggregates or grouping,
the grouping and regular aggregation happens first,
As I've understood limitations of the PostgreSQL implementation of
SERIALIZABLE transactions, at least the only example given in the
documentation, revolve around a rather unlikely situation:
Given concurrent transactions T1 and T2 and non-overlapping sets of
data A and B, T1 reads data
On Mon, Dec 22, 2008 at 11:00:53AM -0600, Kevin Grittner wrote:
As I've understood limitations of the PostgreSQL implementation of
SERIALIZABLE transactions, at least the only example given in the
documentation, revolve around a rather unlikely situation:
Given concurrent transactions T1
Martijn van Oosterhout klep...@svana.org wrote:
On Mon, Dec 22, 2008 at 11:00:53AM -0600, Kevin Grittner wrote:
As I've understood limitations of the PostgreSQL implementation of
SERIALIZABLE transactions, at least the only example given in the
documentation, revolve around a rather unlikely
Heikki Linnakangas wrote:
Peter Eisentraut wrote:
Heikki Linnakangas wrote:
I think we need a threshold similar to autovacuum_freeze_max_age for
manual vacuums as well: vacuum_freeze_max_age. If you run VACUUM, and
relfrozenxid is older than vacuum_freeze_max_age, the visibility map
is
2008/12/23 Tom Lane t...@sss.pgh.pa.us:
* Unlike aggregates, there doesn't seem to be any concept of a window
function being attached to an outer-level query --- in fact 6.10 rule
4 says that a window function's argument can't contain outer references
at all. That seems excessively strong,
Dear PostgreSQL developers,
I am re-sending this to keep this last change to the
internal hash function on the radar.
Ken
Sorry about the delay for this update to the new hash
index implementation. I was trying to get the WAL logging
in place and forgot to post the actual patch. The
Kenneth Marshall wrote:
Dear PostgreSQL developers,
I am re-sending this to keep this last change to the
internal hash function on the radar.
Please add it to the commitfest wiki page,
http://wiki.postgresql.org/wiki/CommitFest_2008-11
Thanks
--
Alvaro Herrera
Grzegorz Jaskiewicz wrote:
Hey folks,
It doesn't stop to bug me, that postgres will return 0 number of
affected rows, if table is triggered.
Now, question is - is this fixable, but no one cares, or is it some
sort of a design/implementation flaw and we just have to live with it.
Would
On Mon, 2008-12-22 at 15:07 -0500, Bruce Momjian wrote:
Grzegorz Jaskiewicz wrote:
Hey folks,
It doesn't stop to bug me, that postgres will return 0 number of
affected rows, if table is triggered.
Now, question is - is this fixable, but no one cares, or is it some
sort of a
Cleaning up the parallel restore patch I came across a question I might
have asked before, but one which in any case I worked around:
Why do we carefully define fseeko() for WIN32 but then not define
HAVE_FSEEKO, which makes doing the former pretty much pointless?
cheers
andrew
--
Sent
On 2008-12-22, at 21:07, Bruce Momjian wrote:
Grzegorz Jaskiewicz wrote:
Hey folks,
It doesn't stop to bug me, that postgres will return 0 number of
affected rows, if table is triggered.
Now, question is - is this fixable, but no one cares, or is it some
sort of a design/implementation flaw
On Mon, Dec 22, 2008 at 9:07 PM, Bruce Momjian br...@momjian.us wrote:
Grzegorz Jaskiewicz wrote:
Hey folks,
It doesn't stop to bug me, that postgres will return 0 number of
affected rows, if table is triggered.
Now, question is - is this fixable, but no one cares, or is it some
sort of a
On 2008-12-22, at 22:35, Dawid Kuroczko wrote:
atlantis= CREATE OR REPLACE FUNCTION foo_trigger() RETURNS trigger AS
$$ BEGIN UPDATE bar SET t=NEW.t WHERE i=NEW.i; RETURN NULL; END; $$
LANGUAGE plpgsql;
atlantis= CREATE TRIGGER foo_update BEFORE UPDATE ON foo FOR EACH ROW
EXECUTE PROCEDURE
Andrew Dunstan wrote:
Cleaning up the parallel restore patch I came across a question I might
have asked before, but one which in any case I worked around:
Why do we carefully define fseeko() for WIN32 but then not define
HAVE_FSEEKO, which makes doing the former pretty much pointless?
On Mon, Dec 22, 2008 at 00:44, ITAGAKI Takahiro
itagaki.takah...@oss.ntt.co.jp wrote:
Alex Hunsaker bada...@gmail.com wrote:
A few comments:
Is there a reason you add sourceText to QueryDesc? AFAICT you can do
ActivePortal-sourceText and it will always be populated correctly.
That's for
On Mon, 2008-12-22 at 17:14 +0900, Tatsuo Ishii wrote:
Also, it seems that an attacker could do a denial service attack if he
could open session A and B, since other users on session C or
following sessions will be blocked.
LOCK TABLE checks the permissions before attempting to acquire the
Kevin Grittner kevin.gritt...@wicourts.gov writes:
At this point, SERIALIZABLE transactions appear to have worked, with
receipt 3 happening before the update of deposit_date; however, there
was a window of time when the update to deposit_date was visible and
receipt 3 was not.
This
Magnus Hagander mag...@hagander.net writes:
I have cleaned up a couple of badly broken encodings in cvs commit
messages in:
src/backend/utils/error/Attic/exc.c,v
Out of curiosity ... what problems exactly? I just looked through my
last complete dump of CVS log history and didn't see anything
On Tue, Dec 23, 2008 at 5:18 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Simon Riggs wrote:
On Wed, 2008-12-17 at 23:32 -0300, Alvaro Herrera wrote:
Simon Riggs escribió:
Please let me know how I can make the reviewer's job easier. Diagrams,
writeups, whatever.
Hitoshi Harada umi.tan...@gmail.com writes:
2008/12/23 Tom Lane t...@sss.pgh.pa.us:
* Unlike aggregates, there doesn't seem to be any concept of a window
function being attached to an outer-level query --- in fact 6.10 rule
4 says that a window function's argument can't contain outer
Kevin,
If you want to know how to build SERIALIZABLE with a database that
provides SI (Snapshot Isolation), read
http://portal.acm.org/citation.cfm?doid=1376616.137669
Note that in practice, READ COMMITTED is the most largely used isolation
level and its limitations are relatively well
On Tue, Dec 23, 2008 at 4:24 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Heikki Linnakangas wrote:
Peter Eisentraut wrote:
Heikki Linnakangas wrote:
I think we need a threshold similar to autovacuum_freeze_max_age for
manual vacuums as well: vacuum_freeze_max_age. If
Hi Markus,
I'm not quite sure what you mean by certification protocol, there's no
such thing in Postgres-R (as proposed by Kemme). Although, I remember
having heard that term in the context of F. Pedone's work. Can you point
me to some paper explaining this certification protocol?
What
35 matches
Mail list logo
