On Wed, Jul 15, 2015 at 10:21 PM, Andrew Gierth wrote:
> > "Jeevan" == Jeevan Chalke writes:
>
> Jeevan> Hi,
> Jeevan> It looks like we do support nested GROUPING SETS, I mean Sets
> Jeevan> withing Sets, not other types. However this nesting is broken.
>
> Good catch, but I'm not yet su
On 7 July 2015 at 21:37, Julien Rouhaud wrote:
> Well, I obviously missed that pg_srand48() is only used if the system
> lacks random/srandom, sorry for the noise. So yes, random() must be
> used instead of pg_lrand48().
>
> I'm attaching a new version of the patch fixing this issue just in case
2015-07-17 6:26 GMT+02:00 Joshua D. Drake :
>
>
>
>> it is one possible solution too
>>
>> multiple -c option has advantage of simple evaluation of backslash
>> statements .. -c "\l" -c "\dt" - but this advantage is not high important.
>>
>
> Or just properly understand the ; ?
>
> -c "select * fr
it is one possible solution too
multiple -c option has advantage of simple evaluation of backslash
statements .. -c "\l" -c "\dt" - but this advantage is not high important.
Or just properly understand the ; ?
-c "select * from foo; update bar set baz = 'bing'; vacuum bar;"
JD
Pavel
On 16 July 2015 at 05:07, Jeff Davis wrote:
> On Wed, 2015-07-15 at 12:59 +0530, Atri Sharma wrote:
>
> >
> > I think a heuristic would be more suited here and ignoring memory
> > consumption for internal types means that we are not making the memory
> > accounting useful for a set of usecases.
>
Peter Geoghegan writes:
> Attached patch adds a portable Postgres wrapper on the GCC intrinsic.
Meh. I don't like the assumption that non-GCC compilers will be smart
enough to optimize away the useless-to-them if() tests this adds.
Please refactor that so that there is exactly 0 new code when th
On Wed, Jul 1, 2015 at 9:31 PM, Fujii Masao wrote:
> On Wed, Jul 1, 2015 at 2:21 AM, Heikki Linnakangas wrote:
>> On 06/29/2015 09:44 AM, Michael Paquier wrote:
>>>
>>> On Mon, Jun 29, 2015 at 4:55 AM, Heikki Linnakangas wrote:
But we'll still need to handle the pg_xlog symlink case som
On Thu, Jul 16, 2015 at 12:30 PM, Alvaro Herrera
wrote:
>
> Amit Kapila wrote:
>
> > This can be tracked either in 9.5 Open Items or for next CF,
> > any opinions?
> >
> > If nobody else has any opinion on this, I will add it to 9.5 Open Items
> > list.
>
> I think this belongs in the open items l
On Thu, Jul 16, 2015 at 11:10 PM, Robert Haas wrote:
>
> On Thu, Jul 16, 2015 at 1:32 PM, Simon Riggs
wrote:
>
> > * Developers will immediately understand the format
>
> I doubt it. I think any format that we pick will have to be carefully
> documented. People may know what JSON looks like in
2015-07-17 0:03 GMT+02:00 dinesh kumar :
> On Thu, Jul 16, 2015 at 12:42 PM, Pavel Stehule
> wrote:
>
>> Hi
>>
>> can we support multiple "-c" option?
>>
>> Why? Because some statements like VACUUM cannot be used together with any
>> other statements with single -c option. The current solution is
On Thu, Jul 16, 2015 at 9:54 PM, Fujii Masao wrote:
> Isn't this "rule" confusing the administrators?
I'd like to think not, but yeah, it probably is. It is not like it
isn't documented. There are even comments in postgresql.conf
explaining it. But the fact that we have committers who are conf
Peter Geoghegan writes:
> I've heard that clock_gettime() with CLOCK_REALTIME_COARSE, or with
> CLOCK_MONOTONIC_COARSE can have significantly lower overhead than
> gettimeofday().
It can, but it also has *much* lower precision, typically 1ms or so.
regards, tom lane
--
Peter Geoghegan writes:
> On Thu, Jul 16, 2015 at 5:05 PM, Tom Lane wrote:
>> It's possible that this issue can only manifest on 9.4 and up where
>> we have the ability for tuplesort to allocate work arrays approaching
>> INT_MAX elements. But I don't have a lot of faith in that; I think the
>>
On Tue, Jul 14, 2015 at 7:25 AM, Tom Lane wrote:
> FWIW, I entirely share Robert's opinion that adding gettimeofday()
> overhead in routinely-taken paths is likely not to be acceptable.
I think that it can depend on many factors. For example, the
availability of vDSO support on Linux/glibc.
I've
On Fri, Jul 17, 2015 at 1:28 AM, Robert Haas wrote:
> On Thu, Jul 16, 2015 at 9:41 AM, Fujii Masao wrote:
>> Here are some minor comments:
>>
>> +ereport(LOG,
>> +(errmsg("ignoring \"%s\" file because no
>> \"%s\" file exists",
>> +
On Fri, Jun 26, 2015 at 12:41 AM, Fabrízio de Royes Mello
wrote:
>
>
> On Wed, Jun 24, 2015 at 3:36 PM, Alvaro Herrera
> wrote:
>>
>> Fabrízio de Royes Mello wrote:
>>
>> > Another rebased version.
>>
>> There are a number of unrelated whitespace changes in this patch; also
>> please update the c
On Thu, Jul 16, 2015 at 10:17 PM, Amit Kapila wrote:
> On Thu, Jul 16, 2015 at 11:21 AM, Haribabu Kommi
> wrote:
>
>>
>> Here I attached updated patches,
>> 1) without prefetch logic.
>> 2) with combined vm and prefetch logic.
>>
>
> I think it is better to just get the first patch in as that in
On Fri, Jul 17, 2015 at 1:08 AM, Paul Ramsey wrote:
> + if ( (!is_builtin(oe->opno)) &&
> (!is_in_extension(oe->opno, fpinfo)) )
> ... And this does not respect the project code format. See here for
> more details for example:
> http://www.postgresql.org/docs/devel/static/source.html
>
> I’m sorry,
On Thu, Jul 16, 2015 at 5:05 PM, Tom Lane wrote:
> It's possible that this issue can only manifest on 9.4 and up where
> we have the ability for tuplesort to allocate work arrays approaching
> INT_MAX elements. But I don't have a lot of faith in that; I think the
> worst-case stack depth for the
I've been trying to figure out the crash in qsort reported here:
http://www.postgresql.org/message-id/flat/cal8hzunr2fr1owzhwg-p64gjtnfbbmpx1y2oxmj_xuq3p8y...@mail.gmail.com
I first noticed that our qsort code uses an int to hold some transient
values representing numbers of elements. Since the p
On Thu, Jul 16, 2015 at 4:01 PM, Peter Geoghegan wrote:
> Attached patch adds a portable Postgres wrapper on the GCC intrinsic.
> It also adds a client within tuplesort.c -- a common function that
> seems like a good generic choke point. I can get a speed-up of 6% - 9%
> for all of these cases by
I've always thought that GCC intrinsics for software-based memory
prefetching are a very sharp tool. While it's really hard to use GCC's
__builtin_prefetch() effectively (I've tried enough times to know), I
always thought that there'd probably end up being a handful of cases
where using it presente
Vignesh Raghunathan writes:
> I was looking at the documentation for TOAST (
> http://www.postgresql.org/docs/devel/static/storage-toast.html) and it's
> specified that the toast pointer occupies 18 bytes. However, the struct
> representing the toast pointer is defined as follows
> typedef struct
Hello,
I was looking at the documentation for TOAST (
http://www.postgresql.org/docs/devel/static/storage-toast.html) and it's
specified that the toast pointer occupies 18 bytes. However, the struct
representing the toast pointer is defined as follows
typedef struct varatt_external
{
int3
On Thu, Jul 16, 2015 at 11:51 AM, Robert Haas wrote:
>
> I don't understand these issues in great technical depth, but if
> somebody is arguing that it's OK for PostgreSQL to be difficult to use
> for a certain category of user for several years until the next
> language rev becomes mainstream, th
On 2015-07-16 13:08:48 -0400, Robert Haas wrote:
> On Thu, Jul 16, 2015 at 12:54 PM, Andres Freund wrote:
> > Well, in combination with logical decoding it kinda has one: It should
> > allow you to take a dump of the database with a certain snapshot and
> > replay all transactions with a commit ls
On Thu, Jul 16, 2015 at 12:42 PM, Pavel Stehule
wrote:
> Hi
>
> can we support multiple "-c" option?
>
> Why? Because some statements like VACUUM cannot be used together with any
> other statements with single -c option. The current solution is using echo
> and pipe op, but it is a complication i
2015-07-16 23:10 GMT+02:00 Rosser Schwarz :
> On Thu, Jul 16, 2015 at 1:44 PM, Pavel Stehule
> wrote:
>
>> 2015-07-16 22:07 GMT+02:00 Fabrízio de Royes Mello <
>> fabriziome...@gmail.com>:
>>
>>> Why you want it if we already have the -f option that cover this use
>>> case?
>>>
>> It doesn't help
On Thu, Jul 16, 2015 at 1:44 PM, Pavel Stehule
wrote:
> 2015-07-16 22:07 GMT+02:00 Fabrízio de Royes Mello <
> fabriziome...@gmail.com>:
>
>> Why you want it if we already have the -f option that cover this use case?
>>
> It doesn't help me - we would to run script or remote script (via ssh)
> wi
2015-07-16 22:07 GMT+02:00 Fabrízio de Royes Mello
:
>
> On Thu, Jul 16, 2015 at 4:42 PM, Pavel Stehule
> wrote:
> >
> > Hi
> >
> > can we support multiple "-c" option?
> >
> > Why? Because some statements like VACUUM cannot be used together with
> any other statements with single -c option. The
On Thu, Jul 16, 2015 at 4:42 PM, Pavel Stehule
wrote:
>
> Hi
>
> can we support multiple "-c" option?
>
> Why? Because some statements like VACUUM cannot be used together with any
other statements with single -c option. The current solution is using echo
and pipe op, but it is a complication in so
Hi
can we support multiple "-c" option?
Why? Because some statements like VACUUM cannot be used together with any
other statements with single -c option. The current solution is using echo
and pipe op, but it is a complication in some complex scripts - higher
complication when you run psql via mu
2015-07-16 19:51 GMT+02:00 Robert Haas :
> On Wed, Jul 15, 2015 at 1:10 PM, Ryan Pedela
> wrote:
> > Like I said previously, the
> > situation with Javascript will hopefully be remedied in a few years with
> ES7
> > anyway.
>
> I don't understand these issues in great technical depth, but if
> so
On Wed, Jul 15, 2015 at 1:10 PM, Ryan Pedela wrote:
> Like I said previously, the
> situation with Javascript will hopefully be remedied in a few years with ES7
> anyway.
I don't understand these issues in great technical depth, but if
somebody is arguing that it's OK for PostgreSQL to be difficu
On Wed, Jul 15, 2015 at 12:58 PM, Andrew Dunstan wrote:
> The approach take was both invasive and broken.
Well, then let's not do it that way.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
On Thu, Jul 16, 2015 at 1:32 PM, Simon Riggs wrote:
>> Personally, I think we're going to find that using JSON for this
>> rather than a custom syntax makes the configuration strings two or
>> three times as long for
>
> They may well be 2-3 times as long. Why is that a negative?
In my opinion, b
On 16 July 2015 at 18:27, Robert Haas wrote:
> On Wed, Jul 15, 2015 at 5:03 AM, Michael Paquier
> wrote:
> >> Group labels are essential.
> >
> > OK, so this is leading us to the following points:
> > - Use a JSON object to define the quorum/priority groups for the sync
> state.
> > - Store it a
On Wed, Jul 15, 2015 at 5:03 AM, Michael Paquier
wrote:
>> Group labels are essential.
>
> OK, so this is leading us to the following points:
> - Use a JSON object to define the quorum/priority groups for the sync state.
> - Store it as a GUC, and use the check hook to validate its format,
> which
On Thu, Jul 16, 2015 at 12:54 PM, Andres Freund wrote:
> Well, in combination with logical decoding it kinda has one: It should
> allow you to take a dump of the database with a certain snapshot and
> replay all transactions with a commit lsn bigger than the "snapshot's
> lsn" and end up with a co
On Thu, Jul 16, 2015 at 10:54 AM, Tom Lane wrote:
> Ildus Kurbangaliev writes:
>> I made benchmark of gettimeofday(). I believe it is certainly usable for
>> monitoring.
>> Testing configuration:
>> 24 cores, Intel Xeon CPU X5675@3.07Ghz
>> RAM 24 GB
>
>> 54179703 - microseconds total
>> 214748
On 2015-07-16 12:40:07 -0400, Robert Haas wrote:
> On Wed, Jul 15, 2015 at 12:51 PM, Florent Guiliani
> wrote:
> > During slot creation, the snapshot building and exporting code seems
> > highly coupled with the logical decoding stuff. It doesn't seems much
> > reusable to retrieve the snapshot's
Robert Haas wrote:
> On Thu, Jul 16, 2015 at 9:41 AM, Fujii Masao wrote:
> > Here are some minor comments:
> >
> > +ereport(LOG,
> > +(errmsg("ignoring \"%s\" file because no
> > \"%s\" file exists",
> > +TABLESPACE_MAP, BACKU
On Wed, Jul 15, 2015 at 12:51 PM, Florent Guiliani wrote:
> During slot creation, the snapshot building and exporting code seems
> highly coupled with the logical decoding stuff. It doesn't seems much
> reusable to retrieve the snapshot's LSN outside of logical decoding.
I don't think "the snapsh
On Thu, Jul 16, 2015 at 9:41 AM, Fujii Masao wrote:
> Here are some minor comments:
>
> +ereport(LOG,
> +(errmsg("ignoring \"%s\" file because no
> \"%s\" file exists",
> +TABLESPACE_MAP, BACKUP_LABEL_FILE),
> +
Michael, thanks so much for the review!
On July 15, 2015 at 7:35:11 PM, Michael Paquier (michael.paqu...@gmail.com)
wrote:
This patch includes some diff noise, it would be better to remove that.
Done.
- if (!is_builtin(fe->funcid))
+ if (!is_builtin(fe->funcid) &&
(!is_in_extension(fe->funcid
On 2015-07-16 16:22, Tom Lane wrote:
Petr Jelinek writes:
On 2015-07-12 18:02, Tom Lane wrote:
A possible way around this problem is to redefine the sampling rule so
that it is not history-dependent but depends only on the tuple TIDs.
For instance, one could hash the TID of a candidate tuple,
Petr Jelinek writes:
> On 2015-07-16 15:59, Tom Lane wrote:
>> I'm not clear on whether sequence AMs would need explicit catalog
>> representation, or could be folded down to just a single SQL function
>> with special signature as I suggested for tablesample handlers.
>> Is there any need for a se
Ildus Kurbangaliev writes:
> I made benchmark of gettimeofday(). I believe it is certainly usable for
> monitoring.
> Testing configuration:
> 24 cores, Intel Xeon CPU X5675@3.07Ghz
> RAM 24 GB
> 54179703 - microseconds total
> 2147483647 - (INT_MAX), the number of gettimeofday() calls
>
On 2015-07-16 15:59, Tom Lane wrote:
Alvaro Herrera writes:
Petr Jelinek wrote:
On 2015-07-13 00:36, Tom Lane wrote:
PS: now that I've written this rant, I wonder why we don't redesign the
index AM API along the same lines. It probably doesn't matter much at
the moment, but if we ever get se
> On Jul 14, 2015, at 5:25 PM, Tom Lane wrote:
>
> Robert Haas writes:
>> I really think we should do the simple thing first. If we make this
>> complicated and add lots of bells and whistles, it is going to be much
>> harder to get anything committed, because there will be more things
>> for
Petr Jelinek writes:
> On 2015-07-12 18:02, Tom Lane wrote:
>> A possible way around this problem is to redefine the sampling rule so
>> that it is not history-dependent but depends only on the tuple TIDs.
>> For instance, one could hash the TID of a candidate tuple, xor that with
>> a hash of the
Amit Langote writes:
> On Thu, Jul 16, 2015 at 10:33 PM, Alvaro Herrera
> wrote:
>> Hmm, how would this work? Would we have index AM implementation run
>> some function that register their support methods somehow at startup?
> I recall a proposal by Alexander Korotkov about extensible access
>
On Thu, Jul 16, 2015 at 11:06 PM, Tom Lane wrote:
> Amit Langote writes:
>> On 2015-07-16 PM 12:43, Tom Lane wrote:
>>> The basic issue here is "how can a user control which functions/operators
>>> can be sent for remote execution?". While it's certainly true that
>>> sometimes you might want fu
Amit Langote writes:
> On 2015-07-16 PM 12:43, Tom Lane wrote:
>> The basic issue here is "how can a user control which functions/operators
>> can be sent for remote execution?". While it's certainly true that
>> sometimes you might want function-by-function control of that, Paul's
>> point was t
On Thu, Jul 16, 2015 at 10:33 PM, Alvaro Herrera
wrote:
> Petr Jelinek wrote:
>> On 2015-07-13 00:36, Tom Lane wrote:
>
>> >PS: now that I've written this rant, I wonder why we don't redesign the
>> >index AM API along the same lines. It probably doesn't matter much at
>> >the moment, but if we e
Alvaro Herrera writes:
> Petr Jelinek wrote:
>> On 2015-07-13 00:36, Tom Lane wrote:
>>> PS: now that I've written this rant, I wonder why we don't redesign the
>>> index AM API along the same lines. It probably doesn't matter much at
>>> the moment, but if we ever get serious about supporting in
On 2015-07-12 18:02, Tom Lane wrote:
A possible way around this problem is to redefine the sampling rule so
that it is not history-dependent but depends only on the tuple TIDs.
For instance, one could hash the TID of a candidate tuple, xor that with
a hash of the seed being used for the current
Hi,
Volatilities of pg_xact_commit_timestamp() and pg_last_committed_xact()
are now STABLE. But ISTM that those functions can return different results
even within a single statement. So we should change the volatilities of them
to VOLATILE?
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers m
On Fri, Jul 3, 2015 at 12:15 PM, Amit Kapila wrote:
> On Thu, Jul 2, 2015 at 7:44 PM, Alvaro Herrera
> wrote:
>>
>> Amit Kapila wrote:
>> >
>> > Added the above log messages in attached patch with small change
>> > such that in message, file names will be displayed with quotes as most
>> > of oth
Petr Jelinek wrote:
> On 2015-07-13 00:36, Tom Lane wrote:
> >PS: now that I've written this rant, I wonder why we don't redesign the
> >index AM API along the same lines. It probably doesn't matter much at
> >the moment, but if we ever get serious about supporting index AM
> >extensions, I think
Petr Jelinek wrote:
> On 2015-07-13 15:39, Tom Lane wrote:
> >I don't find this to be good error message style. The secondary comment
> >is not a "hint", it's an ironclad statement of what you did wrong, so if
> >we wanted to phrase it like this it should be an errdetail not errhint.
> >But the w
On 2015-07-13 18:00, Tom Lane wrote:
And here's that. I do *not* claim that this is a complete list of design
issues with the patch, it's just things I happened to notice in the amount
of time I've spent so far (which is already way more than I wanted to
spend on TABLESAMPLE right now).
I'm n
> > > > - pg_disable_checksums(void) => turn checksums off for a cluster.
> > > > Sets the state to "disabled", which means bg_worker will not do
> > > > anything.
> > > >
> > > > - pg_request_checksum_cycle(void) => if checksums are "enabled",
> > > > increment the data_checksum_cycle coun
On Thu, Jul 16, 2015 at 11:21 AM, Haribabu Kommi
wrote:
>
> On Wed, Jul 15, 2015 at 11:19 PM, Amit Kapila
wrote:
> >
> > One case where this patch can behave differently then current
> > code is, when before taking Exclusive lock on relation for truncation,
> > if some backend clears the vm bit a
On 2015-07-13 15:39, Tom Lane wrote:
Datum
tsm_system_rows_init(PG_FUNCTION_ARGS)
{
TableSampleDesc *tsdesc = (TableSampleDesc *) PG_GETARG_POINTER(0);
uint32 seed = PG_GETARG_UINT32(1);
int32 ntuples = PG_ARGISNULL(2) ? -1 : PG_GETARG_INT32(2);
This is rather curious
On Wed, Jul 15, 2015 at 3:07 AM, Sawada Masahiko wrote:
> On Wed, Jul 15, 2015 at 12:55 AM, Simon Riggs wrote:
>> On 10 July 2015 at 15:11, Sawada Masahiko wrote:
>>>
>>>
>>> Oops, I had forgotten to add new file heapfuncs.c.
>>> Latest patch is attached.
>>
>>
>> I think we've established the a
On 2015-07-13 00:36, Tom Lane wrote:
We have a far better model to follow already, namely the foreign data
wrapper API. In that, there's a single SQL-visible function that returns
a dummy datatype indicating that it's an FDW handler, and when called,
it hands back a struct containing pointers t
Hello,
>Naming the GUC pgstat* seems a little inconsistent.
Sorry, there is a typo in the mail. The GUC name is 'track_activity_progress'.
>Also, adding the new GUC to src/backend/utils/misc/postgresql.conf.sample
>might be helpful
Yes. I will update.
Thank you,
Rahila Syed
__
On Thu, Jul 16, 2015 at 2:23 AM, David Rowley
wrote:
> Attached is a small patch to fix a spelling mistake in an error message
>
>
Applied, thanks.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Wed, Jul 15, 2015 at 11:18 PM, David Christensen
wrote:
> Quick comment fix for edit issue.
>
>
Applied, thanks.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Amit Kapila wrote:
> This can be tracked either in 9.5 Open Items or for next CF,
> any opinions?
>
> If nobody else has any opinion on this, I will add it to 9.5 Open Items
> list.
I think this belongs in the open items list, yeah.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
On Wed, Jul 15, 2015 at 8:44 AM, Heikki Linnakangas wrote:
>
> Both. Here's the patch.
>
> Previously, LWLockAcquireWithVar set the variable associated with the lock
> atomically with acquiring it. Before the lwlock-scalability changes, that
> was straightforward because you held the spinlock any
72 matches
Mail list logo
