hings easier to have a 10g or a 10.8 to explain, instead
of a 10.0.8... and I'm not sure it'll make things easier to not have the
chance to bump the 2 major parts if it happened to be interesting in the
future like it was for 7.4->8 and 8.4->9 (9 is «new», it's the f
Le 07/07/2015 14:55, Andres Freund a écrit :
> On 2015-06-19 17:21:25 +0200, Cédric Villemain wrote:
>>> To make slot usage in pg_receivexlog easier, should we add
>>> --create-slot-if-not-exists? That'd mean you could run the same command
>>> the first and
g
> is new, and this is just adjusting the API slightly. I won't fight much
> for that opinion though.
+1 for it in 9.5
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
--
Sent via pgsql-hackers mail
> To make slot usage in pg_receivexlog easier, should we add
> --create-slot-if-not-exists? That'd mean you could run the same command
> the first and later invocation.
+1 (with a shorter name please, if you can find one... )
--
Cédric Villemain +33 (0)6 20 30 22 52
http://
antic time jumps, I
> think it's fair to patch it. Here's a proposed patch.
Does that still respect an autovacuum_naptime (GUC) greater than 5 minutes ?
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
--
Sen
backing VM object. Using vinvalbuf() here
* is a bit heavy-handed as it flushes all buffers for
* the given vnode, not just the buffers covering the
* requested range.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24
can benefits from the
patch...thus my question.
There were no noise for me, and I learn some more about GiN. So I thank
you for your work!
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
oint now.
So I do.
Alexander said:
1) In order to have fully correct support of fillfactor in GIN we need to
rewrite GIN build algorithm.
2) Without rewriting GIN build algorithm, not much can be done with entry
tree. However, you can implement some heuristics.
The patch is 2), for the posting tre
e benefits of this patch ? (maybe you had some test case or a
benchmark ?)
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
Le samedi 7 juin 2014 09:09:00 Gurjeet Singh a écrit :
> On Sat, Jun 7, 2014 at 8:56 AM, Cédric Villemain
wrote:
> > Le samedi 7 juin 2014 08:35:27 Gurjeet Singh a écrit :
> >> PS: Please note that I am not proposing to add support for the
> >> optimizer hint
ng to add support for the
> optimizer hint embedded in Mitsuru's query.
:-)
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
stgresql.org/message-id/20110504.231048.113741617.iwas...@jp.freebsd.org
https://commitfest.postgresql.org/action/patch_view?idT9
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
the warning. Duly noted.
As written in the meeting notes, Tom Lane revealed an interest in
pluggable storage. So it might be interesting to check that.
https://wiki.postgresql.org/wiki/PgCon_2013_Developer_Meeting
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support
Le jeudi 19 décembre 2013 03:08:59, Robert Haas a écrit :
> On Wed, Dec 18, 2013 at 6:07 PM, Cédric Villemain
wrote:
> >> When the prefetch process starts up, it services requests from the
> >> queue by reading the requested blocks (or block ranges). When the
> >>
t is not appreciated for Extension 'Templates' ....
I stopped trying to figure/undertand many arguments in those Extension email
threads)
Maybe something around that to have also the objects created by extension
dumped, and we're done. I even wnder if Dimitri has not already a patch for
that based on the work done for Extensions feature.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
loud here.
For windows see the C++ PrefetchVirtualMemory() function.
I really wonder if such a bgworker can improve the prefetching on !windows too
if ring insert is faster than posix_fadvise call.
If this is true, then effective_io_concurrency can be revisited. Maybe Greg
Stark already did some benchm
ive_io_concurrency (and pg_warm) it just doesn't
work when posix_fadvise is not available.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
stgresql. Only Windows is
out of scope so far. and there is a solution for windows too, there is just no
requirement from pgfincore users.
Maybe you can add the windows support in PostgreSQL now ?
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
sleep just before that error is thrown. Then run your test
> > case
> > until it hangs at that spot and get a stack backtrace. But that may
> > be more troubleshooting than you want to get into.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
essage-id/20130516165318.gf15...@eldon.alvh.no-ip.org
That's being said, you are correct about the problem you found and it's
good to be able to release new version without a bug for OSX.
I'm just sad you didn't get time to voice a bit before Andrew spent too
much time on that.
--
Le lundi 30 septembre 2013 00:10:09 Andrew Dunstan a écrit :
> On 09/29/2013 07:09 PM, Andrew Dunstan wrote:
> > On 09/03/2013 04:04 AM, Cédric Villemain wrote:
> >>> Simple one, attached.
> >>> I didn't document USE_VPATH, not sure how to explain that clearl
at the same time, rather than backpatch something broken.
Would you mind sharing the problems you are facing ?
You've noticed the problem about installdirs, I suppose. The attached
patch is the fix currently applyed at debian.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
P
ges on
> apt.postgresql.org?
9.3:
http://anonscm.debian.org/loggerhead/pkg-postgresql/postgresql-9.3/trunk/changes
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
Marti Raudsepp a écrit :
>On Tue, May 14, 2013 at 4:12 AM, Marti Raudsepp
>wrote:
>> While testing out PostgreSQL 9.3beta1, I stumbled upon a problem
>
>> % make DESTDIR=/tmp/foo install
>
>> /usr/bin/install: will not overwrite just-created
>> ‘/tmp/foo/usr/share/postgresql/extension/semver--
I know there are arguments against that
too)
Maybe the value for a 4x multiplier instead of 3x, is that the
effective_cache_size usage can be larger than required. It's not a big trouble.
With all things around NUMA we maybe just need to revisit that area (memory
access cost non linear, dou
gfixes were supposed to be backported. The behavior is not changed,
nothing new, just fixing problem for some kind of extension builds. (However
the USE_VPATH is new and is not needed in <9.3)
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 -
patch adding some helpers to validate GUC
change, I claimed this part was good enough to be added without ALTER SYSTEM
(so a contrib can use it).
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
Le jeudi 29 août 2013 11:52:36 Andres Freund a écrit :
> On 2013-08-29 11:49:00 +0200, Cédric Villemain wrote:
> > Le mercredi 28 août 2013 00:12:22 Andres Freund a écrit :
> > > Hi Alvaro,
> > >
> > > On 2013-08-27 14:47:49 -0400, Alvaro Herrer
or real USE_PGXS
> builds (where the original sourcetree won't be at that location
> anymore).
I had the same idea when Peter wished to remove PGXS from the contrib shiped
with postgreSQL.
I've been convinced that if we want to apply testing on pgxs makefile then we
need
> There seemed to be agreement on having a config.d, though.
Yes.
Also, the validate_conf_parameter() (or some similar name) Amit added in his
patch sounds useful if an extension can use it (to check a GUC someone want to
change, to check a configuration file, ...)
--
Cédric Villemain +33 (
b/ to modify config, then design what we can
achieve more with an ALTER SYSTEM command.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
e that the same may also allow postgresql to start with bad GUC value in
postgresql.conf
So this is another topic (IMHO).
With the current idea of one-GUC-one-file in a PGDATA subdirectory it is *easy*
to fix for any DBA or admin. However, note that I do prefer a simple
'include_aut
Le mardi 30 juillet 2013 05:27:12, Amit Kapila a écrit :
> On Monday, July 29, 2013 7:15 PM Cédric Villemain wrote:
> > Le lundi 29 juillet 2013 13:47:57, Amit Kapila a écrit :
> > > On Sunday, July 28, 2013 11:12 AM Amit kapila wrote:
> > > > On Friday, July 2
old/new auto GUC, or at least
> > more simple).
>
> This has already been debated, and we have already reached consensus
> (one file to rule them all). I don't think it's a good idea to go over
> all that discussion again.
ok, I've only lost track for the consen
that it limits the access to ALTER SYSTEM. One file per
GUC allows to LWlock only this GUC, isn't it ? (and also does not require
machinery for holding old/new auto GUC, or at least more simple).
It also prevent usage of ALTER SYSTEM for a cluster (as in replication)
because this is not WAL logged. But it can be easier if trying to manage only
one GUC at a time.
I agree with Tom comment that this file(s) must be in data_directory.
postgresql.auto.conf is useless, a "data_directory/auto.conf" (.d/ ?) is
enough.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
nimal', but not when using archiving of WAL.
I'm unsure how this has been tunned with streaming replication addition.
see xlog.c|h
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
x27;m
> just sure that there would be less keywords. IMHO, this issue is
> orthogonal & independent from this patch.
>
> Finally, to answer your question directly, I'm really a nobody here, so
> you can do whatever pleases you with the patch.
I have no strong objection to the patch. It is only decoration and should not
hurt.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
Le lundi 8 juillet 2013 21:46:39, Andrew Dunstan a écrit :
> On 07/08/2013 03:40 PM, Josh Berkus wrote:
> > On 07/04/2013 06:18 AM, Andrew Dunstan wrote:
> >> On 07/04/2013 09:14 AM, Cédric Villemain wrote:
> >>> ah yes, good catch, I though .control file were uniqu
ok at pgbouncer: query_wait_timeout parameter for example.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
> > I'm not sure whether this is as simple as changing $< to $^ in the
> > pgxs.mk's installcontrol rule, or if something more is required.
> > Could you take a look?
> >
>
> will do.
ah yes, good catch, I though .control file were unique per contrib,
that we need better coverage in PGXS area, so
it is another thing to consider (TODO : add resgress test for PGXS ...)
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
Le mercredi 3 juillet 2013 21:03:42, Christopher Browne a écrit :
> On Wed, Jul 3, 2013 at 2:24 PM, Cédric Villemain
wrote:
> > > Clearly I ticked off a bunch of people by publishing "the list". On
> > > the other hand, in the 5 days succeeding the post, more than
te in a
project which stamps people ?
With or without review, it's a shame if people stop proposing patches because
they are not sure to get time to review other things *in time*.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
r-file.patch , others are in
the hands of Andrew.
Additional patch required for documentation.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
Le samedi 29 juin 2013 19:54:53, Andrew Dunstan a écrit :
> On 06/26/2013 10:52 AM, Andrew Dunstan wrote:
> > On 06/25/2013 11:29 AM, Cédric Villemain wrote:
> >> Le mardi 25 juin 2013 17:18:51, Andrew Dunstan a écrit :
> >>> On 06/24/2013 07:24 PM, Cédric Villemain
[it seems my first email didn't make it, sent again]
Le mercredi 26 juin 2013 16:52:01, Andrew Dunstan a écrit :
> On 06/25/2013 11:29 AM, Cédric Villemain wrote:
> > Le mardi 25 juin 2013 17:18:51, Andrew Dunstan a écrit :
> >> On 06/24/2013 07:24 PM, Cédric Villemain w
Le mercredi 26 juin 2013 16:52:01, Andrew Dunstan a écrit :
> On 06/25/2013 11:29 AM, Cédric Villemain wrote:
> > Le mardi 25 juin 2013 17:18:51, Andrew Dunstan a écrit :
> >> On 06/24/2013 07:24 PM, Cédric Villemain wrote:
> >>> Le mardi 25 juin 2013 00:18:26, Andr
Le mardi 25 juin 2013 17:18:51, Andrew Dunstan a écrit :
> On 06/24/2013 07:24 PM, Cédric Villemain wrote:
> > Le mardi 25 juin 2013 00:18:26, Andrew Dunstan a écrit :
> >> On 06/24/2013 04:02 PM, Cédric Villemain wrote:
> >>> WIth extension, we do have to set VPATH
Le mardi 25 juin 2013 00:18:26, Andrew Dunstan a écrit :
> On 06/24/2013 04:02 PM, Cédric Villemain wrote:
> > WIth extension, we do have to set VPATH explicitely if we want to use
> > VPATH (note that contribs/extensions must not care that postgresql has
> > been built with
Le lundi 24 juin 2013 19:40:19, Andrew Dunstan a écrit :
> On 06/18/2013 09:52 AM, Cédric Villemain wrote:
> > I've rebased the current set of pending patches I had, to fix pgxs and
> > added 2 new patches.
> >
> > Bugfixes have already been presented and sent i
patching file src/test/regress/expected/create_cast.out
(Stripping trailing CRs from patch.)
patching file src/test/regress/sql/create_cast.sql
==
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
ior on this patch is not yet
acquired, you should consider that too.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
than replaying all
> the WALs between W1 and Wn and saves a lot of space.
>
> I was hoping to find some time to dig around this idea, but as the
> subject rose here, then here are my 2¢!
something like that maybe :
./pg_xlogdump -b \
../data/pg_xlog/000100
ed patch update
** Can you make it crash? no
* Architecture review
** Is everything done in a way that fits together coherently with other
features/modules? Yes
** Are there interdependencies that can cause problems? No.
I flag it 'return with feedback', please update the patch so it
ROWS between 0 PRECEDING and
UNBOUNDED FOLLOWING) from foo;
What do you expect "SELECT first(val order by ts desc)" to output ?
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
y a relatively
> simple change, and I don't think that using "hstore.h" within hstore,
> and "contrib/hstore/hstore.h" elsewhere is of great concern.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
Le jeudi 20 juin 2013 05:26:21, Peter Eisentraut a écrit :
> On Wed, 2013-06-19 at 20:58 +0200, Cédric Villemain wrote:
> > I believe he answered the proposal to put all headers on the same flat
> > directory, instead of a tree.
>
> The headers are used as
>
> #in
hout an install we will make targets for that, and buildfarm support.
With the set of patches I sent, contrib can be built with PGXS, there is no
issue hereExcept maybe pg_xlogdump, and this one might be improved not to
have to rebuild shared object from postgresql (IIRC it is a static build
this decision and keep on the idea to just install
headers where there should be will traditional name (contrib).
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
Le mercredi 19 juin 2013 18:48:21, Andrew Dunstan a écrit :
> On 06/19/2013 12:32 PM, Cédric Villemain wrote:
> > Le mercredi 19 juin 2013 18:20:11, Andrew Dunstan a écrit :
> >> On 06/19/2013 11:26 AM, Peter Eisentraut wrote:
> >>> On 6/19/13 10:19 AM, Andrew Dunst
, but I'm open for suggestion.
$ tree -d include
include
├── libpq
└── postgresql
├── contrib
│ └── hstore
├── informix
│ └── esql
├── internal
│ └── libpq
└── server
And all subidrs of server/
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadr
F, for me current status is: 'Ready, Waiting more feedback from
community'.
[1] http://www.postgresql.org/message-
id/1371610695.13762.25.ca...@vanquo.pezone.net
[2] http://www.postgresql.org/message-
id/1371172850.79798.yahoomail...@web193505.mail.sg3.yahoo.com
[3] http://www.postgresq
Le mercredi 19 juin 2013 04:58:15, Peter Eisentraut a écrit :
> On Mon, 2013-06-17 at 19:00 +0200, Cédric Villemain wrote:
> > My only grief is to loose the perfect regression tests for PGXS those
> > contribs are.
>
> I think they are neither perfect nor regression tests
Le mercredi 19 juin 2013 04:48:11, Peter Eisentraut a écrit :
> On Tue, 2013-06-18 at 15:52 +0200, Cédric Villemain wrote:
> > This allows for example to install hstore header and be able to
> > include them
> >
> > in another extension like that:
> > #
0003-set-VPATH-for-out-of-tree-extension-builds.patch
0004-adds-support-for-VPATH-with-USE_PGXS.patch
0006-Fix-suggested-layout-for-extension.patch
New feature:
0005-Allows-extensions-to-install-header-file.patch
I'll do a documentation patch based on what is accepted in HEAD and/or
previous branch
gt;
> > Should we add a "prior version" category to the CF to make sure these
> > don't get dropped? Or do something else?
>
> A separate commit fest for tracking proposed backpatches might be
> useful.
Backpatches are bugs fix, isnt it ?
I will like to have
s try to fix 3. by
> : exporting USE_PGXS
But:
4. can be fixed (see patches I sent) so it is not an excuse.
I agree for other points.
My only grief is to loose the perfect regression tests for PGXS those contribs
are.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
Post
REGRESSDIR ?
Also I suggest to remove the need to set REGRESS at all, and default to all
sql files in REGRESSDIR/sql (if REGRESSDIR is set)
Back to DOCS, we may also have PGXS default to find a README(.*) and rename it
to README.$extension.$1 if MODULEDIR is not set.
> REGRESS_OPTS =
rrently use. I certainly don't claim it's perfect.
I am interested by this topic, since we have Extensions we invite users to
increase the usage of them. So going a step forward with a better layout is
definitively something to do. I have no strong assumption on what the ideal
layou
Andrew Dunstan a écrit :
>
>On 06/14/2013 08:35 AM, Peter Eisentraut wrote:
>> On 6/13/13 9:20 PM, amul sul wrote:
>>> Agree, only if we consider these contrib module is always gonna
>deployed with the postgresql.
>>> But, what if user going to install such module elsewhere i.e. not
>from contri
Peter Eisentraut a écrit :
>A transform is an SQL object that supplies to functions for converting
>between data types and procedural languages. For example, a transform
>could arrange that hstore is converted to an appropriate hash or
>dictionary object in PL/Perl or PL/Python.
Nice !
>Cont
bly be 16 bytes each
> or 8KB total.
The point was only if the original comment was still relevant. It seems it is
just not accurate anymore.
With patch I can union 492 csv tables instead of 32 with beta1.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Suppor
I can think of at the moment is the time spent to close
file descriptors on abort/commit.
I'm not sure of expected value of "max_safe_fds". Your patch now initialize
with 5 slots instead of 10, if max_safe_fds is large maybe it is better to
double the size each time we need
functions,
* it seems OK to put a pretty small maximum limit on the number of
* simultaneously allocated descs.
Is it now encouraged to use those functions, or at least that it seems less
'scary' than in the past ?
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
at providing a patch.
No idea on the best approach yet. But I am interested in this topic (for
debian packaging).
PS: I have a serie of bugfix and patches pending in the current commitfest
(http://commitfest.postgresql.org) to help build with VPATH. You may be
interested in them...
--
Cédric Villem
Le mardi 28 mai 2013 15:15:55, Cédric Villemain a écrit :
> Le samedi 25 mai 2013 16:41:24, Cédric Villemain a écrit :
> > > > If it seems to be on the right way, I'll keep fixing EXTENSION
> > > > building with VPATH.
> > >
> > > I haven'
Le mardi 28 mai 2013 14:10:14, Cédric Villemain a écrit :
> > I just took time to inspect our contribs, USE_PGXS is not supported by
> > all of them atm because of SHLIB_PREREQS (it used submake) I have a
> > patch pending here to fix that.
>
> Attached patch fix SHLIB_PR
Le jeudi 30 mai 2013 14:32:46, Stefan Kaltenbrunner a écrit :
> On 05/29/2013 06:08 PM, Cédric Villemain wrote:
> >> I just took time to inspect our contribs, USE_PGXS is not supported by
> >> all of them atm because of SHLIB_PREREQS (it used submake) I have a
> >>
pped trying to add new item after too many failures from
https://commitfest.postgresql.org/action/patch_form
So one patch is not in the commitfest yet (fix_install_ext_vpath.patch)
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise e
Le samedi 25 mai 2013 16:41:24, Cédric Villemain a écrit :
> > > If it seems to be on the right way, I'll keep fixing EXTENSION building
> > > with VPATH.
> >
> > I haven't tried the patch, but let me just say that Debian (and
> > apt.postgresql
Le mardi 28 mai 2013 14:16:38, Cédric Villemain a écrit :
> > Once all our contribs can build with USE_PGXS I
> > fix the VPATH.
> >
> > The last step is interesting: installcheck/REGRESS. For this one, if I
> > can know exactly what's required (for debian buil
ry of the *first* makefile...
Thus it fixes:
mkdir /tmp/a && cd /tmp/a
make -f extension_src/Makefile USE_PGXS=1
Note that the patch fix things. Still I am not really happy with the rule to
get the srcdir.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Supp
e regression data files from the srcdir
to the builddir when doing 'make VPATH'. but it failed when used in
conjunction with USE_PGXS and out-of-tree build of an extension.
Issue is the absence of the data/ directory in the builddir.
Attached patch fix that.
--
Cédric Villemain +33 (0)6
d to port that to PGXS build.
The issue is that "submake-*" can not be built with PGXS, in this case they
must check that expected files are present (and installed).
Maybe it is better to only check if they have been built ?
This fix the build of dblink and postgres_fdw (make USE_
ibs can build with USE_PGXS I fix the VPATH.
The last step is interesting: installcheck/REGRESS. For this one, if I can
know exactly what's required (for debian build for example), then I can also
fix this target.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL:
e a look at this page:
http://wiki.postgresql.org/wiki/Submitting_a_Patch
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
Le jeudi 16 mai 2013 18:53:19, Alvaro Herrera a écrit :
> Andrew Dunstan wrote:
> > On 05/16/2013 10:39 AM, Cédric Villemain wrote:
> > >Le jeudi 16 mai 2013 15:51:48, Tom Lane a écrit :
> > >>Andrew Dunstan writes:
> > >>>On 05/16/2013 05:41 AM, Dimit
xs.mk: No such
> > file or directory
> >
> > What do I need to do to obtain the required files, and does anybody
> > know why, given Postgres 9.2 is out some time, and 9.3 is in beta, why
> > no prebuild binary PLJavas exist for 9.2?
>
> Because nobody
o help
extension author allows build out-of-tree (postgresql been built out or not).
I'll work on a patch for that.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
ion authors and
add rules/target to pgxs.mk to reduce the useless copy/paste in the Makefile of
extensions.
So what's desirable ?
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
; >
> > If it's built, then it should be listed in DATA_built.
>
> So, AIUI, leaving aside stylistic arguments about use of wildcards, one
> solution could be:
>
> DATA_built = sql/$(EXTENSION)--$(EXTVERSION).sql
> DATA = $(filter-out sql/$(EXTENSION)--$(EXTVERSI
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)
ifeq ($(PG91),yes)
sql/$(EXTENSION)--$(EXTVERSION).sql: sql/$(EXTENSION).sql
cp $< $@
endif
because the default target from the PostgreSQL Makefile is «all:» and the
addition of a target before inclusion of PostgreSQL makefile change
bly still break
> non-public extensions that people have written.
My understanding is that the offending commit reveals possible bad written
instruction in some Makefile. What's wrong ?
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
Le vendredi 3 mai 2013 15:40:51, Heikki Linnakangas a écrit :
> On 03.05.2013 16:29, Bruce Momjian wrote:
> > On Fri, May 3, 2013 at 01:02:08PM +0200, Cédric Villemain wrote:
> >>>>>> This changes the existing API which will confuse people that know it
> >>
st.
> >
> > So, is there a way to add this feature without breaking the API?
>
> Yes, by adding a new parameter exclusively used to control this feature,
> something like recovery_target_immediate = 'on/off'.
We just need to add a named restore point when ending the
tradeoff for
> use in emergencies, I have to give it a lot of praise. The main
> advantage it has here is it implements point-in-time recovery
> operations that easy to use and actually seem to work. That said,
> I've mostly done targeted recoveries rather than trying to
t;, thus
getting expected UNIQUEness also in the history.
Vlad, is your source code in a public versionning system (github, bucket, etc) ?
It will ease the process to participate to your extension...
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
have new feature, so everything can
go in postgreql.conf, and also allows using recovery.conf so it does not break
backward-compatibility.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
of "gram.c" (and "gram.o").
Maybe Makefile has an option to be a little bit more conservative and rebuild
any removed intermediate file even if not required.
> > What was the consensus when Peter did the change ?
>
> It was an experiment, nothing more; or at least th
ELETE_ON_ERROR:
+ifndef NOTSECONDARY
# Never delete any intermediate files automatically.
.SECONDARY:
+endif
$ rm rewriteDefine.o
$ make
nothing to do ...
$ NOTSECONDARY=1 make
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-
statement -Wendif-labels -Wmissing-format-
1 - 100 of 336 matches
Mail list logo
