On 23.08.2012 23:07, Alvaro Herrera wrote:
One problem with this is that I get this warning:
/pgsql/source/HEAD/contrib/pg_upgrade/exec.c: In function ‘s_exec_prog’:
/pgsql/source/HEAD/contrib/pg_upgrade/exec.c:96:2: warning: function might be
possible candidate for ‘gnu_printf’ format attribut
On Friday, August 24, 2012 07:33:01 AM Tom Lane wrote:
> Andres Freund writes:
> >> Um ... how exactly can that happen, if the signal is now ignored?
> >
> > My man 2 signal tells me:
> > "According to POSIX, the behavior of a process is undefined after it
> > ignores a SIGFPE, SIGILL, or SIGSEG
Andres Freund writes:
>> Um ... how exactly can that happen, if the signal is now ignored?
> My man 2 signal tells me:
> "According to POSIX, the behavior of a process is undefined after it ignores
> a SIGFPE, SIGILL, or SIGSEGV signal that was not generated by kill(2) or
> raise(3)."
So I gue
On Friday, August 24, 2012 07:19:42 AM Andres Freund wrote:
> On Friday, August 24, 2012 06:55:04 AM Tom Lane wrote:
> > Andres Freund writes:
> > > On Thursday, August 23, 2012 12:17:22 PM Andres Freund wrote:
> > >> While debugging an instance of this bug I noticed that plperlu always
> > >
> >
On Friday, August 24, 2012 06:55:04 AM Tom Lane wrote:
> Andres Freund writes:
> > On Thursday, August 23, 2012 12:17:22 PM Andres Freund wrote:
> >> While debugging an instance of this bug I noticed that plperlu always
> >
> >> removes the SIGFPE handler and sets it to ignore:
> > In fact it can
On Friday, August 24, 2012 06:55:04 AM Tom Lane wrote:
> Andres Freund writes:
> > On Thursday, August 23, 2012 12:17:22 PM Andres Freund wrote:
> >> While debugging an instance of this bug I noticed that plperlu always
> >
> >> removes the SIGFPE handler and sets it to ignore:
> > In fact it can
Andres Freund writes:
> On Thursday, August 23, 2012 12:17:22 PM Andres Freund wrote:
>> While debugging an instance of this bug I noticed that plperlu always
>> removes the SIGFPE handler and sets it to ignore:
> In fact it can be used to crash the server:
Um ... how exactly can that happen, if
On Thursday, August 23, 2012 12:17:22 PM Andres Freund wrote:
> Hi,
>
> While debugging an instance of this bug I noticed that plperlu always
> removes the SIGFPE handler and sets it to ignore:
>
>
> andres@awork2:~$ psql -p 5435 -U postgres -h /var/run/postgresql test
> Timing is on.
> psql (9.
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Craig Ringer
Sent: Friday, August 24, 2012 7:17 AM
> I've recently noticed two oversights in the docs that I'd like to fix.
> First, in sql-fetch, there's no hint that the cursor name can be the
>
From: Bruce Momjian [mailto:br...@momjian.us]
Sent: Friday, August 24, 2012 2:12 AM
On Wed, Aug 22, 2012 at 07:38:33PM +0530, Amit Kapila wrote:
>> I had made sure no full_page_write happens by making checkpoint interval
and
>> checkpoints segments longer.
>>
>
>
>> Original code - 1.8GMo
On Thu, 2012-08-23 at 11:21 -0400, Alvaro Herrera wrote:
> Yeah, IMHO .po files are handled pretty badly by SCMs.
By SCMs that store diffs internally, perhaps, but Git doesn't, so I
don't think it matters much for storage whether .po files diff well.
> I wonder if we
> could reduce the amount of
On Thu, 2012-08-23 at 17:05 -0400, Bruce Momjian wrote:
> On Thu, Aug 23, 2012 at 02:17:44AM -0400, Peter Eisentraut wrote:
> > The script analyze_new_cluster.sh output by pg_upgrade contains several
> > "sleep" calls (see contrib/pg_upgrade/check.c). What is the point of
> > this? If the purpose
> Tom Lane wrote:
> "Kevin Grittner" writes:
>> I'll run through my tests again tonight, against your patch, not
>> that I expect any problems with it. Unfortunately I can't test
>> Windows, as I don't have a build environment for that.
>
> FWIW, you can approximate Windows close enough for th
>> On Tue, Aug 21, 2012 at 7:49 AM, Tatsuo Ishii wrote:
>>> Please let me know if this is not the right place to ask this kind of
>>> queston.
>>>
>>> PostgreSQL Developers FAQ in Japanese:
>>>
>>> http://wiki.postgresql.org/wiki/Developer_FAQ/ja
>>>
>>> looks pretty outdated. It was last updated
Hi all
I've recently noticed two oversights in the docs that I'd like to fix.
First, in sql-fetch, there's no hint that the cursor name can be the
quoted value of a refcursor, eg:
FETCH ALL FROM "";
This *is* shown in an example in plpgsql-cursors, but only in some
sample code. If you
On 23 August 2012 20:21, Bruce Momjian wrote:
> On Tue, Aug 21, 2012 at 12:16:11PM +0900, Tatsuo Ishii wrote:
>> I found this in https://wiki.postgresql.org/wiki/Todo :
>>
>> Improve ability to display optimizer analysis using OPTIMIZER_DEBUG
>>
>> What does this actually mean?
>>
>> Add GUC swi
> Well, right now, OPTIMIZER_DEBUG lets you see what plans were considered
> and removed. I was thinking that information should be available
> without a special compiled binary.
+1. It would also be popular with our academic users.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
On 08/23/2012 02:44 PM, Andrew Dunstan wrote:
On 08/23/2012 01:58 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 08/23/2012 12:40 AM, Tom Lane wrote:
Anybody who wants to fix it is surely welcome to, but I'm not going
to consider this item as a reason to postpone RC1.
I'm not sure what you
On Thu, Aug 23, 2012 at 02:17:44AM -0400, Peter Eisentraut wrote:
> The script analyze_new_cluster.sh output by pg_upgrade contains several
> "sleep" calls (see contrib/pg_upgrade/check.c). What is the point of
> this? If the purpose of this script is to get the database operational
> again as so
On Thu, Aug 23, 2012 at 11:46:38AM +0900, Tatsuo Ishii wrote:
> > On Wed, Aug 22, 2012 at 9:32 PM, Tatsuo Ishii wrote:
> >> Hi,
> >>
> >> I found following item in the Developer FAQ.
> >> I don't see why this is related to developers.
> >> --
On Wed, Aug 22, 2012 at 07:38:33PM +0530, Amit Kapila wrote:
> I had made sure no full_page_write happens by making checkpoint interval and
> checkpoints segments longer.
>
>
>
> Original code - 1.8GModified code - 1.1G Diff - 63% reduction, incase of
> fill factor 100.
> Original code -
Hi,
I've been bitten twice by exec_prog()s API, so here's a patch to try to
make it a bit harder to misuse.
There are two main changes here; one is to put the logfile option as the
first argument; then comes a bool, then the format string. This means
you get a warning if you pass the wrong numbe
"Kevin Grittner" writes:
> I'll run through my tests again tonight, against your patch, not
> that I expect any problems with it. Unfortunately I can't test
> Windows, as I don't have a build environment for that.
FWIW, you can approximate Windows close enough for this type of problem
by buildin
Tom Lane wrote:
> I tweaked Kevin's error message to keep the same capitalization as
> the existing text for the message in check_XactIsoLevel --- if we
> change that it will cause work for the translators, and I don't
> think it's enough of an improvement to justify that.
That's one of the re
On Tue, Aug 21, 2012 at 12:16:11PM +0900, Tatsuo Ishii wrote:
> I found this in https://wiki.postgresql.org/wiki/Todo :
>
> Improve ability to display optimizer analysis using OPTIMIZER_DEBUG
>
> What does this actually mean?
>
> Add GUC switch to enable optimizer debug on/off?
> More fancy/u
On Tue, Aug 21, 2012 at 09:52:02AM -0400, Robert Haas wrote:
> On Mon, Aug 20, 2012 at 6:44 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Mon, Aug 20, 2012 at 4:27 PM, Tom Lane wrote:
> >>> Surely we could just prevent creation of the FSM until the table has
> >>> reached at least, say, 10
Excerpts from Tom Lane's message of jue ago 23 13:33:46 -0400 2012:
> Roger Leigh writes:
> > On Thu, Aug 23, 2012 at 11:21:35AM -0400, Alvaro Herrera wrote:
> >> Yeah, IMHO .po files are handled pretty badly by SCMs. I wonder if we
> >> could reduce the amount of git churn caused by those files
I wrote:
> I poked around this area a bit. I notice that
> check_transaction_read_only has got the same fundamental error: it
> thinks it can safely consult RecoveryInProgress(), which in general
> it cannot.
After rereading the whole thread I saw that Heikki had already pointed
this out, and com
On 08/23/2012 01:58 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 08/23/2012 12:40 AM, Tom Lane wrote:
Anybody who wants to fix it is surely welcome to, but I'm not going
to consider this item as a reason to postpone RC1.
I'm not sure what you want done. I can test Amit's patch in a couple o
On Mon, Aug 20, 2012 at 07:08:12PM -0400, Tom Lane wrote:
> The only reason I can see for pushing more crypto into core is
> if we needed to stop using MD5 for the core password authentication
> functionality. While that might come to pass eventually, I am aware of
> no evidence whatever that SHAn
Andrew Dunstan writes:
> On 08/23/2012 12:40 AM, Tom Lane wrote:
>> Anybody who wants to fix it is surely welcome to, but I'm not going
>> to consider this item as a reason to postpone RC1.
> I'm not sure what you want done. I can test Amit's patch in a couple of
> Windows environments (say XP+m
On 08/23/2012 12:40 AM, Tom Lane wrote:
I wrote:
... I really can't take responsibility for any of this since
I don't have a Windows development environment. One of the Windows-
hacking committers needs to pick this issue up. Anyone?
[ crickets ]
I guess everybody who might take an interest
Roger Leigh writes:
> On Thu, Aug 23, 2012 at 11:21:35AM -0400, Alvaro Herrera wrote:
>> Yeah, IMHO .po files are handled pretty badly by SCMs. I wonder if we
>> could reduce the amount of git churn caused by those files by simply
>> removing all comment lines from these files as they are exporte
"Kevin Grittner" writes:
> How about we fix the serializable versus HS & Windows bugs in one
> patch, and then look at the other as a separate patch? If that's OK,
> I think this is ready, unless my message text can be improved. (And
> I will have a shot at my first back-patching)
I poked aro
On Thu, Aug 23, 2012 at 11:21:35AM -0400, Alvaro Herrera wrote:
> Excerpts from Tom Lane's message of jue ago 23 11:01:05 -0400 2012:
>
> >
> > $ git diff --shortstat REL9_0_9 REL9_1_5
> > 3186 files changed, 314847 insertions(+), 210452 deletions(-)
> > $ git diff --shortstat REL9_1_5 REL9_2_BE
Excerpts from Tom Lane's message of jue ago 23 11:01:05 -0400 2012:
>
> $ git diff --shortstat REL9_0_9 REL9_1_5
> 3186 files changed, 314847 insertions(+), 210452 deletions(-)
> $ git diff --shortstat REL9_1_5 REL9_2_BETA4
> 2037 files changed, 290919 insertions(+), 189487 deletions(-)
>
> Ho
Jeff Davis wrote:
> On Tue, 2012-08-21 at 17:07 -0500, Kevin Grittner wrote:
>> The fact that it has an unknown sequence number or timestamp for
>> purposes of ordering visibility of transactions doesn't mean you
>> can't show that it completed in an audit log. In other words, I
>> think the ne
Bruce Momjian writes:
> On Mon, Aug 20, 2012 at 03:09:08PM -0400, Robert Haas wrote:
>> I think the thing we need to look at is what percentage of our code
>> churn is coming from stuff like this, versus what percentage of it is
>> coming from other factors. If we change 250,000 lines of code per
On Tue, Aug 21, 2012 at 11:55:20AM -0400, Robert Haas wrote:
> On Wed, Aug 15, 2012 at 6:23 PM, Bruce Momjian wrote:
> > Has this been addressed? A TODO?
>
> I don't think anything's been done about it. According to your email
> of October 11, 2011, you already did add a TODO for this.
Ah, I s
On Tue, Aug 21, 2012 at 11:48:19AM -0400, Robert Haas wrote:
> On Tue, Aug 14, 2012 at 5:41 PM, Bruce Momjian wrote:
> > Did these comment updates ever get addressed?
>
> Partially.
>
> I just made a commit to clean up the rest of it.
Thanks.
--
Bruce Momjian http://momjian.us
En
On Mon, Aug 20, 2012 at 03:09:08PM -0400, Robert Haas wrote:
> I have difficult believing that a change of this type, if implemented
> judiciously, is really going to create that much difficulty in
> back-patching. I don't do as much back-patching as Tom either (no one
> does), but most of the pat
Magnus Hagander writes:
> On Thu, Aug 23, 2012 at 3:42 PM, Tom Lane wrote:
>> to_timestamp is intentionally pretty loose. Personally, if I wanted
>> sanity checking on a date string in any common format, I would just
>> cast the string to timestamp(tz), and *not* use to_timestamp.
> Shouldn't w
On Thu, Aug 23, 2012 at 3:42 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> postgres=# select to_timestamp('2012-08-01', '-mm-dd');
>> to_timestamp
>>
>> 2012-08-01 00:00:00+02
>
>> postgres=# select to_timestamp('2012-08-00', '-mm-dd');
>> to_times
Magnus Hagander writes:
> postgres=# select to_timestamp('2012-08-01', '-mm-dd');
> to_timestamp
>
> 2012-08-01 00:00:00+02
> postgres=# select to_timestamp('2012-08-00', '-mm-dd');
> to_timestamp
>
> 2012-08-01 00:00:00+02
Peter Eisentraut writes:
> On Sun, 2012-06-24 at 01:26 +0300, Peter Eisentraut wrote:
>> About the new --maintenance-db options:
>>
>> Why was this option not added to createuser and dropuser? In the
>> original discussion[0] they were mentioned, but it apparently never
>> made it into the code.
Peter Eisentraut writes:
> On Tue, 2012-08-21 at 12:01 -0400, Robert Haas wrote:
>> It's possible there's something we want to change here, but it's far
>> from obvious what that thing is. Our WAL file handling is
>> ridiculously hard to understand, but the problem with changing it is
>> that the
On 08/23/2012 07:39 AM, Magnus Hagander wrote:
On Thu, Aug 23, 2012 at 1:35 PM, Andrew Dunstan wrote:
On 08/23/2012 06:47 AM, Magnus Hagander wrote:
On Mon, Aug 20, 2012 at 4:52 PM, Andrew Dunstan
wrote:
Here is a patch for this feature, which should alleviate some of the woes
caused by add
On Thu, Aug 23, 2012 at 1:35 PM, Andrew Dunstan wrote:
>
> On 08/23/2012 06:47 AM, Magnus Hagander wrote:
>>
>> On Mon, Aug 20, 2012 at 4:52 PM, Andrew Dunstan
>> wrote:
>>>
>>> Here is a patch for this feature, which should alleviate some of the woes
>>> caused by adding labels not being transac
On 08/23/2012 06:47 AM, Magnus Hagander wrote:
On Mon, Aug 20, 2012 at 4:52 PM, Andrew Dunstan wrote:
Here is a patch for this feature, which should alleviate some of the woes
caused by adding labels not being transactional (and thus not allowing for
the catching of errors).
I haven't actuall
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Magnus Hagander
Sent: Thursday, August 23, 2012 2:08 PM
> postgres=# select to_timestamp('2012-08-01', '-mm-dd');
> to_timestamp
>
> 2012-08-01 00:00:00+02
> postgr
On Mon, Aug 20, 2012 at 4:52 PM, Andrew Dunstan wrote:
> Here is a patch for this feature, which should alleviate some of the woes
> caused by adding labels not being transactional (and thus not allowing for
> the catching of errors).
I haven't actually checked the code in detail, but if it's not
On Wed, Aug 15, 2012 at 5:39 PM, Bruce Momjian wrote:
> On Mon, Aug 15, 2011 at 01:03:35PM +0200, Magnus Hagander wrote:
>> The pg_stat_replication view exposes all the fields in
>> StandbyReplyMessage *except* for the timestamp when the message was
>> generated. On an active system this is not al
Hi,
While debugging an instance of this bug I noticed that plperlu always removes
the SIGFPE handler and sets it to ignore:
andres@awork2:~$ psql -p 5435 -U postgres -h /var/run/postgresql test
Timing is on.
psql (9.1devel, server 9.1.5)
Type "help" for help.
test=# SELECT pg_backend_pid();
p
postgres=# select to_timestamp('2012-08-01', '-mm-dd');
to_timestamp
2012-08-01 00:00:00+02
postgres=# select to_timestamp('2012-08-00', '-mm-dd');
to_timestamp
2012-08-01 00:00:00+02
postgres=# select to_timestamp('2012-00-0
On Sun, 2012-06-24 at 01:26 +0300, Peter Eisentraut wrote:
> About the new --maintenance-db options:
>
> Why was this option not added to createuser and dropuser? In the
> original discussion[0] they were mentioned, but it apparently never
> made it into the code.
What should we do with this?
55 matches
Mail list logo
