, we can group them in a
structure and put them on a stack when an AT starts and pop them off when
the original top transaction becomes active again, finding all such global
state variables is going to be tricky.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
, no ? Or is there a theoretical limit on the number of pins on the
same buffer by a single backend ?
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
On Thu, Apr 10, 2014 at 10:44 AM, Rajeev rastogi
rajeev.rast...@huawei.comwrote:
On 09 April 2014 12:14, Pavan Deolasee Wrote:
Whenever I was asked to have a look at implementing this feature, I
always wondered about the great amount of global state that a backend
maintains which
not sure why.
Is the psql process running out of memory ? AFAIK OOM killer sends SIGKILL.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
listed out above. While the exact semantics of vacuum and
other maintenance activities may differ, ISTM the final goal is just the
same i.e. reduce load on the master.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
be when a column with the same name is added and again dropped ? Of
course, we can have the attribute number and column name both to avoid
conflict.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
only after the first time a hint bit is updated after checkpoint.
But for something like pg_rewind to work, we will need to WAL log every
hint bit update on a page. So we would want to keep it as short as possible.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
as it needs to read through a
lot more WAL, but I think it would still be OK.
Yeah, probably you are right. Though the amount of additional work could be
significantly higher and some testing might be warranted.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
On Thu, Oct 24, 2013 at 4:45 PM, Pavan Deolasee pavan.deola...@gmail.comwrote:
. Or would the recovery logic apply first WAL without looking at the page
lsn ? (Sorry, may be I should read the code instead of asking you)
Never mind. I realized it has to. That's the whole purpose of backing
a good idea about how to capture them in wal_level. May be something
like: minimal, archive, archive_with_this_new_feature, hot_standby and
hot_standby_with_this_new_feature.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
On 16-Oct-2013, at 3:45 pm, Andres Freund and...@2ndquadrant.com wrote:
On 2013-10-16 11:03:12 +0530, Pavan Deolasee wrote:
I think you are right. Someone who understands the replication code very
well advised us to use that log message as a way to measure how much time
it takes to send
is still in the sender's buffer, the standby may not actually catch up
to the desired point contrary to the LOG message displayed on the master.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
implementation.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
. the data loss can
still occur even after master outputs the log message and changes the state
to streaming. Or am I still getting it wrong ?
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
up after the message was displayed on
the master side. But then as you said, may be relying on the message was
not the best way to measure the time.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
On Mon, Oct 14, 2013 at 7:20 PM, Samrat Revagade
revagade.sam...@gmail.comwrote:
Sorry .my environment has some problem.
May be you were using old version of psql ? IIRC tab-completion relies
heavily on the psql side,
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
will definitely need some amount of performance benchmarks even if this
is optional. But are there other things to worry about ? Any strong
objections to this idea or any other stow stopper for pg_rewind itself ?
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
to ensure that the patch is functionally correct.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
this entirely.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
on the synchronous_commit setting of each
standby and their priorities also explicitly defined by this mechanism,
master will decide which standbys to wait for at the commit time.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
On Thu, Sep 26, 2013 at 7:20 PM, Noah Misch n...@leadboat.com wrote:
On Thu, Sep 26, 2013 at 03:23:30PM +0530, Pavan Deolasee wrote:
Should we just fix the comment and say its applicable for all tables
except
accounts ?
Please do.
How about something like this ? Patch attached.
Thanks
:
- If synchronous_commit is ON - wait at commit point
- If synchronous_commit is OFF - do not wait at any point
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
10
(1 row)
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
On Thu, Sep 26, 2013 at 2:05 PM, Pavan Deolasee pavan.deola...@gmail.comwrote:
While looking at the compressibility of WAL files generated by pgbench,
which is close to 90%, I first thought its because of the filler column
in the accounts table. But a comment in pgbench.c says
synchronous_standbys are really *async*
standbys with failback safety.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
branches, even though I understand there could be some
casualties on the border.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
we do for indexes).
What that means is, even if a row was satisfying a constraint while
insertion, it may not once its there. Is that intentional ?
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
if someone was to restore the table
from a dump.
Given that we haven't seen any complaints may mean I am imagining a problem
that does not exist in practice, though I thought the example looks quite
sensible too.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
this is a known behaviour/limitation, but I could not find that in
the documentation. But I wonder if it makes sense to check for dependencies
during function alteration and complain. Or there are other reasons why we
can't do that and its a much larger problem than what I'm imagining ?
Thanks,
Pavan
--
Pavan
standbys via the same mechanism.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
, or a running server and its modified conf file
?
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
/4th (or
some such number) or more than the available RAM. I will see if I can pull
out the patch and the numbers. But if memory serves well, I concluded that
the kernel is already utilising its buffer cache to achieve the same thing
and it does not help beyond a point.
Thanks,
Pavan
--
Pavan
On Sun, Jun 16, 2013 at 5:10 PM, Simon Riggs si...@2ndquadrant.com wrote:
My perspective is that if the master crashed, assuming that you know
everything about that and suddenly jumping back on seem like a recipe
for disaster. Attempting that is currently blocked by the technical
obstacles
algorithm is straight LRU except that we will never swap
* out the latest page (since we know it's going to be hit again
eventually).
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
this problem. It doesn't
require an online feedback loop from the standby to master, for starters.
I agree. That's a big advantage of pg_rewind. Unfortunately, it can't work
with 9.3 and below because of the hint bits issue, otherwise it would have
been even more cool.
Thanks,
Pavan
--
Pavan Deolasee
that the slave
hasn't seen.
WAL records in PostgreSQL can only be used for physical redo. They can not
be used for undo. So what you're suggesting is not possible though I am
sure a few other databases do that.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
I'll retry and report back if I see the problem on the offending platform.
Just to close out this thread, I can't reproduce this on the Mac OS either.
While I'd done a make clean earlier, make distclean did the trick.
Sorry for the noise.
Thanks,
Pavan
--
Pavan Deolasee
http
to set up the environment.
You will need to modify it for your setup though.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
test_cascade_stdby.sh
Description: Bourne shell script
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
this in the relevant releases.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
syncrep-typo-91.patch
Description: Binary data
syncrep-typo-head.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
WAL records are written to the standby
first.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
...@vmware.com.
If you have any better ideas, I'm all ears...
No, I don't have better ideas. I was worried that it was an oversight. But
now I know it was chosen this way after a careful consideration.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
On Tue, Apr 23, 2013 at 3:00 PM, Andres Freund and...@2ndquadrant.comwrote:
On 2013-04-23 14:51:05 +0530, Pavan Deolasee wrote:
Hello,
I was playing with pg_xlogdump in the HEAD and found a few issues.
1. Tried compiling pg_xlogdump via PGXS mechanism and it fails with the
following
in the FK locks
patch. I think he also discovered an old bug that the tableoid was not
being properly checked for HOT conditions but that had very limited impact
since its not common to have indexes on tableoids.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
is really lagging
much behind. Of course, if the standby is not able to keep pace with the
master in a realistic manner then we have a problem with the approach.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
) though some kind of support from the core may be required.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
On Thu, Apr 11, 2013 at 8:39 PM, Ants Aasma a...@cybertec.at wrote:
On Thu, Apr 11, 2013 at 5:33 PM, Hannu Krosing ha...@2ndquadrant.com
wrote:
On 04/11/2013 03:52 PM, Ants Aasma wrote:
On Thu, Apr 11, 2013 at 4:25 PM, Hannu Krosing ha...@2ndquadrant.com
wrote:
The proposed fix -
On 06-Mar-2013, at 4:12 PM, Shigeru Hanada shigeru.han...@gmail.com wrote:
On Wed, Mar 6, 2013 at 12:35 PM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
In the context of postgres_fdw, I am not sure if we need an additional
system column like a node_id. Would there be a possibility where
different foreign tables and at
runtime we need to decide where to execute the UPDATE/DELETE operation
? If we start supporting inheritance involving foreign tables as child
tables, this will become a reality.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
--
Sent via
? I was thinking adding
that to CreateCheckpoint() itself so that the status is displayed at
all relevant places.
Comments ?
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Mon, Mar 4, 2013 at 6:23 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-03-04 18:21:50 +0530, Pavan Deolasee wrote:
If we do that,
what would be the best place to add that code ? I was thinking adding
that to CreateCheckpoint() itself so that the status is displayed at
all
(changing subject)
On Thu, Feb 14, 2013 at 11:48 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Feb 11, 2013 at 5:46 PM, Pavan Deolasee
I also noticed that the WAL file switch
happens after archive_timeout seconds irrespective of whether
archive_mode is turned ON or not. This happens
much work for now. But it will awesome
if we can have all machinery in place to support these configurable
modes in future.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
version gets substituted when docs for that release
are built.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Feb 12, 2013 at 2:49 PM, Dave Page dp...@pgadmin.org wrote:
The phrasing as of 8.2 basically means from 8.2 onwards. Changing the
version there would make the text incorrect.
Ah Ok. Thanks for clarifying. My bad English.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com
we at
least document this behaviour ?
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
a potentially DEAD tuple ?
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Also, the log says checkpoints are occurring too frequently (0
seconds apart). But that looks wrong too. Checkpoints are really
happening at 30 seconds apart and not 0 as the log message claims.
I noticed that as well, and I think it might be a regression. I'll
run a bisection on it
jjanes to a database
jjanes to see the offending table.
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Feb 7, 2013 at 2:25 PM, Pavan Deolasee pavan.deola...@gmail.com wrote:
Will look more into it, but thought this might be useful for others to
spot the problem.
And here is some more forensic info about one of the pages having
duplicate tuples.
jjanes=# select *, xmin, xmax, ctid
On Thu, Feb 7, 2013 at 10:48 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Thu, Feb 7, 2013 at 1:44 AM, Pavan Deolasee pavan.deola...@gmail.com
wrote:
jjanes=# select *, xmin, xmax, ctid from foo where index IN (select
index from foo group by index having count(*) 1 ORDER by index)
ORDER
On Mon, Feb 4, 2013 at 9:05 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Feb 1, 2013 at 12:33 PM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
I can write a patch in next couple of days if we are willing to accept
for this release. I think it should be fairly easy and non-intrusive
or too seldom.
2. Auto-analyze should analyze parent and each child table in a
separate transaction.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
with these changes made. Does this look OK?
Looks good to me. I also repeated pgbench and make check and they work
as expected. I'll add it to the CF and also mark the patch ready for
committer
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
--
Sent via pgsql-hackers
, but your other claim that this goes on for
90 seconds even though the table is just couple of MBs is hard to
justify. How does the auto vacuum settings look like ? I wonder if you
have scaled down naptime and threshold just too low.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com
On Fri, Feb 1, 2013 at 3:07 PM, Pavan Deolasee pavan.deola...@gmail.com wrote:
(re-adding hackers)
Apologies. Did not realize that the original email was on
pgsql-general. Vlad, please copy -general on your responses.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
On Fri, Feb 1, 2013 at 6:10 PM, Pavan Deolasee pavan.deola...@gmail.comwrote:
2012-12-05 00:44:23 EET LOG: automatic analyze of table
fleet.fleet.vehicle_position system usage: CPU 4.46s/0.61u sec elapsed
465.09 sec
This is the interesting piece of information. So its the auto analyze
On Fri, Feb 1, 2013 at 9:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavan Deolasee pavan.deola...@gmail.com writes:
A new reloption such as autovacuum_analyze_enabled is what we need.
This seems to me to be a wart that doesn't fix the actual problem ---
IMHO this case is just an example
On Fri, Feb 1, 2013 at 9:07 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Pavan Deolasee escribió:
A new reloption such as autovacuum_analyze_enabled is what we need.
I was thinking in this option just three days ago, so yeah.
I think we also want an option to turn off just vacuum
an option to turn off just vacuum.
Are these TODO items?
I can write a patch in next couple of days if we are willing to accept
for this release. I think it should be fairly easy and non-intrusive.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
--
Sent via pgsql-hackers
On Wed, Jan 30, 2013 at 7:34 AM, Noah Misch n...@leadboat.com wrote:
On Mon, Jan 28, 2013 at 07:24:04PM +0530, Pavan Deolasee wrote:
On Wed, Jan 23, 2013 at 10:05 AM, Noah Misch n...@leadboat.com wrote:
You're the second commentator to be skittish about the patch's
correctness, so
I
and Simon's recent changes has bit-rotten the patch.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jan 24, 2013 at 9:31 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Thu, Jan 24, 2013 at 1:28 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
Good idea. Even though the cost of pinning/unpinning may not be high
with respect to the vacuum cost itself, but it seems to be a good idea
put in a lot of efforts already.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
. Even though the cost of pinning/unpinning may not be high
with respect to the vacuum cost itself, but it seems to be a good idea
because we already do that at other places. Do you have any other
review comments on the patch or I'll fix this and send an updated
patch soon.
Thanks,
Pavan
--
Pavan
it.
I think it should it be Hot Standby for consistency. +1 for changing
it from HOT to hot/Hot anyway
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
developer or a committer.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
counted but just observation and it could be
wrong). Not sure if its a result of increased testing/adaption or a
slight drop in the quality or just because of the sheer increase in
the number of features/changes we are doing.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
contention which may or may not show up in the benchmarks
we are running, but we know its there.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On Sun, Jan 20, 2013 at 4:29 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavan Deolasee pavan.deola...@gmail.com writes:
Sorry for posting on such an old thread. But here is a patch that
fixes this. I'm also adding to the next commitfest so that we don't
lose track of it again.
As submitted
On Mon, Jan 21, 2013 at 12:22 PM, Jeff Davis pg...@j-davis.com wrote:
On Mon, 2013-01-21 at 11:27 +0530, Pavan Deolasee wrote:
Of course, there is an argument that this patch will
simplify the code, but I'm not sure if its enough to justify the
additional contention which may or may
. That could be true, but I tend to
think it isn't.
May be you've already addressed that concern with the proven
performance numbers, but I'm not sure.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
not fully
documented).
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
this wording.
So +1 from my side. Abhijit, do you want to add the patch and change the CF
status appropriately ?
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
pick from the
secondary branch at some later stage. But not sure if this will add more
overhead and defeat the problem at hand.
My 2 cents on this difficult topic.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
think that way.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
error out because of a
conflict. But the following line in the docs [1] confirms otherwise:
read-only transactions will never have serialization conflicts
So no doc patch necessary :)
Can you please mark the patch as Ready for committer if you think that
way ?
Thanks,
Pavan
--
Pavan
a table is
created and written in the same transaction. But that's more invasive.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
] http://archives.postgresql.org/pgsql-hackers/2011-07/msg00624.php
[2]
http://archives.postgresql.org/message-id/caboikdphax5ugugb9rjnsj+zveytv8sn4ctyfcmbc47r6_b...@mail.gmail.com
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
On Sun, Dec 30, 2012 at 12:38 AM, Stephen Frost sfr...@snowman.net wrote:
* Pavan Deolasee (pavan.deola...@gmail.com) wrote:
On Fri, Sep 7, 2012 at 6:06 PM, Kevin Grittner
That makes sense to me. The reason I didn't make that change when I
added the serializable special case to pg_dump
On Thu, Dec 20, 2012 at 9:23 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Dec 19, 2012 at 11:12 PM, Pavan Deolasee
I'm very reluctant to suggest that we can solve
this my setting aside another page-level bit to track visibility of
tuples for heapscans. Or even have a bit in the tuple
On Thu, Dec 20, 2012 at 10:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavan Deolasee pavan.deola...@gmail.com writes:
Ok. Will try to read archives to see what was actually suggested and
why it was put on back burner. BTW at the risk of being shot down
again, I wonder if can we push down
On Thu, Dec 20, 2012 at 10:59 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Dec 20, 2012 at 11:49 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
I wonder if we should add a flag to heap_page_prune and try to do some
additional work if its being called from lazy vacuum
this by conditional update to the VM bit. Do it only if you
get a conditional exclusive lock on the buffer page.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
testing.
Our initial work has served us well so far. Of course, I've no problem
changing that if its going to benefit users.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Wed, Dec 19, 2012 at 10:40 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Dec 19, 2012 at 11:49 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
Also, if extra WAL-logging is really worrisome, may be we should again
seriously reconsider my idea of *not* clearing the bit at HOT
201 - 300 of 737 matches
Mail list logo
