I am trying to emulate a pessimistic locking system you would find in
an
old school database file system, for example cobol. Generally, when a
cobol program tries to read a record that is locked by somebody else,
the read fails and either a message is displayed by the user or a
error
Michael Meskes kirjutas K, 26.02.2003 kell 13:00:
Did anyone ever think about creating a library that is able to
handle
our numeric datatype? I'm currently thinking about adding this
datatype
among others to the ones know to ecpg so no one is forced to convert
them or work on the
Stephen Marshall [EMAIL PROTECTED] writes:
1. When the FSM is oversubscribed and one is trying to decide which
pages to keep, remember that page info is stored in groups of
CHUNK_SIZE pages, where CHUNK_SIZE is current 32.
Right, oversubscription would actually need to be measured in chunks
That's my fallback position. Obviously, this will lead to false
positives depending on server load. In my case, I'm targeting between
30-50 users so its likely to throw timeouts for various reasons other
than locks even though my queries of interest are generally select a
from b where id = c
Robert Treat [EMAIL PROTECTED] writes:
Now that indexes are getting some reporting, my understanding is an
index would report fewer pages overall than it's associated table, but
those pages would be completely empty. However, given that they don't
reported non-empty pages, the percentage of
That's my fallback position. Obviously, this will lead to false
positives depending on server load. In my case, I'm targeting between
30-50 users so its likely to throw timeouts for various reasons other
than locks even though my queries of interest are generally select a
from b where id
I was referring to 10.3 in the administrator's guide, regarding the
pg_lock view. According to the documentation, the view only contains
table level locks. However, the view also contains an xid for
transactions. The unclear part, at least to me, was what the role of
the xid was in the view and
On Thu, 2003-02-27 at 11:00, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
Now that indexes are getting some reporting, my understanding is an
index would report fewer pages overall than it's associated table, but
those pages would be completely empty. However, given that they
I just dumped and restored a rather large database, I upgraded from
7.2.x to 7.3.x. When I went to test my application against the new
database, it was dog slow. It had all the indexes, and looked fine.
Then it dawned on me, Doh! ANALYZE!
Should pg_dump appened an ANALYZE for each table?
On
Robert Treat [EMAIL PROTECTED] writes:
I think I was thinking that a given table will always report more pages
than an index on that table, since tables can report 50% empty pages
while indexes only report 100% empty pages. This would cause tables to
generally be favored over indexes, even
Merlin Moncure [EMAIL PROTECTED] writes:
In my case, being able to view outstanding row level locks would be
enormously useful.
The only way to do that would be to grovel through every table in the
database, looking for rows that are marked locked by transactions that
are still alive.
A
In my case, being able to view outstanding row level locks would be
enormously useful. I'm assuming this is not possible for structural or
Agreed -- but they're stored on the row themselves. You might be able
to write a function which executes dirty reads on the table and tells
you if the row
mlw [EMAIL PROTECTED] writes:
Should pg_dump appened an ANALYZE for each table?
A single ANALYZE at the end of the script would be sufficient. I'm not
sure that pg_dump should do this automatically though. If you're not
done restoring then it's mostly a waste of cycles, and how is pg_dump to
On Thu, 2003-02-27 at 12:27, mlw wrote:
I just dumped and restored a rather large database, I upgraded from
7.2.x to 7.3.x. When I went to test my application against the new
database, it was dog slow. It had all the indexes, and looked fine.
Then it dawned on me, Doh! ANALYZE!
Should
Tom Lane wrote:
mlw [EMAIL PROTECTED] writes:
Should pg_dump appened an ANALYZE for each table?
A single ANALYZE at the end of the script would be sufficient. I'm not
sure that pg_dump should do this automatically though. If you're not
done restoring then it's mostly a waste of
Rod Taylor [EMAIL PROTECTED] writes:
Agreed -- but they're stored on the row themselves. You might be able
to write a function which executes dirty reads on the table and tells
you if the row is locked or not, but it's not going to be simple.
Actually, I don't think you need a dirty read at
On Thu, 2003-02-27 at 15:02, Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
Agreed -- but they're stored on the row themselves. You might be able
to write a function which executes dirty reads on the table and tells
you if the row is locked or not, but it's not going to be simple.
mlw [EMAIL PROTECTED] writes:
From an ease of use perspective, it would be one less step.
There is something to be said for that. As Rod notes, this has been
considered and rejected before --- but I think that was back when
ANALYZE (a) could only be done as part of VACUUM, and (b) insisted on
I wrote:
Stephen Marshall [EMAIL PROTECTED] writes:
If we sort the page info by available space, we could then use binary
search to find space thresholds when we are handling oversubscription.
The list-of-chunks storage layout provides only limited traction for
searching anyway, and none
This directly answers my question (wasn't previously aware that xid
could be queried out in such a useful fashion). Not only does this
accomplish what I need, but now allows me to not use select ... for
update and stick with a transaction based locking mechanism. The 'Why'
isn't that
On Thu, Feb 27, 2003 at 02:45:46PM -0500, mlw wrote:
Are there any reasons why it should not be an option on pg_dump?
I wonder whether that mightn't be the best answer. Maybe it should
even be the default, and --noanalyse an option.
I agree that from the point of view of simplifying
In contrib/btree_gist/ I see:
CREATE FUNCTION gint4_union(bytea, internal)
RETURNS int4
AS 'MODULE_PATHNAME'
LANGUAGE 'C';
but gint4_union does this:
INT4KEY *out = palloc(sizeof(INT4KEY));
[...]
PG_RETURN_POINTER(out);
Is the int4 return type declared above a bug?
--
Itai
Stephen Marshall [EMAIL PROTECTED] writes:
If I understand the concept correctly, the histogram will only be
calculated when MultiRecordFreeSpace is called AND the FSM is
oversubscribed. However, when it is called, we will need to calculate a
histogram for, and potentially trim data from,
I didn't get any responses on pgsql-sql, so I'm re-posting here...
Is the GiST examples I've looked through, in the picksplit functions,
I see code that looks roughly like this:
bytea *entryvec = (bytea *) PG_GETARG_POINTER(0);
OffsetNumber i, maxoff;
maxoff = ((VARSIZE(entryvec) -
On Thu, Feb 27, 2003 at 03:12:36PM -0500, Tom Lane wrote:
Although I suggested doing a single unconditional ANALYZE at the end
of the script, second thought leads me to think the per-table ANALYZE
(probably issued right after the table's data-load step) might be
better. That way you'd not
On Wed, Feb 12, 2003 at 05:42:44PM -0500, Tom Lane wrote:
I've been thinking hard for the last few days about how to do space
reclamation in b-tree indexes, i.e., recycle pages that are in
no-longer-useful portions of the tree structure.
Hi Tom,
I've seen your applied changes. It looks real
Alvaro Herrera [EMAIL PROTECTED] writes:
Putting the freelist on FSM rather on the metapage still strikes me as
kind of strange; I remember you said the metapage was not enough space
for all the possible candidate pages, but the FSM is even more limited.
Well, on modern machines there should
Two things I regret: one is being unable to see the changes as patches
the way you applied them, to get a sense of how the code evolved.
Unfortunately the interface to CVS via web does not allow me to see it,
or I don't know how to use it. It's not that important, however,
because I was
Two things I regret: one is being unable to see the changes as patches
the way you applied them, to get a sense of how the code evolved.
Unfortunately the interface to CVS via web does not allow me to see it,
or I don't know how to use it. It's not that important, however,
because I was
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
The other is that now I am left without a graduate project :-(
[ various good suggestions ]
FWIW, I would much rather see effort put into GiST than hash indexes.
I think that btree and GiST will be our two primary index types in the
long run.
On Thursday 27 February 2003 13:12, mlw wrote:
Tom Lane wrote:
A single ANALYZE at the end of the script would be sufficient. I'm not
sure that pg_dump should do this automatically though. If you're not
done restoring then it's mostly a waste of cycles, and how is pg_dump to
know that?
Larry Rosenman writes:
[EMAIL PROTECTED] wrote:
Bison is 1.28. Yacc (version 91.7.30) gives a similar error.
you need Bison 1.50 or later...
Which you can get binary and src RPMs of from:
http://services.csl.co.uk/postgresql/
L:
---(end of
Merlin,
Just as a suggestion: In most of my applications, we have a security layer
which is implemented through server-side functions. These functions keep a
table updated which contains:
lock_table
record_id
lock_user
time_locked
This allows us to avoid nasty your update cannot be
D'Arcy J.M. Cain wrote:
On Thursday 27 February 2003 13:12, mlw wrote:
Tom Lane wrote:
A single ANALYZE at the end of the script would be sufficient. I'm not
sure that pg_dump should do this automatically though. If you're not
done restoring then it's mostly a waste of cycles, and how
34 matches
Mail list logo
