not want the
master to be stuck while slave is doing the catchup.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
but not necessarily
in the slave.
I think there is one difference. Assuming that the timeouts happen
infrequently, most of the time the slave is in sync with the master
and that can be reported to the user. Whereas in async mode, the slave
will *always* be out of sync.
Thanks,
Pavan
--
Pavan
. So I
don't see a real problem here. But its good to fix the larger problem
as per the suggestion.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
before it can join as SBY ?
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
can safely refer the memory allocated in a different context as
long as the other memory context is still alive.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
deliberately
left it that way. Even if we want to fix this, we should also replay
the action of clearing the bit in heap_xlog_clean()
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
to the latest
version if not ? I've some free cycles and would like to help with the
review process.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
)
+ return;
+
+ (void) log_heap_cleanup_info(rel-rd_node,
vacrelstats-latestRemovedXid);
+ }
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
.
!*/
! LWLockRelease(WALInsertLock);
}
/*
* If enabled, log checkpoint start. We postpone this until now so as
not
* to log anything if we decided to skip the checkpoint.
*/
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
. Splitting that would definitely help the
review process.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
test and should never be frozen.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
On Thu, Nov 20, 2008 at 7:50 PM, Simon Riggs [EMAIL PROTECTED] wrote:
(I assume you mean bgwriter, not archiver process).
Yeah, its the bgwriter, IIRC hung while taking checkpoint.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
without a
fresh backup.
Of course, this doesn't work for async replication.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
for
HeapTupleSatisfiesVacuum ? We hold exclusive lock continuously in the first
pass. So its not possible for someone else to call heap_page_prune. If its
the second visit in the second heap scan, then it removes only the dead
tuples recorded in the first pass. So we should be good there too.
Thanks,
Pavan
--
Pavan
(ERRCODE_OUT_OF_MEMORY),
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
)));
InitRecoveryTransactionEnvironment();
StartCleanupDelayStats();
if (IsUnderPostmaster)
SendPostmasterSignal(PMSIGNAL_RECOVERY_START);
}
}
Thanks,
Pavan
--
Pavan Deolasee
- transaction B (slot 1) starts and requests AEL lock on the same relation
Won't B deadlock with A ? Since B hasn't yet committed/aborted, the lock
held by A is not released and
relation_redo_lock() would indefinitely wait for the lock.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http
On Thu, Nov 20, 2008 at 8:15 PM, Pavan Deolasee [EMAIL PROTECTED]wrote:
On Thu, Nov 20, 2008 at 7:50 PM, Simon Riggs [EMAIL PROTECTED]wrote:
(I assume you mean bgwriter, not archiver process).
Yeah, its the bgwriter, IIRC hung while taking checkpoint.
Sorry, its the startup process
done that way and if we are freeing the malloced memory at all ?
malloc is used at another place in a new code. Although it seems that the
allocation happens just once, please check if its better to use palloc
there.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
for failed portals in PortalCleanup() ?
Or PortalDrop() is a better(right) place to do that ?
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
? Or am I missing something trivial ?
Anyways, I will wait for your latest version to continue with the
test/review.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
recovery. The patch attempts to do that by setting transaction mode to
read-only, but not enough to prevent somebody to explicitly mark the
transaction as read-write.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
checked if all necessary code paths are covered or not.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
On Wed, Nov 26, 2008 at 3:52 PM, Pavan Deolasee [EMAIL PROTECTED]wrote:
I think whats happening is that ResolveRecoveryConflictWithVirtualXIDs() is
failing to abort the open transaction
Btw, ISTM that SIGINT works only for statement cancellation. So if the
transaction is in idle state
failed to abort the transaction. Thats why the tuples
have disappeared from the standby (most likely because they are cleaned up
by VACUUM).
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
. But
its very straight forward.
I added myself as reviewer to Hot standby few days back since I did some
code review and testing. I intend to spend some more time after new patch is
posted.
Thanks,
Pavan
Pavan Deolasee.
EnterpriseDB http://www.enterprisedb.com
.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
Index: src/backend/access/transam/xact.c
===
RCS file: /repositories/postgreshome/cvs/pgsql/src/backend/access/transam/xact.c,v
retrieving revision 1.269
On Thu, Dec 4, 2008 at 2:25 AM, Alvaro Herrera
[EMAIL PROTECTED]wrote:
Yeah, that was plenty silly. Updated patch attached.
Looks good me to, except for this warning:
snapmgr.c: In function 'RegisterSnapshot':
snapmgr.c:356: warning: unused variable 'snap'
Thanks,
Pavan
--
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
been discussed
before.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
MAPSIZE.
PageGetContents() works that way and I believe that's the right thing to do.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
think that
should happen.
Since the lock is not held, the bit can be flipped while we are reading,
isn't it ? IOW, the test is not reliable is what I fear.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
On Sat, Dec 6, 2008 at 8:08 PM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
If you see a straightforward way, please submit a patch!
Will do that.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
On Mon, Dec 8, 2008 at 11:33 AM, Pavan Deolasee [EMAIL PROTECTED]wrote:
On Sat, Dec 6, 2008 at 8:08 PM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
If you see a straightforward way, please submit a patch!
Will do that.
Here is a patch which implements this. The PD_ALL_VISIBLE flag
msec to 366 msec, I somehow kept waiting for
Heikki's decision on the general direction of the patch and lost interest in
between. If we are still interested in this, I can work out a patch and
submit for next release if not this.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http
in the git log.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
On 3/28/07, Tom Lane [EMAIL PROTECTED] wrote:
It seems a bit brute-force. Why didn't you use SearchSysCache(INDEXRELID)
the same as RelationInitIndexAccessInfo does?
I tried that initially, but it gets into infinite recursion during initdb.
And what's the point of
the extra tuple copy
On 3/23/07, Pavan Deolasee [EMAIL PROTECTED] wrote:
Its slightly different for the HOT-chains created by this transaction
which
is creating the index. We should index the latest version of the row which
is not yet committed. But thats ok because when CREATE INDEX commits
this latest version
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 snapshot? I keep having to
On 3/28/07, Simon Riggs [EMAIL PROTECTED] wrote:
Set it at the end, not the beginning.
At the end of what ? It does not help to set it at the end of CREATE
INDEX because the transaction may not commit immediately. In
the meantime, many new transactions may start with
transaction id
On 3/29/07, Florian G. Pflug [EMAIL PROTECTED] wrote:
Pavan Deolasee wrote:
Tom, please correct me if I am wrong. But ISTM that this idea might
work in this context. In get_relation_info(), we would check if
xcreate
xid stored in pg_index for the index under consideration is seen
committed
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 the end of the session
On 3/29/07, Tom Lane [EMAIL PROTECTED] wrote:
It will replan at the first use of the plan after seeing the relcache
inval sent by commit of the index-creating transaction. If you have
two separate transactions to create an index and then mark it valid
later, everything's fine because there
Sorry to start another thread while we are still discussing CREATE
INDEX design, but I need help/suggestions to finish the patch on
time for 8.3
We earlier thought that CREATE INDEX CONCURRENTLY (CIC)
would be simpler to do because of the existing waits in CIC.
But one major problem with CIC is
On 3/29/07, Gregory Stark [EMAIL PROTECTED] wrote:
Besides, it seems if people are
happy to have indexes take a long time to build they could just do a
concurrent build.
I think we discussed this earlier. One of the down-side of CIC is that
it needs two complete heap scans. Apart from that
On 3/30/07, Simon Riggs [EMAIL PROTECTED] wrote:
Pavan, ISTM you have misunderstood Tom slightly.
Oh, yes. Now that I re-read Tom's comment, his plan invalidation
design and code, I understand things better.
Having the index invisible to all current transactions is acceptable.
Ok.
Tom Lane wrote:
I'm getting tired of repeating this, but: the planner doesn't use a
snapshot. System catalogs run on SnapshotNow.
I am really sorry if I sound foolish here. I am NOT suggesting
that we use snapshot to read system catalogs. I understand
that system catalogs run on SnapshotNow
On 3/30/07, Florian G. Pflug [EMAIL PROTECTED] wrote:
What about doing
PREPARE myplan select ... ;
outside of a transaction? Will this be execute inside a transaction?
I checked that. PREPARE runs with ActiveSnapshot set.
Thanks,
Pavan
--
EnterpriseDB http://www.enterprisedb.com
On 3/30/07, Tom Lane [EMAIL PROTECTED] wrote:
That might work, but it doesn't seem to address the core objection:
there's no mechanism to cause the query to be replanned once the
snapshot is new enough, because no relcache inval will happen. So
most likely existing backends will keep using
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 of
these xid's is committed.
On 3/31/07, Simon Riggs [EMAIL PROTECTED] wrote:
On Fri, 2007-03-30 at 13:54 -0400, Tom Lane wrote:
Hm. So anytime we reject a potentially useful index as being not valid
yet, we mark the plan as only good for this top-level transaction?
That seems possibly workable --- in particular it
On 3/30/07, Tom Lane [EMAIL PROTECTED] wrote:
I do not think you can assume that the plan won't be used later with
some older snapshot. Consider recursive plpgsql functions for a
counterexample: the inner occurrence might be the first to arrive at
a given line of the function, hence the first
Isn't CREATE INDEX CONCURRENTLY prone deadlock conditions ?
I saw one with VACUUM today. But I think it can happen with other
commands like VACUUM FULL, CLUSTER, CREATE INDEX
CONCURRENTLY and so on. These commands conflict on the
ShareUpdateExclusiveLock held by CIC and hence would wait for
CIC
On 3/31/07, Tom Lane [EMAIL PROTECTED] wrote:
Pavan Deolasee [EMAIL PROTECTED] writes:
Isn't CREATE INDEX CONCURRENTLY prone deadlock conditions ?
Can you give a specific example?
txn1 - CREATE INDEX CONCURRENTLY (takes ShareUpdateExclusiveLock)
txn2 - VACUUM ANALYZE (waits
On 3/31/07, Tom Lane [EMAIL PROTECTED] wrote:
Hmm ... only if it's already set inVacuum true ... there's a window
where it has not.
I wonder whether we could change CIC so that the reference
snapshot lists only transactions that are running and have already
determined their serializable
Please see the HOT version 6.3 patch posted on pgsql-patches.
I've implemented support for CREATE INDEX and CREATE INDEX
CONCURRENTLY based on the recent discussions. The implementation
is not yet complete and needs some more testing/work/discussion
before we can start considering it for review.
I noticed that the plan invalidation is not immediately effective.
Not sure whether it's worth fixing or has any other side-effects,
but thought would just post it.
I was testing the following scenario:
session1session2
CREATE TABLE test
(int a, int
On 4/3/07, Tom Lane [EMAIL PROTECTED] wrote:
I'm not particularly worried about missing a potential improvement
in the plan during the first command after a change is committed.
Me too. Just noticed it, so brought it up.
If the invalidation were something that *had* to be accounted for,
On 4/3/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Where are we on this?
---
Tom Lane wrote:
[squint...] How can that fail during a reload if it worked the first
time? Needs a closer look at what's happening.
On 4/6/07, Tatsuo Ishii [EMAIL PROTECTED] wrote:
BTW, is anybody working on enabling the fill factor to the tables used
by pgbench? 8.3 will introduce HOT, and I think adding the feature
will make it easier to test HOT.
Please see if the attached patch looks good. It adds a new -F option
Tom Lane wrote:
Pavan Deolasee [EMAIL PROTECTED] writes:
Good point. I'm envisioning a procarray.c function along the
lines of
bool TransactionHasSnapshot(xid)
which returns true if the xid is currently listed in PGPROC
and has a nonzero xmin. CIC's cleanup wait loop would check
On 4/1/07, Tom Lane [EMAIL PROTECTED] wrote:
Good point. I'm envisioning a procarray.c function along the
lines of
bool TransactionHasSnapshot(xid)
which returns true if the xid is currently listed in PGPROC
and has a nonzero xmin. CIC's cleanup wait loop would check
this and ignore
On 4/11/07, Tom Lane [EMAIL PROTECTED] wrote:
[ itch... ] The problem is with time-extended execution of
GetSnapshotData; what happens if the other guy lost the CPU for a good
long time while in the middle of GetSnapshotData? He might set his
xmin based on info you saw as long gone.
You
On 5/2/07, Tom Lane [EMAIL PROTECTED] wrote:
* [pgsql-patches] Ctid chain following enhancement
/Pavan Deolasee/
I'm not very excited about this --- it seems to me to complicate the code
in some places that are not in fact performance-critical. While it
doesn't seem likely to break
On 5/2/07, Tom Lane [EMAIL PROTECTED] wrote:
* [PATCHES] HOT Patch - Ready for review /Pavan Deolasee/
This needs a *lot* of review. Can we break it down into more manageable
chunks? I'm not sure that anyone's got a full grasp of the implications
of this patch, and that's a scary thought
On 5/2/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
I'm going to go with pgdiagnostics. We could short it to just pgdiag,
but that feels too short :). We could make it pgdiagfuncs, but that's
not much shorter than pgdiagnostics.
Just to add more confusion :-), how about pginspect ?
On 5/2/07, Gregory Stark [EMAIL PROTECTED] wrote:
Can we? I mean, sure you can break the patch up into chunks which might
make
it easier to read, but are any of the chunks useful alone?
Well I agree, it would be a tough job. I can try and break the patch into
several self-complete
On 5/16/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Yep, that is part of our problem, but even items people have already
said they _can_ review have shown little progress.
For complex patches, it might help to identify and associate a core/senior
community member in the early stages of
On 5/17/07, Cui Shijun [EMAIL PROTECTED] wrote:
I want to help the reviewing work of ctid chain following enhancement .
I've been studying the souce code which related with that part recently.
:-)
Tom had objected to this patch on the grounds that it adds complexity
without any significant
On 5/17/07, Joshua D. Drake [EMAIL PROTECTED] wrote:
Pavan Deolasee wrote:
There are few things that we can separate easily, like CREATE INDEX
related changes, VACUUM and VACUUM FULL related changed, space
reuse related changes etc. Let me give it a shot.
Did we ever get a broken up
-cN cluster-mvcc-1.patch
I usually commit each version and tag the tree. That helps me to get
diff between two versions as well.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
On 5/18/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Pavan Deolasee wrote:
For primitive version control, I make a diff after any significant
changes:
~/pg_sandbox/pgsql.cluster$ cvs diff -cN cluster-mvcc-1.patch
I usually commit each version and tag the tree. That helps me to get
into the operator classes and operator families
and how they work. Where should I look for the related code ? Is there
anything else we should be worried about as well ?
Any help is appreciated.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
pointers and give them lower
significance
while deciding whether to vacuum or not.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
. It clearly demonstrates
the danger. The code is attached. Compile and run with an integer
argument to tell which bit to set/reset.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
test.c
Description: Binary data
---(end of broadcast
typically end up being queued up in the
kernel
where each write will have its own copy of the block to the written. Isn't
it ?
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
of people are
interested in the potential to avoid CPU overhead of index inserts. We
need to run CPU bound benchmarks to measure that effect as well.
Sure. May be we should also measure effects on small/large tables,
different mix of HOT and COLD updates etc.
Thanks,
Pavan
--
Pavan Deolasee
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
The MAXIMUM_ALIGNOF value is set to 8 bytes in a Windows- 32-bit
environment. I have very little knowledge about Windows, but at
the face of it, this looks strange. Any idea why is this required ?
May be I am missing something obvious.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http
On 7/20/07, Tom Lane [EMAIL PROTECTED] wrote:
Pavan Deolasee [EMAIL PROTECTED] writes:
The MAXIMUM_ALIGNOF value is set to 8 bytes in a Windows- 32-bit
environment. I have very little knowledge about Windows, but at
the face of it, this looks strange. Any idea why is this required ?
It's
On 7/20/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Pavan Deolasee wrote:
Are we leaking memory in vac_update_relstats ?
/* Fetch a copy of the tuple to scribble on */
ctup = SearchSysCacheCopy(RELOID,
ObjectIdGetDatum(relid
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
I am posting the version 13 of HOT patch on pgsql-patches. It
includes the changes based on feedback received on version 11.
There is also a bug fix in crash recovery of hard chain
pruning during VACUUM FULL.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
On 8/2/07, Pavan Deolasee [EMAIL PROTECTED] wrote:
. It would also be better if we didn't emit a
separate WAL record for defraging a page, if we also prune it at the
same time. I'm not that worried about WAL usage in general, but that
seems simple enough to fix.
Ah I see. I shall
analyze etc
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
On 8/7/07, Simon Riggs [EMAIL PROTECTED] wrote:
On Tue, 2007-08-07 at 18:25 +0530, Pavan Deolasee wrote:
I am posting the version 13 of HOT patch on pgsql-patches. It
includes the changes based on feedback received on version 11.
I think we need a change log, so we can see which feedback
for vacuum.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
UPDATE in each block would be a COLD
update.
Should we consider adding such a GUC now ? I searched through
archives, but did not find any strong objection to doing so in the past.
But I might have missed something. Comments ?
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http
will always reuse the dead space of either expired
updated rows or deleted rows or even aborted rows.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
and then override that (if required) for
each table. It will also be useful for experimenting with different
fillfactor. The only way today is either to recompile your sources
or change the parameter in every CREATE TABLE statement.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http
of COLD updates and they
are discounted in triggering autovac. Am I missing something ?
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
with the broader approach ?
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
to track the space consumed by redirect-dead
line pointers.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
used in the expressions ? Or do I need
to walk the tree and extract that information ?
Thanks,
Pavan
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
On 8/9/07, Simon Riggs [EMAIL PROTECTED] wrote:
On Thu, 2007-08-09 at 15:46 +0530, Pavan Deolasee wrote:
What if we just track the amount of potentially dead space in the
relation
(somebody had suggested that earlier in the thread) ? Every committed
UPDATE/DELETE and aborted UPDATE
stats separately. Index bloat would carry
a different weight in triggering autovacuum.
I shall code up a patch which tracks the dead space in the heap and
trigger autovac based on that.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
are already doing that ?
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
On 9/13/07, Bruce Momjian [EMAIL PROTECTED] wrote:
For those who have forgotten the progress we have made toward 8.3, here
are the open patches we had for 8.3 as of May 1, 2006:
You mean May 1, 2007 ;-)
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
. We would need
to WAL log this information in xl_heap_clean so that we redo the same
during recovery. I have a patch ready since I had already implemented
this few weeks back.
Comments ?
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
1 - 100 of 737 matches
Mail list logo
