On Mon, May 24, 2010 at 10:20 PM, Fujii Masao wrote:
> At the first design phase, I'd like to clarify which synch levels
> should be supported 9.1 and how it should be specified by users.
There is another question about synch level:
When should the master wait for replication?
In my current
The note at the end of;
http://www.postgresql.org/docs/8.4/static/sql-savepoint.html
Lead us to believe that if you roll back to the same savepoint name
twice in a row, that you might start walking back through the
savepoints. I guess I missed the note on ROLLBACK TO SAVEPOINT that
that is not h
Robert Haas writes:
> On Mon, May 24, 2010 at 5:37 PM, Alvaro Herrera
> wrote:
>> Excerpts from Robert Haas's message of lun may 24 17:18:21 -0400 2010:
>>> Well, I might be missing something here, but pg_class already IS
>>> database-specific. If you change anything very significant about a
>>
On Mon, May 24, 2010 at 5:37 PM, Alvaro Herrera wrote:
> Excerpts from Robert Haas's message of lun may 24 17:18:21 -0400 2010:
>> On Mon, May 24, 2010 at 4:23 PM, Alvaro Herrera
>> wrote:
>> > Excerpts from Robert Haas's message of vie may 21 10:20:38 -0400 2010:
>
>> > Uh, how does this work w
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 load on the slave, but in general
> I'd think that users of #
On Mon, May 24, 2010 at 11:25 PM, Jeff Davis wrote:
> I think the original case (same values only) is potentially useful
> enough that we should support it.
+1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-hackers mailing list (pgs
On Mon, May 24, 2010 at 10:51 PM, Stephen Frost wrote:
> * Stephen Frost (sfr...@snowman.net) wrote:
>> Add regression testing for psql backslash commands
>>
>> This patch adds rather extensive regression testing
>> of the psql backslash commands. Hopefully this will
>> minimize i
Robert Haas wrote:
> On Mon, May 24, 2010 at 5:50 PM, Bruce Momjian wrote:
> > What is your point?
>
> My point is that I think Stefan has a good point when he says this:
>
> >> >> >> hmm that seems better thanks, however I just noticed that we don't
> >> >> >> have
> >> >> >> a "general limita
On Sat, 2010-05-22 at 01:02 +0300, Marko Tiikkaja wrote:
> On 5/21/10 11:47 PM +0300, Jeff Davis wrote:
> > It also allows you to enforce the constraint that only one tuple exists
> > in a table by doing something like:
> >
> >create table a
> >(
> > i int,
> > exclude using gist
Stephen Frost writes:
> ... It makes me wonder if COPY shouldn't have been implemented using
> the Executor instead, but that's, again, a completely separate topic.
> It wasn't, but it wants to play like it operates in the same kind of way
> as INSERT, so it needs to pick up the slack.
FWIW, we'v
On Mon, May 24, 2010 at 5:50 PM, Bruce Momjian wrote:
> What is your point?
My point is that I think Stefan has a good point when he says this:
>> >> >> hmm that seems better thanks, however I just noticed that we don't have
>> >> >> a "general limitations" section. The way the docs are now done
On Mon, May 24, 2010 at 9:27 PM, Stephen Frost wrote:
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>> We have two options; If the checker function takes the list of RangeTblEntry,
>> it will be comfortable to ExecCheckRTPerms(), but not DoCopy(). Inversely,
>> if the checker function takes argum
2010/5/24 KaiGai Kohei :
> I think we need a new SPI_*() interface which allows to run the given query
> without any permission checks, because these queries are purely internal
> stuff,
> so we can trust the query is harmless.
[...]
> I'm afraid of that the src/backend/catalog/aclchk.c will becom
(2010/05/25 10:27), Stephen Frost wrote:
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>> We have two options; If the checker function takes the list of RangeTblEntry,
>> it will be comfortable to ExecCheckRTPerms(), but not DoCopy(). Inversely,
>> if the checker function takes arguments in my pat
(2010/05/25 10:13), Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>>postgres=# ALTER TABLE pk_tbl OWNER TO ymj;
>>ALTER TABLE
>>postgres=# ALTER TABLE fk_tbl OWNER TO ymj;
>>ALTER TABLE
>>postgres=# REVOKE ALL ON pk_tbl, fk_tbl FROM ymj;
>>
* Stephen Frost (sfr...@snowman.net) wrote:
> Add regression testing for psql backslash commands
>
> This patch adds rather extensive regression testing
> of the psql backslash commands. Hopefully this will
> minimize issues such as the one which cropped up
> recently with
On Tue, May 25, 2010 at 1:18 AM, Heikki Linnakangas
wrote:
> I see a lot of value in #4; it makes it possible to distribute read-only
> load to the standby using something like pgbouncer, completely transparently
> to the application.
Agreed.
> In the lesser modes, the application can see slight
We determined that $SUBJECT would be a good idea in this thread:
http://archives.postgresql.org/pgsql-bugs/2010-05/msg00159.php
I looked a bit at what it would take to make this happen. The
difficulty is that the input buffer is a local variable in MainLoop(),
and so are a bunch of other subsidia
> #4 is useful for some cases, but might often make the
> transaction commit on the master get stuck since read-only
> query can easily block recovery by the lock conflict. So
> #4 seems not to be worth working on until that HS problem
> has been addressed. Thought?
I agree that #4 should be done
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> We have two options; If the checker function takes the list of RangeTblEntry,
> it will be comfortable to ExecCheckRTPerms(), but not DoCopy(). Inversely,
> if the checker function takes arguments in my patch, it will be comfortable
> to DoCopy(), but
Florian Pflug writes:
> The subtle point here is whether you consider the view from the "outside" (in
> the sense of what a read-only transaction started at an arbitrary time can or
> cannot observe), or from the "inside" (what updating transactions can observe
> and might base their updates on
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> postgres=# ALTER TABLE pk_tbl OWNER TO ymj;
> ALTER TABLE
> postgres=# ALTER TABLE fk_tbl OWNER TO ymj;
> ALTER TABLE
> postgres=# REVOKE ALL ON pk_tbl, fk_tbl FROM ymj;
> REVOKE
> postgres=# GRANT REFERENCES ON pk_tbl, fk_tbl TO
(2010/05/25 4:11), Stephen Frost wrote:
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>> I'd like to point out two more points are necessary to be considered
>> for DML permission checks in addition to ExecCheckRTPerms().
>>
>> * DoCopy()
>>
>> Although DoCopy() is called from standard_ProcessUtil
On May 25, 2010, at 0:42 , Dan Ports wrote:
> On Mon, May 24, 2010 at 10:24:07AM -0500, Kevin Grittner wrote:
>> 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.
>>
>>
Marko Tiikkaja wrote:
> On 5/21/10 11:47 PM +0300, Jeff Davis wrote:
> > It also allows you to enforce the constraint that only one tuple exists
> > in a table by doing something like:
> >
> >create table a
> >(
> > i int,
> > exclude using gist (i with<>),
> > unique (i)
(2010/05/24 22:18), Robert Haas wrote:
> 2010/5/24 KaiGai Kohei:
>> BTW, I guess the reason why permissions on attributes are not checked here is
>> that we missed it at v8.4 development.
>
> That's a little worrying. Can you construct and post a test case
> where this results in a user-visible f
On Mon, May 24, 2010 at 10:24:07AM -0500, Kevin Grittner wrote:
> 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 issue intersects with the serializable work
On Mon, May 24, 2010 at 5:38 PM, Dave Page wrote:
> On Mon, May 24, 2010 at 5:20 PM, Robert Haas wrote:
>
It works OK for me. The link to /contrib/pg_upgrade within the nav
section at the top righthand corner of the page seems to work just
fine.
http://wiki.postgresql.or
On 5/24/2010 3:10 PM, Dan Ports wrote:
I'm not clear on why the total rowcount is useful, but perhaps I'm
missing something obvious.
It is a glimpse into the future. Several years of pain doing replication
work has taught me that knowing approximately who much work the next
chunk will be "bef
Robert Haas wrote:
> On Mon, May 24, 2010 at 3:41 PM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> On Mon, May 24, 2010 at 3:11 PM, Bruce Momjian wrote:
> >> > Stefan Kaltenbrunner wrote:
> >> >> > I have updated the paragraph to be:
> >> >> >
> >> >> > ? ? Upgrading from PostgreSQL 8.3 has a
On Mon, May 24, 2010 at 5:20 PM, Robert Haas wrote:
>>> It works OK for me. The link to /contrib/pg_upgrade within the nav
>>> section at the top righthand corner of the page seems to work just
>>> fine.
>>>
>>> http://wiki.postgresql.org/wiki/Todo#.2Fcontrib.2Fpg_upgrade
>>
>> The problem is th
Excerpts from Robert Haas's message of lun may 24 17:18:21 -0400 2010:
> On Mon, May 24, 2010 at 4:23 PM, Alvaro Herrera
> wrote:
> > Excerpts from Robert Haas's message of vie may 21 10:20:38 -0400 2010:
> > Uh, how does this work when you change the entries for shared relations
> > in a databa
On 5/24/2010 12:51 PM, Kevin Grittner wrote:
Robert Haas wrote:
I think you're confusing two subtly different things.
The only thing I'm confused about is what benefit anyone expects to
get from looking at data between commits in some way other than our
current snapshot mechanism. Can som
On Mon, May 24, 2010 at 4:03 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> It's a tool for replication solutions to use.
>
> I was thrown by the original post referencing "data warehousing".
> For replication I definitely see that it would be good to provide
> some facility to grab a cohere
On Mon, May 24, 2010 at 3:41 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Mon, May 24, 2010 at 3:11 PM, Bruce Momjian wrote:
>> > Stefan Kaltenbrunner wrote:
>> >> > I have updated the paragraph to be:
>> >> >
>> >> > ? ? Upgrading from PostgreSQL 8.3 has additional restrictions not
>> >>
On Mon, May 24, 2010 at 4:23 PM, Alvaro Herrera wrote:
> Excerpts from Robert Haas's message of vie may 21 10:20:38 -0400 2010:
>
>> Actually, there's another way we could do this. Instead of creating
>> pg_shared_class and pg_shared_attribute and moving all of the catalog
>> entries for the sha
Excerpts from Robert Haas's message of vie may 21 10:20:38 -0400 2010:
> Actually, there's another way we could do this. Instead of creating
> pg_shared_class and pg_shared_attribute and moving all of the catalog
> entries for the shared relations into those tables, we could consider
> leaving t
Robert Haas wrote:
> It's a tool for replication solutions to use.
I was thrown by the original post referencing "data warehousing".
For replication I definitely see that it would be good to provide
some facility to grab a coherent snapshot out of the transaction
stream, but I'm still not clea
Excerpts from Josh Berkus's message of vie may 21 17:57:35 -0400 2010:
> Problem: currently, if your database has a large amount of "cold" data,
> such as 350GB of 3-year-old sales transactions, in 8.4 vacuum no longer
> needs to touch it thanks to the visibility map. However, every
> freeze_a
Robert Haas wrote:
> On Mon, May 24, 2010 at 3:11 PM, Bruce Momjian wrote:
> > Stefan Kaltenbrunner wrote:
> >> > I have updated the paragraph to be:
> >> >
> >> > ? ? Upgrading from PostgreSQL 8.3 has additional restrictions not present
> >> > ? ? when upgrading from later PostgreSQL releases. ?F
* Michael Meskes (mes...@postgresql.org) wrote:
> > I think the current coding is extremely fragile (if it indeed works at
> > all) because of its assumption that has been included
>
> Well, this is the case in the code so far.
Right, the existing code is after limits.h is included, my suggesti
> I think the current coding is extremely fragile (if it indeed works at
> all) because of its assumption that has been included
Well, this is the case in the code so far.
> already. In any case, we have configure tests that exist only for the
> benefit of contrib modules, so it's hard to argu
On Mon, May 24, 2010 at 3:11 PM, Bruce Momjian wrote:
> Stefan Kaltenbrunner wrote:
>> > I have updated the paragraph to be:
>> >
>> > Upgrading from PostgreSQL 8.3 has additional restrictions not present
>> > when upgrading from later PostgreSQL releases. For example,
>> > pg_upgrade
On Sun, May 23, 2010 at 04:21:58PM -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 entir
On Mon, May 24, 2010 at 3:07 PM, Alvaro Herrera wrote:
> It'd be nice to have as a side effect, but if not, IMHO this proposal
> could simply use a fixed buffer pool like all other slru.c callers until
> someone gets around to fixing that. Adding more GUC switches for this
> strikes me as overkil
Stefan Kaltenbrunner wrote:
> > I have updated the paragraph to be:
> >
> > Upgrading from PostgreSQL 8.3 has additional restrictions not present
> > when upgrading from later PostgreSQL releases. For example,
> > pg_upgrade will not work for a migration from 8.3 if a user column
> >
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> I'd like to point out two more points are necessary to be considered
> for DML permission checks in addition to ExecCheckRTPerms().
>
> * DoCopy()
>
> Although DoCopy() is called from standard_ProcessUtility(), it performs
> as DML statement, rather
Excerpts from Robert Haas's message of dom may 23 20:38:14 -0400 2010:
> On Sun, May 23, 2010 at 4:21 PM, Jan Wieck wrote:
> > The system will have postgresql.conf options for enabling/disabling the
> > whole shebang, how many shared buffers to allocate for managing access
> > to the data and to d
On Mon, May 24, 2010 at 12:51 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>> I think you're confusing two subtly different things.
>
> The only thing I'm confused about is what benefit anyone expects to
> get from looking at data between commits in some way other than our
> current snapshot me
On 05/24/2010 07:43 PM, Bruce Momjian wrote:
Stefan Kaltenbrunner wrote:
On 05/19/2010 05:16 PM, Bruce Momjian wrote:
Andres Freund wrote:
On Wednesday 19 May 2010 22:39:32 Bruce Momjian wrote:
There are some limitations when migrating from 8.3 to 8.4, but not when
migrating from 8.3 to 9.0,
Pavel Stehule wrote:
> Hello
>
> it fixes bug
>
> pg_upgrade(13359) malloc: *** error for object 0x801600:
> non-page-aligned, non-allocated pointer being freed
> *** set a breakpoint in malloc_error_break to debug
>
>
> arget 03:31 /usr/local/src/postgresql/contrib/pg_upgrade git diff .
> diff
Stefan Kaltenbrunner wrote:
> On 05/19/2010 05:16 PM, Bruce Momjian wrote:
> > Andres Freund wrote:
> >> On Wednesday 19 May 2010 22:39:32 Bruce Momjian wrote:
> >>> There are some limitations when migrating from 8.3 to 8.4, but not when
> >>> migrating from 8.3 to 9.0, because we added a feature t
Michael Meskes writes:
> On Sat, May 22, 2010 at 11:20:50PM -0400, Stephen Frost wrote:
>> git diff -p), I noted that c.h is already included by both extern.h
>> and ecpg.header through postgres_fe.h. Given this and that we're
>> already doing alot of similar #define's there (unlike in those othe
On 24/05/10 19:51, Kevin Grittner wrote:
The only thing I'm confused about is what benefit anyone expects to
get from looking at data between commits in some way other than our
current snapshot mechanism. Can someone explain a use case where
what Jan is proposing is better than snapshot isolatio
Robert Haas wrote:
> I think you're confusing two subtly different things.
The only thing I'm confused about is what benefit anyone expects to
get from looking at data between commits in some way other than our
current snapshot mechanism. Can someone explain a use case where
what Jan is propo
I'm not sure it's cheap. What you suggest would result in a substantial
increase in clog accesses, which means (1) more I/O and (2) more
contention. Certainly it's worth experimenting with, but it's no
guaranteed win.
It seems like there's a number of issues we could fix by making the CLOG
I have some libpq-using application code, in which fetching the data
follows this logic (after a statement has been prepared):
PQexecPrepared(pg_result, pg_conn, pg_statement_name, input_param_cnt,
param_values, param_lengths, param_form
On 24/05/10 16:20, Fujii Masao wrote:
The log-shipping replication has some synch levels as follows.
The transaction commit on the master
#1 doesn't wait for replication (already suppored in 9.0)
#2 waits for WAL to be received by the standby
#3 waits for WAL to be received and f
On Sat, May 22, 2010 at 11:20:50PM -0400, Stephen Frost wrote:
> git diff -p), I noted that c.h is already included by both extern.h
> and ecpg.header through postgres_fe.h. Given this and that we're
> already doing alot of similar #define's there (unlike in those other
> files), I felt c.
On Sun, May 23, 2010 at 11:50:00AM -0400, Stephen Frost wrote:
> > If we need this we should do it properly with autoconf.
I absolutely agree and planed to do that *after* the release if it makes sense
for the rest of PG, but wouldn't want to mess with it in the current
situtation. On the other ha
On Mon, May 24, 2010 at 11:24 AM, Kevin Grittner
wrote:
> 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 issue intersects with the serializable work I've been doi
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 issue intersects with the serializable work I've been doing.
While in database transactions using S2PL the above is true,
Fujii Masao writes:
> Okay, how about the attached patch? It uses the postmaster-local flag
> "ReachedEndOfRecovery" (better name?) instead of XLogCtl one.
ReachedNormalRunning, perhaps?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
On Mon, May 24, 2010 at 10:35 AM, Fujii Masao wrote:
> On Mon, May 24, 2010 at 10:26 PM, Robert Haas wrote:
>> This looks pretty reasonable to me, but I guess I feel like it would
>> be better to drive the CancelBackup() decision off of whether we've
>> ever reached PM_RUN rather than consulting
On Mon, May 24, 2010 at 10:26 PM, Robert Haas wrote:
> This looks pretty reasonable to me, but I guess I feel like it would
> be better to drive the CancelBackup() decision off of whether we've
> ever reached PM_RUN rather than consulting XLogCtl. It just feels
> cleaner to me to drive all of the
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
>> Well, the best way to define what a trusted language can do is to
>> define a *whitelist* of what it can do, not a blacklist of what it
>> can't do. That's the only way to get a complete definition. It's then
>> up to the implementation step
Robert Haas writes:
> On Mon, May 24, 2010 at 9:28 AM, Simon Riggs wrote:
>> On Mon, 2010-05-24 at 09:26 -0400, Robert Haas wrote:
>>> This looks pretty reasonable to me, but I guess I feel like it would
>>> be better to drive the CancelBackup() decision off of whether we've
>>> ever reached PM_R
Heikki Linnakangas writes:
> (As also discussed in the Royal Oak) I think we should simply not dirty
> a page when a hint bit is updated. Reading a page from disk is
> expensive, setting hint bits on the access is generally cheap compared
> to that. But that is orthogonal to the idea of a per-p
On Mon, May 24, 2010 at 9:28 AM, Simon Riggs wrote:
> On Mon, 2010-05-24 at 09:26 -0400, Robert Haas wrote:
>> On Mon, May 24, 2010 at 1:27 AM, Fujii Masao wrote:
>> > On Wed, May 19, 2010 at 2:47 PM, Fujii Masao wrote:
>> Oh, right. How about allowing the postmaster only in PM_STARTUP,
>>
On Sun, May 23, 2010 at 9:44 PM, Jan Wieck wrote:
> I'm not sure the retention policies of the shared buffer cache, the WAL
> buffers, CLOG buffers and every other thing we try to cache are that easy to
> fold into one single set of logic. But I'm all ears.
I'm not sure either, although it seems
On Mon, 2010-05-24 at 09:26 -0400, Robert Haas wrote:
> On Mon, May 24, 2010 at 1:27 AM, Fujii Masao wrote:
> > On Wed, May 19, 2010 at 2:47 PM, Fujii Masao wrote:
> Oh, right. How about allowing the postmaster only in PM_STARTUP,
> PM_RECOVERY, PM_HOT_STANDBY or PM_WAIT_READONLY state
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 Oak.
Me.
Although the scheme would get rid o
-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 result set and an exception.
No, I meant how will
On Mon, May 24, 2010 at 1:27 AM, Fujii Masao wrote:
> On Wed, May 19, 2010 at 2:47 PM, Fujii Masao wrote:
Oh, right. How about allowing the postmaster only in PM_STARTUP,
PM_RECOVERY, PM_HOT_STANDBY or PM_WAIT_READONLY state to invoke
walreceiver? We can keep walreceiver alive unti
Hi,
I'm now designing the "synchronous" replication feature based on
SR for 9.1, while discussing that at another thread.
http://archives.postgresql.org/pgsql-hackers/2010-04/msg01516.php
At the first design phase, I'd like to clarify which synch levels
should be supported 9.1 and how it should b
2010/5/24 KaiGai Kohei :
> BTW, I guess the reason why permissions on attributes are not checked here is
> that we missed it at v8.4 development.
That's a little worrying. Can you construct and post a test case
where this results in a user-visible failure in CVS HEAD?
> The attached patch provid
On 5/23/2010 11:19 PM, Andrew Dunstan wrote:
Jan Wieck wrote:
ISTM we are in danger of confusing several different things. A user
that doesn't want data to be shared should not stash it in global
objects. But to me, trusting a language is not about making data
private, but about not allowin
77 matches
Mail list logo
