Re: [HACKERS] Display of multi-target-table Modify plan nodes in EXPLAIN

On Sun, Mar 22, 2015 at 11:38 PM, Heikki Linnakangas wrote: > If we have promised that, I think we should break the promise. No > application should depend on the details of EXPLAIN output, even if it's in > JSON/YAML/XML format. EXPLAIN is used by humans, and by tools like pgAdmin > that display

Re: [HACKERS] Zero-padding and zero-masking fixes for to_char(float)

On Mon, Mar 23, 2015 at 12:36:25AM -0400, Tom Lane wrote: > Bruce Momjian writes: > > On Sun, Mar 22, 2015 at 12:46:08PM -0400, Noah Misch wrote: > >> I recommend adding a "configure" test to use our snprintf.c replacements if > >> sprintf("%.*f", 65536, 999.0) gives unexpected output. >

Re: [HACKERS] Display of multi-target-table Modify plan nodes in EXPLAIN

On 03/22/2015 03:02 AM, Tom Lane wrote: In a green field we might choose to solve this by refactoring the output so that it's logically Multi-Table Update [ Update Target: pt1 Plan: (seq scan on pt1 here) ]

Re: [HACKERS] inherit support for foreign tables

On Mon, Mar 23, 2015 at 12:09 AM, Robert Haas wrote: > On Sun, Mar 22, 2015 at 1:57 PM, Tom Lane wrote: > > Etsuro Fujita writes: > >> [ fdw-inh-8.patch ] > > > > I've committed this with some substantial rearrangements, notably: > > I'm really glad this is going in! Thanks to to Shigeru Hanad

Re: [HACKERS] proposal: plpgsql - Assert statement

