Bruce Momjian wrote:
Why is this better than:
#if _MSC_VER == 1400
Surely this will not be true if _MSC_VER is undefined?
I experienced injustice and the reason of in OSX for it.
What was the problem with OSX? Did it throw a warning of you did an
equality test on an undefined symbol?
[EMAIL PROTECTED] wrote:
Bruce Momjian wrote:
Why is this better than:
#if _MSC_VER == 1400
Surely this will not be true if _MSC_VER is undefined?
I experienced injustice and the reason of in OSX for it.
What was the problem with OSX? Did it throw a warning of you did an
equality test on
Tom Lane wrote:
Susanne Ebrecht [EMAIL PROTECTED] writes:
... We could provide the mixed update syntax and leave the
typed row value expression for the next release. Do you agree?
I don't really see the point --- the patch won't provide any new
functionality in anything like its current form,
Albe Laurenz wrote:
Tim Allen wrote:
Patch included to implement xlog switching, using an xlog record
processing instruction and forcibly moving xlog pointers.
1. Happens automatically on pg_stop_backup()
Oh - so it will not be possible to do an online backup
_without_ forcing a WAL switch
Tom Lane wrote:
Bernd Helmle [EMAIL PROTECTED] writes:
Since 8.1 has done this all along and no one's actually complained about
it, I guess no one is using scripts that do cd. I'm inclined to go
with Bernd's suggestion to change the docs to match the code, but does
anyone have a contrary
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, are you saying that there is a signal we are ignoring for
overflow/underflow, or that we should just silently overflow/underflow
and not throw an error?
Silent underflow is fine with me; it's the norm in most all float
Tom Lane wrote:
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
This is a stand-alone patch for aggressive freezing. I'll propose
to use OldestXmin instead of FreezeLimit as the freeze threshold
in the circumstances below:
I think it's a really bad idea to freeze that aggressively under any
Heikki Linnakangas wrote:
Florian G. Pflug wrote:
There could be a GUC vacuum_freeze_limit, and the actual FreezeLimit
would be calculated as
GetOldestXmin() - vacuum_freeze_limit
We already have that. It's called vacuum_freeze_min_age, and the default
is 100 million transactions.
IIRC we
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Should there be new a log_line_prefix percent code for virtual
transaction ids? Or should we change the meaning of %x to be virtual
transaction id instead of the real one.
I think the latter should be sufficient, especially if we
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Should there be new a log_line_prefix percent code for virtual
transaction ids? Or should we change the meaning of %x to be virtual
transaction id instead of the real one
Heikki Linnakangas wrote:
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Should there be new a log_line_prefix percent code for virtual
transaction ids? Or should we change the meaning of %x to be virtual
transaction id
Hi
Here is an updated patch, following the discussion.
The patch can be found at: http://soc.phlo.org/lazyxidassign.v4.patch
(I seems I still can't get attachments through to this list)
Most changes are just small fixes and tweaks. Those are
.) Introduced %v for log_line_prefix
.) I missed a
Pavan Deolasee wrote:
On 9/4/07, Florian G. Pflug [EMAIL PROTECTED] wrote:
Hi
Here is an updated patch, following the discussion.
The patch can be found at: http://soc.phlo.org/lazyxidassign.v4.patch
(I seems I still can't get attachments through to this list)
I haven't been able to follow
Chris Browne wrote:
Similarly, does it seem likely that Slony-I users would need to worry
about this?
No.. it should have zero negative effects for Slony-I. In fact, it will
be an advantage in some cases I think. I remember something about
troubles with Slony-I if the in-use xids on a
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Here is an updated patch, following the discussion.
The patch can be found at: http://soc.phlo.org/lazyxidassign.v4.patch
I've been working through this, and found a couple items that seem like
judgment calls:
* Is there a good
Heikki Linnakangas wrote:
Florian G. Pflug wrote:
1) 2PC was broken in V3. I added code that skips
LOCKTYPE_VIRTUALTRANSACTION
locks when writing the locks to the 2PC state file, but I didn't
add the same exception to the code that reassigns the locks to
a dummy PGROC afterwards. So the locks
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Here is an updated patch, following the discussion.
The patch can be found at: http://soc.phlo.org/lazyxidassign.v4.patch
(I seems I still can't get attachments through to this list)
Applied with revisions --- mostly cosmetic
Robert Treat wrote:
On Wednesday 05 September 2007 12:56, Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
However, none of these are very strong reasons - certainly weaker than
doing what ensures to cause the least confusion. I'm therefore
starting to think that we should remove
Andrew Dunstan wrote:
Florian G. Pflug wrote:
So, in essence, you get the old pg_locks format back by doing
select l1.*, l2.transactionid as transaction from pg_locks l1,
pg_locks l2
where l1.vxid = l2.vxid and l2.locktype = 'transaction'
and l2.mode='exclusive' and l2.granted=true.
Hm
Tom Lane wrote:
This patch implements Florian's idea about how to manage snapshot xmax
without the ugly and performance-losing tactic of taking XidGenLock and
ProcArrayLock at the same time. I had to do a couple of slightly klugy
things to get bootstrap and prepared transactions to work, but on
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
2) I don't see how either the childXids array or the XID cache in the proc
array could ever not be in ascending xid order. We do guarantee that a
child xid is always greater than it's parent.
It's the relationships among siblings
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
This guarantee enables a few optimizations. First, as you say in the
comments, finding the largest xid when committing becomes trivial. But more
important, if we can assume that the proc array xid cache is always
sorted, we can get
Hi
Per my post to the hackers list, here is a patch that renamed
latestCompletedXid to latestCommittedXid, and updates it only
on commits.
greetings, Florian Pflug
latestcommitted.patch.gz
Description: GNU Zip compressed data
---(end of
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Per my post to the hackers list, here is a patch that renamed
latestCompletedXid to latestCommittedXid, and updates it only
on commits.
This is wrong --- it will break early detection of aborted
subtransactions.
I don't see how
Neil Conway wrote:
On Sun, 2008-01-27 at 12:36 -0500, Tom Lane wrote:
Both of the above arguments hold water only if we implement
compatible *semantics*, not merely syntax, so I find them
unconvincing at this stage.
How are the semantics of the proposed patch incompatible with the SQL
spec
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
Tom Lane napsal(a):
Most places where we've dealt with this before, we use double, which is
guaranteed to be available whereas uint64 is not ...
Is this requirement still valid?
Yes.
Maybe we should just bite the bullet, and
Merlin Moncure wrote:
Yesterday, we notified -hackers of the latest version of the libpq
type system. Just to be sure the right people are getting notified,
we are posting the latest patch here as well. Would love to get some
feedback on this.
Sorry if this has been discussed before, but why
Pavel Stehule wrote:
One issue that just occurred to me: what if a variadic function
wants to turn around and call another variadic function, passing
the same array argument on to the second one? This is closely akin
to the problem faced by C ... functions, and the solutions are
pretty ugly
28 matches
Mail list logo
