On Mon, Mar 11, 2019 at 08:38:56PM +, Regina Obe wrote:
> I tested on windows mingw64 (as of a week ago) and confirmed the
> patch applies cleanly and significantly faster for left, substr
> tests than head.
int32
pglz_decompress(const char *source, int32 slen, char *dest,
-
Hi!
> 21 февр. 2019 г., в 23:50, Paul Ramsey написал(а):
>
> Merci! Attached are updated patches.
>
As noted before, patches are extremely useful.
So, I've looked into the code too.
I've got some questions about pglz_decompress() changes:
1.
+ if (dp >=
On Mon, Mar 11, 2019 at 02:35:49PM +, Georgios Kokolatos wrote:
> To be honest, I have not checked closely on the failure, still it is
> the only test failing which by itself should be worthwhile
> mentioning.
This works for me, as well as a plain installcheck and check from the
subpath.
Hello.
At Mon, 11 Mar 2019 21:37:32 +0800, Andy Fan wrote
in
> notes on the shared hash map: it needs multi writers and multi readers.
>
> On Mon, Mar 11, 2019 at 9:36 PM Andy Fan wrote:
>
> > Hi:
> > I need some function which requires some message exchange among
> > different
I wrote:
> I've successfully done check-world after renumbering every OID above
> 4000 to somewhere else. I also tried renumbering everything below
> 4000, which unsurprisingly blew up because there are various catalog
> columns we haven't fixed to use symbolic OIDs. (The one that initdb
>
Sorry, I sent a wrong patch. The attached is the right one.
At Mon, 11 Mar 2019 13:57:21 +0100, Julien Rouhaud wrote
in
> On Mon, Mar 11, 2019 at 10:03 AM David Rowley
> wrote:
> >
> > On Mon, 11 Mar 2019 at 09:58, Tom Lane wrote:
> > > The second patch is a delta that rounds off to the next
At Mon, 11 Mar 2019 13:57:21 +0100, Julien Rouhaud wrote
in
> On Mon, Mar 11, 2019 at 10:03 AM David Rowley
> wrote:
> >
> > On Mon, 11 Mar 2019 at 09:58, Tom Lane wrote:
> > > The second patch is a delta that rounds off to the next smaller unit
> > > if there is one, producing a less noisy
On Mon, Mar 11, 2019 at 11:19:50AM +0100, Michael Banck wrote:
> One thing: you (Michael) should be co-author for patch #3 as I took some
> of your code from https://github.com/michaelpq/pg_plugins/tree/master/pg
> _checksums
OK, thanks for the notice. I was not sure as we actually developped
On Mon, Mar 11, 2019 at 06:32:10PM -0700, Jeff Davis wrote:
> * Is the original idea of a special role still viable?
In my opinion, that part may be valuable. The latest patches proposed
change the way tables are filtered and listed on the subscription
side, lowering the permission to spawn a
On Mon, Mar 11, 2019 at 09:54:45PM +0530, Ramanarayana wrote:
> I went through the python script and found that the stdout encoding is set
> to utf-8 only if python version is <=2. The same needs to be done for
> python 3
If you send a patch for that, how would it look like? Could you also
On Mon, Mar 11, 2019 at 07:49:11PM +0800, Shaoqi Bai wrote:
> Thanks, will work on it as you suggested
> Add pg_basebackup --T olddir=newdir to support check the consistency of a
> tablespace created before promotion
> Add run_test('remote');
Thanks for considering my input. Why don't you
On Mon, Mar 11, 2019 at 03:30:22PM -0400, Robert Haas wrote:
> Sorry that I didn't get to this before you did -- I was on PTO on
> Friday and did not work on the weekend.
My apologies, Robert. It seems that I have been too much hasty
then. There are so many things going around lately, it is
On Mon, Mar 11, 2019 at 02:11:11PM +, Sergei Kornilov wrote:
> I review latest patchset.
Thanks, I have committed the refactoring of src/common/ as a first
step.
> I have one big question: Is pg_checksums
> safe for cross-versions operations? Even with update_controlfile
> call? Currently i
Hi Jesper,
Sorry I almost completely forgot to get back to you on this.
Actually your patch works when I tested it before,
and I understand the intention.
.
Although a point was raised by other developers by making
--jobs optional in the suggested line by using the env variable instead.
> >
Hello, Mikalai-san.
Thank you for your mail.
> From: mikalaike...@ibagroup.eu
> I'm with Fabien that "client-side timeout" seems unsafe. Also I agree with
> Fabien
> that quire can take much time to be processed by the PosgtreSQL server and it
> is
> a normal behavior. There is possible that
On Fri, 2018-11-09 at 15:24 +0300, Evgeniy Efimkin wrote:
> Hi!
> In order to support create subscription from non-superuser, we need
> to make it possible to choose tables on the subscriber side:
I'd like to know more about the reasoning here. This thread started out
by suggesting a new special
On 03/11/19 19:53, Euler Taveira wrote:
> Em seg, 11 de mar de 2019 às 10:36, Andy Fan
> escreveu:
>>
>> I need some function which requires some message exchange among different
>> back-ends （connections).
>> specially I need a shared hash map and a message queue.
>>
> It seems you are
In the thread about vacuum_cost_delay vs vacuum_cost_limit,
I wondered whether nanosleep(2) would provide any better
timing resolution than select(2). Some experimentation
suggests that it doesn't, but nonetheless I see a good reason
why we should consider making pg_usleep use nanosleep() if
Em seg, 11 de mar de 2019 às 10:36, Andy Fan
escreveu:
>
> I need some function which requires some message exchange among different
> back-ends （connections).
> specially I need a shared hash map and a message queue.
>
It seems you are looking for LISTEN/NOTIFY. However, if it is part of
a
On 3/11/19 6:07 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> I'm going to mark this as rejected. Here's a possible doc patch
> Maybe s/strictly/ordinary/, or some other word? "strictly"
> doesn't convey much to me. Otherwise seems fine.
OK, done.
cheers
andrew
--
Andrew Dunstan
On Mon, Mar 11, 2019 at 3:07 PM Tom Lane wrote:
>
> Andrew Dunstan writes:
> > I'm going to mark this as rejected. Here's a possible doc patch
>
> Maybe s/strictly/ordinary/, or some other word? "strictly"
> doesn't convey much to me. Otherwise seems fine.
>
How about:
While the COALESCE,
Andrew Dunstan writes:
> I'm going to mark this as rejected. Here's a possible doc patch
Maybe s/strictly/ordinary/, or some other word? "strictly"
doesn't convey much to me. Otherwise seems fine.
regards, tom lane
John Naylor writes:
> Now it looks like:
> perl renumber_oids.pl --first-mapped-oid 8000 --last-mapped-oid 8999
> --first-target-oid 2000 *.dat
> To prevent a maintenance headache, I didn't copy any of the formatting
> logic over. You'll also have to run reformat_dat_files.pl afterwards
> to
On 2019-03-11 13:31:26 -0700, Andres Freund wrote:
> On 2019-03-11 12:37:46 -0700, Andres Freund wrote:
> > Hi,
> >
> > On 2019-03-08 19:13:10 -0800, Andres Freund wrote:
> > > Changes:
> > > - I've added comments to all the callbacks in the first commit / the
> > > scan commit
> > > - I've
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
No need for documentation as this is a performance improvement
On 2019-03-08 11:09, Peter Eisentraut wrote:
> On 2019-03-07 20:04, Daniel Verite wrote:
>> With previous versions, we'd need to call ucol_setAttribute(),
>> with the attributes and values defined here:
>> http://icu-project.org/apiref/icu4c/ucol_8h.html
>> for instance to get
Hi Fabien,
On Sun, 10 Mar 2019 08:15:35 +0100 (CET)
Fabien COELHO I registered as a reviewer in the CF app.
Thanks.
What's causing problems here is that the encode and decode
functions are listed in both the string functions section
and the binary functions section. A related but not-relevant
On 2019-03-11 12:37:46 -0700, Andres Freund wrote:
> Hi,
>
> On 2019-03-08 19:13:10 -0800, Andres Freund wrote:
> > Changes:
> > - I've added comments to all the callbacks in the first commit / the
> > scan commit
> > - I've renamed table_gimmegimmeslot to table_slot_create
> > - I've made the
On 2019-Mar-11, Darafei Praliaskouski wrote:
> The feature is super valuable for complex PostGIS-enabled databases.
After having to debug a perf problem in this area, I agree, +1 for the patch.
Thanks
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
On 2019-Mar-11, Robert Haas wrote:
> On Mon, Mar 11, 2019 at 3:43 PM Alvaro Herrera
> wrote:
> > > Huh. Well, that's another option, but then what do we do if the
> > > number of phases is not a constant?
> >
> > Well, why do we care? "Some phases might be skipped".
>
> It seems pretty
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
I have read the patch and have no problems with it.
The feature is
On Mon, Mar 11, 2019 at 3:43 PM Alvaro Herrera wrote:
> > Huh. Well, that's another option, but then what do we do if the
> > number of phases is not a constant?
>
> Well, why do we care? "Some phases might be skipped".
It seems pretty confusing. I mean, in the case of the CLUSTER patch,
po 11. 3. 2019 v 18:04 odesílatel David Steele napsal:
> On 3/11/19 6:43 PM, Andrew Dunstan wrote:
> >
> > On 3/6/19 10:24 AM, Chapman Flack wrote:
> >> On 3/6/19 10:12 AM, Andrew Dunstan wrote:
> >>
> >>> Having reviewed the thread, I'm with Andres and Tom. Maybe though we
> >>> should have a
On 2019-Mar-11, Robert Haas wrote:
> On Mon, Mar 11, 2019 at 3:26 PM Alvaro Herrera
> wrote:
> > Oh. That's easily removed. Though I have to say that other people said
> > that they liked it so much that they would have liked to have it in the
> > original VACUUM one too
> >
On Thu, Mar 7, 2019 at 8:27 PM Michael Paquier wrote:
> After sleeping on it, let's live with just switching to nleft in the
> message, without openLogOff as that's the second time folks complain
> about the previous code. So I just propose the attached. Robert,
> others, any objections?
On Mon, Mar 11, 2019 at 3:26 PM Alvaro Herrera wrote:
> Oh. That's easily removed. Though I have to say that other people said
> that they liked it so much that they would have liked to have it in the
> original VACUUM one too (5ba2b281-9c84-772a-cf37-17780d782...@lab.ntt.co.jp).
Huh. Well,
On 2019-Mar-11, Robert Haas wrote:
> On Mon, Mar 11, 2019 at 3:18 PM Alvaro Herrera
> wrote:
> > On 2019-Mar-11, Robert Haas wrote:
> > > I don't think that I much like this (3 of 8) and (2 of 5) stuff. It's
> > > inconsistent with what we've got already and it doesn't add much.
> > > Someone
On Mon, Mar 11, 2019 at 3:18 PM Alvaro Herrera wrote:
> On 2019-Mar-11, Robert Haas wrote:
> > I don't think that I much like this (3 of 8) and (2 of 5) stuff. It's
> > inconsistent with what we've got already and it doesn't add much.
> > Someone who wants to know which phase it is can look at
On 2019-Mar-11, Robert Haas wrote:
> I don't think that I much like this (3 of 8) and (2 of 5) stuff. It's
> inconsistent with what we've got already and it doesn't add much.
> Someone who wants to know which phase it is can look at the underlying
> numbers directly instead of going through the
On Mon, Mar 11, 2019 at 8:41 AM Alvaro Herrera wrote:
> > I wonder how is the phase 'building index(3 of 8): initializing(1/5)' when
> > the blocks_done count is increasing. Shouldn't it have
> > changed to reflect PROGRESS_BTREE_PHASE_INDEXBUILD_HEAPSCAN as building
> > index(3 of 8): table
Hi!
I've some questions regarding this patchset.
1) This comment needs to be revised. Now, B-tree supports both
ammatchorderby and amcanbackward. How do we guarantee that kNN is not
backwards scan?
/*
* Only forward scan is supported with reordering. Note: we can get away
* with just
Hello Ryohei-san,
I understand the main aim of your suggestion that a client application has
to do a lot of work except making quires to the database. I agree with you
that "client-side timeout" has to be integrated into the PostgreSQL server
and libpq.
I'm with Fabien that "client-side
Hi,
I applied the patch on current master and run the tests, but I am afraid that
the newly introduced test failed on installcheck-world:
```t/016_min_consistency.pl . # Looks like your test exited with 29
before it could output anything.
t/016_min_consistency.pl .
Hi Alvaro,
On Tue, 5 Mar 2019 at 08:32, Alvaro Herrera
wrote:
> Hi Rahila,
>
> Thanks for looking.
>
> On 2019-Mar-04, Rahila wrote:
>
> > 1. Thank you for incorporating review comments.
> > Can you please rebase the latest 0001-Report-progress-of-
> > CREATE-INDEX-operations.patch on master?
On 3/11/19 1:04 PM, Dagfinn Ilmari Mannsåker wrote:
> Andrew Dunstan writes:
>
>> I think we've spent enough time on this. Committed with minor changes.
> Thanks for committing it. However, I can't see it in git. Did you forget
> to push?
>
>
Ooops, yes, done now.
cheers
andrew
--
On 3/11/19 6:43 PM, Andrew Dunstan wrote:
On 3/6/19 10:24 AM, Chapman Flack wrote:
On 3/6/19 10:12 AM, Andrew Dunstan wrote:
Having reviewed the thread, I'm with Andres and Tom. Maybe though we
should have a note somewhere to the effect that you can't use VARIADIC
with these.
Perhaps such a
Andrew Dunstan writes:
> I think we've spent enough time on this. Committed with minor changes.
Thanks for committing it. However, I can't see it in git. Did you forget
to push?
> cheers
>
>
> andrew
- ilmari
--
"A disappointingly low fraction of the human race is,
at any given time, on
On Mon, Mar 11, 2019 at 10:40 AM amul sul wrote:
>
> All the places from where this handle_missing_partition() get called
> have the following code to decide the value for missing_side_outer/_inner
> which
> I yet to understand. Do you think this has some flaw?
>
> /*
> * For a
On 3/6/19 10:24 AM, Chapman Flack wrote:
> On 3/6/19 10:12 AM, Andrew Dunstan wrote:
>
>> Having reviewed the thread, I'm with Andres and Tom. Maybe though we
>> should have a note somewhere to the effect that you can't use VARIADIC
>> with these.
> Perhaps such a note belongs hoisted into the
On 2019-Jan-25, Alvaro Herrera wrote:
> Would anybody object too hard if I move hash_any() and friends to
> src/backend/utils/hash/hashfn.c and the declarations to
> src/include/utils/hashutils.h?
Pushed this. I ended up adding an #include of utils/hashutils.h to
access/hash.h, so that any
Hi Hackers,
In master branch, unaccent extension is having issue with the below python
script.This issue is only in windows 10 and python 3.
python generate_unaccent_rules.py --unicode-data-file UnicodeData.txt
--latin-ascii-file Latin-ASCII.xml > unaccent.rules
I am getting the following
On 3/11/19 6:07 AM, David Rowley wrote:
> On Mon, 11 Mar 2019 at 12:37, Dagfinn Ilmari Mannsåker
> wrote:
>> David Rowley writes:
>>> I think some comments in the area to explain the 0th is for the sql
>>> would be a good idea too, that might stop any confusion in the
>>> future. I see that's
> I attached a simple bug-fixing patch.
I'm not happy with the situation, but don't see a better solution
either. Therefore I committed the change to get rid of the regression.
Thanks.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at
Amit Kapila writes:
> On Mon, Mar 11, 2019 at 8:45 AM Tom Lane wrote:
>> I can think of three plausible responses. In decreasing order of
>> amount of work:
>>
>> 1. Decide that we'd better wrap strtod() with something that ensures
>> platform-independent behavior for all our uses of strtod
On 10/03/2019 18:40, Andrey Borodin wrote:
Here's new version of the patch for actual page deletion.
Changes:
1. Fixed possible concurrency issue:
We were locking child page while holding lock on internal page. Notes
in GiST README recommend locking child before parent. Thus now we
unlock
Etsuro Fujita writes:
> (2019/03/11 14:14), Tom Lane wrote:
>> Seems to me it's the other way around: the final target would include
>> all functions invoked in the grouping target plus maybe some more.
>> So a non-parallel-safe grouping target implies a non-parallel-safe
>> final target, but not
Dean Rasheed writes:
> +1 for including the inverse functions. However, it looks to me like
> the inverse functions are C99-specific, so they might not be available
> on all supported platforms. If they're not, we may need to provide our
> own implementations.
FWIW, I'm pretty sure they're
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:tested, passed
Hello
I review latest patchset. I have one big question: Is
notes on the shared hash map: it needs multi writers and multi readers.
On Mon, Mar 11, 2019 at 9:36 PM Andy Fan wrote:
> Hi:
> I need some function which requires some message exchange among
> different back-ends （connections).
> specially I need a shared hash map and a message queue.
>
>
Hi:
I need some function which requires some message exchange among different
back-ends （connections).
specially I need a shared hash map and a message queue.
Message queue: it should be many writers, 1 reader. Looks POSIX message
queue should be OK, but postgre doesn't use it. is there
Hi,
I've been reading about TOASTing and would like to modify how the slicing works
by taking into consideration the type of the varlena field. These changes would
support future implementations of type specific optimized TOAST'ing functions.
The first step would be to add information to the
On Mon, Mar 11, 2019 at 10:03 AM David Rowley
wrote:
>
> On Mon, 11 Mar 2019 at 09:58, Tom Lane wrote:
> > The second patch is a delta that rounds off to the next smaller unit
> > if there is one, producing a less noisy result:
> >
> > regression=# set work_mem = '30.1GB';
> > SET
> >
Hi Rahila
On 2019-Mar-11, Rahila Syed wrote:
> On Tue, 5 Mar 2019 at 08:32, Alvaro Herrera
> wrote:
> > +extern char *btbuildphasename(int64 phasenum);
>
> 1. I think int64 is too large a datatype for phasenum.
> Also int32 is used for phasenum in pg_indexam_progress_phasename().
> Can we
On Sun, 3 Feb 2019 at 15:12, Tom Lane wrote:
>
> Andrew Gierth writes:
> > The spec doesn't require the inverse functions (asinh, acosh, atanh),
> > but surely there is no principled reason to omit them?
>
> +1 --- AFAICS, the C library has offered all six since C89.
>
+1 for including the
On 2019-02-06 23:15, Peter Eisentraut wrote:
> On 05/02/2019 17:20, Tom Lane wrote:
>> What I *don't* like about the proposed patch is that it installs a
>> new, different comparison rule for the ON UPDATE CASCADE case only.
>> If we were to go in this direction, I'd think we should try to use
>>
On 2019-Mar-11, Peter Eisentraut wrote:
> Variables used after a longjmp() need to be declared volatile. In
> case of a pointer, it's the pointer itself that needs to be declared
> volatile, not the pointed-to value. So we need
>
> PyObject *volatile items;
>
> instead of
>
>
Thanks, will work on it as you suggested
Add pg_basebackup --T olddir=newdir to support check the consistency of a
tablespace created before promotion
Add run_test('remote');
On Mon, Mar 11, 2019 at 6:50 AM Michael Paquier wrote:
> On Sat, Mar 09, 2019 at 09:09:24AM +0900, Michael Paquier
Thanks for the clarification!
On Mon, Mar 11, 2019 at 5:02 PM Thomas Munro wrote:
> On Mon, Mar 11, 2019 at 9:35 PM Andy Fan wrote:
> > and whenever I run a simple query "SELECT test_shm_mq(1024, 'a');"
> >
> > I see the following log
> >
> > 2019-03-11 16:33:17.800 CST [65021] LOG:
On 3/8/19 2:38 AM, Michael Paquier wrote:
On Thu, Mar 07, 2019 at 10:45:04AM +0200, David Steele wrote:
I think a new patch is required here so I have marked this Waiting on
Author. cfbot is certainly not happy and anyone trying to review is going
to have hard time trying to determine what to
Hi,
Am Montag, den 11.03.2019, 11:11 +0100 schrieb Michael Banck:
> I had a quick look over the patch and your changes and it LGTM.
One thing: you (Michael) should be co-author for patch #3 as I took some
of your code from https://github.com/michaelpq/pg_plugins/tree/master/pg
_checksums
Hi Michael,
Am Montag, den 11.03.2019, 13:53 +0900 schrieb Michael Paquier:
> On Wed, Feb 27, 2019 at 07:59:31AM +0100, Fabien COELHO wrote:
> > Hallo Michael,
>
> Okay, let's move on with these patches!
Wow cool. I was going to go back to these and split them up similar to
how you did it now
On Mon, 11 Mar 2019 at 12:37, Dagfinn Ilmari Mannsåker
wrote:
>
> David Rowley writes:
> > I think some comments in the area to explain the 0th is for the sql
> > would be a good idea too, that might stop any confusion in the
> > future. I see that's documented in the struct header comment, but
On Mon, 11 Mar 2019 at 09:58, Tom Lane wrote:
> The second patch is a delta that rounds off to the next smaller unit
> if there is one, producing a less noisy result:
>
> regression=# set work_mem = '30.1GB';
> SET
> regression=# show work_mem;
> work_mem
> --
> 30822MB
> (1 row)
>
>
On Mon, Mar 11, 2019 at 9:35 PM Andy Fan wrote:
> and whenever I run a simple query "SELECT test_shm_mq(1024, 'a');"
>
> I see the following log
>
> 2019-03-11 16:33:17.800 CST [65021] LOG: background worker "test_shm_mq"
> (PID 65052) exited with exit code 1
Hmm, I don't know actually know
On Sun, 10 Mar 2019 at 22:28, David Rowley wrote:
>
> On Mon, 11 Mar 2019 at 06:36, Tomas Vondra
> wrote:
> >
> > On 3/9/19 7:33 PM, Dean Rasheed wrote:
> > > I wonder if it's possible to write smaller, more targeted tests.
> > > Currently "stats_ext" is by far the slowest test in its group,
and whenever I run a simple query "SELECT test_shm_mq(1024, 'a');"
I see the following log
2019-03-11 16:33:17.800 CST [65021] LOG: background worker "test_shm_mq"
(PID 65052) exited with exit code 1
does it indicates something wrong?
On Mon, Mar 11, 2019 at 4:30 PM Andy Fan wrote:
>
On Mon, Mar 11, 2019 at 08:23:39AM +0100, Peter Eisentraut wrote:
> Attached patch fixes a couple of cases of that. Most instances were
> already correct.
It seems to me that you should look at that:
https://www.postgresql.org/message-id/20190308055911.gg4...@paquier.xyz
They treat about the
Works, thank you Thomas! I have spent more than 2 hours on this. do you
know which document I miss for this question?
Thanks
On Mon, Mar 11, 2019 at 4:05 PM Thomas Munro wrote:
> On Mon, Mar 11, 2019 at 8:59 PM Andy Fan wrote:
> > 4. CREATE EXTENSION test_shm_mq; ==> . could not open
(2019/03/09 1:25), Antonin Houska wrote:
Etsuro Fujita wrote:
(2019/03/01 20:16), Antonin Houska wrote:
Etsuro Fujita wrote:
Conversely, it appears that add_foreign_ordered_paths() added by the patchset
would generate such pre-sorted paths *redundantly* when the input_rel is the
final
On Sun, 10 Mar 2019 at 17:36, Tomas Vondra wrote:
> On 3/10/19 2:09 PM, Dean Rasheed wrote:
> > 14). The attnums Bitmapset passed to
> > statext_is_compatible_clause_internal() is an input/output argument
> > that it updates. That should probably be documented. When it calls
> > itself
On 2019-03-08 16:11, David Fetter wrote:
>> The outcome of that is exactly what my patch does, but the inputs are
>> different. We have PG_MAJORVERSION, which is always a single integer,
>> and PG_VERSION, which could be 10.9.8 or 11beta5 or 12devel. The patch does
>>
>> if (PG_VERSION ends with
On Thu, Feb 21, 2019 at 3:05 PM Pavan Deolasee wrote:
>
> Hi,
>
> Jeff Janes raised an issue [1] about PD_ALL_VISIBLE not being set correctly
> while loading data via COPY FREEZE and had also posted a draft patch.
>
> I now have what I think is a more complete patch. I took a slightly different
On Mon, Mar 11, 2019 at 8:59 PM Andy Fan wrote:
> 4. CREATE EXTENSION test_shm_mq; ==> . could not open extension control
> file "/.../share/postgresql/extension/test_shm_mq.control": No such file or
> directory
>
> how can I get it work? Thanks
Hi Andy,
Try this first:
cd
My code is based on commit
zhifan@zhifandeMacBook-Pro ~/g/polardb_clean> git log
commit d06fe6ce2c79420fd19ac89ace81b66579f08493
Author: Tom Lane
Date: Tue Nov 6 18:56:26 2018 -0500
what I did includes:
1. ./configure --enable-debug
2. make world // doesn't see the test_shm_mq on the
Variables used after a longjmp() need to be declared volatile. In
case of a pointer, it's the pointer itself that needs to be declared
volatile, not the pointed-to value. So we need
PyObject *volatile items;
instead of
volatile PyObject *items; /* wrong */
Attached patch fixes a
On Mon, Mar 11, 2019 at 03:44:39PM +0900, Amit Langote wrote:
> We could make the error message more meaningful depending on the context,
> but maybe it'd better be pursue it as a separate project.
Yeah, I noticed that stuff when working on it this afternoon. The
error message does not
Hi,
On 2019/03/06 17:27, Michael Paquier wrote:
> On Wed, Mar 06, 2019 at 04:00:42PM +0900, Amit Langote wrote:
>> Thanks for looking at this. Your patch seems better, because it allows us
>> to keep the error message consistent with the message one would get with
>> list-partitioned syntax.
>
On Wed, Feb 6, 2019 at 4:32 PM Pavan Deolasee wrote:
>
> Hello,
>
> Currently either the table level option `toast_tuple_target` or the compile
> time default `TOAST_TUPLE_TARGET` is used to decide whether a new tuple
> should be compressed or not. While this works reasonably well for most
>
88 matches
Mail list logo
