Hello,
at PostgreSQL version 9.5rc1,
at line 934 in pg_recvlogical.c
set_pglocale_pgservice(argv[0],PG_TEXTDOMAIN("pg_recvlogical"));
this references invalid catalog file, because pg_basebackup,
pg_recvlogical, pg_receivexlog commands use same catalog file
pg_basebackup.mo
pg_receivexl
I noticed this while reading nodeGather.c. I checked to find other
misspellings of the word and found one more, so the attached fixes both.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
segment_spelling_fix.patch
Descri
Here is another preliminary result I would like to share. As always you
will find corresponding patch in attachment. It has work in progress
quality.
The idea was suggested by colleague of mine Aleksander Lebedev.
freeList is partitioned like in "no lock" patch. When there is no
enough free items
On Mon, Dec 21, 2015 at 11:54 PM, Robert Haas wrote:
> On Mon, Dec 21, 2015 at 3:27 AM, Kyotaro HORIGUCHI
> wrote:
>> Hello,
>>
>> At Fri, 18 Dec 2015 12:09:43 -0500, Robert Haas
>> wrote in
>>> On Thu, Dec 17, 2015 at 1:17 AM, Michael Paquier
>>> wrote:
>>> > I am not really getting the mean
On Thu, Dec 24, 2015 at 5:16 AM, Haribabu Kommi
wrote:
> On Thu, Dec 24, 2015 at 2:37 AM, Tom Lane wrote:
> > "Shulgin, Oleksandr" writes:
> >> 1. Have you considered re-loading the HBA file upon call to this
> function
> >> in a local context instead of keeping it in the backends memory?
> >
>
On 12/28/2015 03:15 AM, David Rowley wrote:
On 18 December 2015 at 04:34, Tomas Vondra mailto:tomas.von...@2ndquadrant.com>> wrote:
I think ultimately we'll need to measure the false positive rate, so
that we can use it to dynamically disable the bloom filter if it
gets inefficient.
Hi,
My compiler is complaining about cube_coord() and cube_coord_llur() not
returning a value on all code paths. On looking at this I noticed that
this is happening due the pattern used is not quite aligned with other
code, as normally we do:
if ()
ereport();
do stuff;
PG_RETURN_(value);
On 28 December 2015 at 23:23, Tomas Vondra
wrote:
> On 12/28/2015 03:15 AM, David Rowley wrote:
>
>> Maybe it would be better to, once the filter is built, simply count the
>>
> number of 1 bits and only use the filter if there's less than
>> 1 bits compared to the size of the filter in bits. Th
On 12/28/2015 11:38 AM, David Rowley wrote:
On 28 December 2015 at 23:23, Tomas Vondra mailto:tomas.von...@2ndquadrant.com>> wrote:
On 12/28/2015 03:15 AM, David Rowley wrote:
Maybe it would be better to, once the filter is built, simply
count the
number of 1 bits a
On 28 December 2015 at 23:44, Tomas Vondra
wrote:
> On 12/28/2015 11:38 AM, David Rowley wrote:
>
>> If so, then a filter with all 1 bits set should be thrown away, as
>>
> it'll never help us, and the filter should generally become more
>> worthwhile as it contains a higher ratio of 0 bits vs 1
On Thu, Dec 24, 2015 at 5:50 PM, Ildus Kurbangaliev <
i.kurbangal...@postgrespro.ru> wrote:
>
> On Tue, 15 Dec 2015 13:56:30 -0500
> Robert Haas wrote:
>
> > On Sun, Dec 13, 2015 at 6:35 AM, and...@anarazel.de
> > wrote:
> > > On 2015-12-12 21:15:52 -0500, Robert Haas wrote:
> > >> On Sat, Dec 12
On 12/28/2015 11:52 AM, David Rowley wrote:
On 28 December 2015 at 23:44, Tomas Vondra mailto:tomas.von...@2ndquadrant.com>> wrote:
On 12/28/2015 11:38 AM, David Rowley wrote:
If so, then a filter with all 1 bits set should be thrown away, as
it'll never help us, and the fi
On Sat, Dec 26, 2015 at 5:41 PM, Andres Freund wrote:
> On 2015-12-26 12:22:48 +0100, Andres Freund wrote:
> > > > 3) Replace the postmaster_alive_fds socketpair by some other
> signalling
> > > >mechanism. E.g. sending a procsignal to each backend, which sets
> the
> > > >latch and a spe
Hi all,
Since commit d5563d7d, -c does not imply any more --no-psqlrc hence
the tests of pg_upgrade may run with a custom psqlrc file loaded. I
think that we had better add -X to avoid that, like in the patch
attached.
Thoughts?
--
Michael
diff --git a/src/bin/pg_upgrade/test.sh b/src/bin/pg_upgr
On Mon, Dec 28, 2015 at 5:07 PM, Ioseph Kim wrote:
> Hello,
>
> at PostgreSQL version 9.5rc1,
> at line 934 in pg_recvlogical.c
>
> set_pglocale_pgservice(argv[0],PG_TEXTDOMAIN("pg_recvlogical"));
>
> this references invalid catalog file, because pg_basebackup,
> pg_recvlogical, pg_receive
Michael Paquier wrote:
> On Mon, Dec 28, 2015 at 5:07 PM, Ioseph Kim wrote:
> > at PostgreSQL version 9.5rc1,
> > at line 934 in pg_recvlogical.c
> >
> > set_pglocale_pgservice(argv[0],PG_TEXTDOMAIN("pg_recvlogical"));
> >
> > this references invalid catalog file, because pg_basebackup,
>
2015-12-28 14:21 GMT+01:00 Michael Paquier :
> Hi all,
>
> Since commit d5563d7d, -c does not imply any more --no-psqlrc hence
> the tests of pg_upgrade may run with a custom psqlrc file loaded. I
> think that we had better add -X to avoid that, like in the patch
> attached.
> Thoughts?
>
+1
Pav
On Fri, Dec 25, 2015 at 11:10 AM, Teodor Sigaev wrote:
> Good catch, committed.
>
Thank you!
Here's the patch with an 'array_elemtype' procedure which returns array's
element type as an oid. It should apply to the commit fc995b. I wasn't sure if
I shoud start a new thread.
--
Dmitry Ivanov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Companydiff --git a/doc/src/s
Hi.
I send new patch:
https://github.com/grzsmp/postgres/commit/3e3a1f187b71acef3f8dc0745da753fb5be821fa
On 12/27/2015 05:31 PM, Grzegorz Sampolski wrote:
> Hi there!
> I'm alive and working on new patch.
> So, I takes into account all suggestions from Tomas and I'll
> add additional parameter `us
Hi.
New patch available.
The new status of this patch is: Needs review
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Dec 16, 2015 at 4:09 PM, Michael Paquier
wrote:
> Yeah, that's actually fine. I just had a look at Windows stuff, and
> things seem to be correct on this side for double:
> https://msdn.microsoft.com/en-us/library/aa691373%28v=vs.71%29.aspx
> And then I also had a look at src/port/snprintf
Jeff Janes wrote:
> Another issue is: it seems to have no SGML documentation. Is that OK?
Here's a patch (which I had to write afresh, because I couldn't find
anything in my brin development tree. Maybe I was just remembering
something I planned to do and never got around to.)
This creates a
Alvaro Herrera writes:
> This creates a new sub-section at the bottom of "9.26 System
> Administration Functions" named "Indexing Helper Functions", containing
> a table with a single row which is for this function.
Perhaps call it "Index Maintenance Functions"?
> We can bikeshed whether the new
On Tue, Dec 22, 2015 at 10:45 AM, Pavel Stehule
wrote:
> Hi
>
> 2015-12-21 16:11 GMT+01:00 Robert Haas :
>
>> On Sun, Dec 20, 2015 at 4:54 AM, Pavel Stehule
>> wrote:
>> > new update:
>> >
>> > 1. unit searching is case insensitive
>> >
>> > 2. initial support for binary byte prefixes - KiB, MiB
Michael Paquier writes:
> Since commit d5563d7d, -c does not imply any more --no-psqlrc hence
> the tests of pg_upgrade may run with a custom psqlrc file loaded. I
> think that we had better add -X to avoid that, like in the patch
> attached.
Yeah. "grep" found a few more, but I think I got them
On 12/26/2015 06:32 PM, Michael Paquier wrote:
> On Sun, Dec 27, 2015 at 10:08 AM, Joe Conway wrote:
>> In looking at the exposing pg_controldata as function patch again, it
>> struck me that the following output seems wrong:
>>
>> --
>> Latest checkpoint's oldestCommitTs: 20257
>> L
Joe Conway writes:
> Ok, but now next question -- should we just change the user visible
> output to oldestCommitXID/newestCommitXID, or should we change the
> variable name everywhere it appears in source as well? Looks like each
> one appears about 25-30 times scattered across 9 or 10 files. Sin
On 12/28/2015 09:03 AM, Tom Lane wrote:
> Joe Conway writes:
>> Ok, but now next question -- should we just change the user visible
>> output to oldestCommitXID/newestCommitXID, or should we change the
>> variable name everywhere it appears in source as well? Looks like each
>> one appears about 2
Joe Conway wrote:
> On 12/28/2015 09:03 AM, Tom Lane wrote:
> > Joe Conway writes:
> >> Ok, but now next question -- should we just change the user visible
> >> output to oldestCommitXID/newestCommitXID, or should we change the
> >> variable name everywhere it appears in source as well? Looks like
On 12/28/2015 09:53 AM, Alvaro Herrera wrote:
>>> The name is just as misleading at the source-code level, maybe more so
>>> since they're all just numbers in C. +1 for changing it everywhere
>>> before somebody makes a mistake based on the incorrect names.
>>
>> Ok, I'm on it now
>
> Great, than
Joe Conway writes:
> I think the attached does the job. Note I settled on
> (new|old)estCommitTsXid as that seemed most descriptive and not horribly
> longer than before. It did mean, however, that I needed to add a single
> space to all the output in pg_resetxlog and pg_controldata, which added
>
Tom Lane wrote:
> Joe Conway writes:
> > I think the attached does the job. Note I settled on
> > (new|old)estCommitTsXid as that seemed most descriptive and not horribly
> > longer than before. It did mean, however, that I needed to add a single
> > space to all the output in pg_resetxlog and pg_
Tom Lane wrote:
> Alvaro Herrera writes:
> > This creates a new sub-section at the bottom of "9.26 System
> > Administration Functions" named "Indexing Helper Functions", containing
> > a table with a single row which is for this function.
>
> Perhaps call it "Index Maintenance Functions"?
>
> >
On 12/28/2015 10:30 AM, Alvaro Herrera wrote:
> Tom Lane wrote:
>> Joe Conway writes:
>>> I think the attached does the job. Note I settled on
>>> (new|old)estCommitTsXid as that seemed most descriptive and not horribly
>>> longer than before. It did mean, however, that I needed to add a single
>>
David Rowley writes:
> My compiler is complaining about cube_coord() and cube_coord_llur() not
> returning a value on all code paths.
Yeah, looking at that code, this would be expected from any compiler
that doesn't know that ereport() doesn't return. On it now. The
documentation aspect of that
Konstantin Knizhnik wrote:
Hi,
> May be you know, that I have implemented IMCS (in-memory-columnar-store) as
> PostgreSQL extension.
> It was not so successful, mostly because people prefer to use standard SQL
> rather than using some special functions for accessing columnar storage
> (CS). Now I
Konstantin Knizhnik wrote:
> 3. Transpose of data and role of CS.
> Let's look once again on Quote example above. Data is received in time
> ascending order. But most queries require grouping it by symbol. So at some
> stage we have to "transpose" data. To efficiently append data to timeseries
>
On 12/28/2015 10:35 AM, Joe Conway wrote:
> An alternative would be to not have a space at all for those two, e.g.
>
> "Latest checkpoint's oldestCommitTsXid:%u\n"
> "Latest checkpoint's newestCommitTsXid:%u\n"
>
> That isn't too bad and would leave everything aligned.
That seems like the be
Joe Conway writes:
> I retract my earlier suggestion of doing HEAD different from
> REL9_5_STABLE, at least for the moment. My patch for pg_controldata
> related functions is going to impact all this anyway, so we might as
> well not fuss about it now.
Seems reasonable.
> Any objections to the a
On Mon, Dec 28, 2015 at 03:01:07PM +, Grzegorz Sampolski wrote:
> Hi.
> New patch available.
Please attach the patch or patch set to your email just like else
does. :)
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfett
On 12/28/2015 11:48 AM, Tom Lane wrote:
> Joe Conway writes:
>> I retract my earlier suggestion of doing HEAD different from
>> REL9_5_STABLE, at least for the moment. My patch for pg_controldata
>> related functions is going to impact all this anyway, so we might as
>> well not fuss about it now.
After setting up 9.5beta2 on the Npgsql build server and running the Npgsql
test suite against I've noticed some weird behavior.
The tests run for a couple minutes, open and close some connection. With my
pre-9.5 backends, the moment the test runner exits I can see that all
backend processes exit
On 12/24/15 16:37, Tom Lane wrote:
> to make this coding pattern work is to set up a subtransaction, and either
> commit it in the success path or roll it back upon catching an error.
> (This is not terribly well documented, but the exception-block handling
> in plpgsql provides a working model to
On 29 December 2015 at 07:38, Tom Lane wrote:
> David Rowley writes:
> > My compiler is complaining about cube_coord() and cube_coord_llur() not
> > returning a value on all code paths.
>
> Yeah, looking at that code, this would be expected from any compiler
> that doesn't know that ereport() do
I wrote:
> Jeff Janes writes:
>> If a partially-active table develops a slug of stable all-visible,
>> non-empty pages at the end of it, then every autovacuum of that table
>> will skip the end pages on the forward scan, think they might be
>> truncatable, and take the access exclusive lock to do
Chapman Flack writes:
> Is there a particular, reasonably tidy idiom that has emerged as the usual,
> customary approach to a task like this?
You could construct a RangeVar node and then use RangeVarGetRelid,
but I dunno that that's really any cleaner than inquiring about it
using the syscaches.
Hello Michaël,
And then I also had a look at src/port/snprintf.c, where things get
actually weird when no transactions are run for a script (emulated
with 2 scripts, one with @1 and the second with @1):
- 0 transactions (0.0% of total, tps = 0.00)
- latency average = -1.#IO ms
- late
Hi there,
The following wiki page:
https://wiki.postgresql.org/wiki/HowToBetaTest#How_to_Test
suggests that I should send the following report to this mailing list.
Name: Boriss Mejías (Tchorix)
Release: Postgresql 9.5 RC1
Test Type: Compatibility with Alfresco Community Edition 5.0.d
Test De
On Fri, Dec 18, 2015 at 11:57 AM, Peter Geoghegan wrote:
> BTW, I'm not necessarily determined to make the new special-purpose
> allocator work exactly as proposed. It seemed useful to prioritize
> simplicity, and currently so there is one big "huge palloc()" with
> which we blow our memory budget
Shay Rojansky writes:
> After setting up 9.5beta2 on the Npgsql build server and running the Npgsql
> test suite against I've noticed some weird behavior.
> The tests run for a couple minutes, open and close some connection. With my
> pre-9.5 backends, the moment the test runner exits I can see t
On Wed, Nov 25, 2015 at 9:29 AM, Jeff Janes wrote:
>
> I'll prepare a patch for core for the January commitfest, and see if
> it flies. If not, there is always the extension to fall back to.
Here is an updated patch. I've added type and permission checks,
docs, and some regression tests.
Cheer
Hi.
I thought link on commitfest to github url was sufficient.
Sorry. Attached new patch.
On 12/28/2015 09:07 PM, David Fetter wrote:
> Please attach the patch or patch set to your email just like else
> does
diff --git a/src/backend/libpq/auth.c b/src/backend/libpq/auth.c
index cdc5bf1..d42cc76
On 28 December 2015 at 21:35, David Rowley
wrote:
> I noticed this while reading nodeGather.c. I checked to find other
> misspellings of the word and found one more, so the attached fixes both.
>
Here's another tiny patch which fixes a spelling mistake in tqueue.c
--
David Rowley
On Tue, Dec 29, 2015 at 12:46:40AM +0100, Grzegorz Sampolski wrote:
> Hi.
> I thought link on commitfest to github url was sufficient.
> Sorry. Attached new patch.
Thanks!
My understanding for the reason behind the policy is that it is to
ensure that patch submissions are all together in a widely
On Mon, Dec 28, 2015 at 9:09 PM, Shulgin, Oleksandr
wrote:
> On Thu, Dec 24, 2015 at 5:16 AM, Haribabu Kommi
> wrote:
>>
>> On Thu, Dec 24, 2015 at 2:37 AM, Tom Lane wrote:
>> > "Shulgin, Oleksandr" writes:
>> >> 1. Have you considered re-loading the HBA file upon call to this
>> >> function
>>
On 28 December 2015 at 22:56, Boriss Mejias wrote:
> Hi there,
>
> The following wiki page:
> https://wiki.postgresql.org/wiki/HowToBetaTest#How_to_Test
> suggests that I should send the following report to this mailing list.
>
Thanks for testing.
Do you have any comments on performance testing
I wonder why "Latest checkpoint's NextXID" is formated like this:
8<-
printf(_("Latest checkpoint's NextXID: %u/%u\n"),
ControlFile.checkPointCopy.nextXidEpoch,
ControlFile.checkPointCopy.nextXid);
8<---
58 matches
Mail list logo
