On 21.05.2013 00:00, Simon Riggs wrote:
When we set the new timeline we should be updating all values that
might be used elsewhere. If we do that, then no matter when or how we
run GetXLogReplayRecPtr, it can't ever get it wrong in any backend.
--- a/src/backend/access/transam/xlog.c
+++ b/src/b
On Mon, May 20, 2013 at 10:55:19PM -0400, Andrew Dunstan wrote:
>
> On 05/20/2013 10:38 PM, Bruce Momjian wrote:
> >-Allow DROP TABLE IF NOT EXISTS to succeed when a
> >-non-existent schema is specified in the table name (Bruce Momjian)
> >
>
> *snort*
>
> This would be a rather
On 05/20/2013 10:38 PM, Bruce Momjian wrote:
-Allow DROP TABLE IF NOT EXISTS to succeed when a
-non-existent schema is specified in the table name (Bruce Momjian)
*snort*
This would be a rather pointless command!
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql
Thanks, applied.
---
On Fri, May 17, 2013 at 03:12:21PM -0400, Joe Abbate wrote:
> Small release notes correction attached.
>
> Joe
> >From 330f5af36ffdba8930ea2da8146e8f17e1ec8a68 Mon Sep 17 00:00:00 2001
> From: Joe Abba
I have actually been working on the task discussed in this thread, most relevant
parts quoted below, for awhile now, and hope to have something concrete that you
can use by the end of this summer.
My in-development Muldis D language is homoiconic as a core feature, its source
code is data to i
Hi all,
The contrib module pageinspect has been upgraded to 1.1, but
pageinspect--1.0.sql is still present in source code. Shouldn't it be
removed? Please find patch attached.
Thanks
--
Michael
20130521_pageinspect10_removal.patch
Description: Binary data
--
Sent via pgsql-hackers mailing li
Hi,
Attached is an updated patch that does only 1 CREATE DATABASE and reuses
that for all other tests.
The code-coverage with this patch goes up from 36% to 70%.
--
Robins Tharakan
On 13 May 2013 21:04, Robins Tharakan wrote:
> I believe Tom / Andres and Fabien all have valid points.
>
> Net-
On 16.05.2013 01:08, Daniel Farina wrote:
On Mon, May 13, 2013 at 5:50 AM, Heikki Linnakangas
wrote:
pgbench -S is such a workload. With 9.3beta1, I'm seeing this profile, when
I run "pgbench -S -c64 -j64 -T60 -M prepared" on a 32-core Linux machine:
- 64.09% postgres postgres [.
On 20 May 2013 20:40, Heikki Linnakangas wrote:
> On 20.05.2013 22:18, Simon Riggs wrote:
>>
>> On 20 May 2013 18:47, Heikki Linnakangas wrote:
>>>
>>> Not sure what the best fix would be. Perhaps change the code in
>>>
>>> CreateRestartPoint() to do something like this instead:
>>>
>>> GetXLogRe
On Mon, May 20, 2013 at 11:16:41PM +0300, Heikki Linnakangas wrote:
> On 20.05.2013 23:01, Bruce Momjian wrote:
> >On Thu, May 16, 2013 at 12:08:40PM -0400, Tom Lane wrote:
> >>Stephen Frost writes:
> >>>Isn't this the same issue which has prompted multiple people to propose
> >>>(sometimes with c
On 20.05.2013 23:11, Alvaro Herrera wrote:
diff --git a/configure.in b/configure.in
index 4ea5699..ff8470e 100644
--- a/configure.in
+++ b/configure.in
@@ -1445,17 +1445,6 @@ fi
AC_CHECK_FUNCS([strtoll strtoq], [break])
AC_CHECK_FUNCS([strtoull strtouq], [break])
-AC_CACHE_CHECK([for builtin
On 20.05.2013 23:01, Bruce Momjian wrote:
On Thu, May 16, 2013 at 12:08:40PM -0400, Tom Lane wrote:
Stephen Frost writes:
Isn't this the same issue which has prompted multiple people to propose
(sometimes with code, as I recall) to rip out our internal spinlock
system and replace it with kerne
> diff --git a/configure.in b/configure.in
> index 4ea5699..ff8470e 100644
> --- a/configure.in
> +++ b/configure.in
> @@ -1445,17 +1445,6 @@ fi
> AC_CHECK_FUNCS([strtoll strtoq], [break])
> AC_CHECK_FUNCS([strtoull strtouq], [break])
>
> -AC_CACHE_CHECK([for builtin locking functions], pgac_cv
On Thu, May 16, 2013 at 12:08:40PM -0400, Tom Lane wrote:
> Stephen Frost writes:
> > Isn't this the same issue which has prompted multiple people to propose
> > (sometimes with code, as I recall) to rip out our internal spinlock
> > system and replace it with kernel-backed calls which do it bette
On 20 May 2013 20:06, Heikki Linnakangas wrote:
>> It would be possible to redesign this with a special new reason, or we
>> could just use "time" as the reason, or we could just leave it.
>>
>> Do nothing is easy, though so are the others, so we can choose
>> anything we want. What do we want it
On 17.05.2013 12:35, Andres Freund wrote:
On 2013-05-17 10:45:26 +0300, Heikki Linnakangas wrote:
On 16.05.2013 04:15, Andres Freund wrote:
Couldn't we "just" take the extension lock and then walk backwards from
the rechecked end of relation ConditionalLockBufferForCleanup() the
buffers?
For ev
On 20.05.2013 22:18, Simon Riggs wrote:
On 20 May 2013 18:47, Heikki Linnakangas wrote:
Not sure what the best fix would be. Perhaps change the code in
CreateRestartPoint() to do something like this instead:
GetXLogReplayRecPtr(&replayTLI);
if (RecoveryInProgress())
ThisTimeLineID = replayT
Daniel Wood wrote:
> As part of 0ac5ad5134f2769ccbaefec73844f8504c4d6182
> the permutations in test/isolation/fk-deadlock2.spec and elsewhere
> were removed. Is it the intent that these tests no longer do
> anything useful? I was expecting a failure in the test with some
> work I'm doing and was
On Sat, May 11, 2013 at 07:22:55PM -0400, Robert Haas wrote:
> On Sat, May 11, 2013 at 12:27 PM, Tom Lane wrote:
> > By the time you've got an expression tree, the problem is mostly solved,
> > at least so far as parser extension is concerned.
>
> Right.
>
> > More years ago than I care to admit
As part of 0ac5ad5134f2769ccbaefec73844f8504c4d6182
the permutations in test/isolation/fk-deadlock2.spec and elsewhere were
removed. Is it the intent that these tests no longer do anything
useful? I was expecting a failure in the test with some work I'm doing
and was confused, after a merge f
On 20 May 2013 18:47, Heikki Linnakangas wrote:
> On 19.05.2013 17:25, Simon Riggs wrote:
>> So while I believe that the checkpointer might have an incorrect TLI
>> and that you've seen a bug, what isn't clear is that the checkpointer
>> is the only process that would see an incorrect TLI, or why
On 19.05.2013 17:22, Simon Riggs wrote:
On 1 May 2013 10:05, Fujii Masao wrote:
In HEAD, when the standby is promoted, recovery requests the checkpoint
but doesn't wait for its completion. I found the checkpoint starting log message
of this checkpoint looks odd as follows:
LOG: checkpoi
I think it would be good to do it in pgbench, provided it can be done
fairly cleanly.
Presumably we would want to repeat all of the ordinary commands, in the
file, but not any of the backslash set commands that precede any ordinary
commands. But what if backslash set commands are sprinkled bet
On 19.05.2013 17:25, Simon Riggs wrote:
However, there is a call to RecoveryInProgress() at the top of the
main loop of the checkpointer, which does explicitly state that it
"initializes TimeLineID if it's not set yet." The checkpointer makes
the decision about whether to run a restartpoint or a
On 17.05.2013 19:03, Boszormenyi Zoltan wrote:
2013-05-17 16:05 keltezéssel, Heikki Linnakangas írta:
On 18.02.2013 16:35, Boszormenyi Zoltan wrote:
2013-01-29 11:15 keltezéssel, Magnus Hagander írta:
On Thu, Jan 24, 2013 at 7:04 AM, Hari Babu
wrote:
On Wed, Jan 23, 2013 11:48 PM, Magnus Hag
On Mon, May 20, 2013 at 4:50 AM, Kevin Grittner wrote:
> I raised this issue near the end of SSI development, but nobody
> seemed very interested and someone argued that a tool to do that
> would be good but we shouldn't try to do it in pgbench -- so I let
> it drop at the time.
>
I think it wo
On 20.05.2013 14:50, Kevin Grittner wrote:
I raised this issue near the end of SSI development, but nobody
seemed very interested and someone argued that a tool to do that
would be good but we shouldn't try to do it in pgbench -- so I let
it drop at the time.
+1 on doing it in pgbench.
- Heikk
Hello PostgreSQL Hackers,
I am now in Ottawa, last week we wrapped up the BSDCon and I was hoping
to chat with a few Postgresql developers in person about using
Postgresql in FreeNAS and offering it as an extension to the platform as
a plug-in technology. Unfortunately due to time constraints
On Mon, May 20, 2013 at 8:54 PM, Alvaro Herrera
wrote:
> Hello,
>
> Would you guys please trim the quoted text of the emails you're replying
> to? I understand Gmail is obnoxious w.r.t. quoted text, but this is
> starting to become excessive.
Oops, I didnt notice that. Sorry!
Regards,
Atri
-
Hello,
Would you guys please trim the quoted text of the emails you're replying
to? I understand Gmail is obnoxious w.r.t. quoted text, but this is
starting to become excessive.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Service
On 13.05.2013 17:21, Merlin Moncure wrote:
On Mon, May 13, 2013 at 7:50 AM, Heikki Linnakangas
wrote:
The attached patch is still work-in-progress. There needs to be a configure
test and fallback to spinlock if a CAS instruction is not available. I used
the gcc __sync_val_compare_and_swap() bu
On 20.05.2013 16:59, Robert Haas wrote:
On Fri, May 17, 2013 at 3:38 AM, Heikki Linnakangas
wrote:
If we could use the catchup interrupts to speed that up though, that would
be much better. I think vacuum could simply send a catchup interrupt, and
wait until everyone has caught up. That would
On Fri, May 17, 2013 at 3:38 AM, Heikki Linnakangas
wrote:
> If we could use the catchup interrupts to speed that up though, that would
> be much better. I think vacuum could simply send a catchup interrupt, and
> wait until everyone has caught up. That would significantly increase the
> traffic o
On Thu, May 16, 2013 at 10:18 AM, Amit Kapila wrote:
> Further Performance Data:
>
> Below data is for average 3 runs of 20 minutes
>
> Scale Factor - 1200
> Shared Buffers - 7G
These results are good but I don't get similar results in my own
testing. I ran pgbench tests at a variety of client
Sent from my iPad
On 20-May-2013, at 18:14, Amit Langote wrote:
> Wonder though if this question is better asked in pgsql-novice?
>
> On Mon, May 20, 2013 at 9:23 PM, Amit Langote wrote:
>> Hello,
>>
>> I think a more appropriate question to be asked here would be at what
>> point (in the l
Em Seg, 2013-05-20 às 14:35 +0200, Andres Freund escreveu:
> On 2013-05-20 09:31:15 -0300, Dickson S. Guedes wrote:
> > Hum, I was supposing that I was doing something wrong but I'm getting
> > the same result as before even using your test case and my results is
> > still different from yours:
> >
Wonder though if this question is better asked in pgsql-novice?
On Mon, May 20, 2013 at 9:23 PM, Amit Langote wrote:
> Hello,
>
> I think a more appropriate question to be asked here would be at what
> point (in the life of a typical tuple), does a tuple's header contain
> t_datum or otherwise,
On 2013-05-20 09:31:15 -0300, Dickson S. Guedes wrote:
> Hum, I was supposing that I was doing something wrong but I'm getting
> the same result as before even using your test case and my results is
> still different from yours:
>
>
> + 71,27% postgres postgres [.] AtEOXact_Buffers
> + 7
Em Dom, 2013-05-19 às 09:29 +0300, Heikki Linnakangas escreveu:
> On 18.05.2013 03:52, Dickson S. Guedes wrote:
> >> pgbench -S is such a workload. With 9.3beta1, I'm seeing this
> >> profile, when I run "pgbench -S -c64 -j64 -T60 -M prepared" on a
> >> 32-core Linux machine:
> >>
> >> - 64.09% p
Hello,
I think a more appropriate question to be asked here would be at what
point (in the life of a typical tuple), does a tuple's header contain
t_datum or otherwise, which I would also like to be answered.
On Mon, May 20, 2013 at 6:06 PM, Soroosh Sardari
wrote:
> Thanks,
>
> If a tuple const
On 05/20/2013 09:54 AM, Chris Farmiloe wrote:
> Hey all,
>
> I find the current LISTEN / NOTIFY rather limited in the context of
> databases with multiple roles. As it stands it is not possible to restrict
> the use of LISTEN or NOTIFY to specific roles, and therefore notifications
> (and their pay
On 19.05.2013 11:15, Greg Smith wrote:
I've thought of two paths to get a block write count out of that so far:
-Provide a function to find the Relation from the RelFileNode. There is
a warning about the perils of assuming you can map that way from a
buftag value in buf_internals.h though:
"Not
Josh Berkus wrote:
> I recently had a reason to benchmark a database which is default
> SERIALIZABLE mode. I was startled to discover that pgbench is set up to
> abort the client once it hits a serialization failure. You get a bunch
> of these:
>
> Client 7 aborted in state 11: ERROR: could no
Thanks,
If a tuple constructed in memory we don't need t_heap. I have another
question,
How make an in-memory tuple?
On Mon, May 20, 2013 at 12:46 PM, Amit Langote wrote:
> Hello,
>
> I think the comment just above the HeapTupleFields struct definition
> has the related details.
>
> /*
> * H
Hello,
I think the comment just above the HeapTupleFields struct definition
has the related details.
/*
* Heap tuple header. To avoid wasting space, the fields should be
* laid out in such a way as to avoid structure padding.
*
* Datums of composite types (row types) share the same general s
On 16 May 2013 22:16, Tom Lane wrote:
>> Specifically, for foreign tables
>> information_schema.tables.is_insertable_into and
>> information_schema.columns.is_updatable always say 'NO' even if the
>> foreign table is writable. Fixing that would require new C functions
>> along the same lines as pg
Dear Hackers
In fix part oh HeapTuple, there is a union that is named t_choice,
union
{
HeapTupleFields t_heap;
DatumTupleFields t_datum;
}t_choice;
I can't find out why we need t_datum, actually there is no comment about
DatumTupleFields.
Regards
Soroosh
>> in a way, we client terminal wont hangup by throwing *The connection to
> the server was lost. Attempting reset: Failed. !*
> The thing is that this just should not be a routine occurrence. It's a
> minor irritation to me when debugging sometimes, but it's not something
> that you should b
48 matches
Mail list logo
