Heikki Linnakangas wrote:
Tom Lane wrote:
I had an idea this morning that might be useful: back off the strength
of what we try to guarantee. Specifically, does it matter if we leak a
file on crash, as long as it isn't occupying a lot of disk space?
(I suppose if you had enough crashes to accum
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,
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 into a
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-cr
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 tr
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 c
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
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 here
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 ne
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
setti
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. smg
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
ope
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
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 re
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 creating
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 i
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
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 INT64_I
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_TR
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,
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
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
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 thin
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 messin
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 sna
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 mappin
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
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 is
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
linkhttp://code.google.com/soc/postgr
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, 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.
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 ne
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
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
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 w
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
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 ma
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-fl
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 a
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
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
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 qu
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
Florian G. Pflug wrote:
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. Then I can
Hi
When ReadRecord encounters an XLOG_SWITCH record, it does
EndRecPtr.xrecoff += XLogSegSize - 1;
EndRecPtr.xrecoff -= EndRecPtr.xrecoff % XLogSegSize;
which seems to set xrecoff to either 0 (if it was 0)
or to XLogSegSize (if it was > 0).
Note that xrecoff == XLogSegSize is kind of "denormaliz
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.
Actu
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 ty
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 t
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?
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
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
arti
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 sche
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 b
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
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
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
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 if
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
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 th
Hi
This is a description of the GSoC work I've so for on readonly
support for PITR slaves. I'm looking for any kind of comments
on this - I want to make sure that I work in a direction that
the community approves.
Work done so far:
-
.) Added a new GUC operational_mode, which can
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
recovery_targe
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 T
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 of
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 such
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 nor
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
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 h
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
on
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 c
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 thi
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 th
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
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 th
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 shift/
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
git://repo.or.cz/PostgreSQL.g
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 -
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 know,
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
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 t-shirt
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
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: conflic
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 n
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).
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
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 w
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
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 a
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
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 f
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
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 pl
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
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 showsto
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
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
start
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 the
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 havi
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
101 - 200 of 306 matches
Mail list logo