Hi Marko,
On Wed, Jan 30, 2013 at 2:07 AM, Marko Tiikkaja wrote:
> On Tue, 29 Jan 2013 10:18:51 +0100, Jeevan Chalke <
> jeevan.chalke@enterprisedb.**com > wrote:
>
>> That's fine. I am not at all pointing that to you. Have a look at this:
>>
>
> Here's the third version of this patch, hopefull
30.01.2013 05:51, Noah Misch wrote:
On Tue, Jan 29, 2013 at 09:54:04AM -0500, Tom Lane wrote:
Alexander Law writes:
Please look at the following l10n bug:
http://www.postgresql.org/message-id/502a26f1.6010...@gmail.com
and the proposed patch.
That patch looks entirely unsafe to me. Neither o
>>> I don't think I like --force because it isn't clear if we are forcing
>>> the start to have done something, or forcing the server to be running.
>
> Do we need this idempotent feature for "stop" too?
Yes, of course.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent vi
On Wed, 2013-01-16 at 14:35 +0530, Jeevan Chalke wrote:
> However, I think you need to add this in docs. Letting people know
> about this environment variable to make use of that.
Done and committed. Thanks.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make change
Satoshi Nagayasu writes:
> First of all, I was looking for some regression tests for
> CREATE/ALTER/DROP DATABASE commands, but I couldn't find them
> in the test/regress/sql/ directory. So, I asked the question.
> I guess these database tests are in pg_regress.c. Right?
Yeah, we don't bother wi
(2013/01/30 0:34), Tom Lane wrote:
> Satoshi Nagayasu writes:
>>> On Mon, 2013-01-07 at 07:14 -0500, Peter Eisentraut wrote:
Here is a patch for psql's \l command to accept patterns, like \d
>
>> BTW, is there any good place to put new regression test for the psql
>> command? I couldn't find
On Mon, Jan 28, 2013 at 07:24:04PM +0530, Pavan Deolasee wrote:
> On Wed, Jan 23, 2013 at 10:05 AM, Noah Misch wrote:
>
> > You're the second commentator to be skittish about the patch's correctness,
> > so
> > I won't argue against a conservatism-motivated bounce of the patch.
>
> Can you plea
On Tue, Jan 29, 2013 at 09:54:04AM -0500, Tom Lane wrote:
> Alexander Law writes:
> > Please look at the following l10n bug:
> > http://www.postgresql.org/message-id/502a26f1.6010...@gmail.com
> > and the proposed patch.
>
> That patch looks entirely unsafe to me. Neither of those functions
> sh
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
I wrote:
> Over in the thread about enhanced error fields, I claimed that
> "constraints are uniquely named among those associated with a table,
> or with a domain". But it turns out that that ain't necessarily so,
> because the code path for index constraints doesn't pay any attention
> to pre-ex
"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 has been about making its behavior more deterministic not le
On 01/29/2013 10:10 PM, Simon Riggs wrote:
> On 29 January 2013 13:30, Kohei KaiGai wrote:
>
>> It makes unavailable to control execution of
>> functions from viewpoint of selinux, and here is no way selinux
>> to prevent to execute functions defined by other domains, or
>> others being not permit
Hi,
Please find attached v2 of the Extension Templates patch, with pg_dump
support and assorted fixes. It's still missing ALTER RENAME and OWNER
facilities, and owner in the dump. There's a design point I want to
address with some input before getting there, though. Hence this email.
Dimitri Font
All,
It's perhaps not the ideal time for a discussion but if I thought it would
turn into a long discussion then I'd probably not post this due to the
current timing in the release cycle.
This is something I thought of while doing a restore on a 40ish GB database
which has a few hundred smallish t
Robert Haas writes:
> On Tue, Jan 29, 2013 at 2:30 PM, Alvaro Herrera
>> Robert, are you working on this?
> I wasn't, but I can, if we agree on it.
I think we need to do *something* (and accordingly have added this to
the 9.3 open items page so we don't forget about it). Whether Robert's
idea i
Christopher Browne writes:
> Hmm. I think some information about the object is pretty needful.
>
> For the immediate case I'm poking at, namely looking for dropped tables,I
> could determine that which object is gone by inference; if I run the trigger
> as part of the ddl_command_end event, then
On Tue, Jan 29, 2013 at 2:30 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Tue, Jan 15, 2013 at 3:22 PM, Tom Lane wrote:
>> > Robert Haas writes:
>> >> Or perhaps there is some other way to make sure that the user "really
>> >> meant it", like refusing to create in pg_catalog unless th
I wrote:
> Here's an updated patch (code only, sans documentation) that fixes that
> and adds some other refactoring that I thought made for improvements.
> I think this is ready to commit except for the documentation.
Pushed with documentation.
regards, tom lane
--
Sen
On Tue, Jan 29, 2013 at 04:34:50PM -0500, Peter Eisentraut wrote:
> On 1/28/13 9:29 PM, Bruce Momjian wrote:
> > pg_upgrade uses that to find out of the server was already running or if
> > we started it. This is to start the server to remove the
> > postmaster.pid file.
>
> It's currently a bit
On 1/28/13 9:29 PM, Bruce Momjian wrote:
> pg_upgrade uses that to find out of the server was already running or if
> we started it. This is to start the server to remove the
> postmaster.pid file.
It's currently a bit missed up anyway. pg_ctl start is successful if
the server is already started
Robert Haas escribió:
> On Tue, Jan 15, 2013 at 3:22 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> Or perhaps there is some other way to make sure that the user "really
> >> meant it", like refusing to create in pg_catalog unless the schema
> >> name is given explicitly. I kind of like that i
Heikki Linnakangas wrote:
> Tolerate timeline switches while "pg_basebackup -X fetch" is running.
I just noticed that this commit introduced a few error messages that
have a file argument which is not properly quoted:
+ ereport(ERROR,
+ (errcode_for_file_access(),
+
I wrote:
> Rather what we've got is that constraints are uniquely named among
> those associated with a table, or with a domain. So the correct
> unique key for a table constraint is table schema + table name +
> constraint name, whereas for a domain constraint it's domain schema +
> domain name +
2013/1/29 Peter Geoghegan :
> On 29 January 2013 17:05, Pavel Stehule wrote:
>>> Perhaps I'm mistaken, but I can't imagine that it would be terribly
>>> useful to anyone (including Pavel) to have a GET DIAGNOSTICS style
>>> ROUTINE_NAME.
>>
>> I hoped so I can use it inside exception handler
>
> R
2013/1/29 Dean Rasheed :
> On 28 January 2013 20:32, Dean Rasheed wrote:
>> In general a format specifier looks like:
>>
>> %[parameter][flags][width][.precision][length]type
>>
>
> This highlights another problem with the current implementation ---
> the '-' flag and the width field need to be pa
2013/1/28 Tom Lane :
> Dean Rasheed writes:
>> On 28 January 2013 20:40, Pavel Stehule wrote:
>>> 2013/1/28 Dean Rasheed :
flags - not currently implemented. Pavel's second patch adds support
for the '-' flag for left justified string output. However, I think
this should support al
2013/1/28 Tom Lane :
> Pavel Stehule writes:
>> 2013/1/28 Dean Rasheed :
>>> Starting with the first patch - it issues a new WARNING if the format
>>> string contains a mixture of format specifiers with and without
>>> parameter indexes (e.g., 'Hello %s, %1$s').
>>>
>>> Having thought about it a b
On 29 January 2013 17:05, Pavel Stehule wrote:
>> Perhaps I'm mistaken, but I can't imagine that it would be terribly
>> useful to anyone (including Pavel) to have a GET DIAGNOSTICS style
>> ROUTINE_NAME.
>
> I hoped so I can use it inside exception handler
Right, but is that really any use to yo
2013/1/28 Peter Geoghegan :
> On 28 January 2013 21:33, Peter Eisentraut wrote:
>> Another point, in case someone wants to revisit this in the future, is
>> that these fields were applied in a way that is contrary to the SQL
>> standard, I think.
>>
>> The presented patch interpreted ROUTINE_NAME
On Mon, Jan 28, 2013 at 6:19 PM, Dimitri Fontaine
wrote:
> Christopher Browne writes:
>> I'm poking at event triggers a bit; would like to set up some examples
>> (and see if they
>> work, or break down badly; both are interesting results) to do some
>> validation of schema
>> for Slony.
>
> Cool
2013/1/27 Tom Lane :
> Peter Geoghegan writes:
>> On 26 January 2013 22:36, Tom Lane wrote:
>>> BTW, one thing that struck me in a quick look-through is that the
>>> ERRCODE_FOREIGN_KEY_VIOLATION patches seem to inconsistently send
>>> either the PK or FK rel as the "errtable". Is this really pe
On Tue, Jan 29, 2013 at 3:12 AM, Alvaro Herrera
wrote:
> Phil Sorber escribió:
>> On Mon, Jan 28, 2013 at 11:20 AM, Fujii Masao wrote:
>> > Maybe. But I'm not inclined to add new libpq interface at this stage.
>> > Because we are in the last CommitFest and I'm not sure whether
>> > we have enough
Bruce Momjian writes:
> pg_upgrade uses that to find out of the server was already running or if
> we started it. This is to start the server to remove the
> postmaster.pid file. Also, no one has explained how not knowing if -o
> options were used was a safe.
What happened to the plan for pg_up
On Sun, Jan 27, 2013 at 11:38 PM, MauMau wrote:
> From: "Fujii Masao"
>>
>> On Sun, Jan 27, 2013 at 12:17 AM, MauMau wrote:
>>>
>>> Although you said the fix will solve my problem, I don't feel it will.
>>> The
>>> discussion is about the crash when the standby "re"starts after the
>>> primary
>
Please find attached the complete patch for alter rename rule. I have
followed all the suggestions. Followings things are added in this updated
patch:
1) Disallow alter rename of ON SELECT rules.
2) Remove warning.
3) Varibles are lined up.
4) Used qualified_name instead of makeRangeVarFromAnyName.
Satoshi Nagayasu writes:
>> On Mon, 2013-01-07 at 07:14 -0500, Peter Eisentraut wrote:
>>> Here is a patch for psql's \l command to accept patterns, like \d
> BTW, is there any good place to put new regression test for the psql
> command? I couldn't find it out.
As far as a test for this specifi
Hi,
I have tried this patch.
https://commitfest.postgresql.org/action/patch_view?id=1051
2013/01/29 14:48, Peter Eisentraut wrote:
On Mon, 2013-01-07 at 07:14 -0500, Peter Eisentraut wrote:
Here is a patch for psql's \l command to accept patterns, like \d
commands do. While at it, I also add
On 29 January 2013 14:39, Kohei KaiGai wrote:
> 2013/1/29 Simon Riggs :
>> On 29 January 2013 13:30, Kohei KaiGai wrote:
>>
>>> It makes unavailable to control execution of
>>> functions from viewpoint of selinux, and here is no way selinux
>>> to prevent to execute functions defined by other dom
Alexander Law writes:
> Please look at the following l10n bug:
> http://www.postgresql.org/message-id/502a26f1.6010...@gmail.com
> and the proposed patch.
That patch looks entirely unsafe to me. Neither of those functions
should be expected to be able to run when none of our standard
infrastruct
2013/1/29 Simon Riggs :
> On 29 January 2013 13:30, Kohei KaiGai wrote:
>
>> It makes unavailable to control execution of
>> functions from viewpoint of selinux, and here is no way selinux
>> to prevent to execute functions defined by other domains, or
>> others being not permitted.
>> Also, what
On 1/28/13 11:08 PM, Tom Lane wrote:
> The issue is that
> this definition presupposes that we want to complain about a table or
> a domain, never both, because we're overloading both the SCHEMA_NAME
> and CONSTRAINT_NAME fields for both purposes. This is annoying in
> validateDomainConstraint(),
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 made
> better,
> > so that we don't need to change the encoding approach, as I am having
> > feeling that this might not be perf
On 29 January 2013 13:30, Kohei KaiGai wrote:
> It makes unavailable to control execution of
> functions from viewpoint of selinux, and here is no way selinux
> to prevent to execute functions defined by other domains, or
> others being not permitted.
> Also, what we want to do is almost same as
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Peter Geoghegan writes:
> > I can see the case for fixing this, but I don't feel that it's
> > particularly important that constraints be uniquely identifiable from
> > the proposed new errdata fields.
>
> I think that we'll soon be buried in gripes if the
2013/1/29 Simon Riggs :
> On 15 January 2013 20:28, Kohei KaiGai wrote:
>
>> This patch adds sepgsql support for permission checks equivalent
>> to the existing SCHEMA USE privilege.
>>
>> This feature is constructed on new OAT_SCHEMA_SEARCH event
>> type being invoked around pg_namespace_aclcheck
On Tue, Jan 29, 2013 at 04:19:15PM +1100, Josh Berkus wrote:
>
> > OK, I had some time to think about this. Basically, we have three
> > outcomes for pg_ctl start:
> >
> > server not running and pg_ctl start success
> > server start failed
> > server already running
> >
> > Can't we
Hi Heikki,
On Mon, Jan 28, 2013 at 2:34 PM, Heikki Linnakangas wrote:
> On 23.01.2013 17:30, Robert Haas wrote:
>
>> On Wed, Jan 23, 2013 at 4:04 AM, Jeevan Chalke
>> >
>> wrote:
>>
>>> I guess my earlier patch, which was directly incrementing
>>>
>>> ControlFile->unloggedLSN counter was the c
On 15 January 2013 20:28, Kohei KaiGai wrote:
> This patch adds sepgsql support for permission checks equivalent
> to the existing SCHEMA USE privilege.
>
> This feature is constructed on new OAT_SCHEMA_SEARCH event
> type being invoked around pg_namespace_aclcheck().
Can you explain the exact d
On 29.01.2013 11:58, Amit Kapila wrote:
Can there be another way with which current patch code can be made better,
so that we don't need to change the encoding approach, as I am having
feeling that this might not be performance wise equally good.
The point is that I don't want to heap_delta_enc
On Thu, Jan 24, 2013 at 7:04 AM, Hari Babu wrote:
> On Wed, Jan 23, 2013 11:48 PM, Magnus Hagander wrote:
>>On Wed, Jan 23, 2013 at 10:18 AM, Hari Babu
> wrote:
>>> Test scenario to reproduce:
>>> 1. Start the server
>>> 2. create the user as follows
>>> ./psql pos
On 28.01.2013 23:30, Gurjeet Singh wrote:
On Sat, Jan 26, 2013 at 11:24 PM, Satoshi Nagayasu wrote:
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
On Tuesday, January 29, 2013 2:53 AM Heikki Linnakangas wrote:
> On 28.01.2013 15:39, Amit Kapila wrote:
> > Rebased the patch as per HEAD.
>
> I don't like the way heap_delta_encode has intimate knowledge of how
> the lz compression works. It feels like a violent punch through the
> abstraction l
On 1/29/13 10:18 AM, Jeevan Chalke wrote:
That's fine. I am not at all pointing that to you. Have a look at this:
Ugh.. I'm sorry, I don't understand how this happened. I manually
looked through all the changes, but somehow this slipped through. Will
have a look this evening.
Regards,
Hi Marko,
On Mon, Jan 28, 2013 at 5:01 PM, Marko Tiikkaja wrote:
> On 1/28/13 12:14 PM, Jeevan Chalke wrote:
>
>> I could not apply the patch with git apply, but able to apply it by patch
>> -p1 command.
>>
>
> IME that's normal for patches that went through filterdiff. I do: git
> diff |filte
On 29.01.2013 04:41, Robert Haas wrote:
On Mon, Jan 28, 2013 at 8:39 AM, Heikki Linnakangas
wrote:
We already have that MyXactAccessedTempRel global flag. Just checking that
should cover many common cases.
+1 for that. I'm actually unconvinced that we need to do any better
than that in gene
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, but of course a width of 0 is the same a
On 28 January 2013 20:32, Dean Rasheed wrote:
> In general a format specifier looks like:
>
> %[parameter][flags][width][.precision][length]type
>
This highlights another problem with the current implementation ---
the '-' flag and the width field need to be parsed separately. So
'%-3s' should be
57 matches
Mail list logo
