On Thu, Jul 14, 2011 at 6:22 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, Jul 14, 2011 at 4:57 PM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
Thanks Simon for looking at the patch.
Sorry, I didn't notice there was a patch attached. Not reviewed it. I
thought we were still just
be we
can get the exact current LSN and not store it in the pg_class if we don't
do anything during the cycle.
Comments ?
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index 01a492e
On Wed, Jun 8, 2011 at 10:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavan Deolasee pavan.deola...@gmail.com writes:
I first thought that analyze and vacuum can not run concurrently on the
same
table since they take a conflicting lock on the table. So even if we
ignore
the analyze process
On Thu, Jun 9, 2011 at 11:50 AM, Pavan Deolasee pavan.deola...@gmail.comwrote:
Ah, I see. Would there will be benefits if we can do some special handling
for cases where we know that ANALYZE is running outside a transaction block
and that its not going to invoke any user-defined functions
Can we make this the last post on this topic please?
+1 :)
Thanks,
Pavan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I am wondering if we shouldn't be asking ourselves a different
question: why is ANALYZE running long enough on your tables for this
to become an issue? How long is it taking?
The log file attached in the first post has the details; it's taking around 5
mins for the accounts table with
On 09-Jun-2011, at 8:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Jun 9, 2011 at 10:52 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
I am wondering if we shouldn't be asking ourselves a different
question: why is ANALYZE running long
to be using it anywhere. Since acquire_sample_rows() returns palloced
tuples, can't we let OldestXmin advance after scanning a page by ignoring
procs with the flag set, just like we do for PROC_IN_VACUUM ?
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
7457:2006-07-07 09:46
On Wed, Jun 8, 2011 at 9:03 PM, Greg Stark st...@mit.edu wrote:
On Jun 8, 2011 1:49 PM, Pavan Deolasee pavan.deola...@gmail.com wrote:
Hi All,
There is a PROC_IN_ANALYZE flag, but we don't seem to be using it
anywhere. Since acquire_sample_rows() returns palloced tuples, can't we let
On Thu, May 26, 2011 at 4:10 PM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
So are there any other objections/suggestions ? Anyone else cares to
look at the brief design that we discussed above ? Otherwise, I would
go ahead and work on this in the coming days. Of course, I will keep
is indeed a major bottleneck.
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
compile with -O0 -g flags to see all the debug symbols.
CFLAGS=-O0 -g ./configure --enable-debug
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
--
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
or not. We can then use that API to test every N
blocks (where N is the number where continuous sequential scans would
still be better than sequential scans with gaps) and either read all
of them sequentially or just skip all of them.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http
On Sun, May 29, 2011 at 9:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavan Deolasee pavan.deola...@gmail.com writes:
On Sun, May 29, 2011 at 8:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
That would require proof, not just suggestion. Skipping pages will
defeat the OS read-ahead algorithm, and so
On Sun, May 29, 2011 at 10:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavan Deolasee pavan.deola...@gmail.com writes:
I am sorry if I sounded terse above. But my gripe is that sometimes we
are too reluctant to listen to ideas and insist on producing some hard
numbers first which might take
debated/tested already.
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
On Fri, May 27, 2011 at 7:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavan Deolasee pavan.deola...@gmail.com writes:
My statistical skills are limited, but wouldn't that mean that for a
fairly well distributed write activity across a large table, if there
are even 3-4% update/deletes, we would
On Fri, May 27, 2011 at 7:41 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 27.05.2011 16:52, Pavan Deolasee wrote:
On closer inspection, I realized that we have
deliberately put in this hook to ensure that we use visibility maps
only when we see at least
On Thu, May 26, 2011 at 9:40 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, May 25, 2011 at 11:51 PM, Pavan Deolasee
Having said that, it doesn't excite me too much because I
think we should do the dead line pointer reclaim operation during page
pruning and we are already holding cleanup
to PostgreSQL implementation ?
http://www.almaden.ibm.com/u/mohan/RJ6649Rev.pdf
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
On Thu, May 26, 2011 at 4:10 PM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
On Thu, May 26, 2011 at 9:40 AM, Robert Haas robertmh...@gmail.com wrote:
Currently, I believe the only way a page can get marked all-visible is
by vacuum. But if we make this change, then it would be possible
./configure --enable-debug
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
to make some further improvements.
Thanks for bringing up the idea during PGCon. That helped me to get
interested in this again. I hope we would be able to take this to a logical
conclusion this time and do something to alleviate the pain.
On Tue, May 24, 2011 at 2:58 AM, Pavan Deolasee
On Wed, May 25, 2011 at 7:20 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, May 25, 2011 at 7:07 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
But instead of allocating permanent space in the page header, which would
both reduce (admittedly only by 8 bytes) the amount of space
to collect
the dead line pointers and then remove the corresponding index
pointers. We would need to also take into consideration the
implications on visibility map for any such scheme to work correctly
and efficiently.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
be reclaimed by shuffling things around.
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
On Wed, May 25, 2011 at 11:39 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, May 25, 2011 at 1:43 PM, Pavan Deolasee
Now, there
is no way you can store is after the line pointer array without moving
the live tuple somewhere else.
So far I agree. But don't we always defragment
not spent time on that,
so it will be easy find holes and corner cases. That can be worked out if we
believe something like this will be useful.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
be great if you can upload the slides on the
conference website. To expect that the attendees would have understood the
nitty-gritties of SSI just listening to the presentation is so unhuman :-)
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
, but
the function really takes just a buf. You can possibly fold
visibilitymap_pin_ok() into a macro (and also name it slightly differently
like visibilitymap_is_pinned ?).
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
and with influential opinions. Its very likely that if
you submit an idea or a patch, you would get some
comment/suggestion/criticism very early.
Since HOT is mentioned often in these discussions, I thought I should share
my experience.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http
to the disk.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
On Wed, May 4, 2011 at 5:46 PM, Pavan Deolasee pavan.deola...@gmail.comwrote:
On Wed, May 4, 2011 at 7:16 AM, Tian Luo jackro...@gmail.com wrote:
Hi guys,
No matter I turn on or turn off the full_page_writes, I always
observe 8192-byte writes of log data for simple write operations
to
some email id, the patch gets applied on the current HEAD, pgindent is run
and the new patch is sent back to the submitter who can then submit it to
the hackers for review. If the patch does not apply cleanly, the same can
also be emailed back to the submitter.
Thanks,
Pavan
--
Pavan Deolasee
congratulations Magnus! You fully deserve it.
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
in the git log.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
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
On Tue, Jul 21, 2009 at 10:38 AM, Robert Haasrobertmh...@gmail.com wrote:
Pavan, are you planning to respond to Alex's comments and/or update this
patch?
Yes, I will. Hopefully by end of this week.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
--
Sent
tuples in the HOT chain may get removed
(because we handle aborted heap-only tuples separately) and break the
HOT chain.
I am also looking at the pruning logic to see if I can spot something unusual.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql
On Thu, Jan 15, 2009 at 7:10 AM, Bruce Momjian br...@momjian.us wrote:
Is this something for 8.4 CVS?
I worked out the patch as per Heikki's suggestion. So I think he needs
to review and decide it's fate.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
--
Sent
Wiki page so that people can
directly edit/comment/remove the items which they are sure about ?
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
threaded recovery
But then these are general problems which may impact any log-based replication.
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
and not the base
backup).
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
is corrupted. Can't this be done by just
selectively applying WAL records to that particular block ? If it's
just because nobody had time/interest to do this, then it's OK, but I
wonder if there are any design issues.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
--
Sent
cancellations and unlike
VACUUM there is no way user can control the frequency of prune
operations.
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
--
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
to all of you!
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
inconsistency which I don't think can be
corrected without a fresh backup.
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
, I won't be too much worried about dirty buffer case because the
WAL synchronization at that point usually occurs much later than the
WAL is actually sent to the standby. I would imagine that most of the
time WAL would have made to standby by that time.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB
? I think the reading from files is addition work in
the sync path when we already have access to the WAL buffers.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
an error. But what if the
hash index is used after recovery and it returns wrong tuple(s) ?
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
better than btree (that's what the doc says), why not just completely
abandon it ?
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
on the table would expect the
next vacuum to be no-op if there are no updates/deletes in between.
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
the problem there. I was
merely explaining how HOT-prune may some time (when there are no DEAD
line pointers created) help us set the visibility bit early.
OTOH I think we can still set PD_ALL_VISIBLE page header flag even
when there are DEAD line pointers.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB
On Thu, Dec 11, 2008 at 8:09 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Pavan Deolasee wrote:
I can do some if we don't have already.
Oh, yes please!
I did some tests today with pgbench on a decent SMP machine. The goal
was to see if multiple clients (20 in the test
update PageLSN during the set operation and that
would require EXLUSIVE lock, but is that required for consistency
given that the entire visibility map is just a hint ?
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql
, but since its just a hint, we can possibly live with some corner
cases. The benefit of avoiding contention on the VM page would easily
out weigh the downside of wrong hints.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql
set the bit (and I believe that's the right
thing to do)
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
will be
removed in the second scan and the rest are all LIVE tuples. So if we
at all want to take out the another scan of line pointers from the
first pass, we should rather push the work setting bits in the prune
code.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
of reading xlog files directly into xlog buffers
during recovery.
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
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
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
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 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
.
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
. 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
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
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
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
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
)));
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
. 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
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
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
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
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
be
possible to decide before the apply step whether this is the case
or not.
I am not against this idea. Just that it still requires us double scan
of the main table and that's exactly what we are trying to avoid with
this patch.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http
again.
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
level. I
expect that feedback during this commit fest.
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
again,
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
personally have a strong feeling that it's worth
the efforts.
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
401 - 500 of 737 matches
Mail list logo
