Hello
>
> Personally, on the face of it I'd expect the "inconsistency" to simply
> reflect the fact that the error related to the referencing table or
> referenced table. Pavel's original patch followed the same convention
> (though it also had a constraint_table field). I'm having a hard time
> f
Hi,
I just reviewed this patch.
https://commitfest.postgresql.org/action/patch_view?id=1035
2013/1/13 Greg Smith :
> On 12/26/12 7:23 PM, Greg Stark wrote:
>>
>> It's also possible it's a bad cpu, not bad memory. If it affects
>> decrement or increment in particular it's possible that the patter
Hello
>From my perspective - the core of this patch has two parts
a) necessary infrastructure
b) enhancing current ereport calls
@a point is important for me and plpgsql coders, because it allows
using these fields in custom PL/pgSQL exception - and errors
processing in this language can be more
On Thu, Jan 24, 2013 at 9:31 PM, Jeff Janes wrote:
> On Thu, Jan 24, 2013 at 1:28 AM, Pavan Deolasee
> wrote:
>>
>> Good idea. Even though the cost of pinning/unpinning may not be high
>> with respect to the vacuum cost itself, but it seems to be a good idea
>> because we already do that at othe
On Sun, Jan 27, 2013 at 1:41 PM, Robert Haas wrote:
> On Sat, Jan 26, 2013 at 9:49 PM, Michael Paquier
> wrote:
> > On Sun, Jan 27, 2013 at 7:14 AM, Phil Sorber wrote:
> >>
> >> On Wed, Jan 23, 2013 at 6:36 AM, Michael Paquier
> >> wrote:
> >> >
> >> > On 2013/01/23, at 18:12, Simon Riggs wro
On Sunday, January 27, 2013 10:07 AM Robert Haas wrote:
On Sat, Jan 26, 2013 at 6:47 PM, Craig Ringer wrote:
> On 01/27/2013 01:01 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Thu, Jan 24, 2013 at 12:39 PM, Andres Freund
>>> wrote:
> More people seem to have voted for the single file a
Hi
I found the ecpg programs can not output the native language messages which
defined in ecpglib6-9.x.mo.
The reason is a misstake in "src/interfaces/ecpg/ecpglib/misc.c",
and i mad a patch for that.
Chen Huajun
diff --git a/postgresql-9.1.4org/src/interfaces/ecpg/ecpglib/misc.c
b/postgresql-9
On Sat, Jan 26, 2013 at 9:49 PM, Michael Paquier
wrote:
> On Sun, Jan 27, 2013 at 7:14 AM, Phil Sorber wrote:
>>
>> On Wed, Jan 23, 2013 at 6:36 AM, Michael Paquier
>> wrote:
>> >
>> > On 2013/01/23, at 18:12, Simon Riggs wrote:
>> >
>> >> On 23 January 2013 04:49, Michael Paquier
>> >> wrote:
On Fri, Jan 25, 2013 at 11:58 AM, Dimitri Fontaine
wrote:
> My understanding is that if the command string we give to event triggers
> is ambiguous (sub-object names, schema qualifications, etc), it comes
> useless for logical replication use. I'll leave it to the consumers of
> that to speak up n
On Sat, Jan 26, 2013 at 6:47 PM, Craig Ringer wrote:
> On 01/27/2013 01:01 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Thu, Jan 24, 2013 at 12:39 PM, Andres Freund
>>> wrote:
More people seem to have voted for the single file approach but I still
haven't understood why...
>>> Me
On Fri, Jan 25, 2013 at 2:59 PM, Kohei KaiGai wrote:
> 2013/1/20 Tom Lane :
>> Robert Haas writes:
>>> Yeah. We'd need to think a little bit about how to make this work,
>>> since I think that adding a gajillion booleans to pg_authid will not
>>> make anyone very happy. But I like the idea. GR
On Sat, Oct 20, 2012 at 2:43 AM, Abhijit Menon-Sen wrote:
> At 2012-10-15 10:28:17 -0400, robertmh...@gmail.com wrote:
>>
>> > Is there any concise description that applies? […]
>>
>> I don't think there is. I think we need to replace those counters
>> with something better. The status quo is qu
On Fri, Jan 25, 2013 at 9:35 PM, Jeff Davis wrote:
> On Fri, 2013-01-25 at 15:29 -0500, Robert Haas wrote:
>> I thought Simon had the idea, at some stage, of writing a WAL record
>> to cover hint-bit changes only at the time we *write* the buffer and
>> only if no FPI had already been emitted that
Hi,
I have reviewed this patch.
https://commitfest.postgresql.org/action/patch_view?id=1068
2012/12/21 Gurjeet Singh :
> The patch is very much what you had posted, except for a couple of
> differences due to bit-rot. (i) I didn't have to #define MAX_RANDOM_VALUE64
> since its cousin MAX_RAN
On Sat, Jan 26, 2013 at 7:00 AM, Francois Tigeot wrote:
> On Fri, Jan 25, 2013 at 05:55:19PM -0500, Robert Haas wrote:
>> On Fri, Jan 25, 2013 at 9:38 AM, Francois Tigeot
>> wrote:
>> >
>> > Some links with more details about improvements and final results:
>> > http://www.shiningsilence.com/dbs
On 26 January 2013 22:36, Tom Lane wrote:
> I started to look this patch over. I think we can get to something
> committable from here, but I'm having a problem with the concept that
> we're going to "guarantee" anything about which additional fields might
> be available for any given SQLSTATE.
Hi Peter,
I took a look at this patch and the benchmarks you've furnished:
https://github.com/petergeoghegan/commit_delay_benchmarks
http://pgeoghegan.blogspot.com/2012/06/towards-14000-write-transactions-on-my.html
On Wed, Nov 14, 2012 at 08:44:26PM +, Peter Geoghegan wrote:
> Attached is
On 01/27/2013 08:11 AM, Craig Ringer wrote:
> On my VS Express 2010 SP1:
>
> Setting environment for using Microsoft Visual Studio 2010 x86 tools.
>
> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC>vcvarsall.bat /?
> Error in script usage. The correct usage is:
> vcvarsall.bat [optio
On 01/27/2013 08:16 AM, Phil Sorber wrote:
>
> Craig Ringer wrote:
> > That's what it sounds like - confirming that PostgreSQL is really fully
> > shut down.
> >
> > I'm not sure how you could do that over a protocol connection, myself.
> > I'd just read the postmaster pid from the pidfile on disk
On Jan 26, 2013 6:56 PM, "Craig Ringer" wrote:
>
> On 01/27/2013 06:20 AM, Phil Sorber wrote:
> > On Sat, Jan 26, 2013 at 4:37 PM, Pavel Stehule
wrote:
> >> 2013/1/26 Phil Sorber :
> >>> On Sat, Jan 26, 2013 at 12:39 PM, Pavel Stehule <
pavel.steh...@gmail.com> wrote:
> 2013/1/26 Phil Sorber
On 01/26/2013 03:39 PM, Andrew Dunstan wrote:
>
> On 01/26/2013 12:38 AM, Craig Ringer wrote:
>> On 01/25/2013 08:25 PM, Noah Misch wrote:
That should be clearer, that 64-bit support exists but is absent
(AFAIK)
from Express editions.
>>> Build farm member "chough" builds 64-bit usin
On 01/27/2013 06:20 AM, Phil Sorber wrote:
> On Sat, Jan 26, 2013 at 4:37 PM, Pavel Stehule
> wrote:
>> 2013/1/26 Phil Sorber :
>>> On Sat, Jan 26, 2013 at 12:39 PM, Pavel Stehule
>>> wrote:
2013/1/26 Phil Sorber :
> On Sat, Jan 26, 2013 at 11:53 AM, Pavel Stehule
> wrote:
>>
On 01/27/2013 01:01 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jan 24, 2013 at 12:39 PM, Andres Freund
>> wrote:
>>> More people seem to have voted for the single file approach but I still
>>> haven't understood why...
>> Me neither. Having an include directory seems good, but I can't
> -Original Message-
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Sent: 26 January 2013 20:12
> Subject: Re: [HACKERS] plpgsql_check_function - rebase for 9.3
>
> I wrote:
> > [ pokes around... ] Hm, it appears that that does work on Linux,
> > because for some reason we're specifying R
On 01/27/2013 12:04 AM, james wrote:
>> So, while no native 64-bit compilers are available for free as part of
>> Visual Studio Express 2012 (11), it doesn't matter much. The issue is
>> more that it's very much Microsoft's whim whether they release compilers
>> at all and if so, which ones, when a
On Sun, Jan 27, 2013 at 1:52 AM, Andres Freund wrote:
> On 2013-01-25 13:48:50 +0900, Michael Paquier wrote:
> > All the comments are addressed in version 8 attached, except for the
> > hashtable part, which requires some heavy changes.
> >
> > On Thu, Jan 24, 2013 at 3:41 AM, Andres Freund >wrot
Peter Geoghegan writes:
> [ eelog6.patch ]
> So, with the question of what fields to include and whether constraint
> name needs to be unambiguously resolvable addressed (I think), it
> appears that I've brought this one as far as I can. I'd still like to
> get input from a Perl hacker, but I thin
On Sun, Jan 27, 2013 at 1:37 AM, Andres Freund wrote:
> On 2013-01-25 14:11:39 +0900, Michael Paquier wrote:
>
> It sure isn't optimal, but it should do the trick if you use the
> hash_seq stuff to iterate the hash afterwards. And you could use it to
> map to the respective locks et al.
>
> If you
On Sat, Jan 26, 2013 at 4:37 PM, Pavel Stehule wrote:
> 2013/1/26 Phil Sorber :
>> On Sat, Jan 26, 2013 at 12:39 PM, Pavel Stehule
>> wrote:
>>> 2013/1/26 Phil Sorber :
On Sat, Jan 26, 2013 at 11:53 AM, Pavel Stehule
wrote:
> 2013/1/26 Phil Sorber :
>> On Sat, Jan 26, 2013 at
On Wed, Jan 23, 2013 at 6:36 AM, Michael Paquier
wrote:
>
> On 2013/01/23, at 18:12, Simon Riggs wrote:
>
>> On 23 January 2013 04:49, Michael Paquier wrote:
>>
>>> - recovery.conf is removed (no backward compatibility in this version of the
>>> patch)
>>
>> If you want to pursue that, you know
On Fri, Jan 25, 2013 at 01:00:59AM -0500, Kevin Grittner wrote:
> Noah Misch wrote:
> > > *** a/contrib/sepgsql/sepgsql.h
> > > --- b/contrib/sepgsql/sepgsql.h
> > > ***
> > > *** 32,37
> > > --- 32,39
> > >
> > > /*
> > > * Internally used code of object classes
> > > + *
>
On Fri, Jan 25, 2013 at 01:54:06PM -0500, Peter Eisentraut wrote:
> On 1/12/13 3:30 PM, Aaron W. Swenson wrote:
> > The Linux Standard Base Core Specification 3.1 says this should return
> > '3'. [1]
> >
> > [1]
> > http://refspecs.freestandards.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/ini
2013/1/26 Phil Sorber :
> On Sat, Jan 26, 2013 at 12:39 PM, Pavel Stehule
> wrote:
>> 2013/1/26 Phil Sorber :
>>> On Sat, Jan 26, 2013 at 11:53 AM, Pavel Stehule
>>> wrote:
2013/1/26 Phil Sorber :
> On Sat, Jan 26, 2013 at 4:02 AM, Pavel Stehule
> wrote:
>> Hello
>>
>
On 13-01-24 11:15 AM, Steve Singer wrote:
On 13-01-24 06:40 AM, Andres Freund wrote:
Fair enough. I am also working on a user of this infrastructure but that
doesn't help you very much. Steve Singer seemed to make some stabs at
writing an output plugin as well. Steve, how far did you get there?
On Sat, Jan 26, 2013 at 12:39 PM, Pavel Stehule wrote:
> 2013/1/26 Phil Sorber :
>> On Sat, Jan 26, 2013 at 11:53 AM, Pavel Stehule
>> wrote:
>>> 2013/1/26 Phil Sorber :
On Sat, Jan 26, 2013 at 4:02 AM, Pavel Stehule
wrote:
> Hello
>
> We now haw to solve small puppet iss
I wrote:
> [ pokes around... ] Hm, it appears that that does work on Linux,
> because for some reason we're specifying RTLD_GLOBAL to dlopen().
> TBH that seems like a truly horrid idea that we should reconsider.
A bit of research in the archives revealed that we're using it because
back in 2001,
"Petr Jelinek" writes:
>> What exactly do you have in mind there? The way we load extensions, they
>> can't (AFAIK) see each other's defined symbols, so you couldn't really make
>> an independent extension that would call functions in plpgsql. This is not
>> really open for debate, either, as ch
2013/1/26 Petr Jelinek :
>> -Original Message-
>> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
>> ow...@postgresql.org] On Behalf Of Tom Lane
>> Sent: 26 January 2013 18:16
>> Subject: Re: [HACKERS] plpgsql_check_function - rebase for 9.3
>>
>> "Petr Jelinek" writes:
>>
On Fri, Jan 25, 2013 at 11:28:58PM -0500, Bruce Momjian wrote:
> On Fri, Jan 25, 2013 at 11:08:56PM -0500, Tom Lane wrote:
> > Bruce Momjian writes:
> > > ! ereport(ERROR,
> > > !
> > > (ERRCODE_OBJECT_NOT_IN_PREREQUI
On Thu, Jan 24, 2013 at 08:45:20PM -0500, Bruce Momjian wrote:
> On Sun, Sep 2, 2012 at 05:40:54PM +, ja...@illusorystudios.com wrote:
> > The following bug has been logged on the website:
> >
> > Bug reference: 7515
> > Logged by: James Bellinger
> > Email address: ja...@i
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Tom Lane
> Sent: 26 January 2013 18:16
> Subject: Re: [HACKERS] plpgsql_check_function - rebase for 9.3
>
> "Petr Jelinek" writes:
> > I was wondering if maybe this
2013/1/26 Phil Sorber :
> On Sat, Jan 26, 2013 at 11:53 AM, Pavel Stehule
> wrote:
>> 2013/1/26 Phil Sorber :
>>> On Sat, Jan 26, 2013 at 4:02 AM, Pavel Stehule
>>> wrote:
Hello
We now haw to solve small puppet issue, because our puppets try to
start server too early, when o
Hello
2013/1/26 Tom Lane :
> I wrote:
>> Pavel Stehule writes:
>>> [ gset_13.diff ]
>
>> One more gripe is that the parsing logic for \gset is pretty
>> unintelligible.
>
> After further thought, it seems to me that the problem here is an
> overcomplicated definition of the \gset command; it coul
Andrew Dunstan writes:
> +1. This looks quite nifty. Maybe useful too to have a default prefix
> via some setting.
Meh. I would expect that "\gset :foo" would work to specify a computed
prefix if you wanted it --- isn't that sufficient indirection? I'm not
thrilled with further expanding the s
"Petr Jelinek" writes:
> I was wondering if maybe this could be split to 2 separate patches, one would
> be all the changes to the existing plpgsql code - rename delete_function to
> plpgsql_delete_function and extern plpgsql_delete_function,
> copy_plpgsql_datum, plpgsql_estate_setup, plpgsql
Robert Haas writes:
> On Thu, Jan 24, 2013 at 12:39 PM, Andres Freund
> wrote:
>> More people seem to have voted for the single file approach but I still
>> haven't understood why...
> Me neither. Having an include directory seems good, but I can't think
> why we'd want to clutter it up with a
On 01/26/2013 11:42 AM, Tom Lane wrote:
A probably-useful extension to this basic concept is to allow \gset
to specify an optional prefix, that is
select 1 as x, 2 as y \gset p_
would set p_x and p_y. This would make it easier to manage results from
multiple \gset operations, and to be
On Sat, Jan 26, 2013 at 11:53 AM, Pavel Stehule wrote:
> 2013/1/26 Phil Sorber :
>> On Sat, Jan 26, 2013 at 4:02 AM, Pavel Stehule
>> wrote:
>>> Hello
>>>
>>> We now haw to solve small puppet issue, because our puppets try to
>>> start server too early, when old instance live still.
>>>
>>> Mayb
2013/1/26 Phil Sorber :
> On Sat, Jan 26, 2013 at 4:02 AM, Pavel Stehule
> wrote:
>> Hello
>>
>> We now haw to solve small puppet issue, because our puppets try to
>> start server too early, when old instance live still.
>>
>> Maybe some new parameter - is_done can be useful.
>>
>
> What about so
On 2013-01-25 13:48:50 +0900, Michael Paquier wrote:
> All the comments are addressed in version 8 attached, except for the
> hashtable part, which requires some heavy changes.
>
> On Thu, Jan 24, 2013 at 3:41 AM, Andres Freund wrote:
>
> > On 2013-01-15 18:16:59 +0900, Michael Paquier wrote:
> >
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Pavel Stehule
> Sent: 28 November 2012 11:07
> To: Selena Deckelmann
> Cc: PostgreSQL Hackers
> Subject: Re: [HACKERS] plpgsql_check_function - rebase for 9.3
>
> Hel
On Sat, Jan 26, 2013 at 4:02 AM, Pavel Stehule wrote:
> Hello
>
> We now haw to solve small puppet issue, because our puppets try to
> start server too early, when old instance live still.
>
> Maybe some new parameter - is_done can be useful.
>
What about something like:
pg_isready; while [ $? -n
I wrote:
> Pavel Stehule writes:
>> [ gset_13.diff ]
> One more gripe is that the parsing logic for \gset is pretty
> unintelligible.
After further thought, it seems to me that the problem here is an
overcomplicated definition of the \gset command; it could be made
both more usable and simpler t
On 2013-01-25 14:11:39 +0900, Michael Paquier wrote:
> On Thu, Jan 24, 2013 at 3:41 AM, Andres Freund wrote:
>
> > I think the usage of list_append_unique_oids in
> > ReindexRelationsConcurrently might get too expensive in larger
> > schemas. Its O(n^2) in the current usage and schemas with lots o
On Fri, 21 Dec 2012 16:14:19 +0100, I wrote:
I wrote a patch
which allows you to add STRICT into PERFORM and INSERT/UPDATE/DELETE
without specifying an INTO clause.
Here's the second version of the patch, addressing the syntax issues. I
also couldn't make the grammar work with PERFORM STRICT
On 2013-01-26 07:46:50 -0500, Robert Haas wrote:
> On Thu, Jan 24, 2013 at 12:39 PM, Andres Freund
> wrote:
> > More people seem to have voted for the single file approach but I still
> > haven't understood why...
>
> Me neither. Having an include directory seems good, but I can't think
> why w
So, while no native 64-bit compilers are available for free as part of
Visual Studio Express 2012 (11), it doesn't matter much. The issue is
more that it's very much Microsoft's whim whether they release compilers
at all and if so, which ones, when and how.
I think I have a pretty vanilla Visual
Robert Haas wrote:
> Andres Freund wrote:
>> More people seem to have voted for the single file approach but I still
>> haven't understood why...
>
> Me neither. Having an include directory seems good, but I can't think
> why we'd want to clutter it up with a bajillion automatically
> generated
From: "Fujii Masao"
On Thu, Jan 24, 2013 at 11:53 PM, MauMau wrote:
I'm wondering if the fix discussed in the above thread solves my problem.
I
found the following differences between Horiguchi-san's case and my case:
(1)
Horiguchi-san says the bug outputs the message:
WARNING: page 0 of r
On Sat, Jan 26, 2013 at 12:20:56PM +0800, Craig Ringer wrote:
> On 01/24/2013 01:13 PM, Craig Ringer wrote:
> > On 01/24/2013 11:28 AM, Craig Ringer wrote:
> >> On 01/24/2013 09:38 AM, Noah Misch wrote:
> >>> The most notable difference is that I have no pre-VS2012 Microsoft
> >>> compilers install
On Thu, Jan 24, 2013 at 12:39 PM, Andres Freund wrote:
> More people seem to have voted for the single file approach but I still
> haven't understood why...
Me neither. Having an include directory seems good, but I can't think
why we'd want to clutter it up with a bajillion automatically
generat
On Fri, Jan 25, 2013 at 05:55:19PM -0500, Robert Haas wrote:
> On Fri, Jan 25, 2013 at 9:38 AM, Francois Tigeot wrote:
> >
> > Some links with more details about improvements and final results:
> > http://www.shiningsilence.com/dbsdlog/2012/09/19/10403.html
> > http://www.shiningsilence.com/dbsdlo
On 10/10/2012 05:34 PM, Tom Lane wrote:
Hannu Krosing writes:
One way would be to check that we are in an any --> cstring
function - perhaps just by setting some static flag et entry and resetting
it at exit - and pass the original byte representation as "bytes" (or
string for py2.x)
Totally a
Hello
2012/12/31 Pavel Stehule :
> Hello
>
> 2012/12/31 Stephen Frost :
>> Pavel,
>>
>> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>>> A result from ours previous talk was a completely disabling mixing
>>> positional and ordered placeholders - like is requested by man and gcc
>>> raises warn
--On 25. Januar 2013 20:37:32 -0500 Tom Lane wrote:
Don't know how careful pgbtreecheck is. The pg_filedump output isn't
very helpful because you filtered away the flags, so we can't tell if
any of these pages are deleted. (If they are, the duplicate-looking
links might not be errors, sinc
Hello
We now haw to solve small puppet issue, because our puppets try to
start server too early, when old instance live still.
Maybe some new parameter - is_done can be useful.
Regards
Pavel
>>> When the conninfo string including the hostname or port number is
>>> specified in -d option, pg_i
66 matches
Mail list logo
