On Fri, Mar 18, 2011 at 2:46 AM, Robert Haas wrote:
> On further review, I've changed my mind. Making synchronous_commit
> trump synchronous_replication is appealing conceptually, but it's
> going to lead to some weird corner cases. For example, a transaction
> that drops a non-temporary relatio
On Fri, Mar 18, 2011 at 2:52 AM, Robert Haas wrote:
> On Thu, Mar 10, 2011 at 3:04 PM, Robert Haas wrote:
>>> - /* Let the master know that we received some data.
>>> */
>>> - XLogWalRcvSendReply();
>>> - XLogWalRcvSendHSFeedback(
On Fri, Mar 18, 2011 at 1:17 AM, Robert Haas wrote:
>> Sorry, I've not been able to understand the point well yet. We should
>> just use elog(ERROR) instead? But since ERROR in startup process
>> is treated as FATAL, I'm not sure whether it's worth using ERROR
>> instead. Or you meant another thin
On Wed, 2011-03-16 at 13:35 -0400, Robert Haas wrote:
> 2. If a query cancel interrupt is received (pg_cancel_backend or ^C),
> then cancel the sync rep wait and issue a warning before acknowledging
> the commit.
When I saw this commit, I noticed that the WARNING doesn't have an
errcode(). It seem
On Thu, Mar 17, 2011 at 5:29 PM, Andrew Dunstan wrote:
>> Is this really intended?
>
> I sure hope not.
That's a bug. Not sure if it's a psql bug or a backend bug, but it's
definitely a bug.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent vi
On 03/17/2011 05:22 PM, Alvaro Herrera wrote:
I just ran this quick test in HEAD:
and was very surprised to see that the foreign key is marked as NOT
VALID:
Is this really intended?
I sure hope not.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On Thu, Mar 17, 2011 at 4:02 PM, Jesper Krogh wrote:
> On the 1 bit per page the "best case" would be 341 times better than above
> reducing the size of the visibiility map on a 10GB table to around 152KB
> which
> is extremely small (and thus also awesome) But the consequenses of a single
> updat
I just ran this quick test in HEAD:
alvherre=# create table study (id int primary key);
NOTICE: CREATE TABLE / PRIMARY KEY creará el índice implícito «study_pkey»
para la tabla «study»
CREATE TABLE
alvherre=# insert into study select a from generate_series(1, 100) as a;
INSERT 0 100
alvh
Rados*aw Smogura wrote:
> I have implemented initial concept of 2nd level cache. Idea is to
> keep some segments of shared memory for special buffers (e.g.
> indices) to prevent overwrite those by other operations. I added
> those functionality to nbtree index scan.
>
> I tested this with doing
On 2011-03-17 15:02, Robert Haas wrote:
On Thu, Mar 17, 2011 at 4:17 AM, Jesper Krogh wrote:
Is it obvious that the visibillity map bits should track complete
pages and not individual tuples? If the visibillity map tracks at
page-level the benefit would fall on "slim tables" where you squeeze
2
Hi,
I have implemented initial concept of 2nd level cache. Idea is to keep some
segments of shared memory for special buffers (e.g. indices) to prevent
overwrite those by other operations. I added those functionality to nbtree
index scan.
I tested this with doing index scan, seq read, drop sys
On Mon, Jan 31, 2011 at 10:45 PM, Fujii Masao wrote:
> On Tue, Feb 1, 2011 at 1:31 AM, Heikki Linnakangas
> wrote:
>> Hmm, good point. It's harmless, but creating the history file in the first
>> place sure seems like a waste of time.
>
> The attached patch changes pg_stop_backup so that it doesn
2011/3/16 Devrim GÜNDÜZ :
> On Tue, 2011-03-15 at 22:00 -0400, Tom Lane wrote:
>>
>> > My only hesitation about this is that it seems like sync rep and
>> > collation support are both still pretty broken. Should we just not
>> > worry about that for alpha?
>>
>> FWIW, collations are probably still
On tis, 2011-03-15 at 20:44 +0200, Peter Eisentraut wrote:
> Consequently, I propose the attached patch. I didn't find any
> relevant documentation references that would need updating.
Applied.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
On 17 March 2011 17:55, Robert Haas wrote:
> On Thu, Mar 17, 2011 at 1:24 PM, Thom Brown wrote:
>> errdetail("The transaction has already been committed locally but
>> might have not been replicated to the standby.")));
>> errdetail("The transaction has committed locally, but may not have
>> repl
On Thu, 2011-03-17 at 13:46 -0400, Robert Haas wrote:
> On Fri, Mar 11, 2011 at 5:46 AM, Fujii Masao wrote:
> > On Fri, Mar 11, 2011 at 5:04 AM, Robert Haas wrote:
> >>>if ((wrote_xlog && XactSyncCommit) || forceSyncCommit || nrels > 0
> >>> ||
> >>> SyncRepRequested())
> >>>
> >>> Whene
On Thu, Mar 17, 2011 at 1:24 PM, Thom Brown wrote:
> errmsg("canceling the wait for replication and terminating connection
> due to administrator command")
> errmsg("canceling wait for synchronous replication due to user request")
>
> Should that first one then also say "synchronous replication"?
On Thu, Mar 10, 2011 at 3:04 PM, Robert Haas wrote:
>> - /* Let the master know that we received some data. */
>> - XLogWalRcvSendReply();
>> - XLogWalRcvSendHSFeedback();
>>
>> This change completely eliminates the difference betwe
On Fri, Mar 11, 2011 at 5:46 AM, Fujii Masao wrote:
> On Fri, Mar 11, 2011 at 5:04 AM, Robert Haas wrote:
>>> if ((wrote_xlog && XactSyncCommit) || forceSyncCommit || nrels > 0 ||
>>> SyncRepRequested())
>>>
>>> Whenever synchronous_replication is TRUE, we disable synchronous_commit.
>>> B
On Thu, Mar 17, 2011 at 2:47 AM, Fujii Masao wrote:
> On Wed, Mar 16, 2011 at 11:27 PM, Tom Lane wrote:
>> Fujii Masao writes:
>>> How should recovery work when pause_at_recovery_target is
>>> enabled but hot standby is disabled? We have three choices:
>>
>>> 1. Forbit those settings, i.e., thro
hom wrote:
> I try to known how a database is implemented and I have been
> reading PG source codes for a month.
That's ambitious.
find -name '*.h' -or -name '*.c' \
| egrep -v '^\./src/test/.+/tmp_check/' \
| xargs cat | wc -l
1059144
Depending on how you do the math, that's about 50,
hom wrote:
> Hi,
>
> I try to known how a database is implemented and I have been reading
> PG source codes for a month.
>
> Now, I only know a little about how PG work. :(
>
> I just know PG work like this but I don't know why PG work like this. :( :(
>
> even worse, I feel I can better u
Excerpts from Marko Kreen's message of jue mar 17 12:01:13 -0300 2011:
> On Thu, Mar 17, 2011 at 4:40 AM, Robert Haas wrote:
> > On Fri, Mar 11, 2011 at 6:02 AM, Bruce Momjian wrote:
> >> What has been done with this report/fix?
> >
> > AFAIK, nothing. Added to 9.1 open items list.
>
> The patc
On Thu, Mar 17, 2011 at 4:40 AM, Robert Haas wrote:
> On Fri, Mar 11, 2011 at 6:02 AM, Bruce Momjian wrote:
>> What has been done with this report/fix?
>
> AFAIK, nothing. Added to 9.1 open items list.
The patch seems to do the right thing.
--
marko
--
Sent via pgsql-hackers mailing list (p
Hi,
I try to known how a database is implemented and I have been reading
PG source codes for a month.
Now, I only know a little about how PG work. :(
I just know PG work like this but I don't know why PG work like this. :( :(
even worse, I feel I can better understand the source code. it m
Martijn van Oosterhout writes:
> It appears the issue is mostly that the compiler is unable to prove
> that the variables aren't changed.
IME, older versions of gcc will warn about any variable that's assigned
more than once, even if those assignments are before the setjmp call.
Presumably this i
Tom Lane wrote:
> what we should first do is see what Oracle does in such cases,
> because the main driving factor for these functions is Oracle
> compatibility not what might seem sane in a vacuum.
+1
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
Excerpts from Robert Haas's message of jue mar 17 11:09:56 -0300 2011:
> On Thu, Mar 17, 2011 at 9:46 AM, Alvaro Herrera
> wrote:
> > Keep in mind that the datetime stuff was abandoned by the maintainer
> > some years ago with quite some rough edges. Some of it has been fixed,
> > but a lot of b
Robert Haas writes:
> On Thu, Mar 17, 2011 at 9:46 AM, Alvaro Herrera
> wrote:
>> Keep in mind that the datetime stuff was abandoned by the maintainer
>> some years ago with quite some rough edges. Some of it has been fixed,
>> but a lot of bugs remain. Looks like this is one of those places an
On Thu, Mar 17, 2011 at 9:46 AM, Alvaro Herrera
wrote:
> Excerpts from Piyush Newe's message of jue mar 17 02:30:06 -0300 2011:
>> Sorry for creating the confusion. The table drawn was PostgreSQL vs EDB
>> Advanced Server.
>> Thanks Burce for clarification.
>>
>> For the 1-digit, 2-digit & 3-digit
On Thu, Mar 17, 2011 at 12:36 AM, Bruce Momjian wrote:
> Looking over the release notes, we have added a few 'volatile' storage
> specifications to variables which are near longjump/TRY blocks to
> silence compilers. I am worried that these specifications don't clearly
> identify their purpose.
On Thu, Mar 17, 2011 at 4:17 AM, Jesper Krogh wrote:
> Is it obvious that the visibillity map bits should track complete
> pages and not individual tuples? If the visibillity map tracks at
> page-level the benefit would fall on "slim tables" where you squeeze
> 200 tuples into each page and having
Excerpts from Piyush Newe's message of jue mar 17 02:30:06 -0300 2011:
> Sorry for creating the confusion. The table drawn was PostgreSQL vs EDB
> Advanced Server.
> Thanks Burce for clarification.
>
> For the 1-digit, 2-digit & 3-digit Year inputs, as I said, I didn't see any
> document in PG whi
On Thu, Mar 17, 2011 at 8:24 AM, Heikki Linnakangas
wrote:
> Hmm, so setting synchronous_standby_names to '' takes effect immediately,
> but other changes to it don't apply to already-blocked commits. That seems a
> bit inconsistent. Perhaps walwriter should store the parsed list of
> standby-name
On Thu, Mar 17, 2011 at 2:08 AM, Fujii Masao wrote:
> This occurs to me; we should ensure that, in shutdown case, walwriter
> should exit after all the backends have gone out? I'm not sure if it's worth
> thinking of the case, but what if synchronous_standby_names is unset
> and config file is rel
2011/3/17 Robert Haas :
> On Wed, Mar 16, 2011 at 6:36 PM, Jim Nasby wrote:
>> One way to look at this is that any system will have a limit on how quickly
>> it can vacuum everything. If it's having trouble dedicating enough IO to
>> vacuum, then autovac is going to have a long list of tables th
On 16.03.2011 19:35, Robert Haas wrote:
3. If synchronous_standby_names is changed to '' by editing
postgresql.conf and issuing pg_ctl reload, then cancel all waits in
progress and wake everybody up. As I mentioned before, reloading the
config file from within the waiting backend (which can't sa
Robert Haas wrote:
Right. Really-lazy vacuum could freeze tuples. Unlike regular
vacuum, it can also sensibly be done incrementally. One thing I was
thinking about is counting the number of times that we fetched a tuple
that was older than RecentGlobalXmin and had a committed xmin and an
inval
On Thu, Mar 17, 2011 at 12:36:59AM -0400, Bruce Momjian wrote:
> Looking over the release notes, we have added a few 'volatile' storage
> specifications to variables which are near longjump/TRY blocks to
> silence compilers. I am worried that these specifications don't clearly
> identify their pur
39 matches
Mail list logo
