This is just an update against CVS because there was a conflict due to the
configure Kerberos change.
There is one bug fix in indextuple.c. I need to think a bit on how to write a
regression test to test it.
I'll try to attach the patch as an attachment this time, crossing my fingers.
Jeremy Drake [EMAIL PROTECTED] writes:
This version of the patch includes documentation changes. Please
review...
Applied with minor revisions --- in particular, I thought the initial
owner of a language should be its creator, full stop, rather than the
rather strange (and undocumented)
On Fri, 2007-03-23 at 17:35 -0400, Tom Lane wrote:
To make intra-transaction advancing of xmin possible, we'd need to
explicitly track all of the backend's live snapshots, probably by
introducing a snapshot cache manager that gives out tracked
refcounts
as we do for some other structures like
On Sat, 2007-03-24 at 11:48 -0400, Tom Lane wrote:
Also, at some point a long-running transaction becomes a bottleneck
simply because its XID is itself the oldest thing visible in the
ProcArray and is determining everyone's xmin. How much daylight is
there really between your xmin is old and
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
[ IDENTITY/GENERATED patch ]
I got around to reviewing this today.
- unique index checks are done in two steps
to avoid inflating the sequence if a unique index check
is failed that doesn't reference the IDENTITY column
This is just not
Simon Riggs [EMAIL PROTECTED] writes:
Did Heikki's patch to move the xmin forward during VACUUM get rejected?
That seems like it has a much wider use case.
It's still in the queue (which I have finally started to review in
earnest).
regards, tom lane
Simon Riggs wrote:
On Sat, 2007-03-24 at 11:48 -0400, Tom Lane wrote:
Also, at some point a long-running transaction becomes a bottleneck
simply because its XID is itself the oldest thing visible in the
ProcArray and is determining everyone's xmin. How much daylight is
there really
Bruce Momjian [EMAIL PROTECTED] writes:
Simon Riggs wrote:
How much does it cost to optimise for this case?
Zero cost. It involves just tracking if there are any old snapshots,
I will be fascinated to hear how you define that as zero cost. It might
be relatively low, but it's not zero, and
This is an optimization so I was thinking of something simpler, like
incrementing/decrementing a counter every time we allocate/free a
snapshot (like in the patch), and updating MyProc-xmin only if there
are no open snapshots. I don't think it is worth tracking anything more
complicated than
On Mon, 26 Mar 2007, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
This version of the patch includes documentation changes. Please
review...
Applied with minor revisions --- in particular, I thought the initial
owner of a language should be its creator, full stop, rather than
Bruce Momjian [EMAIL PROTECTED] writes:
This is an optimization so I was thinking of something simpler, like
incrementing/decrementing a counter every time we allocate/free a
snapshot (like in the patch), and updating MyProc-xmin only if there
are no open snapshots. I don't think it is worth
Jeremy Drake [EMAIL PROTECTED] writes:
On Mon, 26 Mar 2007, Tom Lane wrote:
Applied with minor revisions --- in particular, I thought the initial
owner of a language should be its creator, full stop, rather than the
rather strange (and undocumented) behavior you had.
The reason I did it like
Tom Lane wrote:
On the whole though I think we should let this idea go till 8.4; we have
a lot to deal with for 8.3 and a definite shortage of evidence that
advancing xmin will buy much. Mu gut feeling is that the above design
would save about enough in snapshot-copying costs to pay for its
I have a question about what would happen for a transaction running a command
like COPY FROM. Is it possible it would manage to arrange to have no live
snapshots at all? So it would have no impact on concurrent VACUUMs? What about
something running a large pg_restore?
Tom Lane [EMAIL PROTECTED]
Gregory Stark wrote:
I have a question about what would happen for a transaction running a command
like COPY FROM. Is it possible it would manage to arrange to have no live
snapshots at all? So it would have no impact on concurrent VACUUMs? What about
something running a large pg_restore?
Jeremy Drake wrote:
On Thu, 22 Mar 2007, Tom Lane wrote:
AFAIR, the reason there's no TextPGetDatum (and ditto for lots of other
datatypes) is lack of obvious usefulness. A function dealing with a
text * doesn't normally have reason to convert that to a Datum until
it returns --- and
Greg, do you want to submit a patch for this or add a TODO item for this?
---
Gregory Stark wrote:
I've uploaded a quick hack to store numerics in 8 bytes when possible.
Hi all
Here's the current version of the enums patch. Not much change from last
time, the only thought-inducing stuff was fixing up some macros that
changed with the VARLENA changes, and adding a regression test to do
basic checking of RI behavior, after the discussions that we had
recently
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
... but we won't come out ahead unless advancing xmin
intra-transaction really helps, and I'm not sure I believe that (except
in the special case of VACUUM, and we already have a solution for that,
which would be independent of this).
Bruce Momjian [EMAIL PROTECTED] writes:
Gregory Stark wrote:
I have a question about what would happen for a transaction running a command
like COPY FROM. Is it possible it would manage to arrange to have no live
snapshots at all? So it would have no impact on concurrent VACUUMs? What
about
Bruce Momjian [EMAIL PROTECTED] writes:
Jeremy Drake wrote:
On Thu, 22 Mar 2007, Tom Lane wrote:
AFAIR, the reason there's no TextPGetDatum (and ditto for lots of other
datatypes) is lack of obvious usefulness.
If you are asking why I have reason to convert text * to a Datum in cases
other
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Jeremy Drake wrote:
On Thu, 22 Mar 2007, Tom Lane wrote:
AFAIR, the reason there's no TextPGetDatum (and ditto for lots of other
datatypes) is lack of obvious usefulness.
If you are asking why I have reason to convert text * to a
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
... but we won't come out ahead unless advancing xmin
intra-transaction really helps, and I'm not sure I believe that (except
in the special case of VACUUM, and we already have a solution for that,
which would be
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Uh, no, that's not very clear. A long-running transaction will be a
VACUUM bottleneck because of its own XID, never mind its xmin.
Well, my secondary addition was to start MyProc-xmin with the current
xid counter, rather than your own
On Mon, 26 Mar 2007, Bruce Momjian wrote:
Tom Lane wrote:
Or were you speaking to the question of whether to adjust the regexp
patch to conform more nearly to the coding practices found elsewhere?
I agree with that, but I thought there was already a submitted patch
for it.
Yes, regex
Hi,
Here's an update of a code to improve full page writes as proposed in
http://archives.postgresql.org/pgsql-hackers/2007-01/msg01491.php
and
http://archives.postgresql.org/pgsql-patches/2007-01/msg00607.php
Update includes some modification for error handling in archiver and
restoration
26 matches
Mail list logo
