On 6/15/2013 9:51 PM, Josh Berkus wrote:
Liming,
I've added your proposal in to the commitfest so that you can get a
review this commitfest. However, you need to generate a context diff
and submit it to this mailing list for it to really get reviewed.
That's a requirement.
Hi Josh,
Thanks. W
On Saturday, June 15, 2013 8:29 PM Sawada Masahiko wrote:
On Sat, Jun 15, 2013 at 10:34 PM, Amit kapila wrote:
>
> On Saturday, June 15, 2013 1:19 PM Sawada Masahiko wrote:
> On Fri, Jun 14, 2013 at 10:15 PM, Amit Kapila wrote:
>> On Friday, June 14, 2013 2:42 PM Samrat Revagade wrote:
>>> Hello,
Liming,
I've added your proposal in to the commitfest so that you can get a
review this commitfest. However, you need to generate a context diff
and submit it to this mailing list for it to really get reviewed.
That's a requirement.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
On Sat, Jun 15, 2013 at 8:55 PM, Tom Lane wrote:
> Daniel Farina writes:
>>> Okay, I have a patch that does something *like* (but not the same) as
>>> this, and whose implementation is totally unreasonable, but it's
>>> enough to get a sense of how the whole thing feels. Critically, it
>>> goes
Daniel Farina writes:
>> Okay, I have a patch that does something *like* (but not the same) as
>> this, and whose implementation is totally unreasonable, but it's
>> enough to get a sense of how the whole thing feels. Critically, it
>> goes beyond askpass, instead allowing a shell-command based h
On Fri, May 17, 2013 at 2:03 PM, Daniel Farina wrote:
> On Wed, Jan 9, 2013 at 5:17 AM, Peter Eisentraut wrote:
>> I would like to have something like ssh-askpass for libpq. The main
>> reason is that I don't want to have passwords in plain text on disk,
>> even if .pgpass is read protected. By
Stephen Frost writes:
> Is there really serious overhead from using latches..?
IIRC there's at least one gettimeofday() involved in WaitLatch. There
are platforms on which that already costs more than you want to spend
for, say, CommitDelay.
regards, tom lane
--
Sent
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Tom Lane wrote:
> > In general, we might want to consider replacing long sleep intervals
> > with WaitLatch operations. I thought for a bit about trying to turn
> > pg_usleep itself into a WaitLatch call; but it's also used in frontend
> > code
On Sat, Jun 15, 2013 at 8:22 AM, Hannu Krosing wrote:
>> You suddently need to solve the question of how the identifiers for
>> compression formats are allocated and preserved across pg_upgrade and
>> across machines.
> This is something similar we already need to do for any non-builtin type
> OID
Tom Lane wrote:
> In general, we might want to consider replacing long sleep intervals
> with WaitLatch operations. I thought for a bit about trying to turn
> pg_usleep itself into a WaitLatch call; but it's also used in frontend
> code where that wouldn't work, and anyway it's not clear this wou
On Sat, Jun 15, 2013 at 8:11 AM, Hannu Krosing wrote:
> Claiming that the algorithm will be one of only two (current and
> "whatever algorithm we come up with ") suggests that it is
> only one bit, which is undoubtedly too little for having a "pluggable"
> compression API :)
See
http://www.postg
Nicholas White escribió:
> For the parsing changes, it seems I can either make RESPECT and IGNORE
> reserved keywords, or add a lookahead to construct synthetic RESPECT NULLS
> and IGNORE NULLS keywords. The grammar wouldn't compile if RESPECT and
> IGNORE were just normal unreserved keywords due
On 06/15/2013 02:43 PM, David E. Wheeler wrote:
On Jun 15, 2013, at 4:12 AM, Andrew Dunstan wrote:
REGRESS_OPTS = --inputdir=test --outputdir=test \
--load-extension=$(EXTENSION)
...
override pg_regress_clean_files = test/results/
test/regression.diffs test/regression.ou
On 2013-06-15 11:36:54 -0700, Jeff Davis wrote:
> On Fri, 2013-06-14 at 18:27 +0200, Andres Freund wrote:
> > I'd like to see a comment around the memcpys in XLogSaveBufferForHint()
> > that mentions that they are safe in a non std buffer due to
> > XLogCheckBuffer setting an appropriate hole/offse
On Sun, 2013-03-24 at 20:15 -0400, Nicholas White wrote:
> I've redone the leadlag function changes to use datumCopy as you
> suggested. However, I've had to remove the NOT_USED #ifdef around
> datumFree so I can use it to avoid building up large numbers of copies
> of Datums in the memory context
On 14 June 2013 15:22, Alvaro Herrera wrote:
> Kyotaro HORIGUCHI wrote:
>> Helle,
>>
>> I've added visibility map information to pg_freespace for my
>> utility.
>
> This makes sense to me. I only lament the fact that this makes the
> module a misnomer. Do we want to 1) rename the module (how
> i
On Sat, Jun 15, 2013 at 1:40 AM, Fujii Masao wrote:
> Hi,
>
> When I ran pg_restore -l with the directory arhicve input, I found that
> its format is wrongly reported as UNKNOWN.
>
> $ pg_dump -F d -f hoge
> $ pg_restore -l hoge
> ;
> ; Archive created at Sat Jun 15 01:38:14 2013
> ; dbname: p
Hello Greg,
I've done some more testing with the "test" patch. I have not seen any
spike at the end of the throttled run.
The attached version 11 patch does ensure that throttle added sleeps are
not included in latency measures (-r) and that throttling is performed
right at the beginning of
Simon Riggs wrote:
> On 9 June 2013 14:56, Kevin Grittner wrote:
>> Simon Riggs wrote:
>>> On 8 June 2013 22:25, Kevin Grittner wrote:
Simon Riggs wrote:
>>
>>> There are also difficulties in semantics, since when
>>> we have OLD and NEW at row level we know we are discussing the same
>>>
I have read Peter Eisentraut blog entry about "Moving to C++", I full agree
with him about what he wrote.
Is there any interest or work in progress in making the entire Postgresql
code
base compilable by a C++ compiler?
Regards
Gaetano Mendola
--
cpp-today.blogspot.com
I wrote:
> ... Also, our switch to latches for sleeping purposes
> should have ameliorated the issue of signals failing to wake processes
> when we wanted them to.
> Let's turn on SA_RESTART for SIGALRM in HEAD and 9.3 and see what beta
> testing says.
I experimented with this a bit on my old HPU
On 9 June 2013 14:56, Kevin Grittner wrote:
> Simon Riggs wrote:
>> On 8 June 2013 22:25, Kevin Grittner wrote:
>>> Simon Riggs wrote:
>
>> There are also difficulties in semantics, since when
>> we have OLD and NEW at row level we know we are discussing the same
>> row. With sets of OLD and NE
On 15 June 2013 16:39, Tom Lane wrote:
> Simon Riggs writes:
>> On 15 June 2013 00:01, Josh Berkus wrote:
>>> If we're going to start adding reloptions for specific table behavior,
>>> I'd rather think of all of the optimizations we might have for a
>>> prospective "append-only table" and bundle
On Jun 15, 2013, at 4:12 AM, Andrew Dunstan wrote:
> REGRESS_OPTS = --inputdir=test --outputdir=test \
> --load-extension=$(EXTENSION)
> ...
> override pg_regress_clean_files = test/results/
> test/regression.diffs test/regression.out tmp_check/ log/
>
>
> That keeps the testin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/15/2013 11:28 AM, Alvaro Herrera wrote:
> Craig Ringer wrote:
>> On 06/13/2013 11:16 AM, Peter Eisentraut wrote:
>>> This has served no purpose except to
>>>
>>> 1. take up space 2. confuse users 3. produce broken external
>>> extension modules
On Fri, 2013-06-14 at 18:27 +0200, Andres Freund wrote:
> I'd like to see a comment around the memcpys in XLogSaveBufferForHint()
> that mentions that they are safe in a non std buffer due to
> XLogCheckBuffer setting an appropriate hole/offset. Or make an explicit
> change of the copy algorithm th
Craig Ringer wrote:
> On 06/13/2013 11:16 AM, Peter Eisentraut wrote:
> > This has served no purpose except to
> >
> > 1. take up space
> > 2. confuse users
> > 3. produce broken external extension modules that take contrib as an example
> > 4. break builds of PostgreSQL when users try to fix 3. by
FYI, the core committee is planning to wrap 9.3beta2 on Monday June 24
for release Thursday the 27th.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-ha
> fsync=off
synchronous_commits=off replaced fsync=off in almost every use case
where fsync=off might have been useful. The only remaining use case is
for the initial build of a database. In that case what the user really
wants is to turn off WAL logging entirely though. Having a WAL log and
not f
Andres Freund writes:
> On 2013-06-15 11:29:45 -0400, Tom Lane wrote:
>> Hmm. Personally I'd rather go in the other direction:
>> http://www.postgresql.org/message-id/12819.1183306...@sss.pgh.pa.us
> I am not actually objecting that reasoning, I think it would be rather
> useful to get there.
>
Liming,
I'm putting this in the commitfest regardless, so that it at least gets
a review.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/
On 2013-06-15 11:29:45 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-06-15 10:45:28 -0400, Tom Lane wrote:
> >> On reflection though, we *do* need to make them cope, because even
> >> without lazy SIGALRM disable, any such place is still at risk. We
> >> surely must allow for the pos
Simon Riggs writes:
> On 15 June 2013 00:01, Josh Berkus wrote:
>> If we're going to start adding reloptions for specific table behavior,
>> I'd rather think of all of the optimizations we might have for a
>> prospective "append-only table" and bundle those, rather than tying it
>> to whether a c
On 15 June 2013 00:07, Tom Lane wrote:
> We've talked a lot about index-organized tables in the past. How much
> of the use case for this would be subsumed by a feature like that?
IOTs would only work for one specific organisation, acting like a
multi-column btree. So you could use IOTs for thi
Andres Freund writes:
> On 2013-06-15 10:45:28 -0400, Tom Lane wrote:
>> On reflection though, we *do* need to make them cope, because even
>> without lazy SIGALRM disable, any such place is still at risk. We
>> surely must allow for the possibility of SIGHUP arriving at any instant,
>> for examp
On 15 June 2013 00:01, Josh Berkus wrote:
> Alvaro,
>
> This sounds really interesting, and I can see the possibilities.
> However ...
>
>> Value changes in columns that are part of a minmax index, and tuple insertion
>> in summarized pages, would invalidate the stored min/max values. To support
On 2013-06-15 10:45:28 -0400, Tom Lane wrote:
> I wrote:
> > Richard Poole writes:
> >> This behaviour appears in 6ac7facdd3990baf47efc124e9d7229422a06452 as a
> >> side-effect of speeding things up by getting rid of setitimer() calls;
> >> it's not obvious what's a good way to fix it without losi
Peter Eisentraut writes:
> Complete the implementations of line_in, line_out, line_recv,
> line_send. Remove comments and error messages about the line type not
> being implemented. Add regression tests for existing line operators
> and functions.
> ---
> This just revives existing functionality
On Sat, Jun 15, 2013 at 10:34 PM, Amit kapila wrote:
>
> On Saturday, June 15, 2013 1:19 PM Sawada Masahiko wrote:
> On Fri, Jun 14, 2013 at 10:15 PM, Amit Kapila wrote:
>> On Friday, June 14, 2013 2:42 PM Samrat Revagade wrote:
>>> Hello,
>>
We have already started a discussion on pgsql-hac
I wrote:
> Richard Poole writes:
>> This behaviour appears in 6ac7facdd3990baf47efc124e9d7229422a06452 as a
>> side-effect of speeding things up by getting rid of setitimer() calls;
>> it's not obvious what's a good way to fix it without losing the benefits
>> of that commit.
> Ugh. It doesn't s
On Saturday, June 15, 2013 3:50 PM Andres Freund wrote:
On 2013-06-14 21:56:52 -0400, Robert Haas wrote:
>> I don't think we need it. I think what we need is to decide is which
>> algorithm is legally OK to use. And then put it in.
>>
>> In the past, we've had a great deal of speculation about th
On Saturday, June 15, 2013 1:19 PM Sawada Masahiko wrote:
On Fri, Jun 14, 2013 at 10:15 PM, Amit Kapila wrote:
> On Friday, June 14, 2013 2:42 PM Samrat Revagade wrote:
>> Hello,
>
>>> We have already started a discussion on pgsql-hackers for the problem of
>>> taking fresh backup during the fail
On 2013-06-15 14:11:54 +0200, Hannu Krosing wrote:
> > Could you perhaps actually read the the description and the discussion
> > before making wild suggestions? Possibly even the patch.
> > Compressed toast datums now *do* have an identifier of the compression
> > algorithm used.
> > That's how w
On 06/15/2013 02:02 PM, Andres Freund wrote:
> On 2013-06-15 13:11:47 +0200, Hannu Krosing wrote:
>> If it were truly pluggable - that is just load a .dll, set a GUG and start
>> using it
> Ok. I officially rechristen the patchset to 'extensible compression
> support'.
>
>> - then the selection of
On 06/15/2013 01:56 PM, Andres Freund wrote:
> On 2013-06-15 13:25:49 +0200, Hannu Krosing wrote:
>> On 06/15/2013 02:20 AM, Andres Freund wrote:
>>> On 2013-06-14 17:12:01 -0700, Josh Berkus wrote:
On 06/14/2013 04:01 PM, Andres Freund wrote:
> It still contains a guc as described in the
On 2013-06-15 13:11:47 +0200, Hannu Krosing wrote:
> If it were truly pluggable - that is just load a .dll, set a GUG and start
> using it
Ok. I officially rechristen the patchset to 'extensible compression
support'.
> - then the selection of algorithms would be much
> wider as several slow-but-h
On 2013-06-15 13:25:49 +0200, Hannu Krosing wrote:
> On 06/15/2013 02:20 AM, Andres Freund wrote:
> > On 2013-06-14 17:12:01 -0700, Josh Berkus wrote:
> >> On 06/14/2013 04:01 PM, Andres Freund wrote:
> >>> It still contains a guc as described in the above message to control the
> >>> algorithm use
> >> I don't really like the directory layout we use for these modules
> >> anyway, so I'm not sure they constitute best practice for extension
> >> builders. Lately I have been using an extension skeleton that looks
> >>
> >> something like this:
> >> License
> >> Readme.md
> >> ME
On 06/15/2013 02:20 AM, Andres Freund wrote:
> On 2013-06-14 17:12:01 -0700, Josh Berkus wrote:
>> On 06/14/2013 04:01 PM, Andres Freund wrote:
>>> It still contains a guc as described in the above message to control the
>>> algorithm used for compressing new tuples but I think we should remove
>>>
On 06/15/2013 06:24 AM, Cédric Villemain wrote:
Andrew Dunstan a écrit :
On 06/14/2013 08:35 AM, Peter Eisentraut wrote:
On 6/13/13 9:20 PM, amul sul wrote:
Agree, only if we consider these contrib module is always gonna
deployed with the postgresql.
But, what if user going to install suc
On 06/15/2013 03:56 AM, Robert Haas wrote:
> On Fri, Jun 14, 2013 at 8:45 PM, Andres Freund wrote:
>> On 2013-06-14 17:35:02 -0700, Josh Berkus wrote:
No. I think as long as we only have pglz and one new algorithm (even if
that is lz4 instead of the current snappy) we should just always
Andrew Dunstan a écrit :
>
>On 06/14/2013 08:35 AM, Peter Eisentraut wrote:
>> On 6/13/13 9:20 PM, amul sul wrote:
>>> Agree, only if we consider these contrib module is always gonna
>deployed with the postgresql.
>>> But, what if user going to install such module elsewhere i.e. not
>from contri
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/15/2013 05:57 PM, Martijn van Oosterhout wrote:
> On Sat, Jun 15, 2013 at 12:43:10PM +0800, Craig Ringer wrote:
>> Bloat --
>>
>> Table bloat. Table bloat has been a major issue with PostgreSQL
>> users/admins for years. Anyone care to expl
On 2013-06-14 21:56:52 -0400, Robert Haas wrote:
> I don't think we need it. I think what we need is to decide is which
> algorithm is legally OK to use. And then put it in.
>
> In the past, we've had a great deal of speculation about that legal
> question from people who are not lawyers. Maybe
On Sat, Jun 15, 2013 at 12:43:10PM +0800, Craig Ringer wrote:
> Bloat
> --
>
> Table bloat. Table bloat has been a major issue with PostgreSQL
> users/admins for years. Anyone care to explain to me in a simple
> paragraph how to find out if you have table or index bloat issues in
> your databa
On 06/15/2013 03:53 PM, Joshua D. Drake wrote:
>
> Yeah this one is not making the grade. pg_hba is just that host based
> auth but I think we are bikeshedding now.
Agreed... Even as I posted, I realised I shouldn't have mentioned the
last point, since everything else has been ignored.
--
Craig
On 13 June 2013 10:35, Dean Rasheed wrote:
> Hi,
>
> Attached is a patch implementing a new aggregate function md5_agg() to
> compute the aggregate MD5 sum across a number of rows. This is
> something I've wished for a number of times. I think the primary use
> case is to do a quick check that 2 t
On 06/14/2013 11:44 PM, Brendan Jurd wrote:
If they see something called 'pg_hba.conf', they may very reasonably
assume that it is some internal/advanced stuff that they don't need to
worry about just yet, because what the heck is a 'pg_hba'? The 'pg'
Only the uneducated. Look, I am not tryi
On 06/14/2013 11:18 PM, Craig Ringer wrote:
On 06/15/2013 02:08 PM, Brendan Jurd wrote:
On 15 June 2013 14:43, Craig Ringer wrote:
The #1 question I see on Stack Overflow has to be confusion about
pg_hba.conf, mostly from people who have no idea it exists, don't understand
how to configure i
On Fri, Jun 14, 2013 at 10:15 PM, Amit Kapila wrote:
> On Friday, June 14, 2013 2:42 PM Samrat Revagade wrote:
>> Hello,
>
>> We have already started a discussion on pgsql-hackers for the problem of
> taking fresh backup during the failback operation here is the link for that:
>
>>
> http://www.po
On 2013-06-15 08:44 CEST, Brendan Jurd wrote:
On 15 June 2013 16:18, Craig Ringer ... wrote:
On 06/15/2013 02:08 PM, Brendan Jurd wrote:
On 15 June 2013 14:43, Craig Ringer ... wrote:
The #1 question I see on Stack Overflow has to be confusion about
pg_hba.conf, mostly from people who have no
61 matches
Mail list logo
