Robert Haas writes:
> On Tue, Feb 15, 2011 at 10:53 AM, Tom Lane wrote:
>> What risk? And at least we'd be trying to do it cleanly, in a manner
>> that should work for at least 99% of users. AFAICT, Heikki's proposal
>> is "break it for everyone, and damn the torpedoes".
> I must be confused.
Robert Haas writes:
> Those are good points. My point was just that you can't actually
> build that file at the time you RUN the regression tests, because you
> have to build it first, then install it, then run the regression
> tests. It could be a separate target, like 'make policy', but I don'
Robert Haas writes:
> Something along these lines would be OK with me (I haven't yet
> validated every detail), but there were previous objections to adding
> any new fields to log_line_prefix until we had a flexible CSV format.
> I think that's raising the bar a bit too high, personally, but I do
On Tue, Feb 15, 2011 at 10:53 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Feb 15, 2011 at 10:42 AM, Tom Lane wrote:
>>> I don't see any reason that the old version of the function couldn't be
>>> dropped in the upgrade script. It's not likely anything would be
>>> depending on it, is i
On Tue, Feb 15, 2011 at 10:50 AM, Andrew Dunstan wrote:
> On 02/15/2011 10:34 AM, Robert Haas wrote:
>> On Mon, Feb 14, 2011 at 9:55 PM, Tom Lane wrote:
>>> On the whole, I don't think that sepgsql-regtest.pp should be built or
>>> installed at all during the build phase. It ought to be generate
Robert Haas writes:
> On Tue, Feb 15, 2011 at 10:42 AM, Tom Lane wrote:
>> I don't see any reason that the old version of the function couldn't be
>> dropped in the upgrade script. It's not likely anything would be
>> depending on it, is it?
> I don't see much point in taking the risk.
What ri
On 02/15/2011 10:34 AM, Robert Haas wrote:
On Mon, Feb 14, 2011 at 9:55 PM, Tom Lane wrote:
On the whole, I don't think that sepgsql-regtest.pp should be built or
installed at all during the build phase. It ought to be generated
during regression test startup, instead.
You have to manually
On Tue, Feb 15, 2011 at 10:42 AM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> On 14.02.2011 21:49, Alvaro Herrera wrote:
>>> Thanks to Noah Misch's review of the keylock patch I noticed that
>>> pageinspect's heap_page_items(bytea) function returns infomask and
>>> infomask2 as smallint (sign
On Tue, Feb 15, 2011 at 10:37 AM, Tom Lane wrote:
> Stephen Frost writes:
>> * Robert Haas (robertmh...@gmail.com) wrote:
>>> The payoff
>>> (getting %U) seems quite out of proportion to the potential downsides
>>> of making a change of this type at this late date.
>
>> I'd be happy to go back to
Heikki Linnakangas writes:
> On 14.02.2011 21:49, Alvaro Herrera wrote:
>> Thanks to Noah Misch's review of the keylock patch I noticed that
>> pageinspect's heap_page_items(bytea) function returns infomask and
>> infomask2 as smallint (signed). But the fields in the tuple header are
>> 16 bits u
Stephen Frost writes:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> The payoff
>> (getting %U) seems quite out of proportion to the potential downsides
>> of making a change of this type at this late date.
> I'd be happy to go back to the original patch/idea of just the simple
> addition of %
On Sat, Feb 12, 2011 at 6:16 AM, Lukas Eder wrote:
> I had tried that before. That doesn't seem to change anything. JDBC still
> expects 6 OUT parameters, instead of just 1...
Oh, hrm. I thought you were trying to fix the return value, rather
than the signature.
I am not sure how to fix the sig
On Mon, Feb 14, 2011 at 9:55 PM, Tom Lane wrote:
> On the whole, I don't think that sepgsql-regtest.pp should be built or
> installed at all during the build phase. It ought to be generated
> during regression test startup, instead.
You have to manually install and enable it before you can run t
On Tue, Feb 15, 2011 at 10:26 AM, Stephen Frost wrote:
> * Stephen Frost (sfr...@snowman.net) wrote:
>> I'd be happy to go back to the original patch/idea of just the simple
>> addition of %U as an option for log_line_prefix.
>
> Updated patch attached which just adds %U support to log_line_prefix
* Stephen Frost (sfr...@snowman.net) wrote:
> I'd be happy to go back to the original patch/idea of just the simple
> addition of %U as an option for log_line_prefix.
Updated patch attached which just adds %U support to log_line_prefix.
Will work on adding CSV support for this in 9.2, along with
Tom Lane wrote:
> I wrote:
> > I tried to do a pg_upgrade from 9.0.x to HEAD today. The pg_upgrade run
> > went through without complaint, and I could start the postmaster, but
> > every connection attempt fails with
>
> > psql: FATAL: could not read block 0 in file "base/11964/11683": read onl
Hello guys,
I am a lecturer at Kharkiv National University of Radio Electronics and I have
a proposal for you.
My students have to make their science projects during this half-year. I would
like to involve some of them in PostgreSQL to give them an opportunity to work
on a real project instea
On Feb 12, 2011, at 9:53 AM, Alex Hunsaker wrote:
> On Fri, Feb 11, 2011 at 17:17, Alexey Klyukin wrote:
>
> Anyway in playing with this patch a bit more I found another bug
> return [[]]; would segfault.
>
> So find attached a v9 that:
> - fixes above segfault
>
> - made plperl_sv_to_literal
Tom Lane wrote:
> I wrote:
> > I tried to do a pg_upgrade from 9.0.x to HEAD today. The pg_upgrade run
> > went through without complaint, and I could start the postmaster, but
> > every connection attempt fails with
>
> > psql: FATAL: could not read block 0 in file "base/11964/11683": read onl
On Tue, Feb 15, 2011 at 8:24 AM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> On 11.02.2011 22:44, Gurjeet Singh wrote:
>
>> Looks like the function get_actual_variable_range() was written with the
>> knowledge that virtual/hypothetical indexes may exist, but the assumption
* Stephen Frost (sfr...@snowman.net) wrote:
> Ugh, sorry about that, I should have realized that needed to be done.
> Updated patch attached.
Errr, for real this time.
Thanks,
Stephen
commit 25e94dcb390f56502bc46e683b438c20d2dc74e0
Author: Stephen Frost
Date: Tue Feb
* Itagaki Takahiro (itagaki.takah...@gmail.com) wrote:
> On Mon, Feb 14, 2011 at 23:30, Stephen Frost wrote:
> > > * In assign_csvlog_fields(), we need to cleanup memory and memory context
> > > before return on error.
> > Fixed this and a couple of similar issues.
>
> Not yet fixed. Switched mem
* Fujii Masao (masao.fu...@gmail.com) wrote:
> On Tue, Feb 15, 2011 at 2:10 AM, Stephen Frost wrote:
> > * You removed trigger_file from the list in
> > doc/src/sgml/high-availability.sgml and I'm not sure I agree with
> > that. It's still perfectly valid and could be used by someone
> > i
Noah,
* Noah Misch (n...@leadboat.com) wrote:
> On Mon, Feb 14, 2011 at 04:06:59PM -0500, Stephen Frost wrote:
> I've attached a new version of the patch that attempts to flesh out the
> comments
> based on your feedback. Does it improve things?
Yes, much better, thanks!
> Offhand, I can't thi
On 11.02.2011 22:44, Gurjeet Singh wrote:
Looks like the function get_actual_variable_range() was written with the
knowledge that virtual/hypothetical indexes may exist, but the assumption
seems wrong.
One one hand get_actual_variable_range() expects that virtual indexes do not
have an OID ass
* Robert Haas (robertmh...@gmail.com) wrote:
> The payoff
> (getting %U) seems quite out of proportion to the potential downsides
> of making a change of this type at this late date.
I'd be happy to go back to the original patch/idea of just the simple
addition of %U as an option for log_line_pref
On Fri, Feb 11, 2011 at 6:20 PM, Kevin Grittner
wrote:
> I wrote:
>>> Patch attached.
>
> This time with src/backend/utils/misc/postgresql.conf.sample fixed.
Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing
On Tue, Feb 15, 2011 at 12:46 AM, Itagaki Takahiro
wrote:
> On Mon, Feb 14, 2011 at 23:30, Stephen Frost wrote:
>> > * In assign_csvlog_fields(), we need to cleanup memory and memory context
>> > before return on error.
>> Fixed this and a couple of similar issues.
>
> Not yet fixed. Switched mem
On Tue, Feb 15, 2011 at 12:34 AM, Fujii Masao wrote:
> You suggest that the shared variable Stream tracks the WAL write location,
> after it's set to the replication starting position? I don't think
> that the write
> location needs to be tracked in the shmem because other processes than
> walrece
On Tue, Feb 15, 2011 at 4:31 AM, Itagaki Takahiro
wrote:
> array_flatten() no longer exists. I added array_trim() as an alias
> to trim_array() because it would be a FAQ.
I don't like the alias thing - let's add one name or the other, not both.
Similarly, let's NOT add array_union_all as an alia
On Tue, Feb 15, 2011 at 3:31 AM, Itagaki Takahiro
wrote:
> On Tue, Feb 15, 2011 at 01:27, Robert Haas wrote:
>> However, file_fdw is in pretty serious trouble because (1) the copy
>> API patch that it depends on still isn't committed and (2) it's going
>> to be utterly broken if we don't do somet
On Tue, Feb 15, 2011 at 6:12 AM, Stefan Kaltenbrunner
wrote:
> from what I can see upstream libedit actually has utf8 support for a while
> now (as well as some other fixes) but the debian libedit version (and also
> the one of other distributions) is way too old for that so maybe most of the
> is
- Original message -
> On mån, 2011-02-14 at 22:22 +0100, Jan Urbański wrote:
> > The problem is that every *second* call to the function fails,
> > regardless of the number. The first execution succeeds, but then
> > PLy_delete_args deletes the argument from the globals, and when the
> > n
On 14.02.2011 21:49, Alvaro Herrera wrote:
Thanks to Noah Misch's review of the keylock patch I noticed that
pageinspect's heap_page_items(bytea) function returns infomask and
infomask2 as smallint (signed). But the fields in the tuple header are
16 bits unsigned, so if the high (16th) bit is se
On Tue, Feb 15, 2011 at 01:27, Robert Haas wrote:
> However, file_fdw is in pretty serious trouble because (1) the copy
> API patch that it depends on still isn't committed and (2) it's going
> to be utterly broken if we don't do something about the
> client_encoding vs. file_encoding problem; the
On 14.02.2011 20:10, Kevin Grittner wrote:
Promotion of the lock granularity on the prior tuple is where we
have problems. If the two tuple versions are in separate pages then
the second UPDATE could miss the conflict. My first thought was to
fix that by requiring promotion of a predicate lock o
101 - 136 of 136 matches
Mail list logo
