On Tue, 16 Jun 2015 at 00:52 Vik Fearing wrote:
> While reviewing the seqam patches, I noticed that psql has tab
> completion for ALTER SEQUENCE, but not for CREATE SEQUENCE.
>
> The attached trivial patch fixes that.
>
Hi Vik,
I'm doing an initial review of this patch.
It applies cleanly, alt
Hi all,
In pg_regress.c, there is the following code:
static void
stop_postmaster(void)
{
if (postmaster_running)
{
/* We use pg_ctl to issue the kill and wait for stop */
charbuf[MAXPGPATH * 2];
int r;
Hi all,
The TAP tests in src/test/ssl are using system() in combination with
chmod, but perl has a command chmod integrated into it, and it would
work better on Windows as well.
The attached patch is aimed at fixing that.
Regards,
--
Michael
diff --git a/src/test/ssl/ServerSetup.pm b/src/test/ss
2015-06-19 6:32 GMT+02:00 Thomas Munro :
> On Fri, Jun 19, 2015 at 4:17 PM, Pavel Stehule
> wrote:
> > I am sorry. I didn't the original mail in my mailbox.
>
> There is a (rather well hidden) way to ask Majordomo to send you a
> message that arrived before you subscribed, so that you can reply
>
On Fri, Jun 19, 2015 at 4:17 PM, Pavel Stehule wrote:
> I am sorry. I didn't the original mail in my mailbox.
There is a (rather well hidden) way to ask Majordomo to send you a
message that arrived before you subscribed, so that you can reply
without creating a new thread. I think you have to su
2015-06-19 2:17 GMT+02:00 Michael Paquier :
> On Thu, Jun 18, 2015 at 10:44 PM, Pavel Stehule
> wrote:
> > Hi
> >
> > I am trying to check your patch - but diffs that you sent to mailing list
> > are inconsistent.
> >
> > Please, can you send one complete patch?
>
> In order to follow more easily
On Thu, Jun 18, 2015 at 10:55 PM, Heikki Linnakangas wrote:
> On 06/16/2015 02:04 AM, Michael Paquier wrote:
>>
>> In order to reduce the risk of failure to a minimum and to preserve
>> the performance of the tool when using --source-server, I think that
>> we should add some check using pg_stat_f
On Thu, 2 Apr 2015 at 05:00 Merlin Moncure wrote:
> On Sun, Mar 29, 2015 at 1:27 PM, Tom Lane wrote:
> > While I don't have a problem with hstore_to_array, I don't think that
> > row_to_array is a very good idea; it's basically encouraging people to
> > throw away SQL datatypes altogether and im
On Thu, Jun 18, 2015 at 8:07 PM, Eric Ridge wrote:
>
> According to pg_proc.probin, all 32 of my C language functions point
> to $libdir/my_extension_lib,
That's a damn lie. The deployment server has a number of databases
that have this extension installed and some of them have probin set to
jus
On Thu, Jun 18, 2015 at 10:44 PM, Pavel Stehule wrote:
> Hi
>
> I am trying to check your patch - but diffs that you sent to mailing list
> are inconsistent.
>
> Please, can you send one complete patch?
In order to follow more easily the thread of this patch, could you
answer directly to the exis
On Thu, Jun 18, 2015 at 6:04 PM, Tom Lane wrote:
> What we were expecting I guess is that such functions would be declared
> to reference the library underneath $libdir/plugins, not that you'd use
> a symlink.
According to pg_proc.probin, all 32 of my C language functions point
to $libdir/my_ext
On 2015-06-19 01:04, Petr Jelinek wrote:
On 2015-06-19 00:38, Petr Jelinek wrote:
On 2015-06-18 22:04, Tom Lane wrote:
By the by, the tablesample additions to range_table_mutator are
obviously
broken.
Bah, typos. Attached patch corrects them.
Actually it should probably look more like th
On 2015-06-19 00:38, Petr Jelinek wrote:
On 2015-06-18 22:04, Tom Lane wrote:
By the by, the tablesample additions to range_table_mutator are obviously
broken.
Bah, typos. Attached patch corrects them.
Actually it should probably look more like this, sorry.
--
Petr Jelinek
On 2015-06-18 22:04, Tom Lane wrote:
By the by, the tablesample additions to range_table_mutator are obviously
broken.
Bah, typos. Attached patch corrects them.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
diff --gi
Eric Ridge writes:
> On Thu, Jun 18, 2015 at 5:30 PM, Tom Lane wrote:
>>> As a data point, that might be interesting to know, but I'd still be
>>> scratching my head about how it happened. Postgres doesn't load an
>>> extension library more than once per backend session, does it?
>> It's not su
On Thu, Jun 18, 2015 at 5:39 PM, Tom Lane wrote:
> BTW, if it didn't occur to you already --- next time you see this,
> you could try examining dfmgr.c's DynamicFileList data structure
> using gdb. That might help illuminate what Postgres thinks it
> loaded and why.
Hmm, okay. I'll not check fo
2015-06-05 deavid :
> Mode 3: on "aminsert", put the new entry on a second btree; leaving the
> first one untouched. Because the second btree is new, will be small, and
> writes should be faster. When doing a index scan, read tuples from both at
> same time (like merge sort). On vacuum, merge the
On Thu, Jun 18, 2015 at 5:30 PM, Tom Lane wrote:
>
> If that's broken, then so are most of our contrib modules.
> Certainly none of them have an extra check as suggested by Andres.
I'm putting it in anyways, along with a guard in the actual hook
function to ERROR if prev_hook == my_hook. At leas
I wrote:
> Eric Ridge writes:
>> As a data point, that might be interesting to know, but I'd still be
>> scratching my head about how it happened. Postgres doesn't load an
>> extension library more than once per backend session, does it?
> It's not supposed to, and AFAICS internal_load_library()
Eric Ridge writes:
> On Thu, Jun 18, 2015 at 4:42 PM, Andres Freund wrote:
>> How does your _PG_init() actually look like?
> static ExecutorStart_hook_type prev_ExecutorStartHook = NULL;
> static ExecutorEnd_hook_type prev_ExecutorEndHook = NULL;
> void _PG_init(void)
> {
>prev_ExecutorSta
On Thu, Jun 18, 2015 at 4:04 PM, Tom Lane wrote:
> ... although I see that range_table_mutator doesn't bother to copy/change
> the column alias substructure. (Wonder if that gives rise to any
> observable EXPLAIN bugs...) But it still seems like the append_rel_list
> shouldn't be all that much b
deavid wrote:
> I did another try on BRIN and GIN indexes, and I compared to regular btree
> indexes. Now i have 16M rows to do the test.
>
> The numbers seem to be good. Both GIN and BRIN seem good options for
> certain tables with more writes than reads (Specially BRIN is very good)
Thanks, tha
On Thu, Jun 18, 2015 at 4:42 PM, Andres Freund wrote:
>
>
> How does your _PG_init() actually look like?
static ExecutorStart_hook_type prev_ExecutorStartHook = NULL;
static ExecutorEnd_hook_type prev_ExecutorEndHook = NULL;
void _PG_init(void)
{
prev_ExecutorStartHook = ExecutorStart_hook;
Hi,
On 2015-06-18 16:36:17 -0400, Eric Ridge wrote:
> I've written an extension that hooks ExecutorStart_hook and
> ExecutorEnd_hook. The hooks are assigned in _PG_init() (and the previous
> ones saved to static vars) and reset to the previous values in _PG_fini().
> Maybe also of interest is the
I've written an extension that hooks ExecutorStart_hook and
ExecutorEnd_hook. The hooks are assigned in _PG_init() (and the previous
ones saved to static vars) and reset to the previous values in _PG_fini().
Maybe also of interest is the extension library is set in postgresql.conf
as a local_prelo
I wrote:
> Robert Haas writes:
>> Well, append_rel_list has an AppendRelInfo for every RTE and that
>> contains a List (translated_vars) which in turn contains a Var node
>> for every column. I'm not sure how that compares to the RTE itself.
> RTEs also have a per-column component, namely the li
On 6/12/15 9:17 PM, deavid wrote:
(upper(codagencia::text) );
FWIW, you should consider using citext for these cases; it would let you
cut down on the number of indexes (by 50%?).
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in Treble! http://Blue
I did another try on BRIN and GIN indexes, and I compared to regular btree
indexes. Now i have 16M rows to do the test.
The numbers seem to be good. Both GIN and BRIN seem good options for
certain tables with more writes than reads (Specially BRIN is very good)
I want to share with you my test; I
Robert Haas writes:
> On Thu, Jun 18, 2015 at 3:14 PM, Tom Lane wrote:
>> I'm a bit surprised that duplicating the append_rel_list is a noticeable
>> performance problem. It ought to be far smaller than the Query tree that
>> we've always duplicated in this loop --- in particular, it's really a
On Thu, Jun 18, 2015 at 3:14 PM, Tom Lane wrote:
> Dean Rasheed writes:
>> On 18 June 2015 at 14:48, Robert Haas wrote:
>>> I feel I might be missing a trick here. It seems unlikely to me that
>>> we actually need the entire append_rel_list for every subquery; and we
>>> almost certainly don't
Dean Rasheed writes:
> On 18 June 2015 at 14:48, Robert Haas wrote:
>> I feel I might be missing a trick here. It seems unlikely to me that
>> we actually need the entire append_rel_list for every subquery; and we
>> almost certainly don't need to modify every element of the
>> append_rel_list f
On 18 June 2015 at 14:48, Robert Haas wrote:
> On Wed, Jun 17, 2015 at 9:56 AM, Robert Haas wrote:
>> On Wed, Jun 17, 2015 at 9:32 AM, Thomas Munro
>> wrote:
>>> We saw a rather extreme performance problem in a cluster upgraded from
>>> 9.1 to 9.3. It uses a largish number of child tables (part
On Wed, Jun 17, 2015 at 6:15 PM, Brendan Jurd wrote:
> Posting v2 of the patch, incorporating some helpful suggestions from Merlin.
Based on perfunctory scan of the code, I think this is gonna make it,
unless you draw some objections based on lack of necessity.
merlin
--
Sent via pgsql-hacker
On Wed, Jun 17, 2015 at 5:10 PM, Alvaro Herrera
wrote:
> Yeah, the case is pretty weird and I'm not really sure that the server
> ought to be expected to behave. But if this is actually the only part
> of the server that misbehaves because of sudden gigantic time jumps, I
> think it's fair to pat
On Sun, Jun 14, 2015 at 9:52 AM, Jan Wieck wrote:
> The whole thing turns out to be based on wrong baseline data, taken with a
> pgbench client running from a remote machine. It all started out from an
> investigation against 9.3. Curiously enough, the s_lock() problem that
> existed in 9.3 has a
Noah Misch writes:
> On Wed, Jun 17, 2015 at 01:43:55PM -0400, Tom Lane wrote:
>> I'm not exactly sure that they wouldn't be garbled anyway during the
>> interval where we're setting these things up. Until DatabaseEncoding,
>> ClientEncoding, and gettext's internal notions are all in sync, we
>>
On 06/16/2015 02:04 AM, Michael Paquier wrote:
In order to reduce the risk of failure to a minimum and to preserve
the performance of the tool when using --source-server, I think that
we should add some check using pg_stat_file to see if a file is still
present or not, and if it is missing we can
On Wed, Jun 17, 2015 at 9:56 AM, Robert Haas wrote:
> On Wed, Jun 17, 2015 at 9:32 AM, Thomas Munro
> wrote:
>> We saw a rather extreme performance problem in a cluster upgraded from
>> 9.1 to 9.3. It uses a largish number of child tables (partitions) and
>> many columns. Planning a simple UPDA
Hi
I am trying to check your patch - but diffs that you sent to mailing list
are inconsistent.
Please, can you send one complete patch?
Regards
Pavel
Peter Eisentraut writes:
> On 6/17/15 3:35 PM, Keith Fiske wrote:
>> The current HEAD of postgres in the git repo is not building when using
>> "make world". It's been like this for about a month or so that I've been
>> aware of. I didn't really need the world build so been making due
>> without i
Peter Eisentraut wrote:
> On 6/17/15 3:35 PM, Keith Fiske wrote:
> > The current HEAD of postgres in the git repo is not building when using
> > "make world". It's been like this for about a month or so that I've been
> > aware of. I didn't really need the world build so been making due
> > without
Cédric Villemain wrote:
>
>
> Le 17/06/2015 23:10, Alvaro Herrera a écrit :
> > Tom Lane wrote:
> >> launcher_determine_sleep() does have a minimum sleep time, and it seems
> >> like we could fairly cheaply guard against this kind of scenario by also
> >> enforcing a maximum sleep time (of say 5
Le 17/06/2015 23:10, Alvaro Herrera a écrit :
> Tom Lane wrote:
>> launcher_determine_sleep() does have a minimum sleep time, and it seems
>> like we could fairly cheaply guard against this kind of scenario by also
>> enforcing a maximum sleep time (of say 5 or 10 minutes). Not quite
>> convince
43 matches
Mail list logo
