On Sat, Apr 29, 2006 at 06:39:21PM -0400, Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
The general problem seems to be that a transaction has no way to promise
never to touch a specific table. Maybe some kind of negative lock
would help here - you'd do exclude table foo from
Jim C. Nasby [EMAIL PROTECTED] writes:
I'd actually been thinking about this recently, and had come up with the
following half-baked ideas:
Allow a transaction to specify exactly what tables it will be touching,
perhaps as an extension to BEGIN. Should any action that transaction
takes
Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
I'd actually been thinking about this recently, and had come up with the
following half-baked ideas:
Allow a transaction to specify exactly what tables it will be touching,
perhaps as an extension to BEGIN. Should any action that
On Thu, May 04, 2006 at 03:30:34PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
I'd actually been thinking about this recently, and had come up with the
following half-baked ideas:
Allow a transaction to specify exactly what tables it will be touching,
perhaps as an
I guess what I'm asking for is a kind of REBUILD TABLE which is not
MVCC by definition but it would be useful in the mentioned queue table
case.
vaccum full ?
Nope, it won't work, it will still leave in all the dead tuples
potentially visible by old transactions, even if those
Csaba Nagy wrote:
There is, I believe, a problem there; there is a scenario where data
can get dropped out from under those old connections.
This has been added to the TODO...
http://www.postgresql.org/docs/faqs.TODO.html
* Make CLUSTER preserve recently-dead tuples per MVCC requirements
Florian G. Pflug [EMAIL PROTECTED] writes:
The general problem seems to be that a transaction has no way to promise
never to touch a specific table. Maybe some kind of negative lock
would help here - you'd do exclude table foo from transaction at the
start of your transaction, which would
Hi all,
Short background: postgres does not support very well queue type tables
in an environment where these queue tables are small in size but heavily
inserted/updated/deleted, while there are activities in the system which
cause long running transactions. The reason is that the queue table
2006-04-28 (금), 14:40 +0200, Csaba Nagy 쓰시길:
I placed a cron job to
cluster the queue table on it's PK index.
what does that mean?
--
my site a href=http://www.myowndictionary.com;myowndictionary/a was
made to help students of many languages learn them faster.
On Fri, 2006-04-28 at 15:20, kmh496 wrote:
2006-04-28 (금), 14:40 +0200, Csaba Nagy 쓰시길:
I placed a cron job to
cluster the queue table on it's PK index.
what does that mean?
Means execute:
CLUSTER pk_queue_table ON queue_table;
See
On Apr 28, 2006, at 9:32 AM, Csaba Nagy wrote:
I'm not sure how this operation can work in the presence of other long
running transactions which did not touch the queue table yet, but it
actually does work, I can confirm that. Is it violating MVCC maybe ?
It sounds like it does potentially
Csaba Nagy [EMAIL PROTECTED] writes:
I'm not sure how this operation can work in the presence of other long
running transactions which did not touch the queue table yet, but it
actually does work, I can confirm that. Is it violating MVCC maybe ?
Yes :-(. I think you can get away with it if
actually does work, I can confirm that. Is it violating MVCC maybe ?
Yes :-(. I think you can get away with it if all your transactions that
[snip]
Well, I actually don't want to get away this time :-)
This table is only processed by the queue manager and that uses very
short transactions,
[EMAIL PROTECTED] (Csaba Nagy) writes:
On Fri, 2006-04-28 at 15:20, kmh496 wrote:
2006-04-28 (ê¸), 14:40 +0200, Csaba Nagy ì°ì길:
I placed a cron job to
cluster the queue table on it's PK index.
what does that mean?
Means execute:
CLUSTER pk_queue_table ON queue_table;
See
There is, I believe, a problem there; there is a scenario where data
can get dropped out from under those old connections.
This has been added to the TODO...
http://www.postgresql.org/docs/faqs.TODO.html
* Make CLUSTER preserve recently-dead tuples per MVCC requirements
OK, I can see
On Friday 28 April 2006 12:20, Csaba Nagy wrote:
There is, I believe, a problem there; there is a scenario where data
can get dropped out from under those old connections.
This has been added to the TODO...
http://www.postgresql.org/docs/faqs.TODO.html
* Make CLUSTER preserve
16 matches
Mail list logo
