On 15 June 2013 14:43, Craig Ringer cr...@2ndquadrant.com 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 it, etc.
The totally non-obvious name of the file probably has
On 06/15/2013 02:08 PM, Brendan Jurd wrote:
On 15 June 2013 14:43, Craig Ringer cr...@2ndquadrant.com 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 it, etc.
The totally
On 15 June 2013 16:18, Craig Ringer cr...@2ndquadrant.com wrote:
On 06/15/2013 02:08 PM, Brendan Jurd wrote:
On 15 June 2013 14:43, Craig Ringer cr...@2ndquadrant.com 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
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
On Fri, Jun 14, 2013 at 10:15 PM, Amit Kapila amit.kap...@huawei.com 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:
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 cr...@2ndquadrant.com 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
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
On 13 June 2013 10:35, Dean Rasheed dean.a.rash...@gmail.com 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
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 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 database and
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 it
-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 explain to
Andrew Dunstan and...@dunslane.net 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
On 06/15/2013 03:56 AM, Robert Haas wrote:
On Fri, Jun 14, 2013 at 8:45 PM, Andres Freund and...@2ndquadrant.com 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
On 06/15/2013 06:24 AM, Cédric Villemain wrote:
Andrew Dunstan and...@dunslane.net 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
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
that guc
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
META.json (for pgxn)
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 used for
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
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 above message
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 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 we can
On Saturday, June 15, 2013 1:19 PM Sawada Masahiko wrote:
On Fri, Jun 14, 2013 at 10:15 PM, Amit Kapila amit.kap...@huawei.com 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
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 that
I wrote:
Richard Poole rich...@2ndquadrant.com 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.
On Sat, Jun 15, 2013 at 10:34 PM, Amit kapila amit.kap...@huawei.com wrote:
On Saturday, June 15, 2013 1:19 PM Sawada Masahiko wrote:
On Fri, Jun 14, 2013 at 10:15 PM, Amit Kapila amit.kap...@huawei.com wrote:
On Friday, June 14, 2013 2:42 PM Samrat Revagade wrote:
Hello,
We have already
Peter Eisentraut pete...@gmx.net 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
On 2013-06-15 10:45:28 -0400, Tom Lane wrote:
I wrote:
Richard Poole rich...@2ndquadrant.com 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
On 15 June 2013 00:01, Josh Berkus j...@agliodbs.com 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
Andres Freund and...@2ndquadrant.com 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
On 15 June 2013 00:07, Tom Lane t...@sss.pgh.pa.us 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
Simon Riggs si...@2ndquadrant.com writes:
On 15 June 2013 00:01, Josh Berkus j...@agliodbs.com 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
On 2013-06-15 11:29:45 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
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:
Andres Freund and...@2ndquadrant.com 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
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
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:
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 exporting
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
-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 that take
On 15 June 2013 16:39, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On 15 June 2013 00:01, Josh Berkus j...@agliodbs.com 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
On Jun 15, 2013, at 4:12 AM, Andrew Dunstan and...@dunslane.net 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
On 9 June 2013 14:56, Kevin Grittner kgri...@ymail.com wrote:
Simon Riggs si...@2ndquadrant.com wrote:
On 8 June 2013 22:25, Kevin Grittner kgri...@ymail.com wrote:
Simon Riggs si...@2ndquadrant.com wrote:
There are also difficulties in semantics, since when
we have OLD and NEW at row level
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 HPUX
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
Simon Riggs si...@2ndquadrant.com wrote:
On 9 June 2013 14:56, Kevin Grittner kgri...@ymail.com wrote:
Simon Riggs si...@2ndquadrant.com wrote:
On 8 June 2013 22:25, Kevin Grittner kgri...@ymail.com wrote:
Simon Riggs si...@2ndquadrant.com wrote:
There are also difficulties in semantics,
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
On Sat, Jun 15, 2013 at 1:40 AM, Fujii Masao masao.fu...@gmail.com 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
;
On 14 June 2013 15:22, Alvaro Herrera alvhe...@2ndquadrant.com 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
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 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/offset. Or
On 06/15/2013 02:43 PM, David E. Wheeler wrote:
On Jun 15, 2013, at 4:12 AM, Andrew Dunstan and...@dunslane.net wrote:
REGRESS_OPTS = --inputdir=test --outputdir=test \
--load-extension=$(EXTENSION)
...
override pg_regress_clean_files = test/results/
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 to
On Sat, Jun 15, 2013 at 8:11 AM, Hannu Krosing ha...@2ndquadrant.com 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
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 would
On Sat, Jun 15, 2013 at 8:22 AM, Hannu Krosing ha...@2ndquadrant.com 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
* 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 where
Stephen Frost sfr...@snowman.net 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,
On Fri, May 17, 2013 at 2:03 PM, Daniel Farina dan...@heroku.com wrote:
On Wed, Jan 9, 2013 at 5:17 AM, Peter Eisentraut pete...@gmx.net 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
Daniel Farina dan...@heroku.com 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
On Sat, Jun 15, 2013 at 8:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniel Farina dan...@heroku.com 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.
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 Saturday, June 15, 2013 8:29 PM Sawada Masahiko wrote:
On Sat, Jun 15, 2013 at 10:34 PM, Amit kapila amit.kap...@huawei.com wrote:
On Saturday, June 15, 2013 1:19 PM Sawada Masahiko wrote:
On Fri, Jun 14, 2013 at 10:15 PM, Amit Kapila amit.kap...@huawei.com wrote:
On Friday, June 14, 2013
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.
64 matches
Mail list logo
