On sön, 2011-01-02 at 12:47 +0100, Florian Pflug wrote:
Here's a patch to add support for negative index values in fetching
elements from an array.
That won't work. In SQL, array indices don't necessarily start with 0 (or 1,
or *any*
single value).
FYI, this is true for PostgreSQL, but
WRAPPER
2) foreign_scan.patch includes ForeignScan executor node and
FdwRoutine interface
Regards,
--
Shigeru Hanada
20110105-fdw_handler.patch.gz
Description: Binary data
20110105-foreign_scan.patch.gz
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers
Hello
2011/1/5 Peter Eisentraut pete...@gmx.net:
On sön, 2011-01-02 at 12:47 +0100, Florian Pflug wrote:
Here's a patch to add support for negative index values in fetching
elements from an array.
negative arguments for array can be really strange
That won't work. In SQL, array indices
On Jan5, 2011, at 10:25 , Peter Eisentraut wrote:
On sön, 2011-01-02 at 12:47 +0100, Florian Pflug wrote:
The only way around that would be to introduce magic constants lower,
upper that
can be used within index expressions and evaluate to the indexed dimension's
lower
and upper bound.
On Wed, Jan 5, 2011 at 19:24, Shigeru HANADA han...@metrosystems.co.jp wrote:
2) foreign_scan.patch includes ForeignScan executor node and
FdwRoutine interface
I can see now Iterate() callback is called in per-tuple memory context.
I'll adjust copy from API for the change. We don't need to
David Fetter da...@fetter.org writes:
One could imagine that an extension was updated more quickly than
PostgreSQL major versions come out, or at least not at the exact same
time.
Sure, but I don't see what your proposed syntax is giving us here.
Currently the new version you're upgraded to is
2011/1/5 Florian Pflug f...@phlo.org:
On Jan5, 2011, at 10:25 , Peter Eisentraut wrote:
On sön, 2011-01-02 at 12:47 +0100, Florian Pflug wrote:
The only way around that would be to introduce magic constants lower,
upper that
can be used within index expressions and evaluate to the indexed
On Wed, Jan 5, 2011 at 07:55, Greg Smith g...@2ndquadrant.com wrote:
snip
a bit of work in userland, I don't see this even being justified as an INFO
or LOG level message. Anytime I can script a SQL-level monitor for
something that's easy to tie into Nagios or something, I greatly prefer
On Wed, Jan 5, 2011 at 04:24, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jan 3, 2011 at 5:50 PM, Magnus Hagander mag...@hagander.net wrote:
On Mon, Jan 3, 2011 at 17:23, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jan 3, 2011 at 11:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert
On Wed, Jan 5, 2011 at 02:32, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Wed, Jan 5, 2011 at 04:56, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I think pg_stat_replication is better than pg_stat_standby, but I'm
still not convinced we shouldn't go with the obvious
On Jan5, 2011, at 13:08 , Pavel Stehule wrote:
2011/1/5 Florian Pflug f...@phlo.org:
On Jan5, 2011, at 10:25 , Peter Eisentraut wrote:
On sön, 2011-01-02 at 12:47 +0100, Florian Pflug wrote:
The only way around that would be to introduce magic constants lower,
upper that
can be used within
Attached is an updated streaming base backup patch, based off the work
that Heikki
started. It includes support for tablespaces, permissions, progress
reporting and
some actual documentation of the protocol changes (user interface
documentation is
going to be depending on exactly what the frontend
On Tue, Jan 4, 2011 at 10:56 PM, Rob Wultsch wult...@gmail.com wrote:
1. Could the making a table logged be a non-exclusive lock if the
ALTER is allowed to take a full checkpoint?
No, that doesn't solve either of the two problems I described, unfortunately.
2. Unlogged to logged has giant use
On Wed, Jan 5, 2011 at 8:24 AM, Magnus Hagander mag...@hagander.net wrote:
Ok, done and applied.
Thanks.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Wed, Jan 5, 2011 at 12:54 AM, Jeff Davis pg...@j-davis.com wrote:
On Tue, 2011-01-04 at 16:45 -0800, Josh Berkus wrote:
On 1/4/11 10:18 AM, Jeff Davis wrote:
The main drawback here is that only a select group of people will be
defining discrete range types at all, because it would require
2011/1/5 Florian Pflug f...@phlo.org:
On Jan5, 2011, at 13:08 , Pavel Stehule wrote:
2011/1/5 Florian Pflug f...@phlo.org:
On Jan5, 2011, at 10:25 , Peter Eisentraut wrote:
On sön, 2011-01-02 at 12:47 +0100, Florian Pflug wrote:
The only way around that would be to introduce magic constants
Bruce Momjian br...@momjian.us writes:
The last patch fixes a problem where I was not migrating
pg_largeobject_metadata and its index for 9.0+ migrations, which of
course would only affect migrations to 9.1 and 9.0 to 9.0 migrations, so
I backpatched that to 9.0.
That isn't going to work. At
On Wed, Jan 05, 2011 at 09:04:08AM -0500, Robert Haas wrote:
On Tue, Jan 4, 2011 at 10:56 PM, Rob Wultsch wult...@gmail.com wrote:
1. Could the making a table logged be a non-exclusive lock if the
ALTER is allowed to take a full checkpoint?
No, that doesn't solve either of the two problems
On Wed, Jan 5, 2011 at 7:48 AM, David Fetter da...@fetter.org wrote:
On Wed, Jan 05, 2011 at 09:04:08AM -0500, Robert Haas wrote:
On Tue, Jan 4, 2011 at 10:56 PM, Rob Wultsch wult...@gmail.com wrote:
1. Could the making a table logged be a non-exclusive lock if the
ALTER is allowed to take a
On 01/05/2011 02:54 PM, Magnus Hagander wrote:
[..]
Some remaining thoughts and must-dos:
* Compression: Do we want to be able to compress the backups server-side? Or
defer that to whenever we get compression in libpq? (you can still tunnel it
through for example SSH to get compression if
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
The last patch fixes a problem where I was not migrating
pg_largeobject_metadata and its index for 9.0+ migrations, which of
course would only affect migrations to 9.1 and 9.0 to 9.0 migrations, so
I backpatched that to 9.0.
That
On Wed, Jan 05, 2011 at 10:19:23AM +0100, Dimitri Fontaine wrote:
David Fetter da...@fetter.org writes:
One could imagine that an extension was updated more quickly than
PostgreSQL major versions come out, or at least not at the exact same
time.
Sure, but I don't see what your proposed
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
That isn't going to work. At least not unless you start trying to force
roles to have the same OIDs in the new installation.
If so I can use the CREATE ROLE ... SYSID clause when doing a binary
upgrade.
Oh, I had forgotten we still had
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
That isn't going to work. At least not unless you start trying to force
roles to have the same OIDs in the new installation.
If so I can use the CREATE ROLE ... SYSID clause when doing a binary
upgrade.
Oh, I
On Jan5, 2011, at 15:17 , Pavel Stehule wrote:
2011/1/5 Florian Pflug f...@phlo.org:
How so? You'd still be able to get the last element by simply writing
array_relative(some_array, array[-1]).
Or, if we made the function variadic, by writing
array_relative(some_array, -1).
Sorry,
The attached, applied patch clarifies pg_upgrade's creation of the map
file structure. It also cleans up pg_dump's calling of
pg_upgrade_support functions.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's
The psql manual page mentions lo_insert:
LASTOID
The value of the last affected OID, as returned
--from an INSERT or lo_insert command. This variable
is only guaranteed to be valid until after the
result of the next SQL command
2011/1/5 Jeff Davis pg...@j-davis.com:
On Tue, 2011-01-04 at 23:04 +0900, Hitoshi Harada wrote:
CREATE TYPE numrange
AS RANGE (SUBTYPE=numeric, SUBTYPE_CMP=numeric_cmp);
I am interested in how you define increment/decrement operation of
range value in discrete types. The window
2011/1/5 Jeff Davis pg...@j-davis.com:
On Tue, 2011-01-04 at 23:04 +0900, Hitoshi Harada wrote:
CREATE TYPE numrange
AS RANGE (SUBTYPE=numeric, SUBTYPE_CMP=numeric_cmp);
I am interested in how you define increment/decrement operation of
range value in discrete types. The window
On Mon, Jan 3, 2011 at 16:45, Brar Piening b...@gmx.de wrote:
On Mon, 3 Jan 2011 10:44:19 +0100, Magnus Hagander mag...@hagander.net
wrote:
Yeah, it looks that way - it's missing the ordering of the contrib
I'll run it once for that now, and then please rebase your
patch on top of that -
2011/1/5 Florian Pflug f...@phlo.org:
On Jan5, 2011, at 15:17 , Pavel Stehule wrote:
2011/1/5 Florian Pflug f...@phlo.org:
How so? You'd still be able to get the last element by simply writing
array_relative(some_array, array[-1]).
Or, if we made the function variadic, by writing
On 01/05/2011 12:33 PM, Magnus Hagander wrote:
It's actually the same patch as before with the corrupted line-endings
parsed out.
git diff master VS2010 ../VS2010.patch reproduceabyl generates those on
my (windows) system when I use git-external-diff configured as described in
On Tue, Jan 4, 2011 at 2:48 PM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
David E. Wheeler da...@kineticode.com writes:
As Tom pointed out, you can do the same with naming conventions by having
scripts \i each other as appropriate.
This is a deprecated idea, though. We're talking about
On Wed, Jan 5, 2011 at 12:59 PM, Andrew Dunstan and...@dunslane.net wrote:
I've abandoned the use of an external diff program for git. If I need
context diffs I produce them by piping normal git diff output through
filterdiff --format=context.
One possible disadvantage of that it strips out
On Jan 5, 2011, at 10:05 AM, Robert Haas wrote:
There's no consensus to publish a bakend \i like function. So there's
no support for this upgrade script organizing you're promoting. Unless
the consensus changes again (but a commit has been done).
My understanding of the consensus is that
On Thu, Jan 06, 2011 at 02:25:01AM +0900, Hitoshi Harada wrote:
2011/1/5 Jeff Davis pg...@j-davis.com:
On Tue, 2011-01-04 at 23:04 +0900, Hitoshi Harada wrote:
CREATE TYPE numrange
AS RANGE (SUBTYPE=numeric, SUBTYPE_CMP=numeric_cmp);
I am interested in how you define
On 1/4/11 6:41 PM, Robert Haas wrote:
Going the other direction ought to be possible too, although it seems
somewhat less useful.
Actually, it's more useful; many people who *upgrade* to 9.1 will wand
to convert one or two of their tables to unlogged.
Note that the conversion both ways can be
On Wed, Jan 5, 2011 at 2:02 PM, Josh Berkus j...@agliodbs.com wrote:
Note that the conversion both ways can be worked around with the
CREATE/ALTER TABLE dosiedo, so I don't think either of these is critical
for 9.1. Unless you feel like working on them, of course.
As I said in my OP, I don't
David Fetter da...@fetter.org writes:
The syntax by itself does nothing, but the underlying capability gives
users:
Ok, now I understand that the syntax you proposed was a shortcut for an
I-want-it-all request :)
- The ability to have versions of software on different databases on
the same
If you could gather more info on whether this logging catches the
problem cases you're seeing, that would really be the right test for the
patch's usefulness. I'd give you solid 50/50 odds that you've correctly
diagnosed the issue, and knowing for sure would make advocating for this
logging
On Tue, 2011-01-04 at 21:41 -0500, Robert Haas wrote:
6. If wal_level != minimal, XLOG every page of every fork except the
init fork, for both the table and the associated indexes. (Note that
this step also requires an AccessExclusiveLock rather than some weaker
lock, because of the arbitrary
Robert Haas robertmh...@gmail.com writes:
My understanding of the consensus is that it wasn't felt necessary for
the purpose for which it was proposed. I think it could be
re-proposed with a different argument and very possibly accepted.
Sure. I'd still prefer us to adopt the solution I've
On Wed, Jan 5, 2011 at 2:36 PM, Simon Riggs si...@2ndquadrant.com wrote:
The lock strength selected on the master doesn't need to be the same as
the lock strength on the standby. You could quite easily generate AEL
lock records to send to standby, without actually taking that lock level
on the
On Jan 5, 2011, at 2:37 PM, Robert Haas wrote:
On Wed, Jan 5, 2011 at 2:36 PM, Simon Riggs si...@2ndquadrant.com wrote:
The lock strength selected on the master doesn't need to be the same as
the lock strength on the standby. You could quite easily generate AEL
lock records to send to
On Mon, 2011-01-03 at 23:13 -0500, Robert Haas wrote:
Hmmm, my earlier code took xmax only if xmax xmin. That was wrong;
what I have now is better, but your point is there may be an even better
truth. I'll think on that a little more.
I remember that I thought some more on this and
On Wed, Jan 5, 2011 at 3:00 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2011-01-03 at 23:13 -0500, Robert Haas wrote:
Hmmm, my earlier code took xmax only if xmax xmin. That was wrong;
what I have now is better, but your point is there may be an even better
truth. I'll think on
On Wed, 2011-01-05 at 10:41 -0800, David Fetter wrote:
On Thu, Jan 06, 2011 at 02:25:01AM +0900, Hitoshi Harada wrote:
For any type to calculate boundary based on RANGE clause in window
functions, we need some type interface mechanism in the core to know
how to add / subtract values to
On Wed, Jan 5, 2011 at 3:06 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jan 5, 2011 at 3:00 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2011-01-03 at 23:13 -0500, Robert Haas wrote:
Hmmm, my earlier code took xmax only if xmax xmin. That was wrong;
what I have now is
On 2010-11-30 05:57, Robert Haas wrote:
Last week, I posted a couple of possible designs for making the
visibility map crash-safe, which did not elicit much comment. Since
this is an important prerequisite to index-only scans, I'm trying
again.
The logic seems to be:
* If the visibillity map
Hm- if the unlogged tables are being used as HTTP transient state storage, it
would be handy to have that (admittedly non-essential) data on the standby
when it becomes master, even if there are no guarantees surrounding the data
beyond it looked like this at some point. Since the tables
Jeff Janes jeff.ja...@gmail.com writes:
(top doesn't distinguish between memory that has been requested but
never accessed, versus memory that has been accessed and then truly
swapped out to disk. So unless you first let it run to steady-state
before applying pressure, it is hard to interpret
Magnus Hagander mag...@hagander.net writes:
Attached is an updated streaming base backup patch, based off the work
Thanks! :)
* Compression: Do we want to be able to compress the backups server-side? Or
defer that to whenever we get compression in libpq? (you can still tunnel it
through
On Wed, Jan 5, 2011 at 22:58, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Magnus Hagander mag...@hagander.net writes:
Attached is an updated streaming base backup patch, based off the work
Thanks! :)
* Compression: Do we want to be able to compress the backups server-side? Or
defer
Robert Haas robertmh...@gmail.com writes:
diff --git a/src/backend/commands/alter.c b/src/backend/commands/alter.c
index 6a9b21d..1c6ae02 100644
I actually haven't figured out exactly under what circumstances that
I think it's for git am -3
Josh Berkus j...@agliodbs.com writes:
It would be useful (this would allow per-standby buffer tables, for that
matter), but it would also be tremendously difficult. Seems worthy of a
TODO, though.
Don't we have anything covering xid-less tables in the TODO already? The
read-only tables
Magnus Hagander mag...@hagander.net writes:
Compression in libpq would be a nice way to solve it, later.
Yeah, I'm pretty much set on postponing that one.
+1, in case it was not clear for whoever's counting the votes :)
What about pg_streamrecv | gzip …, which has the big advantage of
On Wed, Jan 5, 2011 at 2:27 PM, Josh Berkus j...@agliodbs.com wrote:
If you could gather more info on whether this logging catches the
problem cases you're seeing, that would really be the right test for the
patch's usefulness. I'd give you solid 50/50 odds that you've correctly
diagnosed
This is a great use case for user level tracing support. Add a probe
around these bits, and you can capture the information when you need
it.
Yeah, would be lovely if user-level tracing existed on all platforms.
--
-- Josh Berkus
On Wed, Jan 5, 2011 at 3:58 PM, Josh Berkus j...@agliodbs.com wrote:
Hm- if the unlogged tables are being used as HTTP transient state storage,
it would be handy to have that (admittedly non-essential) data on the
standby when it becomes master, even if there are no guarantees surrounding
On 1/5/11 3:14 PM, Robert Haas wrote:
I think that's probably a dead end - just to take one example, if you
don't sync often enough, the standby might have transaction ID
wraparound problems. Autovacuum on the master will prevent that for
permanent tables, but not for an
Hello,
I have added my common table expressions docpatch to the 2011-01 commitfest:
https://commitfest.postgresql.org/action/patch_view?id=476
I think that we need to get this resolved.
--
Regards,
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
2011/1/6 Jeff Davis pg...@j-davis.com:
Even if add and subtract were associated with a range type, there's no
way to tell which range type to pick given the window function syntax
(multiple range types could be defined over the same subtype).
I think the interface question should be addressed
On Wed, Jan 5, 2011 at 6:25 PM, Josh Berkus j...@agliodbs.com wrote:
On 1/5/11 3:14 PM, Robert Haas wrote:
I think that's probably a dead end - just to take one example, if you
don't sync often enough, the standby might have transaction ID
wraparound problems. Autovacuum on the master will
On Wed, Jan 5, 2011 at 3:22 PM, Jesper Krogh jes...@krogh.cc wrote:
Given a crash-safe visibility map, what purpuse does the PD_ALL_VISIBLE bit
serve?
If we modify a page on which PD_ALL_VISIBLE isn't set, we don't
attempt to update the visibility map. In theory, this is an important
On Wed, Jan 5, 2011 at 12:21 PM, Bruce Momjian br...@momjian.us wrote:
The psql manual page mentions lo_insert:
LASTOID
The value of the last affected OID, as returned
-- from an INSERT or lo_insert command. This variable
is only guaranteed to
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
That isn't going to work. At least not unless you start trying to force
roles to have the same OIDs in the new installation.
If so I can use the CREATE ROLE ... SYSID clause when doing a
Robert Haas wrote:
On Wed, Jan 5, 2011 at 12:21 PM, Bruce Momjian br...@momjian.us wrote:
The psql manual page mentions lo_insert:
? ? ? ? ? LASTOID
? ? ? ? ? ? ? The value of the last affected OID, as returned
-- ? ? ? ? ? ?from an INSERT or lo_insert command. This variable
? ? ? ? ?
Florian Pflug wrote:
Hi
I've just ran into a problem while upgrading from 8.4 to 9.0.
pg_upgrade aborted during the step Adding support functions to new
cluster with ERROR: permission denied for language c error.
Unfortunately, the log didn't include the name of the database where
the
Robert Haas wrote:
On Mon, Dec 13, 2010 at 12:59 AM, Rob Wultsch wult...@gmail.com wrote:
On Sun, Dec 12, 2010 at 7:24 PM, Andrew Dunstan and...@dunslane.net wrote:
In fact it's possible now to disable FK enforcement, by disabling the
triggers. It's definitely a footgun though. Just the
On Wed, Jan 5, 2011 at 9:44 PM, Bruce Momjian br...@momjian.us wrote:
I think pg_dumpall would have failed with this setup too, so I don't see
this as a pg_upgrade bug, nor something that I am willing to risk adding
to pg_upgrade.
If adding RESET SESSION AUTHORIZATION fixes the bug, I think we
Robert Haas wrote:
On Wed, Jan 5, 2011 at 9:44 PM, Bruce Momjian br...@momjian.us wrote:
I think pg_dumpall would have failed with this setup too, so I don't see
this as a pg_upgrade bug, nor something that I am willing to risk adding
to pg_upgrade.
If adding RESET SESSION AUTHORIZATION
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 5, 2011 at 9:44 PM, Bruce Momjian br...@momjian.us wrote:
I think pg_dumpall would have failed with this setup too, so I don't see
this as a pg_upgrade bug, nor something that I am willing to risk adding
to pg_upgrade.
If adding RESET
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 5, 2011 at 9:44 PM, Bruce Momjian br...@momjian.us wrote:
I think pg_dumpall would have failed with this setup too, so I don't see
this as a pg_upgrade bug, nor something that I am willing to risk adding
to pg_upgrade.
On 01/05/2011 11:08 PM, Tom Lane wrote:
If they want to deliberately shoot themselves in the foot by hosing the
login system like that, it's not our job to prevent it. But it's not
our job to try to work around it, either.
I think this is especially true in this
On Thu, Dec 30, 2010 at 08:35:34PM -0500, Noah Misch wrote:
On Thu, Dec 30, 2010 at 12:57:45AM -0500, Robert Haas wrote:
On Thu, Dec 30, 2010 at 12:24 AM, Noah Misch n...@leadboat.com wrote:
On Wed, Dec 29, 2010 at 11:14:37PM -0500, Robert Haas wrote:
I think for any pair of types (T1,
On mån, 2011-01-03 at 11:20 -0500, Tom Lane wrote:
You might want to reflect on rolcatupdate a bit before asserting that
there are no cases where privileges are ever denied to superusers.
Arguably, the reason that that is hardly documented and slightly
deprecated is that the underlying design
On tis, 2011-01-04 at 22:24 -0500, Robert Haas wrote:
Just to be clear: are we saying that CREATE ROLE foo SUPERUSER
should grant both superuser and replication, as well as the default
postgres user also having replication as well?
I think that's what we're saying.
So now superusers have
On Wed, Jan 5, 2011 at 11:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Or we could take the approach somebody was just espousing about
Our job is to prevent the user from *accidentally*
shooting themselves in the foot.
I don't see how you can compare those two cases with a straight face.
In the
On Wed, Jan 5, 2011 at 11:26 PM, Noah Misch n...@leadboat.com wrote:
On Thu, Dec 30, 2010 at 08:35:34PM -0500, Noah Misch wrote:
On Thu, Dec 30, 2010 at 12:57:45AM -0500, Robert Haas wrote:
On Thu, Dec 30, 2010 at 12:24 AM, Noah Misch n...@leadboat.com wrote:
On Wed, Dec 29, 2010 at
2011/1/5 KaiGai Kohei kai...@ak.jp.nec.com:
The attached patch is the modular version of SE-PostgreSQL (take.2).
I'm reading through the documentation and so far it looks pretty
reasonable. But I have some questions and suggested changes, of
course. :-)
1. Why is sepgsql the right name for
On Thu, Jan 06, 2011 at 12:24:19AM -0500, Robert Haas wrote:
I still think you're better off focusing first on the case where we
can skip the whole nine yards, and doing this stuff as a follow-on
patch. Trying to do too many things, especially possibly
controversial stuff, especially in the
(2011/01/06 14:28), Robert Haas wrote:
2011/1/5 KaiGai Koheikai...@ak.jp.nec.com:
The attached patch is the modular version of SE-PostgreSQL (take.2).
I'm reading through the documentation and so far it looks pretty
reasonable. But I have some questions and suggested changes, of
course.
On 2011-01-06 03:10, Robert Haas wrote:
On Wed, Jan 5, 2011 at 3:22 PM, Jesper Kroghjes...@krogh.cc wrote:
Given a crash-safe visibility map, what purpuse does the PD_ALL_VISIBLE bit
serve?
If we modify a page on which PD_ALL_VISIBLE isn't set, we don't
attempt to update the visibility map.
83 matches
Mail list logo
