2011/3/24 Robert Haas :
> On Wed, Mar 23, 2011 at 4:50 PM, Pavel Stehule
> wrote:
>> 2011/3/23 Alvaro Herrera :
>>> Excerpts from Robert Haas's message of mié mar 23 17:24:59 -0300 2011:
On Mon, Mar 21, 2011 at 1:44 PM, Bernd Helmle wrote:
> It stroke me today again, that \dt+ isn't di
Any inputs further ?
On Tue, Mar 22, 2011 at 2:37 PM, Piyush Newe
wrote:
> Thanks Heikki, Tom & Robert for your valuable inputs.
>
> According to the code, PG is behaving what is mentioned below.
>
> 1. Format = Y
> 0 ... 9 = 2000 ... 2009 (we are always adding 2000 to the year)
>
> 2. Format =
On Thu, Mar 24, 2011 at 11:33 PM, Jeff Janes wrote:
> I tried under the circumstances I thought were mostly likely to show a
> time difference, and I was unable to detect a reliable difference in
> timing between free list and clock sweep.
It strikes me that it shouldn't be terribly hard to add a
Hello List,
I have a couple of use cases that are important to me, but my reading
of xlog.c suggests I'm stuck between a rock and a hard place. Or, I am
missing some commonly used pattern -- forgive me in that case. I am
reading 9.0.3 when making these determinations.
Here is the mechanism: I w
On Thu, Mar 24, 2011 at 12:36 PM, Jim Nasby wrote:
> On Mar 23, 2011, at 5:12 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> It looks like the only way anything can ever get put on the free list
>>> right now is if a relation or database is dropped. That doesn't seem
>>> too good.
>>
>> Why not?
On Wed, Mar 23, 2011 at 5:13 PM, Kohei KaiGai wrote:
> I found a problem that extension.c does not invoke post-creation hook
> on its creation time, although no module supports to assign security
> label on extension objects right now.
>
> The attached patch tries to fix it.
Thanks, committed.
-
* Heikki Linnakangas (heikki.linnakan...@enterprisedb.com) wrote:
> The problem is that you still need to track which queries within the
> transaction can see the tuples. For example:
Alright, one final thought on this for a while..
We can check if the table was created in the current transaction
On Wed, Mar 23, 2011 at 6:16 AM, Jesper Krogh wrote:
> On 2011-03-22 21:43, Robert Haas wrote:
>>
>> I took a crack at implementing the first approach described above,
>> which seems to be by far the simplest idea we've come up with to date.
>> Patch attached. It doesn't seem to be that complica
Robert Haas Thursday 24 March 2011 22:41:19
> On Thu, Mar 24, 2011 at 5:34 PM, Greg Stark wrote:
> > On Thu, Mar 24, 2011 at 8:59 PM, Robert Haas
wrote:
> >> It seems at least plausible that buffer allocation could be
> >> significantly faster if it need only pop the head of a list, rather
> >>
* Greg Stark (gsst...@mit.edu) wrote:
> Fwiw this was the original plan with Simon's patch in the 8.3 era to
> skip wal logging tables being loaded in the same transaction they were
> created. (Ironically often made futile by his own HS work.)
Hah, knew I couldn't have been the first, my subconcio
* Heikki Linnakangas (heikki.linnakan...@enterprisedb.com) wrote:
> The problem is that you still need to track which queries within the
> transaction can see the tuples. For example:
Wow, that's a good point wrt cursors. Sounds more and more like we'd
need a special data-loading mode for this wh
* Robert Haas (robertmh...@gmail.com) wrote:
> Also, you're not really going to get the whole benefit unless you can
> somehow manage to mark the pages PD_ALL_VISIBLE and set the visibility
> map bits. Without that, the next vacuum is going to dirty the whole
> heap anyway. Granted that's a bit b
* Greg Stark (gsst...@mit.edu) wrote:
> I'm not sure this solves the cases of subtransactions -- but perhaps
> we just wouldn't store frozenxid if we're in a subtransaction. And I'm
> not sure we have access to the relation id when we're doing visibility
> checks. I think we do. This would involve
A few days ago I was complaining that we needed to adjust the SPI and
parser APIs so that callers could pass in collation values for Param
symbols. After some review of the code, I think we can get away without
that. Instead, let's just legislate that you have to use a parser
callback hook if you
On Wed, Mar 23, 2011 at 4:50 PM, Pavel Stehule wrote:
> 2011/3/23 Alvaro Herrera :
>> Excerpts from Robert Haas's message of mié mar 23 17:24:59 -0300 2011:
>>> On Mon, Mar 21, 2011 at 1:44 PM, Bernd Helmle wrote:
>>> > It stroke me today again, that \dt+ isn't displaying the acurate table
>>> >
On Thu, Mar 24, 2011 at 7:02 AM, Fujii Masao wrote:
> On Thu, Mar 24, 2011 at 12:19 AM, Robert Haas wrote:
>> On Wed, Mar 23, 2011 at 9:38 AM, Simon Riggs wrote:
Actually, my previous email was all nonsense, wasn't it? If we don't
reach the consistency point, we can't enter normal run
On Thu, Mar 24, 2011 at 9:39 PM, Greg Stark wrote:
>
> We could conceivably deal with that by not setting the frozenxid but
> setting the hint bit for those tuples and having a documented special
> case that if the hint bit is set but it's the same xid as your own you
> have to treat it as not-com
On Thu, Mar 24, 2011 at 5:39 PM, Greg Stark wrote:
> On Thu, Mar 24, 2011 at 9:15 PM, Heikki Linnakangas
> wrote:
>> On 24.03.2011 23:08, Stephen Frost wrote:
>>>
>>> In a discussion which came up at PgEast, I questioned if it'd be
>>> possible to set the 'all visible' hint bit and give the t
On Thu, Mar 24, 2011 at 5:34 PM, Greg Stark wrote:
> On Thu, Mar 24, 2011 at 8:59 PM, Robert Haas wrote:
>> It seems at least plausible that buffer allocation could be
>> significantly faster if it need only pop the head of a list, rather
>> than scanning until it finds a suitable candidate. Mov
On Thu, Mar 24, 2011 at 9:15 PM, Heikki Linnakangas
wrote:
> On 24.03.2011 23:08, Stephen Frost wrote:
>>
>> In a discussion which came up at PgEast, I questioned if it'd be
>> possible to set the 'all visible' hint bit and give the tuples the
>> frozen XID when loading data into a table whi
On Thu, Mar 24, 2011 at 8:59 PM, Robert Haas wrote:
> It seems at least plausible that buffer allocation could be
> significantly faster if it need only pop the head of a list, rather
> than scanning until it finds a suitable candidate. Moving as much
> buffer allocation work as possible into the
On Thu, Mar 24, 2011 at 12:56 AM, Gokulakannan Somasundaram
wrote:
> Yeah. i looked at it. I don't think it addresses the problem raised here.
> http://archives.postgresql.org/pgsql-hackers/2010-02/msg02097.php
> Or may be i am missing something.
Yeah, I think you're right.
--
Robert Haas
Enter
On 24.03.2011 23:08, Stephen Frost wrote:
In a discussion which came up at PgEast, I questioned if it'd be
possible to set the 'all visible' hint bit and give the tuples the
frozen XID when loading data into a table which was created in the
same transaction.
The idea being that no
On Thu, Mar 24, 2011 at 4:05 PM, Peter Eisentraut wrote:
> On tor, 2011-02-10 at 12:58 +0200, Peter Eisentraut wrote:
>> There is make check target in doc/src/sgml/ that is supposed to catch
>> this. But it's probably hard to remember to run that.
>>
>> One thing I was thinking of was that we cou
On Thu, Mar 24, 2011 at 2:28 PM, Simon Riggs wrote:
> The protocol supports sending two values, so two are displayed.
>
> If you wish to remove one from the display then that only makes sense
> if you also prevent the protocol from supporting two values.
>
> There is no benefit in doing that, so w
Greetings,
In a discussion which came up at PgEast, I questioned if it'd be
possible to set the 'all visible' hint bit and give the tuples the
frozen XID when loading data into a table which was created in the
same transaction.
The idea being that no other transactions could see the tab
On Wed, Mar 23, 2011 at 6:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> It looks like the only way anything can ever get put on the free list
>> right now is if a relation or database is dropped. That doesn't seem
>> too good.
>
> Why not? AIUI the free list is only for buffers that are total
Jim Nasby Thursday 24 March 2011 20:36:48
> On Mar 23, 2011, at 5:12 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> It looks like the only way anything can ever get put on the free list
> >> right now is if a relation or database is dropped. That doesn't seem
> >> too good.
> >
> > Why not?
On tor, 2011-02-10 at 12:58 +0200, Peter Eisentraut wrote:
> There is make check target in doc/src/sgml/ that is supposed to catch
> this. But it's probably hard to remember to run that.
>
> One thing I was thinking of was that we could add a global make
> maintainer-check target (a name I picked
On Mar 23, 2011, at 5:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> It looks like the only way anything can ever get put on the free list
>> right now is if a relation or database is dropped. That doesn't seem
>> too good.
>
> Why not? AIUI the free list is only for buffers that are totally d
On Thu, Mar 24, 2011 at 11:07 AM, Ross J. Reedstrom wrote:
> On Fri, Mar 18, 2011 at 11:00:19PM -0400, Tom Lane wrote:
>> Robert Haas writes:
>> > On Fri, Mar 18, 2011 at 10:19 PM, Andrew Dunstan
>> > wrote:
>> >> On 03/18/2011 09:18 PM, Robert Haas wrote:
>> >>> "all balls" seems like a colloq
On 24.03.2011 19:53, aaronenabs wrote:
I am relatively new to postgresql, have downloaded it and done some
exercises on how to use postgresql and can say i have picked up on it very
quicky. At the minute i have downloaded the sourcecode for version9.0.3 and
trying to compile it on my computer(win
Hi All
I am relatively new to postgresql, have downloaded it and done some
exercises on how to use postgresql and can say i have picked up on it very
quicky. At the minute i have downloaded the sourcecode for version9.0.3 and
trying to compile it on my computer(win xp) but cannot find any document
On Mar 22, 2011, at 11:46 AM, Cédric Villemain wrote:
> 2011/3/22 Greg Stark :
>> On Mon, Mar 21, 2011 at 6:08 PM, Jim Nasby wrote:
>>> Has anyone looked at the overhead of measuring how long IO requests to the
>>> kernel take? If we did that not only could we get an idea of what our IO
>>> work
On Fri, Mar 18, 2011 at 11:00:19PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Fri, Mar 18, 2011 at 10:19 PM, Andrew Dunstan
> > wrote:
> >> On 03/18/2011 09:18 PM, Robert Haas wrote:
> >>> "all balls" seems like a colloquialism best avoided in our documentation.
>
> >> It's already the
On 3/24/11 8:16 AM, Kevin Grittner wrote:
> Simon Riggs wrote:
>> Robert Haas wrote:
>
>>> At least as I understand it, it's not our project policy to carry
>>> around code that doesn't accomplish anything useful. I have no
>>> objection to keeping the field; I simply think that if we're
>>> go
"Kevin Grittner" writes:
> +1 for either dropping it or making it work.
That's my feeling also. There is *no* reason that we can't add a column
to the status view later, and every probability that we will find
reasons other than this to do so. So if the column isn't going to
provide useful info
On Sun, Mar 20, 2011 at 5:31 AM, Robert Haas wrote:
> On Sat, Mar 19, 2011 at 11:34 AM, Grzegorz Jaskiewicz
> wrote:
>>
>> On 18 Mar 2011, at 21:12, Robert Haas wrote:
>>
>>> While investigating Simon's complaint about my patch of a few days
>>> ago, I discovered that synchronous replication appe
On Wed, Mar 23, 2011 at 7:33 PM, Heikki Linnakangas
wrote:
> I don't much like the API for this. Walsender shouldn't need to know about
> the details of the FE/BE protocol, pq_putbytes_if_available() seems too low
> level to be useful.
>
> I think a better API would be to have a non-blocking versi
Simon Riggs wrote:
> Robert Haas wrote:
>> At least as I understand it, it's not our project policy to carry
>> around code that doesn't accomplish anything useful. I have no
>> objection to keeping the field; I simply think that if we're
>> going to have it, we should make it work
> What a s
On Thu, Mar 24, 2011 at 8:34 PM, Simon Riggs wrote:
> On Thu, Mar 24, 2011 at 11:17 AM, Fujii Masao wrote:
>> On Wed, Mar 23, 2011 at 5:53 PM, Fujii Masao wrote:
> Do you still want to work up a patch for this? If so, I can review.
>>>
>>> Sure. Will do.
>>
>> The attached patch allows stan
On Thu, Mar 24, 2011 at 11:17 AM, Fujii Masao wrote:
> On Wed, Mar 23, 2011 at 5:53 PM, Fujii Masao wrote:
Do you still want to work up a patch for this? If so, I can review.
>>
>> Sure. Will do.
>
> The attached patch allows standby servers to connect during smart shutdown
> in order to wa
On Wed, Mar 23, 2011 at 5:53 PM, Fujii Masao wrote:
>>> Do you still want to work up a patch for this? If so, I can review.
>
> Sure. Will do.
The attached patch allows standby servers to connect during smart shutdown
in order to wake up backends waiting for sync rep.
Regards,
--
Fujii Masao
On Thu, Mar 24, 2011 at 12:19 AM, Robert Haas wrote:
> On Wed, Mar 23, 2011 at 9:38 AM, Simon Riggs wrote:
>>> Actually, my previous email was all nonsense, wasn't it? If we don't
>>> reach the consistency point, we can't enter normal running anyway -
>>> shut down is the only option no matter w
44 matches
Mail list logo
