On Wed, Nov 28, 2012 at 7:01 AM, Magnus Hagander wrote:
>
> On Nov 28, 2012 1:54 AM, "Tom Lane" wrote:
>>
>> Alvaro Herrera writes:
>> > Peter Eisentraut wrote:
>> >> There is already the PQconninfoOption.dispchar field for this purpose.
>>
>> > I had the impression that that field would go away
> buffer lenghth). So my proposal is, if prepare_buffer() detects
> possible inconsistency between buffer encoding and file encoding, warn
> user.
I agree with that.
On 2012/11/30 12:52, Tatsuo Ishii Wrote:
1. some especial character
(my sql file contains japanese comment "-- コメント" . It can ca
>> 1. some especial character
>> (my sql file contains japanese comment "-- コメント" . It can cause
>> psql crash.)
>> 2. PGCLIENTENCODING is SJIS
>> 3. the encoding of input sql file is UTF-8
Actually the problem can occur even when importing following 3 byte
UTF8 input file:
ト
(in hexa, 0xe3, 0x
Bruce Momjian writes:
> In looking to add an fsync-only option to initdb, I found its main()
> function to be 743 lines long, and very hard to understand.
> The attached patch moves much of that code into separate functions,
> which will make initdb.c easier to understand, and easier to add an
>
In looking to add an fsync-only option to initdb, I found its main()
function to be 743 lines long, and very hard to understand.
The attached patch moves much of that code into separate functions,
which will make initdb.c easier to understand, and easier to add an
fsync-only option. The original
On Fri, Nov 30, 2012 at 3:19 AM, Andres Freund wrote:
> Hi,
>
> while looking at trigger.c from the POV of foreign key locks I noticed
> that GetTupleForTrigger commentless assumes it can just look at a pages
> content without a
> LockBuffer(buffer, BUFFER_LOCK_SHARE);
>
> That code path is on
On Fri, Nov 30, 2012 at 4:43 AM, Andres Freund wrote:
> On 2012-11-29 11:53:50 -0500, Tom Lane wrote:
> > And here is a version for 9.1. This omits the code changes directly
> > relevant to DROP INDEX CONCURRENTLY, but includes the changes to avoid
> > transactional updates of the pg_index row du
Andrew Dunstan writes:
> On 11/29/2012 07:16 PM, Tom Lane wrote:
>> Um ... that's *another* place that needs to change then, because the
>> test script fires up postmasters on its own, outside of pg_upgrade.
> True, but it doesn't do anything about setting the socket dir, so those
> just get the
On 11/29/2012 07:16 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 11/29/2012 06:23 PM, Tom Lane wrote:
However, that's only addressing the reporting end of it; I think we
also need to change the pg_upgrade test script as suggested by Noah.
The test script doesn't do anything. It's pg_upgrade
Tom Lane writes:
> Andrew Dunstan writes:
>> ... Or maybe the
>> postmaster needs to check the length somehow before it calls
>> StreamServerPort() so we can give a saner error message.
> Hm. That's ugly, but a lot less invasive than trying to get the
> official API to pass the information th
Andrew Dunstan writes:
> On 11/29/2012 06:23 PM, Tom Lane wrote:
>> However, that's only addressing the reporting end of it; I think we
>> also need to change the pg_upgrade test script as suggested by Noah.
> The test script doesn't do anything. It's pg_upgrade itself that sets
> the socket dir
On Thu, Nov 29, 2012 at 4:14 PM, Andrew Dunstan wrote:
> There are many things wrong with this. First, converting to hstore so you
> can call populate_record is quite horrible and ugly and inefficient. And
> it's dependent on having hstore loaded - you can't have an hstore_to_jon in
> core because
On 11/29/2012 06:23 PM, Tom Lane wrote:
Andrew Dunstan writes:
... Or maybe the
postmaster needs to check the length somehow before it calls
StreamServerPort() so we can give a saner error message.
Hm. That's ugly, but a lot less invasive than trying to get the
official API to pass the infor
Andrew Dunstan writes:
> ... Or maybe the
> postmaster needs to check the length somehow before it calls
> StreamServerPort() so we can give a saner error message.
Hm. That's ugly, but a lot less invasive than trying to get the
official API to pass the information through. Sounds like a plan
On 11/29/2012 05:20 PM, Tom Lane wrote:
I don't think it's worth a heroic effort. Meanwhile I'll add a check in
the upgrade test module(s) to check for overly long paths likely to give
problems.
I'm thinking maybe we should try to fix this. What's bugging me is that
Jeremy's build path doesn't
Noah Misch writes:
> Linux enforces a hard limit matching the static buffer in sockaddr_un. You'd
> proceed a bit further and hit "could not bind Unix socket: Invalid argument"
> or some such.
Hm, I was wondering about that. The Single Unix Spec suggests that
bind/connect ought to accept pathna
On Thu, Nov 29, 2012 at 03:33:59PM -0500, Tom Lane wrote:
> I wrote:
> > So far as I can see, none of the spec-defined EAI_XXX codes map very
> > nicely to "path name too long". Possibly we could return EAI_SYSTEM
> > and set errno to ENAMETOOLONG, but I'm not sure the latter is very
> > portable
Andrew Dunstan writes:
> On 11/29/2012 03:33 PM, Tom Lane wrote:
>>> Another line of attack is to just teach getaddrinfo_unix() to malloc its
>>> result struct big enough to hold whatever the supplied path is.
>> I tried this out too, and found that it doesn't work well, because both
>> libpq and
On 11/29/2012 04:52 PM, Merlin Moncure wrote:
On Thu, Nov 29, 2012 at 1:19 PM, Andrew Dunstan wrote:
On 11/29/2012 01:06 PM, Merlin Moncure wrote:
so, just hashing out your proposal and making sure it's reasonable
analogous implementation of xpath. Sleeping on it, I say mostly, but
not quite
On Thu, Nov 29, 2012 at 1:19 PM, Andrew Dunstan wrote:
>
> On 11/29/2012 01:06 PM, Merlin Moncure wrote:
>>
>> so, just hashing out your proposal and making sure it's reasonable
>> analogous implementation of xpath. Sleeping on it, I say mostly, but
>> not quite. how about some changes for json_g
Hi,
while looking at trigger.c from the POV of foreign key locks I noticed
that GetTupleForTrigger commentless assumes it can just look at a pages
content without a
LockBuffer(buffer, BUFFER_LOCK_SHARE);
That code path is only reached for AFTER ... FOR EACH ROW ... triggers,
so its fine it's
On 11/29/2012 03:33 PM, Tom Lane wrote:
I wrote:
Andrew Dunstan writes:
Looks like it was. Good catch. What's the best way to fix?
So far as I can see, none of the spec-defined EAI_XXX codes map very
nicely to "path name too long". Possibly we could return EAI_SYSTEM
and set errno to ENAMET
I wrote:
> Andrew Dunstan writes:
>> Looks like it was. Good catch. What's the best way to fix?
> So far as I can see, none of the spec-defined EAI_XXX codes map very
> nicely to "path name too long". Possibly we could return EAI_SYSTEM
> and set errno to ENAMETOOLONG, but I'm not sure the latte
On 2012-11-29 15:03:48 -0500, Tom Lane wrote:
> Alvaro Herrera writes:
> > The other interesting question remaining is what to do about the rm_desc
> > function in rmgr.c. We're split between these two ideas:
>
> Why try to link rmgr.c into frontend versions at all? Just make
> a new table file
Alvaro Herrera writes:
> The other interesting question remaining is what to do about the rm_desc
> function in rmgr.c. We're split between these two ideas:
Why try to link rmgr.c into frontend versions at all? Just make
a new table file that only includes the desc function pointers.
Yeah, then
On 2012-11-29 11:53:50 -0500, Tom Lane wrote:
> And here is a version for 9.1. This omits the code changes directly
> relevant to DROP INDEX CONCURRENTLY, but includes the changes to avoid
> transactional updates of the pg_index row during CREATE CONCURRENTLY,
> as well as the changes to prevent u
On 2012-11-27 12:07:34 -0300, Alvaro Herrera wrote:
> Alvaro Herrera wrote:
> > Here's version 24.
>
> Old review emails still contains some items that didn't lead to any
> changes. I tried to keep close track of those. To that list I add a
> couple of things of my own. Here they are, for those
On 11/29/2012 01:06 PM, Merlin Moncure wrote:
so, just hashing out your proposal and making sure it's reasonable
analogous implementation of xpath. Sleeping on it, I say mostly, but
not quite. how about some changes for json_get:
1) return setof (key, value) in the style of jquery each().
2) w
On Thu, Nov 29, 2012 at 7:58 AM, Andrew Dunstan wrote:
> On 11/28/2012 08:16 PM, Hannu Krosing wrote:
>> You could even do a template-less row_from_json which returns a records
>> with all fields converted to
>> the JSON-encodable types and hope that the next conversions will be done
>> by postgre
On Wed, Nov 28, 2012 at 03:22:32PM -0500, Bruce Momjian wrote:
> On Tue, Nov 27, 2012 at 09:35:10PM -0800, Jeff Janes wrote:
> > > I tested custom format with pg_restore -j and -1, as well as text
> > > restore. The winner was pg_dump -Fc | pg_restore -1;
> >
> > I don't have the numbers at hand,
And here is a version for 9.1. This omits the code changes directly
relevant to DROP INDEX CONCURRENTLY, but includes the changes to avoid
transactional updates of the pg_index row during CREATE CONCURRENTLY,
as well as the changes to prevent use of not-valid or not-ready indexes
in places where i
Andrew Dunstan writes:
> On 11/28/2012 11:03 PM, Tom Lane wrote:
>> [ digs around ... ] It looks like the failure is coming from here:
>>
>> if (strlen(path) >= sizeof(unp->sun_path))
>> return EAI_FAIL;
> Looks like it was. Good catch. What's the best way to fix?
So far as I
> I have bumped in the segmentation fault in ecpg when using pointer to
> nested structure variable.
> ...
> Please see the attached patch for the fix and test case to reproduce the
> scenario.
Thanks for spotting and fixing this. Patch committed to git.
Michael
--
Michael Meskes
Michael at Fam-
On 11/28/2012 11:03 PM, Tom Lane wrote:
Jeremy Drake writes:
While we're talking about odd issues that only seem to happen on Okapi,
does anyone know of anything I can do to diagnose the pg_upgrade failure
on the 9.2 branch? There are no rogue (non-buildfarm-related)
postmaster/postgres proce
On Wed, Nov 28, 2012 at 3:21 PM, Andres Freund wrote:
> Looks ready to me.
Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://
Kevin Grittner wrote:
> Kevin Grittner wrote:
> > Alvaro Herrera wrote:
> >
> >> Here's version 24.
> >
> > This no longer applies after the rmgr rm_desc patch.
>
> I took a shot at merging those so I could review the patch against
> HEAD; attached in hopes that it will be useful.
>
> Hopefully
On 11/29/2012 9:46 AM, Tom Lane wrote:
Jan Wieck writes:
On 11/28/2012 3:33 PM, Kevin Grittner wrote:
Resetting starttime this way seems especially odd.
instr_time is LARGE_INTEGER on Win32 but struct timeval on Unix. Is
starttime = currenttime;
portable if those are structs?
Sure.
Jan Wieck writes:
> On 11/28/2012 3:33 PM, Kevin Grittner wrote:
>> Resetting starttime this way seems especially odd.
> instr_time is LARGE_INTEGER on Win32 but struct timeval on Unix. Is
> starttime = currenttime;
> portable if those are structs?
Sure. We rely on struct assignment in lot
On 11/28/2012 3:33 PM, Kevin Grittner wrote:
Kevin Grittner wrote:
I still need to review the timing calls, since I'm not familiar
with them so it wasn't immediately obvious to me whether they
were being used correctly. I have no reason to believe that they
aren't, but feel I should check.
It
On Wed, 28 Nov 2012, Tom Lane wrote:
> Jeremy Drake writes:
> > While we're talking about odd issues that only seem to happen on Okapi,
> > does anyone know of anything I can do to diagnose the pg_upgrade failure
> > on the 9.2 branch? There are no rogue (non-buildfarm-related)
> > postmaster/po
On Wed, 28 Nov 2012, Tom Lane wrote:
> Andrew Dunstan writes:
> > On 11/28/2012 02:14 PM, Alvaro Herrera wrote:
> >> Okapi has been failing sporadically on ecpg, and I wonder if it's
> >> related to this change.
>
> > Well, it looks like the make is broken and missing a clear dependency
> > requi
On 11/28/2012 08:16 PM, Hannu Krosing wrote:
On 11/29/2012 02:07 AM, Hannu Krosing wrote:
On 11/29/2012 01:10 AM, Merlin Moncure wrote:
On Wed, Nov 28, 2012 at 2:44 PM, Andrew Dunstan
wrote:
...
*) have you considered something like
anyelement from_json(anyelement, json)
or
select ::some_
Hi,
Currently "make -jN check" fails during "creating temporary installation"
with:
make[1]: *** read jobs pipe: Invalid argument. Stop.
make[1]: *** Waiting for unfinished jobs
make[2]: warning: jobserver unavailable: using -j1. Add `+' to parent make
rule.
in install.log.
This is due to
One thing that bothers me with this algoritm is that the overflow
mechanism is all-or-nothing. In many cases, even when there is a huge
number of states in the diagram, you could still extract at least a few
trigrams that must be present in any matching string, with little
effort. At least, it
Hi
I have bumped in the segmentation fault in ecpg when using pointer to
nested structure variable.
ecpg crash.pgc
Segmentation fault: 11
Please see the attached patch for the fix and test case to reproduce the
scenario.
Thanks
Regards
Muhammad Usama
crash.pgc
Description: Binary data
ecpg
On Thursday, November 29, 2012 4:24 PM Andres Freund wrote:
> On 2012-11-29 16:18:07 +0530, Amit Kapila wrote:
> > On Thursday, November 29, 2012 12:39 AM Tom Lane wrote.
> > > Andres Freund writes:
> > > > On 2012-11-27 23:46:58 -0500, Tom Lane wrote:
> > > >> Attached is a very preliminary draft
On 2012-11-29 16:18:07 +0530, Amit Kapila wrote:
> On Thursday, November 29, 2012 12:39 AM Tom Lane wrote.
> > Andres Freund writes:
> > > On 2012-11-27 23:46:58 -0500, Tom Lane wrote:
> > >> Attached is a very preliminary draft patch for this. I've not
> > >> addressed the question of whether we
On Thursday, November 29, 2012 12:39 AM Tom Lane wrote.
> Andres Freund writes:
> > On 2012-11-27 23:46:58 -0500, Tom Lane wrote:
> >> Attached is a very preliminary draft patch for this. I've not
> >> addressed the question of whether we can clear indcheckxmin during
> >> transactional updates o
I confirmed the problem. Also I confirmed your patch fixes the
problem. In addition to this, all the tests in test/mb and
test/regress are passed.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
> hi
>
> When i test psql under m
The code that reads the WAL from the archive, from pg_xlog, and from a
master server via walreceiver, is quite complicated. I'm talking about
the WaitForWALToBecomeAvailable() function in xlog.c. I got frustrated
with that while working on the "switching timeline over streaming
replication" pat
On Mon, November 26, 2012 20:49, Alexander Korotkov wrote:
> trgm-regexp-0.6.patch.gz
I ran the simple-minded tests against generated data (similar to the ones I did
in January 2012).
The problems of that older version seem pretty much all removed. (although I
didn't do much work
on it -- just
hi
When i test psql under multi-lingual and different encoding environment,
I found a crash of psql.
--
$ export PGCLIENTENCODING=SJIS
$ psql
psql (9.2rc1)
Type "help" for help.
postgres=# \i sql
CREATE DATABASE
You are now con
52 matches
Mail list logo
