Hello
fast reply
2012/10/14 Tom Lane :
> Pavel Stehule writes:
>> [ gset_08.diff ]
>
> In the course of adding a new backslash command, this patch manages to
> touch:
>
> * the main loop's concept of what types of backslash commands exist
> (PSQL_CMD_NOSEND ... what's the point of that, rather
Hi all,
It seems the queries in ./src/tutorial/syscat.source use string
escaping with the assumption that standard_conforming_strings is off,
and thus give wrong results with modern versions. A simple fix is
attached.
Josh
syscat.source_escaping.diff
Description: Binary data
--
Sent via pgsql-h
Robert Haas writes:
> On Thu, Oct 11, 2012 at 5:59 PM, Tom Lane wrote:
>> I'm reasonably convinced that this is a good fix for HEAD, but am of two
>> minds whether to back-patch it or not. The problem complained of in
>> bug #7598 may seem a bit narrow, but the real point is that whether you
>>
On Thu, Oct 11, 2012 at 3:15 AM, Heikki Linnakangas
wrote:
> IMHO that's a good thing, and I'd hope this new logical replication to live
> outside core as well, as much as possible. But whether or not something is
> in core is just a political decision, not a reason to implement something
> new.
>
On Thu, Oct 11, 2012 at 5:59 PM, Tom Lane wrote:
> I'm reasonably convinced that this is a good fix for HEAD, but am of two
> minds whether to back-patch it or not. The problem complained of in
> bug #7598 may seem a bit narrow, but the real point is that whether you
> write a cast explicitly or
I got a bit suspicious of the transient-file mechanism introduced in
commit fba105b1099f4f5fa7283bb17cba6fed2baa8d0c after noticing that
CleanupTempFiles seemed to take an unreasonable amount of time in a
test case that didn't involve any temp files, cf
http://archives.postgresql.org/message-id/711
Simon,
* Simon Riggs (si...@2ndquadrant.com) wrote:
> You also mention that 3 years wasn't long enough for some people, but
> I am unsure as to your point there. It might be that we should take
> longer than 3 years to deprecate things, or that the same pain will be
> felt however long we leave it
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Simon Riggs
> Sent: Sunday, October 14, 2012 5:30 PM
> To: Tom Lane
> Cc: Greg Stark; Peter Geoghegan; PostgreSQL-development
> Subject: Re: [HACKERS] Deprecating RULE
On Sun, Oct 14, 2012 at 9:30 AM, Simon Riggs wrote:
> On 12 October 2012 19:48, Greg Stark wrote:
>> On Fri, Oct 12, 2012 at 7:55 AM, Simon Riggs wrote:
>>> AFAICS all RULEs can be re-expressed as Triggers or Views.
>>
>> This is a bizarre discussion. Firstly this isn't even close to true.
>> Th
On Sat, Oct 13, 2012 at 3:13 AM, Stephen Frost wrote:
> Josh's concern is about autovacuum causing lots of stats churn, which is
> understandable, we don't want it constantly rescanning a table
I don't think rescanning the table is a big concern. autovacuum will
only scan as often as it feels lik
Le 14/10/2012 18:50, Tom Lane a écrit :
> Gilles Darold writes:
>> Restoring a backup generated with pg_dump/pg_dumpall in plain text
>> format and the --clean option will report errors if the backup is loaded
>> in an other or empty database.
> This is intentional. What you propose amounts to a
Noah Misch wrote:
I decided to try a 32-bit build, but Solution::DeterminePlatform
detected it as x64. Its shibboleth is no longer valid; the cl.exe shipping
with VS 2012 Express for Desktop has a /favor option for both architectures:
32clhelp:/favor: select processor to optimize for, one of:
6
On 14 October 2012 17:35, Tom Lane wrote:
> Simon Riggs writes:
>> On 12 October 2012 19:48, Greg Stark wrote:
>>> On Fri, Oct 12, 2012 at 7:55 AM, Simon Riggs wrote:
AFAICS all RULEs can be re-expressed as Triggers or Views.
>
>>> This is a bizarre discussion. Firstly this isn't even clos
On Sun, Oct 14, 2012 at 2:04 AM, Magnus Hagander wrote:
> There's a lot of shades of gray to that one. Way too many to say
> they're right *or* wrong, IMHO.
We can agree it is 'sub-ideal', but there is not one doubt in my mind
that it is not 'right' given the scope of Debian's task, which does
*
Noah Misch wrote:
My build log filled 8.8 MiB, a large increase from the 432 KiB of the "chough"
build log. This isn't strictly a problem, but do you happen to have ideas for
curbing the noise?
Not yet.
I find no functional problems with the patch, but some comment updates and
other trivia n
Pavel Stehule writes:
> [ gset_08.diff ]
In the course of adding a new backslash command, this patch manages to
touch:
* the main loop's concept of what types of backslash commands exist
(PSQL_CMD_NOSEND ... what's the point of that, rather than making
this work the same as \g?)
* SendQuery'
2012-10-14 22:26 keltezéssel, Boszormenyi Zoltan írta:
2012-10-14 22:23 keltezéssel, Boszormenyi Zoltan írta:
Hi,
2012-10-14 18:41 keltezéssel, Boszormenyi Zoltan írta:
2012-10-14 18:02 keltezéssel, Fujii Masao írta:
Thanks for updating the patch!
On Sun, Oct 14, 2012 at 8:41 PM, Boszormenyi
2012-10-14 22:23 keltezéssel, Boszormenyi Zoltan írta:
Hi,
2012-10-14 18:41 keltezéssel, Boszormenyi Zoltan írta:
2012-10-14 18:02 keltezéssel, Fujii Masao írta:
Thanks for updating the patch!
On Sun, Oct 14, 2012 at 8:41 PM, Boszormenyi Zoltan wrote:
Backing up a standby server without -R
Hi,
2012-10-14 18:41 keltezéssel, Boszormenyi Zoltan írta:
2012-10-14 18:02 keltezéssel, Fujii Masao írta:
Thanks for updating the patch!
On Sun, Oct 14, 2012 at 8:41 PM, Boszormenyi Zoltan wrote:
Backing up a standby server without -R preserves the original recovery.conf
of the
standby, it
Hi Pavel,
On Sat, Oct 13, 2012 at 12:58 AM, Pavel Stehule
wrote:
* merge Shigeru's doc patch
* rename psql regression test from "psql" to "psql_cmd"
Those changes seem good.
Besides, I found an error message which doesn't end with '¥n' in
common.c. In general, messages passed to psql_erro
Hello
2012/10/14 Erik Rijkers :
> On Sat, October 13, 2012 19:26, Pavel Stehule wrote:
>> 2012/10/13 Shigeru HANADA :
>>> After you determine whether it's ok or unnecessary, I'll mark this patch as
>>> "Ready for committer".
>>>
>>
>
> I found this behaviour which I think must count as a bug.
> \g
On Oct 14, 2012, at 12:35 PM, Tom Lane wrote:
> Simon Riggs writes:
>> On 12 October 2012 19:48, Greg Stark wrote:
>>> On Fri, Oct 12, 2012 at 7:55 AM, Simon Riggs wrote:
AFAICS all RULEs can be re-expressed as Triggers or Views.
>
>>> This is a bizarre discussion. Firstly this isn't eve
On 14 October 2012 19:17, Tom Lane wrote:
> Anyway, the simplest working solution proved to be to put the
> InitializeLatchSupport calls in InitProcess and InitAuxiliaryProcess,
> plus add them in a few background process types that use InitLatch but
> don't call either of those functions. Patch
I wrote:
> Sean Chittenden recently reported that 9.2 can crash after logging
> "FATAL: pipe() failed" if the kernel is short of file descriptors:
> http://archives.postgresql.org/pgsql-general/2012-10/msg00202.php
> ...
> What I think would be a better idea is to fix things so that OwnLatch
> cann
On 14 October 2012 17:47, Tom Lane wrote:
> Simon Riggs writes:
>> As discussed on other threads, Hash Indexes are currently a broken
>> feature and bring us into disrepute.
>
> Yeah ...
>
>> Suggested actions are
>
> I find it curious that you don't even bother to list "add WAL support to
> hash
Gilles Darold writes:
> Restoring a backup generated with pg_dump/pg_dumpall in plain text
> format and the --clean option will report errors if the backup is loaded
> in an other or empty database.
This is intentional. What you propose amounts to a fundamental change
in the semantics of --clean
Simon Riggs writes:
> As discussed on other threads, Hash Indexes are currently a broken
> feature and bring us into disrepute.
Yeah ...
> Suggested actions are
I find it curious that you don't even bother to list "add WAL support to
hash indexes" as a possible solution. It's certainly doable,
Satoshi Nagayasu writes:
> (2012/10/14 13:26), Fujii Masao wrote:
>> The tracing lwlock usage seems to still cause a small performance
>> overhead even if reporting is disabled. I believe some users would
>> prefer to avoid such overhead even if pg_stat_lwlocks is not available.
>> It should be up
2012-10-14 18:02 keltezéssel, Fujii Masao írta:
Thanks for updating the patch!
On Sun, Oct 14, 2012 at 8:41 PM, Boszormenyi Zoltan wrote:
Backing up a standby server without -R preserves the original recovery.conf
of the
standby, it points to the standby's source server.
Backing up a standby
Simon Riggs writes:
> On 12 October 2012 19:48, Greg Stark wrote:
>> On Fri, Oct 12, 2012 at 7:55 AM, Simon Riggs wrote:
>>> AFAICS all RULEs can be re-expressed as Triggers or Views.
>> This is a bizarre discussion. Firstly this isn't even close to true.
>> The whole source of people's discont
On Mon, Oct 15, 2012 at 12:57 AM, Boszormenyi Zoltan wrote:
> 2012-10-11 02:02 keltezéssel, Fujii Masao írta:
>
>> On Thu, Oct 11, 2012 at 3:36 AM, Boszormenyi Zoltan
>> wrote:
>>>
>>> 2012-10-10 18:23 keltezéssel, Fujii Masao írta:
When tar output format is specified together with -R o
Thanks for updating the patch!
On Sun, Oct 14, 2012 at 8:41 PM, Boszormenyi Zoltan wrote:
> Backing up a standby server without -R preserves the original recovery.conf
> of the
> standby, it points to the standby's source server.
>
> Backing up a standby server with -R overwrites the original rec
2012-10-11 02:02 keltezéssel, Fujii Masao írta:
On Thu, Oct 11, 2012 at 3:36 AM, Boszormenyi Zoltan wrote:
2012-10-10 18:23 keltezéssel, Fujii Masao írta:
When tar output format is specified together with -R option, recovery.conf
is
not included in base.tar. I think it should.
Why? This patc
On 14 October 2012 09:19, Simon Riggs wrote:
> This is a very useful optimisation, for both the low and the high end.
I suppose it's possible to not think of it as an optimisation at all.
Rather, it could be considered a way of making tuplesort really use
the work_mem allotted to it, or at least
Hello,
Restoring a backup generated with pg_dump/pg_dumpall in plain text
format and the --clean option will report errors if the backup is loaded
in an other or empty database. I mean that the backup file contains all
SQL order to drop the database's objects before recreating them, so if
you load
On 10/14/2012 09:45 AM, Simon Riggs wrote:
As discussed on other threads, Hash Indexes are currently a broken
feature and bring us into disrepute.
I describe them as broken because they are neither crash safe, nor
could they properly be called unlogged indexes (or if so, why just
hash?). And al
On Sun, Oct 14, 2012 at 7:52 PM, Satoshi Nagayasu wrote:
> (2012/10/14 13:26), Fujii Masao wrote:
>>
>> On Sun, Oct 14, 2012 at 10:46 AM, Satoshi Nagayasu
>> wrote:
>>>
>>> HEAD
>>>
>>> number of transactions actually processed: 3439971
>>> tps = 57331.891602 (including connections establish
As discussed on other threads, Hash Indexes are currently a broken
feature and bring us into disrepute.
I describe them as broken because they are neither crash safe, nor
could they properly be called unlogged indexes (or if so, why just
hash?). And also because if somebody suggested implementing
2012-10-12 22:21 keltezéssel, Robert Haas írta:
On Wed, Oct 10, 2012 at 8:02 PM, Fujii Masao wrote:
On Thu, Oct 11, 2012 at 3:36 AM, Boszormenyi Zoltan wrote:
2012-10-10 18:23 keltezéssel, Fujii Masao írta:
When tar output format is specified together with -R option, recovery.conf
is
not inc
(2012/10/14 13:26), Fujii Masao wrote:
On Sun, Oct 14, 2012 at 10:46 AM, Satoshi Nagayasu wrote:
HEAD
number of transactions actually processed: 3439971
tps = 57331.891602 (including connections establishing)
tps = 57340.932324 (excluding connections establishing)
pg_stat_lwlocks patch
On 12 October 2012 20:07, Robert Haas wrote:
> On Thu, Oct 11, 2012 at 3:37 PM, Simon Riggs wrote:
>> On 11 October 2012 20:30, Robert Haas wrote:
>>> On Thu, Oct 11, 2012 at 2:42 PM, Andrew Dunstan wrote:
I have a quietish few days starting on Saturday, will be looking at this
then.
On 13 October 2012 21:15, Joshua Berkus wrote:
> Simon,
>
>> I think its sad we can't even attempt a technical conversation
>> without
>> you making snide ad hominem attacks that aren't even close to being
>> true on a personal level, nor accurate in a technical sense.
>
> I would prefer it if you
On Sun, Oct 14, 2012 at 5:59 AM, Daniel Farina wrote:
> On Sat, Oct 13, 2012 at 7:00 AM, Andrew Dunstan wrote:
>> Does Debian they create a self-signed certificate? If so, count me as
>> unimpressed. I'd argue that's worse than doing nothing. Here's what the docs
>> say (rightly) about such certi
On 12 October 2012 19:48, Greg Stark wrote:
> On Fri, Oct 12, 2012 at 7:55 AM, Simon Riggs wrote:
>> AFAICS all RULEs can be re-expressed as Triggers or Views.
>
> This is a bizarre discussion. Firstly this isn't even close to true.
> The whole source of people's discontentment is that triggers a
On 17 August 2012 00:26, Peter Geoghegan wrote:
> This patch works by not doubling the size of state->memtupsize when
> available memory is less than half of allowed memory (i.e. we are one
> call to grow_memtuples() away from reporting ). Rather, in that
> situation, it is set to a size that ext
45 matches
Mail list logo
