On 21 March 2013 17:32, Pavel Stehule wrote:
> If I though about it more, I like to more limit one parametric
> array_length function just for only 1D array. So it is your A use
> case. But I understand so this variant is not orthogonal. Hard to say,
> what is better.
>
Yes, for me (a) is running
2013/3/21 Brendan Jurd :
> On 21 March 2013 17:08, Pavel Stehule wrote:
>> 2013/3/21 Tom Lane :
>>> I'm not entirely convinced that this is a good idea, but if we're going
>>> to allow it I would argue that "array_length(a)" should be defined as
>>> "array_length(a, 1)". The other possibilities a
On 21 March 2013 17:08, Pavel Stehule wrote:
> 2013/3/21 Tom Lane :
>> I'm not entirely convinced that this is a good idea, but if we're going
>> to allow it I would argue that "array_length(a)" should be defined as
>> "array_length(a, 1)". The other possibilities are too complicated to
>> explai
2013/3/21 Tom Lane :
> Brendan Jurd writes:
>> While I was working on my empty array patch I was frequently irritated
>> by the absence of an array_length(anyarray). The same goes for
>> array_upper and array_lower. Most of the time when I work with
>> arrays, they are 1-D, and it's inelegant to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/19/2013 09:46 PM, Stephen Frost wrote:
> * Craig Ringer (cr...@2ndquadrant.com) wrote:
>> As far as I'm concerned that's the immediate problem fixed. It may be
>> worth adding a warning on startup if we find non-self-signed certs in
>> root.crt
Brendan Jurd writes:
> While I was working on my empty array patch I was frequently irritated
> by the absence of an array_length(anyarray). The same goes for
> array_upper and array_lower. Most of the time when I work with
> arrays, they are 1-D, and it's inelegant to having to specify which
>
Noah Misch writes:
> On Wed, Mar 20, 2013 at 05:17:11PM -0400, Peter Eisentraut wrote:
>> On 3/4/13 1:36 PM, Noah Misch wrote:
>>> Do you have in mind a target system exhibiting a problem? CentOS 6 ships a
>>> single xml2-config, but its --cflags --libs output is the same regardless of
>>> the in
On Mar 20, 2013 11:14 PM, "Dimitri Fontaine" wrote:
>
> Atri Sharma writes:
> > We can use a scheduling algorithm, and can define a pool of tasks as
well as
> > a time constraint for the amount of time which can be used for running
the
> > tasks.Then, a scheduling algorithm can pick tasks from th
Simon Riggs writes:
> On 20 March 2013 18:02, Tom Lane wrote:
>> The API that comes to mind is (name subject to
>> bikeshedding)
>>
>> pg_blocking_pids(pid int) returns int[]
> Useful. Can we also have an SRF rather than an array?
I thought about that, but at least for the isolationtester use-
On Wed, Mar 20, 2013 at 02:02:32PM -0400, Tom Lane wrote:
[fun query for appraising lock contention]
> This is way more knowledge than we (should) want a client to embed about
> which lock types block which others. What's worse, it's still wrong.
> The query will find cases where one of the test
On Thu, Mar 21, 2013 at 12:58 AM, Tom Lane wrote:
> I had been on the fence about what to do here, but I find Josh's
> arguments persuasive, particularly the second one. Why shouldn't we
> consider an in-progress index to be an uncommitted DDL change?
>
> (Now admittedly, there won't *be* any un
Hi hackers,
While I was working on my empty array patch I was frequently irritated
by the absence of an array_length(anyarray). The same goes for
array_upper and array_lower. Most of the time when I work with
arrays, they are 1-D, and it's inelegant to having to specify which
dimension I mean wh
On Wed, Mar 20, 2013 at 05:17:11PM -0400, Peter Eisentraut wrote:
> On 3/4/13 1:36 PM, Noah Misch wrote:
> > Do you have in mind a target system exhibiting a problem? CentOS 6 ships a
> > single xml2-config, but its --cflags --libs output is the same regardless of
> > the installed combination of
On 20 March 2013 21:50, Peter Geoghegan wrote:
> I realize that this isn't terribly critical, but I'd like to suggest
> that commit_delay be made PGC_SIGHUP on 9.3 (it's currently
> PGC_USERSET). It's not that a poorly chosen commit_delay setting has
> the potential to adversely affect other backe
On 20 March 2013 18:02, Tom Lane wrote:
> The API that comes to mind is (name subject to
> bikeshedding)
>
> pg_blocking_pids(pid int) returns int[]
>
Useful. Can we also have an SRF rather than an array?
Does the definition as an array imply anything about our ability to
join an SRF to
On Mar 20, 2013, at 4:45 PM, Brendan Jurd wrote:
> I submit a patch to rectify the weird and confusing quirk of Postgres
> to use "zero dimensions" to signify an empty array.
Epic. Thank you. I’m very glad now that I complained about this (again)!
Best,
David
--
Sent via pgsql-hackers mail
On 17 March 2013 05:19, Tom Lane wrote:
> Brendan Jurd writes:
>> On 16 March 2013 09:07, Tom Lane wrote:
>>> The thing is that that syntax creates an array of zero dimensions,
>>> not one that has 1 dimension and zero elements.
>
>> I'm going to ask the question that immediately comes to mind:
Tom Lane writes:
>> pg_is_lock_exclusive(lock, lock) returns boolean
>> pg_is_lock_exclusive(lock[], lock[]) returns boolean
>
>> I suppose that the lock type would be text ('ExclusiveLock'), but we
>> could also expose a new ENUM type for that (pg_lock_mode).
>
> I don't have an objection to
Dimitri Fontaine writes:
> Tom Lane writes:
>> If we want a global view of the who-blocks-whom situation, I think we'll
>> need another approach. But since this way solves isolationtester's
>> problem fairly neatly, I was hopeful that it would be useful for other
>> apps too.
> What about a fun
Kevin Grittner wrote:
> Robert Haas wrote:
>> It seems to me that the right place to fix this is in
>> interpretOidsOption(), by returning false rather than
>> default_with_oids whenever the relation is a materialized view.
> I like it.
In working up a patch for this approach, I see that if CR
Tom Lane writes:
>>> I propose that we should add a backend function that simplifies this
>>> type of query. The API that comes to mind is (name subject to
>>> bikeshedding)
>>>
>>> pg_blocking_pids(pid int) returns int[]
+1
> If we want a global view of the who-blocks-whom situation, I think
Atri Sharma writes:
> We can use a scheduling algorithm, and can define a pool of tasks as well as
> a time constraint for the amount of time which can be used for running the
> tasks.Then, a scheduling algorithm can pick tasks from the pool based on
> priorities and the time duration of a task.I
Steve Singer writes:
> On 13-03-20 02:17 PM, Bruce Momjian wrote:
>> I think the concern is that the services file could easily change the
>> defaults that are used for connecting, though you could argue that the
>> real defaults for a bad service entry are properly returned.
> Yes, my concern is
I realize that this isn't terribly critical, but I'd like to suggest
that commit_delay be made PGC_SIGHUP on 9.3 (it's currently
PGC_USERSET). It's not that a poorly chosen commit_delay setting has
the potential to adversely affect other backends where the setting
*has* been set in those other back
On 13-03-20 02:17 PM, Bruce Momjian wrote:
On Wed, Mar 20, 2013 at 01:30:20PM -0400, Tom Lane wrote:
While this surely isn't the nicest answer, it doesn't seem totally
unreasonable to me. A bad service name indeed does not contribute
anything to the set of defaults available.
I think the c
Here's a new version of this patch, rebased on top of the new
pg_identify_object() stuff. Note that the regression test doesn't work
yet, because I didn't adjust to the new identity output definition (the
docs need work, too). But that's a simple change to do. I'm leaving
that for later.
--
Ál
Tom Lane wrote:
> Alvaro Herrera writes:
> > One change I made was to move all the new code from dependency.c into
> > objectaddress.c. The only reason it was in dependency.c was that
> > getObjectDescription was there in the first place; but it doesn't seem
> > to me that it really belongs there
On 3/4/13 1:36 PM, Noah Misch wrote:
> Do you have in mind a target system exhibiting a problem? CentOS 6 ships a
> single xml2-config, but its --cflags --libs output is the same regardless of
> the installed combination of libxml2-dev packages. Ubuntu 13.04 does not ship
> 32-bit libxml2, so it
Greg Stark writes:
> On Wed, Mar 20, 2013 at 6:02 PM, Tom Lane wrote:
>> I propose that we should add a backend function that simplifies this
>> type of query. The API that comes to mind is (name subject to
>> bikeshedding)
>>
>> pg_blocking_pids(pid int) returns int[]
> I've wanted to use pg_
Robert Haas wrote:
> Kevin Grittner wrote:
>> I want to give everyone else a chance to weigh in before I start
>> the pendulum swinging back in the other direction on OIDs in MVs.
>> Opinions?
>
> I agree that it's probably better to just disallow this, but I have to
> admit I don't like your pro
On Wed, Mar 20, 2013 at 6:02 PM, Tom Lane wrote:
> I propose that we should add a backend function that simplifies this
> type of query. The API that comes to mind is (name subject to
> bikeshedding)
>
> pg_blocking_pids(pid int) returns int[]
I've wanted to use pg_locks as a demonstrati
Alvaro Herrera writes:
> One change I made was to move all the new code from dependency.c into
> objectaddress.c. The only reason it was in dependency.c was that
> getObjectDescription was there in the first place; but it doesn't seem
> to me that it really belongs there. (Back when it was first
Robert Haas escribió:
> On Wed, Mar 20, 2013 at 2:02 PM, Tom Lane wrote:
> > I was just looking into why the -DCLOBBER_CACHE_ALWAYS buildfarm
> > critters aren't managing to run the new "timeouts" isolation test
> > successfully, despite very generous timeouts. The answer is that
> > 2 seconds is
On Wed, Mar 20, 2013 at 2:02 PM, Tom Lane wrote:
> I was just looking into why the -DCLOBBER_CACHE_ALWAYS buildfarm
> critters aren't managing to run the new "timeouts" isolation test
> successfully, despite very generous timeouts. The answer is that
> 2 seconds isn't quite enough time to parse+p
On Mon, Mar 18, 2013 at 4:42 PM, Kevin Grittner wrote:
> I want to give everyone else a chance to weigh in before I start
> the pendulum swinging back in the other direction on OIDs in MVs.
> Opinions?
I agree that it's probably better to just disallow this, but I have to
admit I don't like your
On Wed, Mar 20, 2013 at 01:30:20PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Wed, Mar 20, 2013 at 12:30:32PM -0400, Tom Lane wrote:
> >> I think we should either change PQconndefaults to *not* fail in this
> >> circumstance, or find a way to return an error message.
>
> > Well, Steve
I was just looking into why the -DCLOBBER_CACHE_ALWAYS buildfarm
critters aren't managing to run the new "timeouts" isolation test
successfully, despite very generous timeouts. The answer is that
2 seconds isn't quite enough time to parse+plan+execute the query
that isolationtester uses to see if
Bruce Momjian writes:
> On Wed, Mar 20, 2013 at 12:30:32PM -0400, Tom Lane wrote:
>> I think we should either change PQconndefaults to *not* fail in this
>> circumstance, or find a way to return an error message.
> Well, Steve Singer didn't like the idea of ignoring a service lookup
> failure. W
Daniel Farina writes:
> On Wed, Mar 20, 2013 at 7:43 AM, Tom Lane wrote:
>> Um ... you shouldn't need a PG_TRY for that at all. guc.c will take
>> care of popping the values on transaction abort --- that's really rather
>> the whole point of having that mechanism.
> Hmm, well, merely raising th
It does sound nice,something like cron?
We can use a scheduling algorithm, and can define a pool of tasks as well as a
time constraint for the amount of time which can be used for running the
tasks.Then, a scheduling algorithm can pick tasks from the pool based on
priorities and the time durati
On Wed, Mar 20, 2013 at 12:30:32PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Tue, Mar 19, 2013 at 10:12:21AM -0400, Steve Singer wrote:
> >>> * Should we document this?
>
> >> Yes the documentation should indicate that PQconndefaults() can
> >> return NULL for more than just memory f
On Wed, Mar 20, 2013 at 7:43 AM, Tom Lane wrote:
> Daniel Farina writes:
>> Okay, one more of those fridge-logic bugs. Sorry for the noise. v5.
>
>> A missing PG_RETHROW to get the properly finally-esque semantics:
>
>> --- a/contrib/dblink/dblink.c
>> +++ b/contrib/dblink/dblink.c
>> @@ -642,7
Hi Tom,
Tom Lane wrote:
> After thinking about that for awhile: if we pursue this type of
> optimization, what would probably be appropriate is to add an aggregate
> property (stored in pg_aggregate) that allows direct specification of
> the size that the planner should assume for the aggregate's
On Wed, Mar 20, 2013 at 2:01 PM, Tom Lane wrote:
> Daniele Varrazzo writes:
>> while translating the new PostgreSQL 9.3 strings I've found a couple
>> questionable. Patches attached.
>
> Hmm ... I agree with the MultiXactId->MultiXactIds changes, but not with
> this one:
>
>> -
Bruce Momjian writes:
> On Tue, Mar 19, 2013 at 10:12:21AM -0400, Steve Singer wrote:
>>> * Should we document this?
>> Yes the documentation should indicate that PQconndefaults() can
>> return NULL for more than just memory failures.
> The attached patch fixes this. I am unclear about backpat
Marc Cousin escribió:
> On 20/03/2013 16:33, Alvaro Herrera wrote:
> >Ah. The reason for this problem is that the statement start time (which
> >also sets the transaction start time, when it's the first statement) is
> >set by postgres.c, not the transaction-control functions in xact.c. So
> >yo
On 20/03/2013 16:33, Alvaro Herrera wrote:
Marc Cousin escribió:
Hi,
I'm trying to write a background writer, and I'm facing a problem with
timestamps. The following code is where I'm having a problem (it's just a demo
for
the problem):
BackgroundWorkerInitializeConnection("test", NULL);
whil
On Tue, Mar 19, 2013 at 10:12:21AM -0400, Steve Singer wrote:
> >so it is clearly possible for PQconndefaults() to return NULL for
> >service file failures. The questions are:
> >
> >* Is this what we want?
>
> What other choices do we have? I don't think PQconndefaults() should
> continue on as
On 19 March 2013 17:42, Thom Brown wrote:
> On 14 February 2013 18:02, Josh Berkus wrote:
>> Folks,
>>
>> Once again, Google is holding Summer of Code. We need to assess whether
>> we want to participate this year.
>>
>> Questions:
>>
>> - Who wants to mentor for GSOC?
>>
>> - Who can admin for
Josh Kupershmidt writes:
> On Wed, Mar 20, 2013 at 2:00 AM, Simon Riggs wrote:
>> Invalid also means currently-in-progress, so it would be better to keep them
>> in.
> For invalid indexes which are left hanging around in the database, if
> the index definition is included by pg_dump, it will li
On Wed, Mar 20, 2013 at 2:00 AM, Simon Riggs wrote:
> On 20 March 2013 02:51, Michael Paquier wrote:
>
>> If failures happen with CREATE INDEX CONCURRENTLY, the system will be let
>> with invalid indexes. I don't think that the user would like to see invalid
>> indexes of
>> an existing system be
Marc Cousin escribió:
> Hi,
>
> I'm trying to write a background writer, and I'm facing a problem with
> timestamps. The following code is where I'm having a problem (it's just a
> demo for
> the problem):
>
> BackgroundWorkerInitializeConnection("test", NULL);
> while (!got_sigterm)
> {
>
Daniel Farina writes:
> Okay, one more of those fridge-logic bugs. Sorry for the noise. v5.
> A missing PG_RETHROW to get the properly finally-esque semantics:
> --- a/contrib/dblink/dblink.c
> +++ b/contrib/dblink/dblink.c
> @@ -642,7 +642,10 @@ dblink_fetch(PG_FUNCTION_ARGS)
> }
> PG_CATC
Hi,
I'm trying to write a background writer, and I'm facing a problem with
timestamps. The following code is where I'm having a problem (it's just a demo
for
the problem):
BackgroundWorkerInitializeConnection("test", NULL);
while (!got_sigterm)
{
int ret;
/* Wait 1s */
re
The table at
http://www.postgresql.org/docs/devel/static/event-trigger-matrix.html
does not include things like CREATE MATERIALIZED VIEW or REFRESH
MATERIALIZED VIEW. but they certainly seem to work?
Just a missing doc patch, or is there something in the code that's not
behaving as intended?
If
Alvaro Herrera writes:
> The new identity column is amazingly verbose on things like pg_amproc entries:
> 10650 | 1 (pg_catalog.point, pg_catalog.point) of pg_catalog.point_ops for
> gist:
> pg_catalog.gist_point_consistent(pg_catalog.internal,pg_catalog.point,integer,pg_catalog.oid,pg_catalog
Daniele Varrazzo writes:
> while translating the new PostgreSQL 9.3 strings I've found a couple
> questionable. Patches attached.
Hmm ... I agree with the MultiXactId->MultiXactIds changes, but not with
this one:
> -errhint("To make the view
> upd
On Mon, Mar 18, 2013 at 01:52:58PM -0400, Bruce Momjian wrote:
> I assume a user would wait until they suspected corruption to turn it
> on, and because it is only initdb-enabled, they would have to
> dump/reload their cluster. The open question is whether this is a
> usable feature as written, or
On Mon, Mar 18, 2013 at 5:52 PM, Bruce Momjian wrote:
> With a potential 10-20% overhead, I am unclear who would enable this at
> initdb time.
For what it's worth I think cpu overhead of the checksum is totally a
red herring.. Of course there's no reason not to optimize it to be as
fast as possib
Hello,
while translating the new PostgreSQL 9.3 strings I've found a couple
questionable. Patches attached.
Cheers,
-- Daniele
0001-Fixed-MultiXactIds-string-warning.patch
Description: Binary data
0002-Fixed-pasto-in-hint-string-about-making-views-deleta.patch
Description: Binary data
--
S
Hello
2013/3/19 Tom Lane :
> I wrote:
>> [ looks at patch... ] Oh, I see what's affecting the plan: you changed
>> the aggtranstypes to internal for a bunch of aggregates. That's not
>> very good, because right now the planner takes that to mean that the
>> aggregate could eat a lot of space. W
Alvaro Herrera writes:
> All in all, I'm happy with this and I'm considering committing it as
> soon as we agree on the set of columns. I'm mildly on the side of
> removing the separate schema column and keeping name, so we'd have
> type/name/identity.
I would prefer that we keep the schema colu
On 20 March 2013 02:51, Michael Paquier wrote:
> If failures happen with CREATE INDEX CONCURRENTLY, the system will be let
> with invalid indexes. I don't think that the user would like to see invalid
> indexes of
> an existing system being recreated as valid after a restore.
> So why not removin
63 matches
Mail list logo
