The attached patch is a revised one for DML permission checks.
List of updates:
- Source code comments in the patched functions were revised.
- ExecCheckRTPerms() and ExecCheckRTEPerms() were moved to aclchk.c,
and renamed to chkpriv_relation_perms() and chkpriv_rte_perms().
- It took the 2nd ar
On Wed, 2010-05-26 at 13:03 +0900, Fujii Masao wrote:
> On Wed, May 26, 2010 at 1:04 AM, Simon Riggs wrote:
> > On Tue, 2010-05-25 at 12:40 +0900, Fujii Masao wrote:
> >> On Tue, May 25, 2010 at 10:29 AM, Josh Berkus wrote:
> >> > I agree that #4 should be done last, but it will be needed, not in
On Tue, 2010-05-25 at 23:59 -0400, Robert Haas wrote:
> Quorum commit is definitely an extra knob, IMHO.
No, its about three less, as I have explained.
Explain your position, don't just demand others listen.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list
On 25/05/10 23:56, Josh Berkus wrote:
Do we get a bit in the visibility map for a page which has aborted
transaction rows on it?
If there's a tuple with an aborted xmin on a page, the bit in the
visibility map is not set. A tuple with aborted xmax doesn't matter.
--
Heikki Linnakangas
En
On 26/05/2010, at 01.16, Jan Urbański wrote:
On 19/05/10 21:01, Jesper Krogh wrote:
The document base is arount 350.000 documents and
I have set the statistics target on the tsvector column
to 1000 since the 100 seems way of.
So for tsvectors the statistics target means more or less "at any
On Wed, May 26, 2010 at 1:04 AM, Simon Riggs wrote:
> On Tue, 2010-05-25 at 12:40 +0900, Fujii Masao wrote:
>> On Tue, May 25, 2010 at 10:29 AM, Josh Berkus wrote:
>> > I agree that #4 should be done last, but it will be needed, not in the
>> > least by your employer ;-) . I don't see any obviou
On Tue, May 25, 2010 at 11:36 PM, Fujii Masao wrote:
> On Wed, May 26, 2010 at 2:10 AM, Simon Riggs wrote:
>> My suggestion is simply to have a single parameter (name unimportant)
>>
>> number_of_synch_servers_we_wait_for = N
>>
>> which is much easier to understand because it is phrased in terms
(2010/05/26 12:17), Tom Lane wrote:
> Stephen Frost writes:
>> That may be the case. I'm certainly more concerned with a bug in the
>> existing code than any new code that we're working on. The question is-
>> is this actually a user-visible bug? Or do we require that a user
>> creating an FK n
On Wed, May 26, 2010 at 2:10 AM, Simon Riggs wrote:
> My suggestion is simply to have a single parameter (name unimportant)
>
> number_of_synch_servers_we_wait_for = N
>
> which is much easier to understand because it is phrased in terms of the
> guarantee given to the transaction, not in terms of
Joe Conway wrote:
> >> There is an open item "pg_controldata - machine readable?" in the list:
> >> http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items
> >> Should we add the module to 9.0?
> >
> > No. This is a new feature that wasn't even under consideration,
> > let alone written, at
Takahiro Itagaki writes:
> * Should we backport the fix to previous releases?
Certainly not. It hasn't gotten through beta, and the risk of
breaking third-party modules is nonnegligible.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
Stephen Frost writes:
> That may be the case. I'm certainly more concerned with a bug in the
> existing code than any new code that we're working on. The question is-
> is this actually a user-visible bug? Or do we require that a user
> creating an FK needs SELECT rights on the primary table?
On 05/25/2010 08:03 PM, Tom Lane wrote:
> Takahiro Itagaki writes:
>> There is an open item "pg_controldata - machine readable?" in the list:
>> http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items
>
>> The proposal by Joe Conway is adding a new contib module.
>> http://archives.postgresql.o
(2010/05/26 11:12), Stephen Frost wrote:
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>>> #2: REALLY BIG ISSUE- You've added ExecutorCheckPerms_hook as part of
>>> this patch- don't, we're in feature-freeze right now and should not be
>>> adding hooks at this time.
>>
>> The patch is intended to
Takahiro Itagaki writes:
> There is an open item "pg_controldata - machine readable?" in the list:
> http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items
> The proposal by Joe Conway is adding a new contib module.
> http://archives.postgresql.org/message-id/4b959d7a.6010...@joeconway.com
> h
On 5/25/2010 4:16 PM, Tom Lane wrote:
Jan Wieck writes:
No, I meant how will the *function* know, if a superuser and/or some
background process can purge records at any time?
The data contains timestamps which are supposedly taken in commit order.
You can *not* rely on the commit timestamp
I've been experimenting with SSL setups involving chains of CA
certificates, ie, where the server or client cert itself is signed by
an intermediate CA rather than a trusted root CA. This appears to work
well enough on the server side if you configure the server correctly
(see discussion of bug #5
This open item is for replacing PGDLLIMPORT markers for PG_MODULE_MAGIC
and PG_FUNCTION_INFO_V1 to __declspec(dllexport) because they are always
expored by user modules rather than by the core codes.
http://archives.postgresql.org/message-id/20100329184705.a60e.52131...@oss.ntt.co.jp
The fix is si
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> The reason why user must have SELECT privileges on the PK/FK tables is
> the validateForeignKeyConstraint() entirely calls SPI_execute() to verify
> FK constraints can be established between two tables (even if fallback path).
>
> And, the reason why
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> > #2: REALLY BIG ISSUE- You've added ExecutorCheckPerms_hook as part of
> > this patch- don't, we're in feature-freeze right now and should not be
> > adding hooks at this time.
>
> The patch is intended to submit for the v9.1 development, not v9.0, i
It was recommended to me to forward this to -hackers.
Regards,
Mark
-- Forwarded message --
From: Mark Wong
Date: Tue, May 18, 2010 at 6:57 AM
Subject: PDXPUG Day at OSCON 2010
To: pgsql-annou...@postgresql.org
Thanks to the generosity of O'Reilly, we will be having a full day
There is an open item "pg_controldata - machine readable?" in the list:
http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items
The proposal by Joe Conway is adding a new contib module.
http://archives.postgresql.org/message-id/4b959d7a.6010...@joeconway.com
http://github.com/jconway/pg_controld
Hector,
* Hector Beyers (hqbey...@gmail.com) wrote:
> Does someone have any ideas how I can hide data without the meta data
> noticing? To explain further, I would like to save some collection of data
> where the meta-data does not see it. I am trying to do some security through
> obscurity. It is
On May 25, 2010, at 22:16 , Simon Riggs wrote:
> All of these issues show why I want to specify the synchronisation mode
> as a USERSET. That will allow us to specify more easily which parts of
> our application are important when the cluster is degraded and which
> data is so critical it must reac
(2010/05/25 22:59), Stephen Frost wrote:
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>> * DoCopy() and RI_Initial_Check() were reworked to call ExecCheckRTEPerms()
>>with locally built RangeTblEntry.
>
> Maybe I missed it somewhere, but we still need to address the case where
> the user doe
(2010/05/25 21:44), Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>> OK, the attached patch reworks it according to the way.
>
> Reviewing this patch, there are a whole slew of problems.
>
> #1: REALLY BIG ISSUE- Insufficient comment updates. You've changed
> f
On 19/05/10 21:01, Jesper Krogh wrote:
> The document base is arount 350.000 documents and
> I have set the statistics target on the tsvector column
> to 1000 since the 100 seems way of.
So for tsvectors the statistics target means more or less "at any time
track at most 10 * lexemes simultaneous
Florian Pflug wrote:
> On May 25, 2010, at 12:18 , Heikki Linnakangas wrote:
>
>> On 25/05/10 13:03, Florian Pflug wrote:
>>
>>> On May 25, 2010, at 6:08 , Sam Vilain wrote:
>>>
http://www.postgresql.org/docs/8.4/static/sql-savepoint.html
Lead us to believe that if you
On 5/25/2010 4:50 PM, Simon Riggs wrote:
On Tue, 2010-05-25 at 16:41 -0400, Jan Wieck wrote:
On 5/25/2010 12:03 PM, Simon Riggs wrote:
> On Sun, 2010-05-23 at 16:21 -0400, Jan Wieck wrote:
>
>> In some systems (data warehousing, replication), the order of commits is
>> important, since that is
> Correct. The problem actually are aborted transactions. Just because an
> XID is really old doesn't mean it was committed.
Yes, that's the main issue with my idea; XIDs which fell off the CLOG
would become visible even if they'd aborted.
Do we get a bit in the visibility map for a page which h
MMK,
> But it does not tell my anything about what the actual buffer size is.
> How do I know what the real buffer size is? I am using 8.4.4 and I am
> running only one query at a time.
Please move this discussion to the pgsql-general or pgsql-performance
lists. pgsql-hackers is for working on P
On 5/24/2010 9:30 AM, Heikki Linnakangas wrote:
On 22/05/10 16:35, Tom Lane wrote:
Josh Berkus writes:
From a discussion at dinner at pgcon, I wanted to send this to the list
for people to poke holes in it:
Somebody (I think Joe or Heikki) poked a big hole in this last night at
the Royal
On Tue, 2010-05-25 at 16:41 -0400, Jan Wieck wrote:
> On 5/25/2010 12:03 PM, Simon Riggs wrote:
> > On Sun, 2010-05-23 at 16:21 -0400, Jan Wieck wrote:
> >
> >> In some systems (data warehousing, replication), the order of commits is
> >> important, since that is the order in which changes have be
Alvaro,
>> This sounds like extending Xid to 64 bits, without having to store the
>> high bits everywhere. Was this discussed in the PGCon devs meeting?
Essentially, yes.
One of the main objections to raising XID to 64-bit has been the per-row
overhead. But adding 4 bytes per page wouldn't be
On 5/25/2010 12:03 PM, Simon Riggs wrote:
On Sun, 2010-05-23 at 16:21 -0400, Jan Wieck wrote:
In some systems (data warehousing, replication), the order of commits is
important, since that is the order in which changes have become visible.
This information could theoretically be extracted from
Robert Haas wrote:
> maybe we should get serializable working and committed on one
> node first and then worry about how to distribute it. I think
> there might be other approaches to this problem
Well, I've got two or three other ideas on how we can manage this
for HS, but since I now realiz
On Tue, 2010-05-25 at 21:19 +0200, Yeb Havinga wrote:
> Simon Riggs wrote:
> > How we handle degraded mode is important, yes. Whatever parameters we
> > choose the problem will remain the same.
> >
> > Should we just ignore degraded mode and respond as if nothing bad had
> > happened? Most people w
Jan Wieck writes:
>> No, I meant how will the *function* know, if a superuser and/or some
>> background process can purge records at any time?
> The data contains timestamps which are supposedly taken in commit order.
You can *not* rely on the commit timestamps to be in exact order.
(Perhaps a
On Tue, May 25, 2010 at 3:39 PM, Hector Beyers wrote:
>
> Hi guys,
> (I tried the question in another forum first)
> Does someone have any ideas how I can hide data without the meta data
> noticing? To explain further, I would like to save some collection of data
> where the meta-data does not see
Scott Marlowe writes:
> So, Tom, so you think it's possible that the planner isn't noticing
> all those nulls and thinks it'll just take a row or two to get to the
> value it needs to join on?
I dug through this and have concluded that it's really an oversight in
the patch I wrote some years ago
On 5/24/2010 9:30 AM, Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
In light of the proposed purging scheme, how would it be able to distinguish
between those two cases (nothing there yet vs. was there but purged)?
There is a difference between an empty resul
Florian Pflug wrote:
> Hm, but for there to be an actual problem (and not a false
> positive), an actual dangerous circle has to exist in the
> dependency graph. The existence of a dangerous structure is just a
> necessary (but not sufficient) and easily checked-for condition
> for that, right?
2010/5/25 Florian Pflug :
> Hm, but for there to be an actual problem (and not a false positive), an
> actual dangerous circle has to exist in the dependency graph. The
> existence of a dangerous structure is just a necessary (but not
> sufficient) and easily checked-for condition for that, right?
Hi guys,
(I tried the question in another forum first)
Does someone have any ideas how I can hide data without the meta data
noticing? To explain further, I would like to save some collection of data
where the meta-data does not see it. I am trying to do some security through
obscurity. It is for
2010/5/25 Florian Pflug :
> On May 25, 2010, at 20:18 , Dan Ports wrote:
>
>> T3, which is a read-only transaction, sees the incremented date and an
>> empty list of receipts. But T1 later commits a new entry in the
>> receipts table with the old date. No serializable ordering allows this.
>>
>> H
On May 25, 2010, at 20:48 , Dan Ports wrote:
> On Tue, May 25, 2010 at 08:35:44PM +0200, Florian Pflug wrote:
>> Hm, so in fact SSI sometimes allows the database to be inconsistent, but
>> only as long as nobody tries to observe it?
>
> Yes. Note that even while it's in an inconsistent state, you
2010/5/25 Dan Ports :
> On Tue, May 25, 2010 at 02:00:42PM +0200, Nicolas Barbier wrote:
>
>> I don't understand the problem. According to me, in the context of
>> SSI, a read-only slave can just map SERIALIZABLE to the technical
>> implementation of REPEATABLE READ (i.e., the currently-existing
>
Hello Heikki:
This is what the documentation says (see below).
But it does not tell my anything about what the actual buffer size is.
How do I know what the real buffer size is? I am using 8.4.4 and I am running
only one query at a time.
Cheers,
MMK.
Sets the planner's assumption about the ef
Hi,
Simon Riggs writes:
> On Tue, 2010-05-25 at 19:08 +0200, Alastair Turner wrote:
>> On Tue, May 25, 2010 at 6:28 PM, Simon Riggs wrote:
>> > The best parameter we can specify is the number of servers that we wish
>> > to wait for confirmation from.
>>
>> This may be an incredibly naive ques
Simon Riggs wrote:
How we handle degraded mode is important, yes. Whatever parameters we
choose the problem will remain the same.
Should we just ignore degraded mode and respond as if nothing bad had
happened? Most people would say not.
If we specify server1 = synch and server2 = async we then
Jan Wieck wrote:
> Have you ever looked at one of those queries, that Londiste or
> Slony issue against the provider DB in order to get all the log
> data that has been committed between two snapshots? Is that really
> the best you can think of?
No, I admit I haven't. In fact, I was thinking
On Tue, May 25, 2010 at 08:35:44PM +0200, Florian Pflug wrote:
> Hm, so in fact SSI sometimes allows the database to be inconsistent, but only
> as long as nobody tries to observe it?
Yes. Note that even while it's in an inconsistent state, you can still
perform any query that doesn't observe the
Florian Pflug wrote:
> Hm, so in fact SSI sometimes allows the database to be
> inconsistent, but only as long as nobody tries to observe it?
Not exactly. The eventually-persisted state is always consistent,
but there can be a transitory committed state which would violate
user-defined constr
Excerpts from Jesper Krogh's message of mié may 19 15:01:18 -0400 2010:
> But the distribution is very "flat" at the end, the last 128 values are
> excactly
> 1.00189e-05
> which means that any term sitting outside the array would get an estimate of
> 1.00189e-05 * 350174 / 2 = 1.75 ~ 2 rows
I d
On May 25, 2010, at 20:18 , Dan Ports wrote:
> On Tue, May 25, 2010 at 02:00:42PM +0200, Nicolas Barbier wrote:
>> I don't understand the problem. According to me, in the context of
>> SSI, a read-only slave can just map SERIALIZABLE to the technical
>> implementation of REPEATABLE READ (i.e., the
On Tue, May 25, 2010 at 02:00:42PM +0200, Nicolas Barbier wrote:
> I don't understand the problem. According to me, in the context of
> SSI, a read-only slave can just map SERIALIZABLE to the technical
> implementation of REPEATABLE READ (i.e., the currently-existing
> "SERIALIZABLE"). The union of
Alvaro Herrera writes:
> This sounds like extending Xid to 64 bits, without having to store the
> high bits everywhere. Was this discussed in the PGCon devs meeting?
Yeah, that's what it would amount to. It was not discussed at the dev
meeting --- it was an idea that came up one evening at PGCo
Robert Haas writes:
> On Tue, May 25, 2010 at 1:09 PM, Mike Fowler wrote:
>>> We're unlikely to accept this patch if it changes the minimum version
>>> of libxml2 required to compile PostgreSQL
>>
>> Why? 2.6.27 is almost 4 years old.
> Because we work hard to minimize our dependencies and make
Robert Haas wrote:
On Tue, May 25, 2010 at 1:09 PM, Mike Fowler wrote:
We're unlikely to accept this patch if it changes the minimum version
of libxml2 required to compile PostgreSQL
Why? 2.6.27 is almost 4 years old.
Because we work hard to minimize our dependencies and mak
On Tue, May 25, 2010 at 6:28 PM, Simon Riggs wrote:
...
>
> The best parameter we can specify is the number of servers that we wish
> to wait for confirmation from. That is a definition that easily manages
> the complexity of having various servers up/down at any one time. It
> also survives m
On Tue, 2010-05-25 at 13:31 -0400, Robert Haas wrote:
> So I agree that we need to talk about whether or not we want to do
> this. I'll give my opinion. I am not sure how useful this really is.
> Consider a master with two standbys. The master commits a
> transaction and waits for one of the tw
On 05/25/2010 01:09 PM, Mike Fowler wrote:
Why? 2.6.27 is almost 4 years old.
RHEL 5 ships with 2.6.26. I imagine that supporting it is very
desirable, regardless of its age, since that is unfortunately still the
latest version of RHEL.
-- m. tharp
--
Sent via pgsql-hackers mailing list (p
On Tue, 2010-05-25 at 19:08 +0200, Alastair Turner wrote:
> On Tue, May 25, 2010 at 6:28 PM, Simon Riggs wrote:
> ...
> >
> > The best parameter we can specify is the number of servers that we wish
> > to wait for confirmation from. That is a definition that easily manages
> > the complexity o
On Tue, May 25, 2010 at 1:09 PM, Mike Fowler wrote:
>> We're unlikely to accept this patch if it changes the minimum version
>> of libxml2 required to compile PostgreSQL
>
> Why? 2.6.27 is almost 4 years old.
Because we work hard to minimize our dependencies and make them as
non-onerous as possib
On Tue, 2010-05-25 at 13:31 -0400, Robert Haas wrote:
> On Tue, May 25, 2010 at 1:10 PM, Simon Riggs wrote:
> > On Tue, 2010-05-25 at 11:52 -0500, Kevin Grittner wrote:
> >> Robert Haas wrote:
> >> > Simon Riggs wrote:
> >> >> If we define robustness at the standby level then robustness
> >> >>
On 25/05/10 19:49, MMK wrote:
Hello All:
In the code (costsize.c), I see that effective_cache_size is set to
DEFAULT_EFFECTIVE_CACHE_SIZE.
This is defined as follows in cost.h
#define DEFAULT_EFFECTIVE_CACHE_SIZE 16384
But when I say
show shared_buffers in psql I get,
shared_buffers
On Tue, May 25, 2010 at 1:10 PM, Simon Riggs wrote:
> On Tue, 2010-05-25 at 11:52 -0500, Kevin Grittner wrote:
>> Robert Haas wrote:
>> > Simon Riggs wrote:
>> >> If we define robustness at the standby level then robustness
>> >> depends upon unseen administrators, as well as the current
>> >> u
Excerpts from Heikki Linnakangas's message of mar may 25 04:41:30 -0400 2010:
> On 24/05/10 22:49, Alvaro Herrera wrote:
> > I think this is nonsense. If you have 3-years-old sales transactions,
> > and your database has any interesting churn, tuples those pages have
> > been frozen for a very lo
On Tue, 2010-05-25 at 11:52 -0500, Kevin Grittner wrote:
> Robert Haas wrote:
> > Simon Riggs wrote:
> >> If we define robustness at the standby level then robustness
> >> depends upon unseen administrators, as well as the current
> >> up/down state of standbys. This is action-at-a-distance in i
Robert Haas wrote:
On Tue, May 25, 2010 at 12:04 PM, Mike Fowler wrote:
Erik Rijkers wrote:
libxml2.x86_64 2.6.26-2.1.2.8 installed
libxml2-devel.x86_642.6.26-2.1.2.8 installed
Thanks for testing my patch Erik. It turns out I've got libxml2 installed at
version
On Tue, 2010-05-25 at 12:40 -0400, Robert Haas wrote:
> On Tue, May 25, 2010 at 12:28 PM, Simon Riggs wrote:
> > Synchronous replication implies that a commit should wait. This wait is
> > experienced by the transaction, not by other parts of the system. If we
> > define robustness at the standby
Howdy,
This tiny doc patch adds _PG_init to the skeleton example code for a
PL. The information is quite valuable to PL authors, who might miss it
when it is described in the shared library documentation.
This patch was based off of 6e2ba96 in the git mirror and a colorized
diff can be viewed her
Robert Haas wrote:
> Simon Riggs wrote:
>> If we define robustness at the standby level then robustness
>> depends upon unseen administrators, as well as the current
>> up/down state of standbys. This is action-at-a-distance in its
>> worst form.
>
> Maybe, but I can't help thinking people are
On Tue, May 25, 2010 at 10:52 AM, Joseph Adams
wrote:
>> Well, I think it's fine to use the wiki for brainstorming, but before
>> you change the design you probably need to talk about it here. You
>> can't rely on everyone on -hackers to follow changes on a wiki page
>> somewhere. It looks like
Hello All:
In the code (costsize.c), I see that effective_cache_size is set
to DEFAULT_EFFECTIVE_CACHE_SIZE.
This is defined as follows in cost.h
#define DEFAULT_EFFECTIVE_CACHE_SIZE 16384
But when I say
show shared_buffers in psql I get,
shared_buffers 28MB
In postgresql.conf fi
On Tue, 2010-05-25 at 12:40 -0400, Robert Haas wrote:
> On Tue, May 25, 2010 at 12:28 PM, Simon Riggs wrote:
> > Synchronous replication implies that a commit should wait. This wait is
> > experienced by the transaction, not by other parts of the system. If we
> > define robustness at the standby
On Tue, May 25, 2010 at 12:04 PM, Mike Fowler wrote:
> Erik Rijkers wrote:
>>
>> libxml2.x86_64 2.6.26-2.1.2.8 installed
>> libxml2-devel.x86_64 2.6.26-2.1.2.8 installed
>>
>
> Thanks for testing my patch Erik. It turns out I've got libxml2 installed at
> version 2.7.5. Searching the
On Tue, May 25, 2010 at 12:36 PM, Simon Riggs wrote:
> On Tue, 2010-05-25 at 19:12 +0900, Fujii Masao wrote:
>> On Mon, May 17, 2010 at 5:33 PM, Fujii Masao wrote:
>> > On Sat, May 15, 2010 at 3:20 AM, Robert Haas wrote:
>> >> Hmm, OK, I think that makes sense. Would you care to propose a patch
On Tue, May 25, 2010 at 12:28 PM, Simon Riggs wrote:
> Synchronous replication implies that a commit should wait. This wait is
> experienced by the transaction, not by other parts of the system. If we
> define robustness at the standby level then robustness depends upon
> unseen administrators, as
On Tue, 2010-05-25 at 19:12 +0900, Fujii Masao wrote:
> On Mon, May 17, 2010 at 5:33 PM, Fujii Masao wrote:
> > On Sat, May 15, 2010 at 3:20 AM, Robert Haas wrote:
> >> Hmm, OK, I think that makes sense. Would you care to propose a patch?
> >
> > Yep. Here is the patch.
> >
> > This patch distin
On Mon, 2010-05-24 at 18:29 -0700, Josh Berkus wrote:
> If people agree that the above is our roadmap, implementing
> "per-standby" first makes sense, and then we can implement "per-session"
> GUC later.
IMHO "per-standby" sounds simple, but is dangerously simplistic,
explained on another part of
On Mon, 2010-05-24 at 22:20 +0900, Fujii Masao wrote:
> Second, we need to discuss about how to specify the synch
> level. There are three approaches:
>
> * Per standby
> Since the purpose, location and H/W resource often differ
> from one standby to another, specifying level per standby
>
On Tue, 2010-05-25 at 12:40 +0900, Fujii Masao wrote:
> On Tue, May 25, 2010 at 10:29 AM, Josh Berkus wrote:
> > I agree that #4 should be done last, but it will be needed, not in the
> > least by your employer ;-) . I don't see any obvious way to make #4
> > compatible with any significant query
On Sun, 2010-05-23 at 16:21 -0400, Jan Wieck wrote:
> In some systems (data warehousing, replication), the order of commits is
> important, since that is the order in which changes have become visible.
> This information could theoretically be extracted from the WAL, but
> scanning the entire WAL
Erik Rijkers wrote:
libxml2.x86_64 2.6.26-2.1.2.8 installed
libxml2-devel.x86_642.6.26-2.1.2.8 installed
Thanks for testing my patch Erik. It turns out I've got libxml2
installed at version 2.7.5. Searching the gnome mailing lists, it turns
out xmlXPathCompiledEvalToBoolean
On Tue, May 25, 2010 16:31, Mike Fowler wrote:
> I've been reading the SQL/XML standard and discovered that it defines a
> function named XMLEXISTS that does exactly what the todo item
> xpath_exists defines. My original patch named the function as per the
> todo but I think using the function name
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> 3. Have CheckConnection do longjmp(sigint_interrupt_jmp) after resetting
...
> Now #1 might be the best long-term solution but I have no particular
> appetite to tackle it, and #2 is just too ugly to contemplate. That
> leaves #3, which is a
Robert Haas wrote:
> On Mon, May 24, 2010 at 11:35 PM, Bruce Momjian wrote:
> > Have you read the docs? ?It does mention the issue with /contrib and
> > stuff. ?How do I document a limitation I don't know about? ?This is all
> > very vague. ?Please suggest some wording.
>
> OK, here's an attempt.
> Well, I think it's fine to use the wiki for brainstorming, but before
> you change the design you probably need to talk about it here. You
> can't rely on everyone on -hackers to follow changes on a wiki page
> somewhere. It looks like the API has been overhauled pretty heavily
> since the last
Alex Goncharov wrote:
,--- I/Alex (Mon, 24 May 2010 12:25:18 -0400) *
| No equivalent of FETCH_COUNT is available at the libpq level, so I
| assume that the interface I am using is smart enough not to send
| gigabytes of data to FE.
|
| Where does the result set (GBs of data) reside after
I've been reading the SQL/XML standard and discovered that it defines a
function named XMLEXISTS that does exactly what the todo item
xpath_exists defines. My original patch named the function as per the
todo but I think using the function name from the standard is a better
idea. So this patch
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> * DoCopy() and RI_Initial_Check() were reworked to call ExecCheckRTEPerms()
> with locally built RangeTblEntry.
Maybe I missed it somewhere, but we still need to address the case where
the user doesn't have those SELECT permissions that we're lookin
On 05/25/2010 07:35 AM, Alex Goncharov wrote:
,--- I/Alex (Mon, 24 May 2010 12:25:18 -0400) *
| No equivalent of FETCH_COUNT is available at the libpq level, so I
| assume that the interface I am using is smart enough not to send
| gigabytes of data to FE.
|
| Where does the result set (GBs o
On Mon, May 24, 2010 at 11:35 PM, Bruce Momjian wrote:
> Have you read the docs? It does mention the issue with /contrib and
> stuff. How do I document a limitation I don't know about? This is all
> very vague. Please suggest some wording.
OK, here's an attempt. Please fact-check.
--
Gener
,--- Abhijit Menon-Sen (Tue, 25 May 2010 17:26:18 +0530) *
| Unless you explicitly declare and fetch from an SQL-level cursor, your
| many GBs of data are going to be transmitted to libpq, which will eat
| lots of memory. (The wire protocol does have something like cursors,
| but libpq does not
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> OK, the attached patch reworks it according to the way.
Reviewing this patch, there are a whole slew of problems.
#1: REALLY BIG ISSUE- Insufficient comment updates. You've changed
function definitions in a pretty serious way as well as mov
On Tue, May 25, 2010 at 12:57, Robert Haas wrote:
> On Tue, May 25, 2010 at 5:37 AM, Joseph Adams
> wrote:
>> I started a wiki article for brainstorming the JSON API:
>> http://wiki.postgresql.org/wiki/JSON_API_Brainstorm . I also made
>> substantial changes to the draft of the API based on disc
At 2010-05-25 07:35:34 -0400, alex-goncha...@comcast.net wrote:
>
> | Where does the result set (GBs of data) reside after I call
> | PQexecPrepared? On BE, I hope?
Unless you explicitly declare and fetch from an SQL-level cursor, your
many GBs of data are going to be transmitted to libpq, which
Alex Goncharov wrote:
,--- I/Alex (Mon, 24 May 2010 12:25:18 -0400) *
| No equivalent of FETCH_COUNT is available at the libpq level, so I
| assume that the interface I am using is smart enough not to send
| gigabytes of data to FE.
|
| Where does the result set (GBs of data) reside after I
2010/5/25 Dan Ports :
> On Mon, May 24, 2010 at 10:24:07AM -0500, Kevin Grittner wrote:
>
>> Replicating or recreating the whole predicate locking and conflict
>> detection on slaves is not feasible for performance reasons. (I
>> won't elaborate unless someone feels that's not intuitively
>> obvio
1 - 100 of 115 matches
Mail list logo
