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 Bett
On Tue, Dec 23, 2008 at 4:24 AM, Heikki Linnakangas
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 you run VACUU
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 underst
"Hitoshi Harada" writes:
> 2008/12/23 Tom Lane :
>> * 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 exces
On Tue, Dec 23, 2008 at 5:18 AM, Heikki Linnakangas
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. Thanks,
>>>
>>> A li
Magnus Hagander 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 funny
in the mes
"Kevin Grittner" 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 absolutely can't happen in a
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 l
On Mon, Dec 22, 2008 at 00:44, ITAGAKI Takahiro
wrote:
>
> "Alex Hunsaker" 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 nested statements (SQLs called in
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 pointle
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 f
On Mon, Dec 22, 2008 at 9:07 PM, 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 desig
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 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 vi
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
> > sor
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.
W
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
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
2008/12/23 Tom Lane :
> * 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, but it does seem
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 ignore
>>> Martijn van Oosterhout 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 situatio
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 T
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 including
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, and
Tom Lane wrote:
Robert Lor 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 TRACE_POSTGRESQL_WAL_BUFFER_WRITE_DIRTY similar to
ITAGAKI Takahiro wrote:
> Alvaro Herrera 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
> > minimum and default
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.
On 12/20/08, Alvaro Herrera 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 the first)
--
Atenta
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.
Unfortunately I'm not seeing wonderful speedups with the particular
queries I did in this case.
Tom Lane wrote:
> Tatsuo Ishii 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 Mittwoch, November 26, 2008 10:54:01 +0100 Bernd Helmle
wrote:
--On Dienstag, November 25, 2008 23:43:02 -0500 Robert Haas
wrote:
Do you intend to submit an updated version of this patch for this
commitfest?
I'll do asap, i've updated the status to 'waiting on author'.
Okay, i've f
Tatsuo Ishii 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 TABLE pg_class ..
> "Albe" == Albe Laurenz 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 -mimmediate (not -
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
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 acq
35 matches
Mail list logo
