On Sunday, 27 January 2013, Robert Haas wrote:
> If we're going to start installing safeguards against doing stupid
> things, there's a long list of scenarios that happen far more
> regularly than this ever will and cause far more damage.
+1
--
Regards,
Peter Geoghegan
Hello
minor update - fix align NULL for %L
Regards
Pavel
2013/1/31 Pavel Stehule :
> Hello
>
> 2013/1/29 Dean Rasheed :
>> On 29 January 2013 08:19, Dean Rasheed wrote:
>>> * The width field is optional, even if the '-' flag is specified. So
>>> '%-s' is perfectly legal and should be interpret
Hello
can you look, please, on updated version - it respects Tom's proposal
and it is significantly reduced?
Thank you
Pavel Stehule
2013/1/28 Pavel Stehule :
> Hello
>
> 2013/1/26 Tom Lane :
>> Andrew Dunstan writes:
>>> +1. This looks quite nifty. Maybe useful too to have a default prefix
>>
On Wednesday, January 30, 2013 6:53 AM Morten Hustveit wrote:
> Hi!
>
> Calling "SET TRANSACTION ISOLATION LEVEL ..." outside a transaction
> block has no effect. This is unlike "LOCK ..." and "DECLARE foo
> CURSOR FOR ...", which both raise an error. This is also unlike
> MySQL, where such a st
Andrew Dunstan writes:
> What's the best way for me to find out if a given parameter of a
> function is a constant? The context is that it's expensive to process,
> and in most cases will in fact be a constant, so if it is in fact a
> constant I'd like to process it once and stash the results.
hello
2013/2/1 Andrew Dunstan :
>
> What's the best way for me to find out if a given parameter of a function is
> a constant? The context is that it's expensive to process, and in most cases
> will in fact be a constant, so if it is in fact a constant I'd like to
> process it once and stash the r
On Fri, 2013-01-18 at 10:00 -0500, Stephen Frost wrote:
> I've done another review of this patch and it looks pretty good to me.
> My only complaint is that there isn't a single comment inside
> makeRecursiveViewSelect().
Added some of that and committed.
> One other thought is- I'm guessing this
On Mon, 2013-01-14 at 10:25 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > The attached patch looks for pkg-config first, and finds libxml2 using
> > that if available. Otherwise it falls back to using xml2-config.
>
> What happens if pkg-config is installed but doesn't know anything abou
On 02/01/2013 12:01 PM, Josh Berkus wrote:
>
>> If we're going to start installing safeguards against doing stupid
>> things, there's a long list of scenarios that happen far more
>> regularly than this ever will and cause far more damage.
>
> What's wrong with making it easier for sysadmins to t
What's the best way for me to find out if a given parameter of a
function is a constant? The context is that it's expensive to process,
and in most cases will in fact be a constant, so if it is in fact a
constant I'd like to process it once and stash the results.
cheers
andrew
--
Sent via
Heikki,
I thought this was only a 9.3 issue, but it turns out to be
reproduceable on 9.2.2. Basically, I did:
1. master is queicent ... no writes occuring.
2. createded cascading replica (reprep1) from replica (repmaster)
3. reprep1 remains "in recovery mode" until a write occurs on master
I've
> If we're going to start installing safeguards against doing stupid
> things, there's a long list of scenarios that happen far more
> regularly than this ever will and cause far more damage.
What's wrong with making it easier for sysadmins to troubleshoot things?
Again, I'm not talking about er
On 01/02/13 13:26, Andrew Dunstan wrote:
On 01/31/2013 07:16 PM, David E. Wheeler wrote:
On Jan 31, 2013, at 2:20 PM, Andrew Dunstan wrote:
I'm happy to take opinions about this, and I expected some
bikeshedding, but your reaction is contrary to everything others
have told me. Mostly they l
On Jan 31, 2013, at 4:32 PM, Tom Lane wrote:
> Ada or no, its use in plpgsql would render that a seriously bad idea.
I assumed that its use in function params would be the main reason not to use
it.
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Andrew Dunstan writes:
> On 01/31/2013 07:16 PM, David E. Wheeler wrote:
>> I suppose that := is out of the question?
> Even if it were I would not on any account use it. As an old Ada
> programmer my mind just revolts at the idea of using this for anything
> but assignment.
Ada or no, its use
On 01/31/2013 07:16 PM, David E. Wheeler wrote:
On Jan 31, 2013, at 2:20 PM, Andrew Dunstan wrote:
I'm happy to take opinions about this, and I expected some bikeshedding, but
your reaction is contrary to everything others have told me. Mostly they love
the operators.
I guess that '~>' and
On Jan 31, 2013, at 2:20 PM, Andrew Dunstan wrote:
> I'm happy to take opinions about this, and I expected some bikeshedding, but
> your reaction is contrary to everything others have told me. Mostly they love
> the operators.
>
> I guess that '~>' and '~>>' would work as well as '->' and '->>
Merlin Moncure writes:
> On Thu, Jan 31, 2013 at 4:20 PM, Andrew Dunstan wrote:
>> On 01/31/2013 05:06 PM, Peter Eisentraut wrote:
>>> I would like to not create any -> operators, so that that syntax could
>>> be used in the future for method invocation or something similar (it's
>>> in the SQL s
On Thu, Jan 31, 2013 at 4:20 PM, Andrew Dunstan wrote:
>
> On 01/31/2013 05:06 PM, Peter Eisentraut wrote:
>>
>> On 1/10/13 6:42 PM, Andrew Dunstan wrote:
>>>
>>> This updated patch contains all the intended functionality, including
>>> operators for the json_get_path functions, so you can say thi
MauMau wrote:
> Just doing "pkill postgres" will unexpectedly terminate postgres
> of other instances.
Not if you run each instance under a different OS user, and execute
pkill with the right user. (Never use root for that!) This is
just one of the reasons that you should not run multiple clus
From: "Peter Eisentraut"
On 1/30/13 9:11 AM, MauMau wrote:
When I ran "pg_ctl stop -mi" against the primary, some applications
connected to the primary did not stop. The cause was that the backends
was deadlocked in quickdie() with some call stack like the following.
I'm sorry to have left the
On 01/31/2013 05:06 PM, Peter Eisentraut wrote:
On 1/10/13 6:42 PM, Andrew Dunstan wrote:
This updated patch contains all the intended functionality, including
operators for the json_get_path functions, so you can say things like
select jsonval->array['f1','0','f2] ...
I would like to no
On 1/10/13 6:42 PM, Andrew Dunstan wrote:
> This updated patch contains all the intended functionality, including
> operators for the json_get_path functions, so you can say things like
>
> select jsonval->array['f1','0','f2] ...
I would like to not create any -> operators, so that that synta
2013-01-31 19:38 keltezéssel, Tom Lane írta:
=?ISO-8859-2?Q?Zolt=E1n_B=F6sz=F6rm=E9nyi?= writes:
Thanks. A question though: how does "make check" or "make installcheck"
chooses between the *.out and its different *_N.out incarnations?
I couldn't find traces of prepared_xacts_1.out in any file s
On 1/9/13 8:56 PM, Tom Lane wrote:
> However, it seems to me that this behavior is actually wrong for our
> purposes, as it represents a too-literal reading of the spec. The SQL
> standard has no concept of privileges on schemas, only ownership.
> We do have privileges on schemas, so it seems to m
Hello
2013/1/29 Dean Rasheed :
> On 29 January 2013 08:19, Dean Rasheed wrote:
>> * The width field is optional, even if the '-' flag is specified. So
>> '%-s' is perfectly legal and should be interpreted as '%s'. The
>> current implementation treats it as a width of 0, which is wrong.
>>
>
> Oh,
On 1/30/13 9:11 AM, MauMau wrote:
> When I ran "pg_ctl stop -mi" against the primary, some applications
> connected to the primary did not stop. The cause was that the backends
> was deadlocked in quickdie() with some call stack like the following.
> I'm sorry to have left the stack trace file on
On Thu, Jan 31, 2013 at 3:18 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Thu, Jan 31, 2013 at 2:40 PM, Alvaro Herrera
>> wrote:
>> > Alvaro Herrera escribió:
>> >
>> >> Okay, here's a patch along these lines. I haven't considered Jim's
>> >> suggestion downthread about discounting de
Robert Haas escribió:
> On Thu, Jan 31, 2013 at 2:40 PM, Alvaro Herrera
> wrote:
> > Alvaro Herrera escribió:
> >
> >> Okay, here's a patch along these lines. I haven't considered Jim's
> >> suggestion downthread about discounting dead tuples from relpages; maybe
> >> we can do that by subtractin
Tom Lane escribió:
> Alvaro Herrera writes:
> > Instead, what I propose (and is not really in the patch), as a
> > backpatchable item, is an approach in which the functions to compute
> > each rel's Browne strength and sort are hooks. Normal behavior is not
> > to sort at all, as currently, and s
Alvaro Herrera writes:
> Instead, what I propose (and is not really in the patch), as a
> backpatchable item, is an approach in which the functions to compute
> each rel's Browne strength and sort are hooks. Normal behavior is not
> to sort at all, as currently, and sites that have a problem with
On Thu, Jan 31, 2013 at 2:36 PM, Alvaro Herrera
wrote:
> Instead, what I propose (and is not really in the patch), as a
> backpatchable item, is an approach in which the functions to compute
> each rel's Browne strength and sort are hooks. Normal behavior is not
> to sort at all, as currently, an
On Thu, Jan 31, 2013 at 2:40 PM, Alvaro Herrera
wrote:
> Alvaro Herrera escribió:
>
>> Okay, here's a patch along these lines. I haven't considered Jim's
>> suggestion downthread about discounting dead tuples from relpages; maybe
>> we can do that by subtracting the pages attributed to dead ones,
Alvaro Herrera escribió:
> Okay, here's a patch along these lines. I haven't considered Jim's
> suggestion downthread about discounting dead tuples from relpages; maybe
> we can do that by subtracting the pages attributed to dead ones,
> estimating via tuple density (reltuples/relpages).
Patch a
Christopher Browne escribió:
> On Fri, Jan 25, 2013 at 12:00 PM, Andres Freund
> wrote:
> I'd be inclined to do something a bit more sophisticated than just
> age(relfrozenxid) for wraparound; I'd be inclined to kick off large tables'
> wraparound vacuums earlier than those for smaller tables.
>
=?ISO-8859-2?Q?Zolt=E1n_B=F6sz=F6rm=E9nyi?= writes:
> Thanks. A question though: how does "make check" or "make installcheck"
> chooses between the *.out and its different *_N.out incarnations?
> I couldn't find traces of prepared_xacts_1.out in any file saying "this
> is the one to be used in thi
2013-01-31 16:39 keltezéssel, Tom Lane írta:
=?ISO-8859-1?Q?Zolt=E1n_B=F6sz=F6rm=E9nyi?= writes:
2013-01-31 15:22 keltezéssel, Alvaro Herrera írta:
That sounds a lot more difficult than just using "make installcheck" and
configure the running server with zero prepared xacts ...
It didn't occu
On Thu, Jan 31, 2013 at 5:06 AM, Dimitri Fontaine
wrote:
> Tom Lane writes:
>> Also, it's far from obvious to me that "largest first" is the best rule
>> anyhow; it's likely to be more complicated than that.
>>
>> But anyway, the right place to add this sort of consideration is in
>> pg_restore -
On Tue, Jan 29, 2013 at 3:34 PM, Tom Lane wrote:
> "David Rowley" writes:
>> If pg_dump was to still follow the dependencies of objects, would there be
>> any reason why it shouldn't backup larger tables first?
>
> Pretty much every single discussion/complaint about pg_dump's ordering
> choices h
=?ISO-8859-1?Q?Zolt=E1n_B=F6sz=F6rm=E9nyi?= writes:
> 2013-01-31 15:22 keltezéssel, Alvaro Herrera írta:
>> That sounds a lot more difficult than just using "make installcheck" and
>> configure the running server with zero prepared xacts ...
> It didn't occur to me to use "make installcheck" for
On 01/31/2013 09:55 AM, Zoltán Böszörményi wrote:
2013-01-31 15:22 keltezéssel, Alvaro Herrera írta:
Zoltán Böszörményi wrote:
I have found a little time to look into this problem and
found a way to make pg_regress use prepared_xacts_1.out.
I had to change line 2193 in pg_regress.c from
2013-01-31 15:22 keltezéssel, Alvaro Herrera írta:
Zoltán Böszörményi wrote:
I have found a little time to look into this problem and
found a way to make pg_regress use prepared_xacts_1.out.
I had to change line 2193 in pg_regress.c from
fputs("max_prepared_transactions = 2\n", pg_conf);
Zoltán Böszörményi wrote:
> I have found a little time to look into this problem and
> found a way to make pg_regress use prepared_xacts_1.out.
> I had to change line 2193 in pg_regress.c from
>
> fputs("max_prepared_transactions = 2\n", pg_conf);
>
> to
>
> fputs("max_prepared_transact
Another thing I forget: The patch does not apply because of the changes in
"catversion.h"
Regards,
Ali Dar
On Thu, Jan 31, 2013 at 6:59 PM, Ali Dar wrote:
> On Wed, Jan 9, 2013 at 4:28 PM, Peter Eisentraut wrote:
>
>> Here is an implementation of the
>> information_schema.parameters.parameter
On Wed, Jan 9, 2013 at 4:28 PM, Peter Eisentraut wrote:
> Here is an implementation of the
> information_schema.parameters.parameter_default column.
>
> I ended up writing a C function to decode the whole thing from the
> system catalogs, because it was too complicated in SQL, so I abandoned
> th
2013-01-30 17:45 keltezéssel, Zoltán Böszörményi írta:
2013-01-30 16:06 keltezéssel, Hari Babu írta:
On Wednesday, January 30, 2013 7:59 PM Zoltán Böszörményi wrote:
2013-01-28 15:20 keltezéssel, Hari Babu írta:
2. regress check failed because the expected ".out" file is not
updated properly.
Hi!
Calling "SET TRANSACTION ISOLATION LEVEL ..." outside a transaction
block has no effect. This is unlike "LOCK ..." and "DECLARE foo
CURSOR FOR ...", which both raise an error. This is also unlike
MySQL, where such a statement will affect the next transaction
performed. There's some risk of
On Wednesday, January 30, 2013 8:32 PM Amit Kapila wrote:
> On Tuesday, January 29, 2013 7:42 PM Amit Kapila wrote:
> > On Tuesday, January 29, 2013 3:53 PM Heikki Linnakangas wrote:
> > > On 29.01.2013 11:58, Amit Kapila wrote:
> > > > Can there be another way with which current patch code can be
From: "Tom Lane"
"MauMau" writes:
How about the case where some backend crashes due to a bug of PostgreSQL?
In this case, postmaster sends SIGQUIT to all backends, too. The
instance
is expected to disappear cleanly and quickly. Doesn't the hanging
backend
harm the restart of the instance?
Hi,
The fklocks patch moved HeapSatisfiesHOTandKeyUpdate (or rather
HeapSatisfiesHOTUpdate back then) to be called way earlier in
heap_update as its needed to know which lock level is
required. Unfortunately the oid of the new tuple isn't yet setup at that
point.
Due to this everytime there's an
As I promised yesterday, I'll show you the precise call stack:
#0 0x003fa0cf542e in __lll_lock_wait_private () from /lib64/libc.so.6
#1 0x003fa0c7bed5 in _L_lock_9323 () from /lib64/libc.so.6
#2 0x003fa0c797c6 in malloc () from /lib64/libc.so.6
#3 0x003fa0c2fd99 in _nl_make_l1
Andrew Dunstan writes:
> Well, we could actually set the wrap value to 0, which would mean always
> wrap. That wouldn't be making any assumption about the user's terminal
> window size ;-)
+1
> Personally I find the wrapped case MUCH more readable. I guess anything is
> an advance, but turning o
On 1/31/2013 2:06 AM, Dimitri Fontaine wrote:
Loading several big'o'tables in parallel tend not to give benefits in
the tests I've done so far, but that might be an artefact of python
multi threading, I will do some testing with proper tooling later.
or insufficient IO parallelism in your disk
Tom Lane writes:
> Also, it's far from obvious to me that "largest first" is the best rule
> anyhow; it's likely to be more complicated than that.
>
> But anyway, the right place to add this sort of consideration is in
> pg_restore --parallel, not pg_dump. I don't know how hard it would be
> for
54 matches
Mail list logo