2015-01-28 0:13 GMT+01:00 Jim Nasby : > On 1/27/15 1:30 PM, Pavel Stehule wrote: > >> I don't see the separate warning as being helpful. I'd just do >> something like >> >> +(err_hint != NULL) ? errhint("%s", >> err_hint) : errhint("Message attached to faile

Re: [HACKERS] Auditing extension for PostgreSQL (Take 2)

At 2015-02-24 11:22:41 -0500, da...@pgmasters.net wrote: > > Patch v3 is attached. > > […] > > +/* Log class enum used to represent bits in auditLogBitmap */ > +enum LogClass > +{ > + LOG_NONE = 0, > + > + /* SELECT */ > + LOG_READ = (1 << 0), > + > + /* INSERT, UPDATE, DELETE, TRUN

Re: [HACKERS] Display of multi-target-table Modify plan nodes in EXPLAIN

On Mon, Mar 23, 2015 at 10:51 AM, Tom Lane wrote: > Ashutosh Bapat writes: > > On Sun, Mar 22, 2015 at 6:32 AM, Tom Lane wrote: > >> What I'm imagining instead is that when there's more than one > >> target relation, we produce output like ... > > > This looks better. > > In the format above, y

Re: [HACKERS] Table-level log_autovacuum_min_duration

On Mon, Mar 23, 2015 at 1:54 PM, Fujii Masao wrote: > On Thu, Mar 19, 2015 at 1:43 PM, Michael Paquier > wrote: >> On Thu, Mar 19, 2015 at 12:40 PM, Michael Paquier >> wrote: >>> On Thu, Mar 19, 2015 at 12:23 PM, Fujii Masao wrote: Are you planning to update the patch so that it's based on

Re: [HACKERS] Order of enforcement of CHECK constraints?

I might be only one objecting here but ... On Sat, Mar 21, 2015 at 12:45 AM, Tom Lane wrote: > My Salesforce colleagues noticed some tests flapping as a result of table > CHECK constraints not always being enforced in the same order; ie, if a > tuple insertion/update violates more than one CHECK

Re: [HACKERS] Display of multi-target-table Modify plan nodes in EXPLAIN

Ashutosh Bapat writes: > On Sun, Mar 22, 2015 at 6:32 AM, Tom Lane wrote: >> What I'm imagining instead is that when there's more than one >> target relation, we produce output like ... > This looks better. > In the format above, you have specified both the Remote SQL for scan as > well as updat

Re: [HACKERS] Display of multi-target-table Modify plan nodes in EXPLAIN

On Sun, Mar 22, 2015 at 6:32 AM, Tom Lane wrote: > I've gotten the foreign table inheritance patch to a state where I'm > almost ready to commit it, but there's one thing that's bothering me, > which is what it does for EXPLAIN. As it stands you might get something > like > > regression=# explai

Re: [HACKERS] Table-level log_autovacuum_min_duration

On Thu, Mar 19, 2015 at 1:43 PM, Michael Paquier wrote: > On Thu, Mar 19, 2015 at 12:40 PM, Michael Paquier > wrote: >> On Thu, Mar 19, 2015 at 12:23 PM, Fujii Masao wrote: >>> Are you planning to update the patch so that it's based on the commit >>> 0d83138? >> >> Yes... Very soon. > > And her

[HACKERS] recovery_target_time ignored ?

Hi, Assuming that this might require a patch, i am posting this in pgsql-hackers. Apologies, if this is not the appropriate mailing list to start this discussion. I performed a PITR and saw the below message in the log file is a bit confusing. 2015-03-23 13:49:09.816 GMT-10 DB= PID=4707 LOG: * d

Re: [HACKERS] Zero-padding and zero-masking fixes for to_char(float)

Bruce Momjian writes: > On Sun, Mar 22, 2015 at 12:46:08PM -0400, Noah Misch wrote: >> I recommend adding a "configure" test to use our snprintf.c replacements if >> sprintf("%.*f", 65536, 999.0) gives unexpected output. > Do we really want to go to our /port snprintf just to handle 512+

Re: [HACKERS] New functions

On Mon, Mar 23, 2015 at 1:48 AM, Воронин Дмитрий wrote: > >> Please, attach new version of my patch to commitfest page. > > Michael, I found a way to attach patch. sorry to trouble. Cool. Thanks. I am seeing your patch entry here: https://commitfest.postgresql.org/5/192/ I'll try to take a look

Re: [HACKERS] Zero-padding and zero-masking fixes for to_char(float)

On Sun, Mar 22, 2015 at 10:53:12PM -0400, Bruce Momjian wrote: > > > *** int4_to_char(PG_FUNCTION_ARGS) > > > *** 5214,5221 > > > /* we can do it easily because float8 won't lose any > > > precision */ > > > float8 val = (float8) value;

Re: [HACKERS] Resetting crash time of background worker

On 17 March 2015 at 19:12, Robert Haas wrote: > On Tue, Mar 17, 2015 at 1:33 AM, Amit Khandekar > wrote: > > I think we either have to retain the knowledge that the worker has > crashed > > using some new field, or else, we should reset the crash time only if it > is > > not flagged BGW_NEVER_RE

Re: [HACKERS] Zero-padding and zero-masking fixes for to_char(float)

On Sun, Mar 22, 2015 at 04:41:19PM -0400, Noah Misch wrote: > When you posted this, I made a note to review it. > > On Wed, Mar 18, 2015 at 05:52:44PM -0400, Bruce Momjian wrote: > > This "junk" digit zeroing matches the Oracle behavior: > > > > SELECT to_char(1.123456789123456789123456789d,

Re: [HACKERS] Zero-padding and zero-masking fixes for to_char(float)

On Sun, Mar 22, 2015 at 12:46:08PM -0400, Noah Misch wrote: > On Sun, Mar 22, 2015 at 11:22:26AM -0400, Bruce Momjian wrote: > > What has me more concerned is the Solaris 10 failure. This query: > > > > SELECT to_char(float8 '999', 'D' || repeat('9', > > 1000)); > >

Re: [HACKERS] debug_sortsupport GUC?

On Sun, Mar 22, 2015 at 6:59 PM, Andrew Gierth wrote: > Ungh... yes, it's defined by default, but it clearly still requires > keeping the #ifdefs in there in order to still build if someone manually > undefines it. Was hoping to avoid the #ifdefs entirely - perhaps the > existing #ifdefs should ju

Re: [HACKERS] Abbreviated keys for Numeric

On Sun, Mar 22, 2015 at 6:48 PM, Andrew Gierth wrote: > Your version would have aborted abbrevation on that second query, thus > losing a 3 second speedup. How on earth is that supposed to be > justified? It's not like there's any realistically possible case where > your version performs faster th

Re: [HACKERS] debug_sortsupport GUC?

> "Peter" == Peter Geoghegan writes: >> So if these debugging elogs are to be kept at all, I propose that >> rather than being compile-time options they should be controlled by >> a debug_sortsupport GUC. Opinions? Peter> This seems like a reasonable idea. Why wouldn't it just be under

Re: [HACKERS] Abbreviated keys for Numeric

> "Peter" == Peter Geoghegan writes: >> Was there some reason why you added #include "utils/memutils.h"? >> Because I don't see anything in your patch that actually needs it. Peter> MaxAllocSize is defiined there. So it is. (That seems to me to be another mistake along the same lines as

Re: [HACKERS] Abbreviated keys for Numeric

> "Peter" == Peter Geoghegan writes: Peter> I don't think it's that simple. The actual point of abbreviation Peter> is to amortize the total cost of performing O(n log n) Peter> comparisons (the average case, which is usually assumed by Peter> infrastructure like sortsupport), by performi

Re: [HACKERS] Parallel Seq Scan

On 20-03-2015 PM 09:06, Amit Kapila wrote: > On Mon, Mar 16, 2015 at 12:58 PM, Amit Langote < > langote_amit...@lab.ntt.co.jp> wrote: >> Actually I meant "currently the last" or: >> >> funnel->nextqueue == funnel->nqueue - 1 >> >> So the code you quote would only take care of subset of the case

Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)

> On Wed, Mar 18, 2015 at 9:33 AM, Kouhei Kaigai wrote: > >> On Wed, Mar 18, 2015 at 2:34 AM, Kouhei Kaigai > >> wrote: > >> > So, overall consensus for the FDW hook location is just before the > >> > set_chepest() > >> > at standard_join_search() and merge_clump(), isn't it? > >> > >> Yes, I t

Re: [HACKERS] Abbreviated keys for Numeric

On Fri, Mar 20, 2015 at 11:58 PM, Andrew Gierth wrote: > Comparisons between nulls and nulls, or between nulls and non-nulls, are > cheap; only comparisons between non-nulls and non-nulls can be > expensive. > > The purpose of abbreviation is to replace expensive comparisons by cheap > ones where

Re: [HACKERS] Remove fsync ON/OFF as a visible option?

On 22/03/15 08:14, Jaime Casanova wrote: El mar 21, 2015 2:00 AM, "Mark Kirkwood" mailto:mark.kirkw...@catalyst.net.nz>> escribió: > > On 21/03/15 19:28, Jaime Casanova wrote: >> >> what about not removing it but not showing it in postgresql.conf? as a >> side note, i wonder why trace_sort

Re: [HACKERS] debug_sortsupport GUC?

On Sat, Mar 21, 2015 at 8:28 PM, Andrew Gierth wrote: > So if these debugging elogs are to be kept at all, I propose that rather > than being compile-time options they should be controlled by a > debug_sortsupport GUC. Opinions? This seems like a reasonable idea. Why wouldn't it just be under the

Re: [HACKERS] Abbreviated keys for Numeric

On Sat, Mar 21, 2015 at 3:33 PM, Andrew Gierth wrote: > Was there some reason why you added #include "utils/memutils.h"? > Because I don't see anything in your patch that actually needs it. MaxAllocSize is defiined there. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hacke

[HACKERS] barnacle (running CLOBBER_CACHE_RECURSIVELY) seems stuck since November

Hi, I've been checking progress on barnacle, one of the animals running with CLOBBER_CACHE_RECURSIVELY. It's running for ~170 days (250k minutes). This time I've however checked the log, and what caught my eye is that the last log message is from November. There were regular messages until then (

Re: [HACKERS] INT64_MIN and _MAX

On Sun, Mar 22, 2015 at 2:26 AM, Andres Freund wrote: > I have been annoyed by this multiple times. I think we should make sure the > C99 defines are there (providing values if they aren't) and always use those. > We've used them in parts of the tree long enough that it's unlikely to cause > pr

Re: [HACKERS] Remove fsync ON/OFF as a visible option?

On Sun, Mar 22, 2015 at 3:34 PM, Euler Taveira wrote: > On 21-03-2015 17:53, Josh Berkus wrote: >> Now, I have *long* been an advocate that we should ship a "stripped" >> PostgreSQL.conf which has only the most commonly used settings, and >> leave the rest of the settings in the docs and >> share/

Re: [HACKERS] Using 128-bit integers for sum, avg and statistics aggregates

On 2015-03-22 22:28:01 +0100, Andreas Karlsson wrote: > On 03/22/2015 10:20 PM, Andres Freund wrote: > >Yes, or a compiler bug. I looked through the code again and found and > >fixed one minor bug, but that doesnt' explain the problem. > > Strangely enough the bug looks like it has been fixed at j

Re: [HACKERS] Using 128-bit integers for sum, avg and statistics aggregates

On 2015-03-22 22:20:49 +0100, Andres Freund wrote: > A compiler bug looks like a not unreasonable bet at this point. I've > asked Andrew to recompile without optimizations... We'll see whether > that makes a difference. Jacana is the only compiler with gcc 4.8.1 (or > is it 4.8.0? there's conflicti

Re: [HACKERS] Using 128-bit integers for sum, avg and statistics aggregates

On 03/22/2015 10:20 PM, Andres Freund wrote: Yes, or a compiler bug. I looked through the code again and found and fixed one minor bug, but that doesnt' explain the problem. Strangely enough the bug looks like it has been fixed at jacana after your fix of my copypasto. Maybe the bug is random,

Re: [HACKERS] Using 128-bit integers for sum, avg and statistics aggregates

On 2015-03-22 22:00:13 +0100, Petr Jelinek wrote: > On 22/03/15 13:59, Andreas Karlsson wrote: > >Would this mean the bug is most likely somewhere in > >int128_to_numericvar()? Maybe that version of gcc has a bug in some > >__int128 operator or I messed up the code there somehow. Yes, or a compile

Re: [HACKERS] Remove fsync ON/OFF as a visible option?

* David G. Johnston: > On Sunday, March 22, 2015, Florian Weimer wrote: > >> * David G. Johnston: >> >> > "​enables or disables data durability ​promise of ACID." ? >> >> “fsync = on” only works if the storage stack doesn't do funny things. >> Depending on the system, it might not be sufficient.

Re: [HACKERS] Using 128-bit integers for sum, avg and statistics aggregates

On 22/03/15 13:59, Andreas Karlsson wrote: On 03/22/2015 11:47 AM, Petr Jelinek wrote: On 22/03/15 10:35, Andres Freund wrote: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana&dt=2015-03-21%2003%3A01%3A21 That's the stuff looking like random memory that I talk about above...

Re: [HACKERS] Zero-padding and zero-masking fixes for to_char(float)

When you posted this, I made a note to review it. On Wed, Mar 18, 2015 at 05:52:44PM -0400, Bruce Momjian wrote: > This "junk" digit zeroing matches the Oracle behavior: > > SELECT to_char(1.123456789123456789123456789d, > '9.9') as x from dual; >

Re: [HACKERS] Abbreviated keys for Numeric

So here's a version 3 patch: 1. #ifdefism is reduced to a minimum by (a) desupporting values of NBASE other than 1, and (b) keeping the 32bit code, so that there is now no longer any question of abbreviation not being used (it always is). So the only #ifs in the code body (rather than declarat

Re: [HACKERS] PATCH: numeric timestamp in log_line_prefix

On 22.3.2015 20:25, Fabien COELHO wrote: > >>> The proposed format is much simpler to manage in a script, and if you're >>> interested in runtime, its formatting would be less expensive than %t >>> and >>> %m. >> >> Maybe, but do we really need two? How about just %M? > > I guess Tomas put 2 for

Re: [HACKERS] Remove fsync ON/OFF as a visible option?

On 03/22/2015 06:45 AM, Andres Freund wrote: > On 2015-03-21 13:53:47 -0700, Josh Berkus wrote: >> Coincidentally, I am just at this moment performance testing "running >> with scissors mode" for PostgreSQL on AWS. When intentional, this mode >> is useful for spinning up lots of read-only replica

Re: [HACKERS] PATCH: numeric timestamp in log_line_prefix

On 22.3.2015 19:45, Fabien COELHO wrote: > >>> I'm not sure that the "." in "%.03d" is useful. ISTM that it is used for >>> floatting point formatting, but is not needed with integers. >> >> It is needed for integers, because you need to make sure 1 millisecond >> is formatted as .001 and not .1.

Re: [HACKERS] PATCH: numeric timestamp in log_line_prefix

[oops, stalled because of wrong From, resending just to the list] On Sun, 22 Mar 2015, Tom Lane wrote: The proposed format is much simpler to manage in a script, and if you're interested in runtime, its formatting would be less expensive than %t and %m. Maybe, but do we really need two? How

Re: [HACKERS] PATCH: numeric timestamp in log_line_prefix

On Sat, Mar 21, 2015 at 4:47 PM, Tomas Vondra wrote: > Hi, > > from time to time I need to correlate PostgreSQL logs to other logs, > containing numeric timestamps - a prime example of that is pgbench. With > %t and %m that's not quite trivial, because of timezones etc. > > I propose adding two n

Re: [HACKERS] PATCH: numeric timestamp in log_line_prefix

Fabien COELHO writes: >> On 2015-03-22 00:47:12 +0100, Tomas Vondra wrote: >>> from time to time I need to correlate PostgreSQL logs to other logs, >>> containing numeric timestamps - a prime example of that is pgbench. With >>> %t and %m that's not quite trivial, because of timezones etc. >> I h

Re: [HACKERS] PATCH: numeric timestamp in log_line_prefix

On 2015-03-22 00:47:12 +0100, Tomas Vondra wrote: from time to time I need to correlate PostgreSQL logs to other logs, containing numeric timestamps - a prime example of that is pgbench. With %t and %m that's not quite trivial, because of timezones etc. I have a hard time seing this is suffic

Re: [HACKERS] Remove fsync ON/OFF as a visible option?

On Sunday, March 22, 2015, Florian Weimer wrote: > * David G. Johnston: > > > "​enables or disables data durability ​promise of ACID." ? > > “fsync = on” only works if the storage stack doesn't do funny things. > Depending on the system, it might not be sufficient. > Allows for (underlying stora

Re: [HACKERS] PATCH: numeric timestamp in log_line_prefix

On 2015-03-22 00:47:12 +0100, Tomas Vondra wrote: > from time to time I need to correlate PostgreSQL logs to other logs, > containing numeric timestamps - a prime example of that is pgbench. With > %t and %m that's not quite trivial, because of timezones etc. I have a hard time seing this is suffi

Re: [HACKERS] PATCH: numeric timestamp in log_line_prefix

I'm not sure that the "." in "%.03d" is useful. ISTM that it is used for floatting point formatting, but is not needed with integers. It is needed for integers, because you need to make sure 1 millisecond is formatted as .001 and not .1. ISTM that the "03" does that on its own: sh> printf

Re: [HACKERS] PATCH: numeric timestamp in log_line_prefix

On 22.3.2015 08:14, David Rowley wrote: > Hi Tomas, > > I just had a quick glance at this. > Is there a reason you didn't include code to support the space padding > for the new log_line_prefixes? > The others support % in the prefix, to allow left or > right alignment of the item. Didn't realiz

Re: [HACKERS] PATCH: numeric timestamp in log_line_prefix

On 22.3.2015 16:58, Fabien COELHO wrote: > > About the feature: I find it is a good thing. It may help scripting over > the logs, for instance to compute delays between events, whereas the > full date-time-tz syntax is maybe nice but heavier to work with afterwards. > > In addition to the comment

Re: [HACKERS] inherit support for foreign tables

On Sun, Mar 22, 2015 at 1:57 PM, Tom Lane wrote: > Etsuro Fujita writes: >> [ fdw-inh-8.patch ] > > I've committed this with some substantial rearrangements, notably: I'm really glad this is going in! Thanks to to Shigeru Hanada and Etsuro Fujita for working on this, to you (Tom) for putting in

Re: [HACKERS] Patch: Add launchd Support

On Mar 20, 2015, at 4:11 PM, David E. Wheeler wrote: > No one replied. Want a new patch with that? Here it is. Best, David launchd2.patch Description: Binary data smime.p7s Description: S/MIME cryptographic signature

Re: [HACKERS] inherit support for foreign tables

Etsuro Fujita writes: > [ fdw-inh-8.patch ] I've committed this with some substantial rearrangements, notably: * I thought that if we were doing this at all, we should go all the way and allow foreign tables to be both inheritance parents and children. * As I mentioned earlier, I got rid of a f

Re: [HACKERS] Remove fsync ON/OFF as a visible option?

* David G. Johnston: > "​enables or disables data durability ​promise of ACID." ? “fsync = on” only works if the storage stack doesn't do funny things. Depending on the system, it might not be sufficient. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: [HACKERS] INT64_MIN and _MAX

> "Andres" == Andres Freund writes: >> Hm, it looks like the same could be said for INT32_MIN and _MAX; >> some places use INT_MIN etc., others say "we shouldn't assume int = >> int32" and use (-0x7fff - 1) or whatever instead. Andres> I have been annoyed by this multiple times. I th

Re: [HACKERS] New functions

>  Please, attach new version of my patch to commitfest page. Micheal, I found a way to attach patch. sorry to trouble. --  Best regards, Dmitry Voronin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpre

Re: [HACKERS] Zero-padding and zero-masking fixes for to_char(float)

On Sun, Mar 22, 2015 at 11:22:26AM -0400, Bruce Momjian wrote: > What has me more concerned is the Solaris 10 failure. This query: > > SELECT to_char(float8 '999', 'D' || repeat('9', > 1000)); > > expects this: > > 999.000... > > but on Sola

Re: [HACKERS] PATCH: numeric timestamp in log_line_prefix

About the feature: I find it is a good thing. It may help scripting over the logs, for instance to compute delays between events, whereas the full date-time-tz syntax is maybe nice but heavier to work with afterwards. In addition to the comments already made (typo in doc, padding...): +s

Re: [HACKERS] Remove fsync ON/OFF as a visible option?

On 21-03-2015 17:53, Josh Berkus wrote: > Now, I have *long* been an advocate that we should ship a "stripped" > PostgreSQL.conf which has only the most commonly used settings, and > leave the rest of the settings in the docs and > share/postgresql/postgresql.conf.advanced. Here's my example of su

Re: [HACKERS] Zero-padding and zero-masking fixes for to_char(float)

On Sun, Mar 22, 2015 at 01:42:56AM -0400, Tom Lane wrote: > David Rowley writes: > > This seems to have broken jacana. Looks like MSVC by default has a 3 digit > > exponent. > > jacana was broken before this patch; but some other Windows critters > are now unhappy as well. > > > Going by this:

Re: [HACKERS] Order of enforcement of CHECK constraints?

On Sunday, March 22, 2015, David Steele wrote: > On 3/20/15 3:37 PM, Tom Lane wrote: > > =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= > writes: > >> On Fri, Mar 20, 2015 at 4:19 PM, Peter Geoghegan > wrote: > >>> On Fri, Mar 20, 2015 at 12:15 PM, Tom Lane > wrote: > We could fix it by, say, h

Re: [HACKERS] Order of enforcement of CHECK constraints?

On 3/20/15 3:37 PM, Tom Lane wrote: > =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes: >> On Fri, Mar 20, 2015 at 4:19 PM, Peter Geoghegan wrote: >>> On Fri, Mar 20, 2015 at 12:15 PM, Tom Lane wrote: We could fix it by, say, having CheckConstraintFetch() sort the constraints by name af

Re: [HACKERS] Remove fsync ON/OFF as a visible option?

On 2015-03-21 13:53:47 -0700, Josh Berkus wrote: > Coincidentally, I am just at this moment performance testing "running > with scissors mode" for PostgreSQL on AWS. When intentional, this mode > is useful for spinning up lots of read-only replicas which are intended > mainly as cache support, so

Re: [HACKERS] Using 128-bit integers for sum, avg and statistics aggregates

On 03/22/2015 11:47 AM, Petr Jelinek wrote: On 22/03/15 10:35, Andres Freund wrote: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana&dt=2015-03-21%2003%3A01%3A21 That's the stuff looking like random memory that I talk about above... If you look at it closely, it's actually not

Re: [HACKERS] New functions

Hello, Michael. Please, attach new version of my patch to commitfest page. --  Best regards, Dmitry Voronin *** /dev/null --- b/contrib/sslinfo/sslinfo--1.0--1.1.sql *** *** 0 --- 1,21 + /* contrib/sslinfo/sslinfo--1.0--1.1.sql */ + + -- complain if script is sourced in psq

Re: [HACKERS] PITR failing to stop before DROP DATABASE

On March 22, 2015 12:17:57 PM GMT+01:00, Christoph Berg wrote: >Re: Bruce Momjian 2015-03-20 <20150320223549.gz6...@momjian.us> >> > > >So my suggestion for a simple fix would be to make DROP DATABASE >> > > >execute a short fake transaction before it starts deleting files >and >> > > >then contin

Re: [HACKERS] PITR failing to stop before DROP DATABASE

Re: Bruce Momjian 2015-03-20 <20150320223549.gz6...@momjian.us> > > > >So my suggestion for a simple fix would be to make DROP DATABASE > > > >execute a short fake transaction before it starts deleting files and > > > >then continue as before. This would serve as a stopping point for > > > >recover

Re: [HACKERS] printing table in asciidoc with psql

On Sun, Mar 22, 2015 at 10:09 AM, Bruce Momjian wrote: > On Sat, Mar 21, 2015 at 09:20:03PM +0900, Michael Paquier wrote: >> This does not work: >> =# create table "5 2.2+^.^" (); >> CREATE TABLE >> =# \pset format asciidoc >> Output format is asciidoc. >> =# \d >> >> .List of relations >> [option

Re: [HACKERS] proposal: searching in array function - array_position

2015-03-22 11:30 GMT+01:00 Dean Rasheed : > On 22 March 2015 at 06:11, Pavel Stehule wrote: > > Hi > > > > here is updated patch with array_position, array_positions > implementation. > > > > It is based on committed code - so please, revert commit > > 13dbc7a824b3f905904cab51840d37f31a07a9ef and

Re: [HACKERS] Using 128-bit integers for sum, avg and statistics aggregates

On 22/03/15 10:35, Andres Freund wrote: On March 22, 2015 10:34:04 AM GMT+01:00, Michael Paquier wrote: On Sun, Mar 22, 2015 at 6:22 PM, Andres Freund That's due to a different patch though, right? When I checked earlier only jacana had problems due to this, and it looked like random memory

Re: [HACKERS] proposal: searching in array function - array_position

On 22 March 2015 at 06:11, Pavel Stehule wrote: > Hi > > here is updated patch with array_position, array_positions implementation. > > It is based on committed code - so please, revert commit > 13dbc7a824b3f905904cab51840d37f31a07a9ef and apply this patch > I checked this and the changes look go

[HACKERS] Fix pgbench --progress report under (very) low rate

When running with low rate, the --progress is only printed when there is some activity, which makes it quite irregular, including some catching up with stupid tps figures. Shame on me for this "feature" (aka bug) in the first place. This patch fixes this behavior by considering the next repo

Re: [HACKERS] [PATCH] Add transforms feature

2015-03-22 3:55 GMT+01:00 Peter Eisentraut : > Here is an updated patch. > > On 3/17/15 1:11 AM, Pavel Stehule wrote: > > 2015-03-17 2:51 GMT+01:00 Peter Eisentraut > >: > > > > On 3/12/15 8:12 AM, Pavel Stehule wrote: > > > 1. fix missing semicolon pg_proc.h > >

Re: [HACKERS] Using 128-bit integers for sum, avg and statistics aggregates

On Sun, Mar 22, 2015 at 6:34 PM, David Rowley wrote: > On 22 March 2015 at 22:22, Andres Freund wrote: >> >> On March 22, 2015 6:17:28 AM GMT+01:00, Michael Paquier >> wrote: >> >On Sun, Mar 22, 2015 at 12:32 AM, Tom Lane wrote: >> >> Andres Freund writes: >> >>> Pushed with that additional ch

Re: [HACKERS] Using 128-bit integers for sum, avg and statistics aggregates

On March 22, 2015 10:34:04 AM GMT+01:00, Michael Paquier wrote: >On Sun, Mar 22, 2015 at 6:22 PM, Andres Freund >wrote: >> On March 22, 2015 6:17:28 AM GMT+01:00, Michael Paquier > wrote: >>>On Sun, Mar 22, 2015 at 12:32 AM, Tom Lane wrote: Andres Freund writes: > Pushed with that add

Re: [HACKERS] Using 128-bit integers for sum, avg and statistics aggregates

On 22 March 2015 at 22:22, Andres Freund wrote: > On March 22, 2015 6:17:28 AM GMT+01:00, Michael Paquier < > michael.paqu...@gmail.com> wrote: > >On Sun, Mar 22, 2015 at 12:32 AM, Tom Lane wrote: > >> Andres Freund writes: > >>> Pushed with that additional change. Let's see if the buildfarm >

Re: [HACKERS] Using 128-bit integers for sum, avg and statistics aggregates

On Sun, Mar 22, 2015 at 6:22 PM, Andres Freund wrote: > On March 22, 2015 6:17:28 AM GMT+01:00, Michael Paquier > wrote: >>On Sun, Mar 22, 2015 at 12:32 AM, Tom Lane wrote: >>> Andres Freund writes: Pushed with that additional change. Let's see if the buildfarm >>thinks. >>> >>> jacana, a

Re: [HACKERS] Lets delete src/test/performance

On March 22, 2015 3:21:34 AM GMT+01:00, Bruce Momjian wrote: >On Thu, Mar 19, 2015 at 09:57:05PM -0400, Bruce Momjian wrote: >> > commit cf76759f34a172d424301cfa3723baee37f4a7ce >> > Author: Vadim B. Mikheev >> > Date: Fri Sep 26 14:55:21 1997 + >> > >> > Start with performance suite.

Re: [HACKERS] No toast table for pg_shseclabel but for pg_seclabel

On March 22, 2015 3:15:07 AM GMT+01:00, Bruce Momjian wrote: >On Thu, Mar 19, 2015 at 11:50:36AM -0400, Bruce Momjian wrote: >> > Then there's the other discussion about using the security labels >> > structure for more than just security labels, which could end up >with a >> > lot of other use-ca

Re: [HACKERS] INT64_MIN and _MAX

On March 22, 2015 6:19:52 AM GMT+01:00, Andrew Gierth wrote: >> "Andrew" == Andrew Gierth writes: > >> "Petr" == Petr Jelinek writes: > So wouldn't it make more sense to move these definitions into c.h >and > >>> standardize their usage? > >Petr> I was thinking the same when I've s

Re: [HACKERS] Using 128-bit integers for sum, avg and statistics aggregates

On March 22, 2015 6:17:28 AM GMT+01:00, Michael Paquier wrote: >On Sun, Mar 22, 2015 at 12:32 AM, Tom Lane wrote: >> Andres Freund writes: >>> Pushed with that additional change. Let's see if the buildfarm >thinks. >> >> jacana, apparently alone among buildfarm members, does not like it. > >All

Re: [HACKERS] [PATCH] Add transforms feature

2015-03-22 5:45 GMT+01:00 Pavel Stehule : > > > 2015-03-22 3:55 GMT+01:00 Peter Eisentraut : > >> Here is an updated patch. >> >> On 3/17/15 1:11 AM, Pavel Stehule wrote: >> > 2015-03-17 2:51 GMT+01:00 Peter Eisentraut > > >: >> > >> > On 3/12/15 8:12 AM, Pavel Stehule

Re: [HACKERS] PATCH: numeric timestamp in log_line_prefix

On 22 March 2015 at 12:47, Tomas Vondra wrote: > > I propose adding two new log_line_prefix escape sequences - %T and %M, > doing the same thing as %t and %m, but formatting the value as a number. > > Hi Tomas, I just had a quick glance at this. Is there a reason you didn't include code to suppo