On 06/12/2013 02:52 PM, Peter Geoghegan wrote:
> On Tue, Jun 11, 2013 at 11:42 PM, Craig Ringer wrote:
>> Anyway, point being that PostgreSQL from Macports, Homebrew, and/or
>> EnterpriseDB's installer might be present ... and even in use.
> Perhaps you should direct those users towards http://pos
On 2013-06-07 19:09, Fred&Dani&Pandora&Aquiles wrote:
I asked a while ago in this group about the possibility to implement a
parallel planner in a multithread way, and the replies were that the
proposed approach couldn't be implemented, because the postgres is not
thread-safe. With the new fea
On 12 June 2013 00:56, Craig Ringer wrote:
> The main thing I'm wondering is how/if to handle backward compatibility
> with the existing NUMERIC and its DECIMAL alias, or whether adding new
> DECIMAL32, DECIMAL64, and DECIMAL128 types would be more appropriate. I'd
> love to just use the SQL stan
Did you look at the giant latency spikes at the end of the test run I
submitted the graph for? I wanted to nail down what was causing those
before worrying about the startup timing.
If you are still worried: if you run the very same command without
throttling and measure the same latency, d
On 12 June 2013 16:12, Craig Ringer wrote:
> Yes, they do - including a horde of deeply confused and frustrated Rails
> users struggling to understand why they're getting "no such file or
> directory" or "permission denied" messages about Pg's unix socket,
> because of course they're linked to Ap
On 12 June 2013 16:30, Craig Ringer wrote:
> None of this is hard if you have clue what you're doing. Rebuild the Pg
> gem against the right libpq by fixing your PATH so it finds the right
> pg_config, set host=/tmp, or set host=localhost. Any of the three will
> work. Unfortunately most of thes
On Wed, Jun 12, 2013 at 7:24 AM, Tom Dunstan wrote:
>
> Another alternative is for the Postgres.app to add its bin dir to the user's
> (or system's) path on first startup. Then the correct pg_config will be
> found (and the correct psql, pgdump etc etc as well). The app could in
> theory even go l
On 12 June 2013 04:50, David E. Wheeler wrote:
> On Jun 11, 2013, at 3:09 PM, Brendan Jurd wrote:
>
>> There have been attempts to add a cardinality function in the past, as
>> it is required by the SQL spec, but these attempts have stalled when
>> trying to decide how it should handle multidim a
On 12 June 2013 17:30, Dave Page wrote:
> Messing with the path (or the dynamic load path) can cause all sorts
> of fun and interesting problems for users, as we found in the early
> days with the EDB installers. I realise it doesn't help these users
> (who doubtless don't know it exists) but wha
On 12 June 2013 18:22, Dean Rasheed wrote:
> +1 for having a function to return the total number of elements in an
> array, because that's something that's currently missing from SQL.
>
> However, I think that CARDINALITY() should be that function.
>
> I'm not convinced that having CARDINALITY() r
On Wed, Jun 12, 2013 at 12:56 AM, Craig Ringer wrote:
> The main thing I'm wondering is how/if to handle backward compatibility with
> the existing NUMERIC and its DECIMAL alias
If it were 100% functionally equivalent you could just hide the
implementation internally. Have a bit that indicates wh
On 06/12/2013 12:13 AM, Craig Ringer wrote:
On 06/12/2013 08:42 AM, Andrew Dunstan wrote:
If we work by analogy to Postgres' own handling of Unicode escapes,
we'll raise an error on any Unicode escape beyond ASCII (not on input
for legacy reasons, but on trying to process such datums). I gather
On Wed, Jun 12, 2013 at 6:41 AM, Amit Kapila wrote:
> On Wednesday, June 12, 2013 4:23 AM Fujii Masao wrote:
>> Hi,
>>
>> In streaming replication, when we shutdown the master, walsender tries
>> to send all the outstanding WAL records including the shutdown
>> checkpoint record to the standby, an
Hi,
On 2013-06-12 07:53:29 +0900, Fujii Masao wrote:
> The attached patch fixes this problem. It just changes walsender so that it
> waits for all the outstanding WAL records to be replicated to the standby
> before closing the replication connection.
Imo this is a fix that needs to get backpatch
On 06/12/2013 05:55 PM, Greg Stark wrote:
> On Wed, Jun 12, 2013 at 12:56 AM, Craig Ringer wrote:
>> The main thing I'm wondering is how/if to handle backward compatibility with
>> the existing NUMERIC and its DECIMAL alias
> If it were 100% functionally equivalent you could just hide the
> implem
On Wed, Jun 12, 2013 at 1:48 PM, Andres Freund wrote:
> Hi,
>
> On 2013-06-12 07:53:29 +0900, Fujii Masao wrote:
>> The attached patch fixes this problem. It just changes walsender so that it
>> waits for all the outstanding WAL records to be replicated to the standby
>> before closing the replica
On 2013-06-12 19:47:46 +0800, Craig Ringer wrote:
> On 06/12/2013 05:55 PM, Greg Stark wrote:
> > On Wed, Jun 12, 2013 at 12:56 AM, Craig Ringer
> > wrote:
> >> The main thing I'm wondering is how/if to handle backward compatibility
> >> with
> >> the existing NUMERIC and its DECIMAL alias
> > I
* Magnus Hagander (mag...@hagander.net) wrote:
> On Wed, Jun 12, 2013 at 1:48 PM, Andres Freund wrote:
> > On 2013-06-12 07:53:29 +0900, Fujii Masao wrote:
> >> The attached patch fixes this problem. It just changes walsender so that it
> >> waits for all the outstanding WAL records to be replicat
On 2013-06-12 08:48:39 -0400, Stephen Frost wrote:
> * Magnus Hagander (mag...@hagander.net) wrote:
> > On Wed, Jun 12, 2013 at 1:48 PM, Andres Freund
> > wrote:
> > > On 2013-06-12 07:53:29 +0900, Fujii Masao wrote:
> > >> The attached patch fixes this problem. It just changes walsender so that
On Mon, Jun 10, 2013 at 3:48 PM, Simon Riggs wrote:
> On 10 June 2013 11:51, KONDO Mitsumasa wrote:
>> I create patch which is improvement of checkpoint IO scheduler for stable
>> transaction responses.
>
> Looks like good results, with good measurements. Should be an
> interesting discussion.
+
On Jun 12, 2013 2:02 AM, "Tatsuo Ishii" wrote:
> No, I'm not talking about conflict resolution.
>
> From http://www.cs.cmu.edu/~natassa/courses/15-823/F02/papers/replication.pdf:
> --
> Eager or Lazy Replication?
> Eager replication:
> keep all replica
On 12 June 2013 01:35, Tom Lane wrote:
> On the whole, I think the effort would be a lot more usefully spent on
> trying to make the existing NUMERIC support go faster.
Did you have a specific idea in mind? Or an area of investigation?
--
Simon Riggs http://www.2ndQuadrant.co
On Sat, Jun 8, 2013 at 10:36 AM, MauMau wrote:
> Yes, I feel designing reliable archiving, even for the simplest case - copy
> WAL to disk, is very difficult. I know there are following three problems
> if you just follow the PostgreSQL manual. Average users won't notice them.
> I guess even pro
Craig Ringer writes:
> On 06/12/2013 02:24 PM, Tom Dunstan wrote:
>> Oh, interesting. Do the ruby/rails folks use that rather than a pure-ruby
>> driver? I guess I'm spoiled - most of my development happens on the JVM,
>> and the JDBC driver doesn't use libpq.
> Yes, they do - including a horde o
On Wed, Jun 12, 2013 at 11:55 AM, Robert Haas wrote:
>> I hope PostgreSQL will provide a reliable archiving facility that is ready
>> to use.
>
> +1. I think we should have a way to set an archive DIRECTORY, rather
> than an archive command. And if you set it, then PostgreSQL should
> just do al
Simon Riggs writes:
> On 12 June 2013 01:35, Tom Lane wrote:
>> On the whole, I think the effort would be a lot more usefully spent on
>> trying to make the existing NUMERIC support go faster.
> Did you have a specific idea in mind? Or an area of investigation?
As I said further up, we should l
> On Sat, Jun 8, 2013 at 10:36 AM, MauMau wrote:
>> Yes, I feel designing reliable archiving, even for the simplest case - copy
>> WAL to disk, is very difficult. I know there are following three problems
>> if you just follow the PostgreSQL manual. Average users won't notice them.
>> I guess ev
On Jun 12, 2013 4:56 PM, "Robert Haas" wrote:
>
> On Sat, Jun 8, 2013 at 10:36 AM, MauMau wrote:
> > Yes, I feel designing reliable archiving, even for the simplest case -
copy
> > WAL to disk, is very difficult. I know there are following three
problems
> > if you just follow the PostgreSQL man
On Sat, Jun 8, 2013 at 7:20 PM, Jeff Janes wrote:
> If archiving is on and failure is due to no space, could we just keep trying
> XLogFileInit again for a couple minutes to give archiving a chance to do its
> things? Doing that while holding onto locks and a critical section would be
> unfortuna
On Wed, Jun 12, 2013 at 11:32 AM, Magnus Hagander wrote:
> Wouldn't that encourage people to do local archiving, which is almost always
> a bad idea?
Maybe, but refusing to improve the UI because people might then use
the feature seems wrong-headed.
> I'd rather improve the experience with pg_re
On 6/12/13 10:55 AM, Robert Haas wrote:
> But it's got to be pretty common to archive to a local
> path that happens to be a remote mount, or to a local directory whose
> contents are subsequently copied off by a batch job. Making that work
> nicely with near-zero configuration would be a signific
On 6/12/13 1:20 AM, Josh Berkus wrote:
> Peter, All:
>
> Does anyone feel like fixing the LOAD issue with transforms? I haven't
> seen any activity on the patch.
I plan to send in an updated patch.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Tue, Jun 11, 2013 at 10:11 AM, Tatsuo Ishii wrote:
>> Did you see my email with proposed alternative text? You didn't even
>> fix the whitespace error I pointed out.
>
> I don't know why but I haven't received your email. I just found the
> email in the web archive and it looks better than wha
On Tue, Jun 11, 2013 at 12:58 PM, Stephen Frost wrote:
> * Merlin Moncure (mmonc...@gmail.com) wrote:
>> It's understood that posix_fallocate is faster at this -- the question
>> on the table is 'does this matter in context of postgres?'.
>> Personally I think this patch should go in regardless --
On Wed, Jun 12, 2013 at 12:07 PM, Peter Eisentraut wrote:
> On 6/12/13 10:55 AM, Robert Haas wrote:
>> But it's got to be pretty common to archive to a local
>> path that happens to be a remote mount, or to a local directory whose
>> contents are subsequently copied off by a batch job. Making tha
On Wed, Jun 12, 2013 at 5:05 AM, Brendan Jurd wrote:
> On 12 June 2013 18:22, Dean Rasheed wrote:
>> +1 for having a function to return the total number of elements in an
>> array, because that's something that's currently missing from SQL.
>>
>> However, I think that CARDINALITY() should be that
>> Multidim arrays are why we can't have nice things.
>
> Yeah, I think that was not our best moment. :-(
They were one of those hacks which looked really clever at the time, but
proved not to be so. Unfortunately, they *are* useful, and are being
used; I use MD arrays all the time to push dat
looking at this patch some more ...
Dean Rasheed writes:
> One place where I think we have diverged from the spec, however, is in
> information_schema.columns.updatable. This should be returning 'YES'
> if the individual column is updatable, and I see no reason for that
> the require the relation
Josh Berkus writes:
> Actually, if you think about it, we've never had "arrays" in PostgreSQL
> ... we have always had matrixes. If you think about things that way,
> most of the current functionality makes sense.
Arguably, the only thing wrong with multidim arrays is that they're not
what the S
On 06/12/2013 11:01 AM, Tom Lane wrote:
> Arguably, the only thing wrong with multidim arrays is that they're not
> what the SQL standard asks for. However, the original point in this
> thread was that we have some very bizarre corner-case behavior for empty
> arrays. I'm going to be disappointe
Josh Berkus writes:
> On 06/12/2013 11:01 AM, Tom Lane wrote:
>> I'm going to be disappointed if all we can get out of this is
>> a cardinality() function, and nothing is done about the empty-array
>> semantics.
> Well, we can't change the zero-dim behavior without breaking backwards
> compatibil
On Wed, Jun 12, 2013 at 1:20 PM, Tom Lane wrote:
> Josh Berkus writes:
>> On 06/12/2013 11:01 AM, Tom Lane wrote:
>>> I'm going to be disappointed if all we can get out of this is
>>> a cardinality() function, and nothing is done about the empty-array
>>> semantics.
>
>> Well, we can't change the
On 6/12/13 1:29 PM, FabrÃzio de Royes Mello wrote:
> The attached patch add support to "IF NOT EXISTS" to "CREATE" statements
> listed below:
>
> - CREATE AGGREGATE [ IF NOT EXISTS ] ...
> - CREATE CAST [ IF NOT EXISTS ] ...
> - CREATE COLLATION [ IF NOT EXISTS ] ...
> - CREATE OPERATOR [ IF NOT E
On Wed, Jun 12, 2013 at 4:00 PM, Peter Eisentraut wrote:
>
>
> I'm wondering where "IF NOT EXISTS" and "OR REPLACE" will meet.
>
> For example, why doesn't your list include CREATE FUNCTION?
>
> I have on my personal todo list to add "OR REPLACE" support to CREATE
> AGGREGATE and CREATE OPERATOR.
On 06/12/2013 08:49 AM, Robert Haas wrote:
Sure, remote archiving is great, and I'm glad you've been working on
it. In general, I think that's a cleaner approach, but there are
still enough people using archive_command that we can't throw them
under the bus.
Correct.
I guess archiving to
On Wed, Jun 12, 2013 at 6:03 PM, Joshua D. Drake wrote:
>
>> Right now you have to be a rocket
>> scientist no matter what configuration you're running.
>
>
> This is quite a bit overblown. Assuming your needs are simple. Archiving is
> at it is now, a relatively simple process to set up, even wi
On Mon, Jun 3, 2013 at 6:42 AM, Andres Freund wrote:
> On 2013-06-02 11:44:04 -0700, Jeff Janes wrote:
> > Do we know why anti-wraparound uses so many resources in the first place?
> > The default settings seem to be quite conservative to me, even for a
> > system that has only a single 5400 rpm
On 2013-06-12 14:43:53 -0700, Jeff Janes wrote:
> > The default suggestion that frequently seems to be made is just to
> > disable autovac cost limitations because of that.
> Is there general agreement that this suggestion is bad? Setting
> autovacuum_vacuum_cost_delay to zero is basically saying
Dean Rasheed writes:
> [ pg_relation_is_updatable.patch ]
I've committed this with some modifications as mentioned. There is
still room to debate exactly what
information_schema.columns.is_updatable means --- we can now change that
without an initdb.
regards, tom lane
On 12 June 2013 18:35, Tom Lane wrote:
> looking at this patch some more ...
>
> Dean Rasheed writes:
>> One place where I think we have diverged from the spec, however, is in
>> information_schema.columns.updatable. This should be returning 'YES'
>> if the individual column is updatable, and I s
Jeff Janes wrote:
> Are there other anecdotes about what settings work well in
> practise, assuming people ever find ones that work well?
Putting WAL on its own RAID on its own battery-backed cached can
help a lot more than I would have thought -- even with read-only
transactions.
http://www.po
Dean Rasheed writes:
> The more I read the spec, the less sense it seems to make, and each
> time I read it, I seem to reach a different conclusion.
> On my latest reading, I've almost convinced myself that "updatable" is
> meant to imply support for all 3 operations (INSERT, UPDATE and
> DELETE)
> On Jun 12, 2013 2:02 AM, "Tatsuo Ishii" wrote:
>> No, I'm not talking about conflict resolution.
>>
>> From
>> http://www.cs.cmu.edu/~natassa/courses/15-823/F02/papers/replication.pdf:
>> --
>> Eager or Lazy Replication?
>> Eager replication:
>> kee
On Thu, Jun 13, 2013 at 3:22 AM, Tatsuo Ishii wrote:
>> Parallel query execution doesn't require commits to synchronize all
>> nodes. Parallel execution needs consistent snapshots across all nodes.
>> In effect this means that nodes need to agree on commit ordering,
>> either total order or a part
> On Thu, Jun 13, 2013 at 3:22 AM, Tatsuo Ishii wrote:
>>> Parallel query execution doesn't require commits to synchronize all
>>> nodes. Parallel execution needs consistent snapshots across all nodes.
>>> In effect this means that nodes need to agree on commit ordering,
>>> either total order or
* Ants Aasma (a...@cybertec.at) wrote:
> In a cluster setting you take the CSN value on the master, then before
> starting execution on a standby you wait until that the standby has
> replayed enough WAL to reach the CSN point read from the master and
> you know that after that everything that the
On Jun 13, 2013 4:18 AM, "Stephen Frost" wrote:
> * Ants Aasma (a...@cybertec.at) wrote:
> > In a cluster setting you take the CSN value on the master, then before
> > starting execution on a standby you wait until that the standby has
> > replayed enough WAL to reach the CSN point read from the m
Ants,
* Ants Aasma (ants.aa...@eesti.ee) wrote:
> On Jun 13, 2013 4:18 AM, "Stephen Frost" wrote:
> > * Ants Aasma (a...@cybertec.at) wrote:
> > > In a cluster setting you take the CSN value on the master, then before
> > > starting execution on a standby you wait until that the standby has
> > >
On 2013.06.12 10:11 AM, Josh Berkus wrote:
Multidim arrays are why we can't have nice things.
Yeah, I think that was not our best moment. :-(
Actually, if you think about it, we've never had "arrays" in PostgreSQL
... we have always had matrixes. If you think about things that way,
most of
On 13 June 2013 04:30, Peter Eisentraut wrote:
> I'm wondering where "IF NOT EXISTS" and "OR REPLACE" will meet.
>
CREATE OR REPLACE (or ALTER / UPDATE ?) would definitely be useful for
enums, where it would be nice if we could teach an ORM to generate DDL
based on the current values of the enum
On 13 June 2013 04:26, Merlin Moncure wrote:
> On Wed, Jun 12, 2013 at 1:20 PM, Tom Lane wrote:
>> Josh Berkus writes:
>>> On 06/12/2013 11:01 AM, Tom Lane wrote:
I'm going to be disappointed if all we can get out of this is
a cardinality() function, and nothing is done about the empty
This is like shared_preload_libraries except that it takes effect at
backend start and can be changed without a full postmaster restart. It
is like local_preload_libraries except that it is still only settable by
a superuser. This can be a better way to load modules such as
auto_explain.
Since t
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 USE_PGXS
There is adequate material in the documentation and elsewhere (PGXN) on
On 12 June 2013 23:01, Tom Lane wrote:
> Dean Rasheed writes:
>> [ pg_relation_is_updatable.patch ]
>
> I've committed this with some modifications as mentioned. There is
> still room to debate exactly what
> information_schema.columns.is_updatable means --- we can now change that
> without an i
64 matches
Mail list logo
