Tom Lane wrote:
So I coded up a patch for this, based on the idea of creating a
quasi-subtransaction that affects only GUC while entering/exiting a
function that has GUC settings attached. The specified settings are
applied as if by SET LOCAL before starting function execution, and then
they
Hi
I've updated the lazy xid assignment patch, incorporating the results of the
discussion over the past few days. I'll try to explain what the patch does,
and why. This reasoning got a bit lengthy, but I felt that I should summarize
my own thought, plus the relevant parts of the discussions
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
A few comments ...
GetOldestXmin() is changed slightly - it used to use
GetTopTransactionId() as a starting point for it's xmin
calculation, falling back to ReadNewTransactionId() if called
from outside a transaction. Now, it always
August Zajonc wrote:
I assume that you meant that mail to go to pgsql-hackers too, and just
clicked the wrong button by accident. If not, please forgive that
I post the reply to the list.
Are you going to look at putting temp relations into a special folder
for 8.4? I really like that idea for
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Florian G. Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
I don't much like this, since as I mentioned before I don't think
MyProc-xmin is going to be constant over a whole transaction for
long. I don't think xid_age is performance
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
I don't much like this, since as I mentioned before I don't think
MyProc-xmin is going to be constant over a whole transaction for
long. I don't think xid_age is performance-critical in any way,
so I'd vote for letting
Alvaro Herrera wrote:
Florian G. Pflug wrote:
August Zajonc wrote:
I assume that you meant that mail to go to pgsql-hackers too, and just
clicked the wrong button by accident. If not, please forgive that
I post the reply to the list.
Are you going to look at putting temp relations
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Actually, after more thought on this I'd
argue that the only really correct reference for computing a xid's
age is GetOldestXmin(). It's what VACUUM uses to calculate the
freezeLimit, after all. Now, using GetOldestXmin() directly
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
And I'm quite tempted to not flush the XLOG at all during ABORT, and to
only force synchronous commits if one of the to-be-deleted files is
non-temporary.
+1 on the first, but -1 on the second, because we'd have to track
whether
Gregory Stark wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
It seems doable, but it's not pretty. One possible scheme would be to
emit a record *after* chosing a name but *before* creating the file,
No, because the way you know the name is good is a successful
open(O_CREAT).
The idea
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
+1 on the first, but -1 on the second, because we'd have to track
whether deleted files are temp or not ... it's very unclear that it'd
be worth the trouble.
I'm confused. smgrcreate already tracks if it created
Simon Riggs wrote:
Async Commit is a useful feature, yet it requires some additional
application code to be added to appropriate transactions. That code is
then clearly version dependent, which may not always be desirable.
It would be good if there was a way to make that a DBA-controllable
Tom Lane wrote:
Whether that's common enough to be worth special optimization, I'm
not sure. Your point that the transaction may have been heavyweight
enough that it'd hardly matter is still on-target, you just got there
by the wrong reasoning ;-)
My point is that there is hardly any effort
Hi
When we lazily assign XIDs, we gain another flag beside the existing
MyXactMadeTempRelUpdates, MyXactMadeXLogEntry, MyLastRecPtr and smgr's
pendingDeletes to tell what kind of actions a transaction performed. Adding
TransactionIsIsValid(GetCurrentTransactionIdIfAny()) on top of that
makes
Hi
Since generating transient XIDs (named ResourceOwnerIDs in my patch, since
their lifetime is coupled to the lifetime of a transaction's toplevel
resource owner) seems to be to way to go for lazx xid assignment, I need
to find a way to represent them in the pg_locks view.
ResourceOwnerIds are
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
I propose to do the following in my lazy XID assignment patch - can
anyone see a hole in that?
One comment is that at the time we make an entry into smgr's
pending-deletes list, I think we might not have acquired an XID yet
--- if I
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Since generating transient XIDs (named ResourceOwnerIDs in my patch, since
their lifetime is coupled to the lifetime of a transaction's toplevel
resource owner) seems to be to way to go for lazx xid assignment, I need
to find a way
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
One thought here is that it's not clear that we really need a concept of
transaction-controlled vs not-transaction-controlled xlog records
anymore.
I've thinking about keeping XLOG_NO_TRAN, and doing
if (!no_tran
Hi
I'm confused about whether int8s work on a machine on which
INT64_IS_BUSTED. My reading of the code suggests that int8
will be available, but be, well, busted in such a machine.
For example, int8mul seems as if I'd just return the wrong
answer on such a machine.
Or are platforms with
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
What about the following.
.) Remove the right-hand side XID from pg_locks (The one holder or waiter
of the lock). It seems to make more sense to store a RID here,
Yeah, we have to do that since there might not *be* an XID holding
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
I'm confused about whether int8s work on a machine on which
INT64_IS_BUSTED. My reading of the code suggests that int8
will be available, but be, well, busted in such a machine.
The datatype exists, but it's really only int32
Tom Lane wrote:
One comment is that at the time we make an entry into smgr's
pending-deletes list, I think we might not have acquired an XID yet
--- if I understand your patch correctly, a CREATE TABLE would acquire
an XID when it makes its first catalog insertion, and that happens
after
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
One comment is that at the time we make an entry into smgr's
pending-deletes list, I think we might not have acquired an XID yet
Hm.. I was just going to implement this, but I'm now wondering if
thats really worth it.
Basically
Tom Lane wrote:
I wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Yeah - I do not really like that dual-locking thing either. But it makes
prepared transaction handling much easier - if we were to only lock the
RID, we'd have to store the rid-xid mapping for prepared transactions
Hmmm
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Sounds good, if we decide to go with the transient XID idea. So below
for an alternative that I just came up with.
This proposal appears to require taking and releasing a brand-new lock
type every time a snapshot is made or destroyed
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
What do you think about solving the requirements of the *first* waiting
phase (Where we wait for current ShareLock holders) inside the lock manager?
The only real downside I can see is that I feel uneasy about messing with
that code
I'm resending this without that actual patch attached, since my first
mail didn't get through. The patch can be found here:
http://soc.phlo.org/lazyxidassign.patch
Hi
Lately, there was some interest in assigning XIDs for toplevel Transactions
only when the transaction actually needs one (that
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
I've spent the last few days factoring out that work, and turning it into
a general solution. The result is this patch, which basically does the following
.) It defines a special TemporaryTransactionId that is used as an xact's xid
Edoardo wrote:
On Aug 24, 4:27 pm, [EMAIL PROTECTED] (Heikki Linnakangas)
wrote:
Edoardo wrote:
- Google Summer of Code effort by Florian Pflug
I would like to talk about the last one: I couldn't find any website /
explanation or further post.
The google
Ben Tilly wrote:
On 8/22/07, Michael Glaesemann [EMAIL PROTECTED] wrote:
On Aug 22, 2007, at 20:49 , Ben Tilly wrote:
If your implementation accepts:
group by case when true then 'foo' end
What would that mean? Regardless of whether or not it's accepted, it
should have *some* meaning.
Kevin Grittner wrote:
On Thu, Aug 23, 2007 at 3:01 PM, in message [EMAIL PROTECTED],
Tom Lane [EMAIL PROTECTED] wrote:
The only argument I've
heard that carries much weight with me is that it eases porting from
other DBMS's that allow this. Are there any others besides Oracle?
select *
Ben Tilly wrote:
On 8/22/07, Gregory Stark [EMAIL PROTECTED] wrote:
Ben Tilly [EMAIL PROTECTED] writes:
2. Why is 'non-integer constant in GROUP BY' an error?
Hm... I was a bit surprised by this warning myself. IIRC there was an
implementation convenience issue.
If your implementation
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Is enlarging the xid field something we should consider for 8.4?
No. We just got the tuple header down to 24 bytes, we are not going
to give that back and then some.
If you are processing 6K transactions per second, you can afford to
Hi
Since my attempts to find a simple solution for the read-only query
locking problems (Once that doesn't need full wal logging of lock
requests) haven't been successfully yet, I've decided to turn to the
problems of tracking a snapshot on the slaves for now. (Because first
such a snapshot is
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Anyway, if you believe that DDL is infrequent, why are you resistant
to the idea of WAL-logging cache flushes?
First, cache invalidations are not the only problem caused by replaying
system-table updates. The whole SnapshotNow
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
I came up with the following plan for both inval events and locks
.) Store two flags in the commit record of a transaction, for
transaction generated inval events and transaction held an
access exlusive lock.
.) Upon replay
Simon Riggs wrote:
On Sun, 2007-07-22 at 19:58 +0200, Florian G. Pflug wrote:
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
I'm currently working on correctly flushing the
catalog/relation/sgmr caches on a readonly PITR
slave during recovery.
I don't believe there is any
Hi
I'm currently working on correctly flushing the
catalog/relation/sgmr caches on a readonly PITR
slave during recovery. These are the things that
currently cause me headache.
1) It seems that the btree code sends out relcache
invalidation msgs during normal operation
(No DDL statements
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
I'm currently working on correctly flushing the
catalog/relation/sgmr caches on a readonly PITR
slave during recovery.
I don't believe there is any workable solution to that short of logging
cache-flush operations in WAL.
I still
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Leaving aside the btree issues, are you worried about performance
problems, or can aggressive cache flushing hurt correctness?
It shouldn't hurt correctness, but I don't think you entirely grasp
the magnitude of the performance hit
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
My basic assumption is that DDL is something quite uncommon on a
production system.
I'm not sure I believe that, because of temp tables. There's also
the problem that plain VACUUM (or ANALYZE) causes a relcache flush
to update
Hi
To test my PITR-slave readonly-query patch, I continously do
insert into test ...
pg_switch_xlog()
sleep 1
on the master, and let the slave process the generated xlogs
The log output on the slave looks the following (unnecessary lines remove)
LOG: restored log file 0001016E
Simon Riggs wrote:
On Thu, 2007-07-12 at 16:17 +0200, Florian G. Pflug wrote:
To test my PITR-slave readonly-query patch, I continously do
insert into test ...
pg_switch_xlog()
sleep 1
on the master, and let the slave process the generated xlogs
The log output on the slave looks the following
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I'd be much more comfortable if LOCK TABLE caused a message to the log
if it is executed on any system table.
Enabled by set training_wheels = on, perhaps?
This is really pretty silly to be getting worked up about. The command
in
Florian G. Pflug wrote:
snipped my own mail
Please disregard - I was confusing xlogid with xlog segments, so
most of my mail was nonsense.
I've fixed my problem by storing not the EndRecPtr, but rather
the ReadRecPtr, in shmem and rereading the last already applied
record in my bgreplay process
Hi
After struggling with understanding xlog.c and friends far enough to
be able to refactor StartupXLOG to suit the needs of concurrent recovery,
I think I've finally reached a workable (but still a bit hacky) solution.
My design is centered around the idea of a bgreplay process that
takes over
Michael Paesold wrote:
Alvaro Herrera wrote:
So what you are proposing above amounts to setting scale factor = 0.05.
The threshold is unimportant -- in the case of a big table it matters
not if it's 0 or 1000, it will be almost irrelevant in calculations. In
the case of small tables, then the
Tom Lane wrote:
[ back to dealing with this patch, finally ]
Florian G. Pflug [EMAIL PROTECTED] writes:
While creating the patch, I've been thinking if it might be worthwile
to note that we just did recovery in the ShutdownCheckpoint
(or create a new checkpoint type RecoveryCheckpoint
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
Conclusion: we should apply Florian's patch as-is in 8.2, do something
morally equivalent in 8.1 and before, and invent a
CrashRecoveryCheckpoint record type in HEAD.
Sounds good.
Actually, now that I look closer
PFC wrote:
On Fri, 22 Jun 2007 16:43:00 +0200, Bruce Momjian [EMAIL PROTECTED] wrote:
Simon Riggs wrote:
On Fri, 2007-06-22 at 14:29 +0100, Gregory Stark wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Tom Lane wrote:
untrustworthy disk hardware, for instance. I'd much rather use names
Richard Huxton wrote:
Bruce Momjian wrote:
Tom Lane wrote:
What's wrong with synchronous_commit? It's accurate and simple.
That is fine too.
My concern would be that it can be read two ways:
1. When you commit, sync (something or other - unspecified)
2. Synchronise commits (to each other?
Gregory Stark wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
I agree. XML seems like a fairly natural fit for this. Just as people should
not try to shoehorn everything into XML, neither should they try to shoehorn
everything into a relational format either.
Now all we need is an XML schema
Heikki Linnakangas wrote:
Jim C. Nasby wrote:
On Thu, Jun 07, 2007 at 10:16:25AM -0400, Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Thinking about this whole idea a bit more, it occured to me that the
current approach to write all, then fsync all is really a historical
Dann Corbit wrote:
-Original Message-
From: Hannu Krosing [mailto:[EMAIL PROTECTED]
Since libpq function PQfsize returns -2 for all constant character
strings in SQL statements ... What is the proper procedure to determine
the length of a constant character column after query execution
Joshua D. Drake wrote:
Take the following:
INFO: analyzing pg_catalog.pg_authid
INFO: pg_authid: scanned 1 of 1 pages, containing 5 live rows and 0
dead rows; 5 rows in sample, 5 estimated total rows
The above is completely redundant. Why not just say:
INFO: pg_authid: scanned 1 of 1
Simon Riggs wrote:
On Wed, 2007-06-06 at 16:11 +0200, Florian G. Pflug wrote:
.) Added a new GUC operational_mode, which can be set to either
readwrite or readonly. If it is set to readwrite (the default),
postgres behaves as usual. All the following changes are only
in effect
Heikki Linnakangas wrote:
Florian G. Pflug wrote:
Jeff Davis wrote:
Are you referring to the size of the xip array being a problem? Would it
help to tie the size of the xip array to max_connections? I understand
that max_connections might be greater on the master, but maybe something
similar
Jeff Davis wrote:
On Wed, 2007-06-06 at 22:36 +0100, Simon Riggs wrote:
.) Transactions are assigned a dummy xid ReadOnlyTransactionId, that
is considered to be later than any other xid.
So you are bumping FirstNormalTransactionId up by one for this?
You're assuming then that we will
Matthew T. O'Connor wrote:
Florian G. Pflug wrote:
Work done so far:
-
.) Don't start autovacuum and bgwriter.
Do table stats used by the planner get replicated on a PITR slave? I
assume so, but if not, you would need autovac to do analyzes.
Yes - everything that get wal
Jeff Davis wrote:
On Wed, 2007-06-06 at 16:11 +0200, Florian G. Pflug wrote:
.) Since the slaves needs to track an Snapshot in shared memory, it cannot
resize that snapshot to accomodate however many concurrent transactions
might have been running on the master. My current plan
Hi
I'm currently working on splitting StartupXLog into smaller
parts, because I need to reuse some of the parts for concurrent
wal recovery (for my GSoC project)
The function recoveryStopsHere in xlog.c checks if we should
stop recovery due to the values of recovery_target_xid and
Simon Riggs wrote:
On Mon, 2007-05-28 at 19:56 -0400, Bruce Momjian wrote:
Added to TODO:
* Fix self-referential UPDATEs seeing inconsistent row versions in
read-committed mode
http://archives.postgresql.org/pgsql-hackers/2007-05/msg00507.php
I'm sorry guys but I don't agree this is a
Andrew Dunstan wrote:
What would making a branch actually do for you? The only advantage I can
see is that it will give you a way of checkpointing your files. As I
remarked upthread, I occasionally use RCS for that. But mostly I don't
actually bother. I don't see how you can do it reasonably
Richard Huxton wrote:
Hiroshi Inoue wrote:
Florian G. Pflug wrote:
I think there should be a big, fat warning that self-referential
updates have highly non-obvious behaviour in read-committed mode,
and should be avoided.
It seems pretty difficult for PostgreSQL rule system to avoid
Richard Huxton wrote:
Richard Huxton wrote:
Heikki Linnakangas wrote:
The problem is that the new tuple version is checked only against the
condition in the update rule, id=OLD.id, but not the condition in the
original update-claus, dt='a'.
Yeah, that's confusing :(.
Bit more than just
Zdenek Kotala wrote:
I did not find forensics in translator and It mentions in Oxford
vocabulary but explanation is not clear for me. I agree with Bruce It is
not good name. What about short form of diagnostic diag?
Doesn't forensics basically mean to find the cause of something
*after* it
Martin Langhoff wrote:
So - if you are committed to providing your gateway long term to
Florian, I'm happy to drop my gateway in favour of yours.
(Florian, before basing your code on either you should get a checkout of
Aidan's and mine and check that the tips of the branches you are working
Aidan Van Dyk wrote:
* Florian G. Pflug [EMAIL PROTECTED] [070430 08:58]:
It seems as if git pulls all revisions of all files during the pull -
which it shouldn't do as far as I understand things - it should only
pull those objects referenced by some head, no?
Git pulls full history
Simon Riggs wrote:
On Thu, 2007-04-19 at 22:37 +0200, Florian G. Pflug wrote:
The problem is that after a crash, the master might complete incomplete
actions via rm_cleanup() - but since it won't wal-log those changes,
the slave won't know about this. This will at least prevent the creation
Hi
I believe I have discovered the following problem in pgsql 8.2 and HEAD,
concerning warm-standbys using WAL log shipping.
The problem is that after a crash, the master might complete incomplete
actions via rm_cleanup() - but since it won't wal-log those changes,
the slave won't know about
Martin Langhoff wrote:
Aidan Van Dyk wrote:
And remember the warning I gave that my conversion is *not* a direct CVS
import - I intentionally *unexpand* all Keywords before stuffing them
into GIT so that merging and branching can ignore all the Keyword
conflicts...
My import is unexpanding
Alvaro Herrera wrote:
Ah, it seems the SVN repo just got its first user ;-) Congratulations.
Ask Joshua to send you a Command Prompt tee shirt, maybe he is excited
enough.
I hope the fact that I use the SVN repo just to get the changes into
git doesn't reduce my chances of getting that
Alvaro Herrera wrote:
Florian G. Pflug wrote:
Alvaro Herrera wrote:
Ah, it seems the SVN repo just got its first user ;-) Congratulations.
Ask Joshua to send you a Command Prompt tee shirt, maybe he is excited
enough.
I hope the fact that I use the SVN repo just to get the changes into
git
Joshua D. Drake wrote:
http://projects.commandprompt.com/public/pgsql/browser
or do the anonymous checkout with:
svn co http://projects.commandprompt.com/public/pgsql/repo/
But if you have a checked out tree, does it work to do an update after
the tree has been regenerated? As far as I
Martin Langhoff wrote:
Hi Florian,
I am right now running an rsync of the Pg CVS repo to my work machine to
get a git import underway. I'm rather keen on seeing your cool PITR Pg
project go well and I have some git+cvs fu I can apply here (being one
of the git-cvsimport maintainers) ;-)
Cool -
Aidan Van Dyk wrote:
Martin Langhoff wrote:
Well, now that more than one of us are working with git on PostgreSQL...
I've had a repo conversion running for a while... I've only got it to what
I consider stable last week:
http://repo.or.cz/w/PostgreSQL.git
Zoltan Boszormenyi wrote:
Tom Lane írta:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
Also, the current grammar is made to give a syntax error
if you say colname type GENERATED BY DEFAULT AS ( expr ).
But it makes the grammar unbalanced, and gives me:
bison -y -d gram.y
conflicts: 2
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
These files are generated (from gram.y, pgc.l and preproc.y
respectievly) and are not present in the CVS repo, though I think they
have been at some point.
It's strange that other generated files (that have also been in the repo
in the
Tom Lane wrote:
Mark Kirkwood [EMAIL PROTECTED] writes:
Tom Lane wrote:
The current documentation for RESET exhibits a certain lack of, um,
intellectual cohesiveness:
Synopsis
RESET configuration_parameter
RESET ALL
RESET { PLANS | SESSION | TEMP | TEMPORARY }
Maybe DISCARD for the plans
Hi
When I try to build CVS HEAD on OSX 10.4, compiling
src/interfaces/ecpg/preproc/preproc.c fails with:
In file included from preproc.y:6951:
pgc.l:3:20: error: config.h: No such file or directory
In file included from pgc.l:28,
from preproc.y:6951:
preproc.h:996: error:
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
When I try to build CVS HEAD on OSX 10.4, compiling
src/interfaces/ecpg/preproc/preproc.c fails with:
...
If I delete pgc.c, it is rebuilt automatically, and then
preproc.c compiles just fine.
...
I'm using gcc 4.0.1, flex 2.5.4
Hi
I'm very excited that my project for implementing read-only queries
on PITR slaves was accepted for GSoC, and I'm now trying to work
out what tools I'll use for that job.
I'd like to be able to create some sort of branches and tags for
my own work (only inside my local repository of course).
Joshua D. Drake wrote:
Alexey Klyukin wrote:
Alvaro Herrera wrote:
But if you have a checked out tree, does it work to do an update after
the tree has been regenerated? As far as I know, the repo is generated
completely every few hours, so it wouldn't surprise me that the checked
out copy is
Nikolay Samokhvalov wrote:
On 4/10/07, Tom Lane [EMAIL PROTECTED] wrote:
Nikolay Samokhvalov [EMAIL PROTECTED] writes:
I remember several cases when people (e.g. me :-) ) were spending some
time trying to find an error in some pl/pgsql function and the reason
lied in incorrect work with
Neil Conway wrote:
On Tue, 2007-04-10 at 18:28 +0200, Peter Eisentraut wrote:
The problem is that most of the standard methods are platform dependent, as
they require MAC addresses or a good random source, for instance.
http://archives.postgresql.org/pgsql-patches/2007-01/msg00392.php
ISTM
Hi
Does anyone know if pgsnmpd is still actively developed?
The last version (0.1b1) is about 15 months old.
greetings, Florian Pflug
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Tom Lane wrote:
Pavan Deolasee [EMAIL PROTECTED] writes:
How about storing the snapshot which we used during planning in
CachedPlanSource, if at least one index was seen unusable because
its CREATE INDEX transaction was seen as in-progress ?
I'm getting tired of repeating this, but: the
Tom Lane wrote:
Pavan Deolasee [EMAIL PROTECTED] writes:
What I am suggesting is to use ActiveSnapshot (actually
Florian's idea) to decide whether the transaction that created
index was still running when we started. Isn't it the case that
some snapshot will be active when we plan ?
I do not
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
I do not think you can assume that the plan won't be used later with
some older snapshot.
So maybe we'd need to use the SerializableSnapshot created at the start
of each transaction for this check
Pavan Deolasee wrote:
On 3/30/07, Florian G. Pflug [EMAIL PROTECTED] wrote:
My idea was to store a list of xid's together with the cached plan that
are assumed to be uncommitted accoring to the IndexSnapshot. The query
is replanned if upon execution the IndexSnapshot assumes that one
Simon Riggs wrote:
On Fri, 2007-03-30 at 16:34 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
2. pg_stop_backup() should wait until all archive files are safely
archived before returning
Not sure I agree with that one. If it fails, you can't tell whether the
action is done and
Pavan Deolasee wrote:
In this specific context, this particular case is easy to handle because
we are only concerned about the serializable transactions started before
CREATE INDEX commits. If PREPARE can see the new index, it
implies that the CI transaction is committed. So the transaction
Pavan Deolasee wrote:
On 3/29/07, Florian G. Pflug [EMAIL PROTECTED] wrote:
Yes, but the non-index plan PREPARE generated will be used until the end
of the session, nut only until the end of the transaction.
Frankly I don't know this works, but are you sure that the plan will
be used until
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
ISTM that the run-another-transaction-afterwards idea is the only one
that does everything I think we need. I really do wish we could put in a
wait, like CIC, but I just think it will break existing programs.
Actually, there's a
Simon Riggs wrote:
On Thu, 2007-03-29 at 17:27 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
ISTM that the run-another-transaction-afterwards idea is the only one
that does everything I think we need. I really do wish we could put in a
wait, like CIC, but I just think it will
Kenneth Marshall wrote:
We use DSPAM as one of our anti-spam options. Its UPDATE pattern is to
increment a spam counter or a not-spam counter while keeping the user and
token information the same. This would benefit from this optimization.
Currently we are forced to use MySQL with MyISM tables
Simon Riggs wrote:
On Wed, 2007-03-28 at 22:24 +0530, Pavan Deolasee wrote:
Just when I thought we have nailed down CREATE INDEX, I realized
that there something more to worry. The problem is with the HOT-chains
created by our own transaction which is creating the index. We thought
it will be
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Couldn't you store the creating transaction's xid in pg_index, and
let other transaction check that against their snapshot like they
would for any tuple's xmin or xmax?
What snapshot? I keep having to remind people that system
Pavan Deolasee wrote:
On 3/28/07, Tom Lane [EMAIL PROTECTED] wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Couldn't you store the creating transaction's xid in pg_index, and
let other transaction check that against their snapshot like they
would for any tuple's xmin or xmax?
What
Oleg Bartunov wrote:
On Fri, 23 Mar 2007, Florian G. Pflug wrote:
Teodor Sigaev wrote:
For given schema and server's locale, it's possible to have several
FTS configurations, but the only one (with special flag enabled)
could be used as default. Current (active) FTS configuration contains
101 - 200 of 303 matches
Mail list logo
