On Sat, Oct 13, 2018 at 3:57 AM Robert Haas wrote:
> On Wed, Oct 10, 2018 at 8:27 AM Haribabu Kommi
> wrote:
> > Here is the patch as per the above discussion.
>
> One potential problem with this is that we could add more control-file
> attributes in the future, and it will be annoying if the vi
Colleagues,
I've encountered some problems trying to enable gss support in MSVC
build of Postgres (I've experemented with REL_10_STABLE branch, but
code in question seems to be same in all supported releases, including
master).
As it is recommended in the documentation, I've downloaded MIT Kerber
Hi hackers,
Currently for quals in the form of "NOT NOT (SubLink)", this SubLink would
not
be considered when pulling up sublinks. For instance:
gpadmin=# explain select * from a where NOT NOT (a.i in (select b.i from
b));
QUERY PLAN
--
Colleagues,
Since Active State stopped to distribute perl 5.22, we decided to
upgrade installer builds to most use recent version available
(5.26.1.2601 now).
But upstream perl changes policy around this version and no longer
adds current directory to the module search path.
This doesn't break w
On Mon, Oct 15, 2018 at 6:09 PM Amit Kapila wrote:
>
> On Sun, Sep 2, 2018 at 12:19 AM Thomas Munro
> wrote:
> > I have also pushed a new WIP version of the lower level undo log
> > storage layer patch set to a public branch[1]. I'll leave the earlier
> > branch[2] there because the record-level
Hi all,
I want to init SHM in a background worker, which is supported in PG9.4.
Also I need to use lwlock to protect the share memory inside the worker
code.
RequestNamedLWLockTranche is the way to handle it, but it's not supported
in PG 9.4, is there any way I could request an unique lock inside
On Wed, Oct 17, 2018 at 3:49 PM Hubert Zhang wrote:
>
> Hi all,
>
> I want to init SHM in a background worker, which is supported in PG9.4. Also
> I need to use lwlock to protect the share memory inside the worker code.
>
> RequestNamedLWLockTranche is the way to handle it, but it's not supported
Am 16. Okt. 2018 um 17:13 schrieb Tom Lane :
> Oh, well *this* is interesting. I stated at the top of this thread that
> pltcl doesn't build on Mojave without -isysroot because TCL_INCLUDE_SPEC
> gets set to
> -iwithsysroot
> /System/Library/Frameworks/Tcl.framework/Versions/8.5/Headers
>
Hi
On Wed, Oct 17, 2018 at 2:08 PM Victor Wagner wrote:
> Colleagues,
>
> Since Active State stopped to distribute perl 5.22, we decided to
> upgrade installer builds to most use recent version available
> (5.26.1.2601 now).
>
> But upstream perl changes policy around this version and no longer
>
Hi Sumit,
Unfortunately, those questions seem rather vague and generic, to the
extent that it's virtually impossible to answer them without speculating
what your "join order optimization" might do ...
Generally speaking, paths are the primary output of a planner, so if all
you do is construc
Jakob Egger writes:
> Am 16. Okt. 2018 um 17:13 schrieb Tom Lane :
>> Oh, well *this* is interesting. I stated at the top of this thread that
>> pltcl doesn't build on Mojave without -isysroot because TCL_INCLUDE_SPEC
>> gets set to
>> -iwithsysroot /System/Library/Frameworks/Tcl.framework/Versio
On Wed, 17 Oct 2018 18:45:42 +0530
Sandeep Thakkar wrote:
> > Simple adding
> >
> > use lib ".";
> >
> > to the beginning of these script solves problem.
> >
> >
> > We observed the same issue with Strawberry Perl 5.26. We use 5.24
> > to
> execute the build.pl.
Of course. This is (mis)featu
Hi Amit
The section "Share Memory and LWLocks" describe the AddinShmemInitLock which
is used to protect the ShmemInitStruct() when backend workers initialize
their shm. My requirement is to how to protect the shm access within the
bgworkers(not at init stage). This lock should be bgworkers specif
Am 17.10.2018 um 16:28 schrieb Tom Lane :
> It's also very odd,
> if the compiler will search the sysroot automatically, why that seemingly
> works for tcl.h but not perl.h. plperl definitely still fails if you
> lobotomize the PG_SYSROOT logic.
Because pl/tcl ends up using -iwithsysroot to spec
Hi,
On 2018-10-17 23:11:26 +0800, Hubert Zhang wrote:
> The section "Share Memory and LWLocks" describe the AddinShmemInitLock which
> is used to protect the ShmemInitStruct() when backend workers initialize
> their shm. My requirement is to how to protect the shm access within the
> bgworkers(no
В письме от 16 октября 2018 19:17:20 пользователь Andres Freund написал:
> Hi,
>
> On 2018-10-16 22:05:28 -0400, James Coleman wrote:
> > > I don't think it's entirely safe to do so for invisible rows. The toast
> > > references could be reused, constraints be violated, etc. So while I
> > > cou
Thanks a lot.
On Wed, Oct 17, 2018 at 11:21 PM Andres Freund wrote:
> Hi,
>
> On 2018-10-17 23:11:26 +0800, Hubert Zhang wrote:
> > The section "Share Memory and LWLocks" describe the AddinShmemInitLock
> which
> > is used to protect the ShmemInitStruct() when backend workers initialize
> > thei
Greetings,
* Thomas Munro (thomas.mu...@enterprisedb.com) wrote:
> On Mon, Oct 15, 2018 at 11:35 AM Tom Lane wrote:
> > Andres Freund writes:
> > > Does anybody have engineering / architecture level comments about this
> > > proposal?
> >
> > FWIW, I'm -1 on making OIDs be not-magic for SELECT p
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Sun, Oct 14, 2018 at 6:43 PM Andres Freund wrote:
> > I'm not sure we want that however - yes, the short time pain will be
> > lower, but do we really want to inflict the confusion about invisible
> > oids on our users for the next 20 y
>
>
> I did compleatly got the question... The question is it safe to split
> tuple
> record into array of raw bytea? It is quite safe from my point of view.
> We
> use only data that is inside the tuple, and info from pg_catalog that
> describes the tuple structure. So we are not affected if for e
В письме от 17 октября 2018 12:36:54 пользователь James Coleman написал:
> > I did compleatly got the question... The question is it safe to split
> > tuple
> > record into array of raw bytea? It is quite safe from my point of view.
> > We
> > use only data that is inside the tuple, and info from p
On 2018-10-17 12:36:54 -0400, James Coleman wrote:
> >
> >
> > I did compleatly got the question... The question is it safe to split
> > tuple
> > record into array of raw bytea? It is quite safe from my point of view.
> > We
> > use only data that is inside the tuple, and info from pg_catalog that
Indeed. But I do think your approach - which means that the binary data is
> actually interpreded as a datum of a specific type, drastically
> increases the risk.
>
>
Agreed.
As I noted earlier, I don't at all think deTOASTing is a must for this
function to be
valuable, just as tuple_data_split()
Hi,
On 2018-10-17 13:04:33 -0400, James Coleman wrote:
> Indeed. But I do think your approach - which means that the binary data is
> > actually interpreded as a datum of a specific type, drastically
> > increases the risk.
> >
> >
> Agreed.
>
> As I noted earlier, I don't at all think deTOASTing
> It's far from only toast that could be problematic here.
>
Do you have an example in mind? Wouldn’t the tuples have to be corrupted in
some way to have problems with being interpreted as a datum? Or are you
thinking very old tuples with a radically different structure to be causing
the problem?
Hi,
On 2018-10-17 13:14:17 -0400, James Coleman wrote:
> > It's far from only toast that could be problematic here.
> >
>
> Do you have an example in mind? Wouldn’t the tuples have to be corrupted in
> some way to have problems with being interpreted as a datum? Or are you
> thinking very old tup
It looks like my upgrade to the current head of FreeBSD 12-to-be, which
includes OpenSSL 1.1.1 broke a bunch of our stuff.
In at least the 9.x branches. Just a heads up.
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...
Larry Rosenman writes:
> It looks like my upgrade to the current head of FreeBSD 12-to-be, which
> includes OpenSSL 1.1.1 broke a bunch of our stuff.
> In at least the 9.x branches. Just a heads up.
It looks like configure is drawing the wrong conclusions about OpenSSL's
API options. Since the
On Wed, Oct 17, 2018 at 01:41:59PM -0400, Tom Lane wrote:
> Larry Rosenman writes:
> > It looks like my upgrade to the current head of FreeBSD 12-to-be, which
> > includes OpenSSL 1.1.1 broke a bunch of our stuff.
> > In at least the 9.x branches. Just a heads up.
>
> It looks like configure is
On 2018-10-16 19:48:42 -0400, Tom Lane wrote:
> BTW, I looked around for .o files with large BSS numbers, and came across
>
> $ size src/interfaces/ecpg/ecpglib/prepare.o
>textdata bss dec hex filename
>4023 4 1048576 1052603 100fbb src/interfaces/ecpg/ecpglib/prepar
On 16/10/2018 06:33, Ashutosh Sharma wrote:
> I think, the root cause of this problem is that CopyFrom() is using
> the stale value of *has_before_insert_row_trig* to determine if the
> current partition is okay for multi-insert or not i.e.
> has_before_insert_row_trig used to determine multi-inser
This is something I'm very interested in. Very helpful for fixing mistakes
you didn't realize in time.
One question, would it be possible to allow this to be able to be
configured on a hot standby and not the master?
That would be very helpful by being able to keep some arbitrary length of
extra
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Surafel Temesgen writes:
> > According to the documentation –inserts option is mainly useful for making
> > dumps that can be loaded into non-PostgreSQL databases and to reduce the
> > amount of rows that might lost during error in reloading but
On 16/10/2018 08:30, Andres Freund wrote:
> This just reminded me that a couple times I wanted a cast that casts
> away const, but otherwise makes sure the type stays the same. I don't
> think there's a way to do that in C, but we can write one that verifies
> the cast doesn't do something bad if g
Andres Freund writes:
> .data 1180 datetktbl ./src/interfaces/ecpg/pgtypeslib/dt_common.o
> .data 0c28 ibmkanji
> ./src/backend/utils/mb/conversion_procs/euc_jp_and_sjis/euc_jp_and_sjis.o
> .data 03f0 deltatktbl ./src/interfaces/ecpg/pgtypeslib/dt_common.o
Hmm
I wrote:
> Andres Freund writes:
>> .data 1180 datetktbl ./src/interfaces/ecpg/pgtypeslib/dt_common.o
>> .data 0c28 ibmkanji
>> ./src/backend/utils/mb/conversion_procs/euc_jp_and_sjis/euc_jp_and_sjis.o
>> .data 03f0 deltatktbl
>> ./src/interfaces/ecpg/pgtypesl
Larry Rosenman writes:
> That got it further, but still fails at PLCheck-C (at least on 9.3).
> It's still running the other branches.
Hmm. I'm not sure why plpython is crashing for you, but this is exposing
a robustness problem in the DSM logic:
https://buildfarm.postgresql.org/cgi-bin/show_lo
On 2018-10-17 21:06:13 +0200, Peter Eisentraut wrote:
> On 16/10/2018 08:30, Andres Freund wrote:
> > This just reminded me that a couple times I wanted a cast that casts
> > away const, but otherwise makes sure the type stays the same. I don't
> > think there's a way to do that in C, but we can wr
On Thu, Oct 18, 2018 at 9:00 AM Tom Lane wrote:
> 2018-10-17 13:43:24.235 CDT [46467:6] LOG: dynamic shared memory control
> segment is corrupt
> TRAP: FailedAssertion("!(dsm_control_mapped_size == 0)", File: "dsm.c", Line:
> 181)
>
> It looks to me like what's happening is
>
> (1) crashing pro
> There's plenty ways it can go horribly wrong. Let's start with something
> simple:
>
> BEGIN;
> ALTER TABLE ... ADD COLUMN blarg INT;
> INSERT ... (blag) VALUES (132467890);
> ROLLBACK;
>
> ALTER TABLE ... ADD COLUMN blarg TEXT;
>
> If you now read the table with your function you'll see a dead r
On 2018-10-17 17:02:20 -0400, James Coleman wrote:
> > There's plenty ways it can go horribly wrong. Let's start with something
> > simple:
> >
> > BEGIN;
> > ALTER TABLE ... ADD COLUMN blarg INT;
> > INSERT ... (blag) VALUES (132467890);
> > ROLLBACK;
> >
> > ALTER TABLE ... ADD COLUMN blarg TEXT;
On 10/17/2018 04:38 AM, Victor Wagner wrote:
Colleagues,
Since Active State stopped to distribute perl 5.22, we decided to
upgrade installer builds to most use recent version available
(5.26.1.2601 now).
But upstream perl changes policy around this version and no longer
adds current director
On 10/17/2018 05:16 PM, Andrew Dunstan wrote:
On 10/17/2018 04:38 AM, Victor Wagner wrote:
Colleagues,
Since Active State stopped to distribute perl 5.22, we decided to
upgrade installer builds to most use recent version available
(5.26.1.2601 now).
But upstream perl changes policy around
The MSVC compilers are whingeing about recent changes in snprintf.c:
src\port\snprintf.c(1051): warning C4146: unary minus operator
applied to unsigned type, result still unsigned
The line in question reads:
uvalue = -(unsigned long long) value;
cheers
andrew
--
Andrew Dunstan
On 10/16/2018 06:09 PM, Michael Paquier wrote:
On Mon, Oct 15, 2018 at 11:20:28AM -0400, Andrew Dunstan wrote:
On 10/15/2018 11:05 AM, Tom Lane wrote:
Andrew Dunstan writes:
We should fix this in PG11 rather than ship a broken utility. If
everyone is happy, I can apply this.
At this point
Hi,
On 2018-10-17 17:27:14 -0400, Andrew Dunstan wrote:
>
> The MSVC compilers are whingeing about recent changes in snprintf.c:
>
>
>src\port\snprintf.c(1051): warning C4146: unary minus operator
>applied to unsigned type, result still unsigned
>
>
> The line in question reads:
>
>
On 17/10/2018 22:02, Andres Freund wrote:
>> Your version with __builtin_types_compatible_p() doesn't work for
>> casting between char * and const char *, so it wouldn't be very useful.
> Huh, why wouldn't it work for char *? Seems to work fine for me?
__builtin_types_compatible_p(const char *, ch
Hi,
On 2018-10-17 23:43:31 +0200, Peter Eisentraut wrote:
> On 17/10/2018 22:02, Andres Freund wrote:
> >> Your version with __builtin_types_compatible_p() doesn't work for
> >> casting between char * and const char *, so it wouldn't be very useful.
> > Huh, why wouldn't it work for char *? Seems
During discussions of alternative SSL implementations, contrib/sslinfo
is usually mentioned as something that something needs to be done about.
I've looked into adapting some functionality from sslinfo into the
pg_stat_ssl view. These two facilities have a lot of overlap but seem
mostly oblivious
On 10/17/2018 05:31 PM, Andres Freund wrote:
Hi,
On 2018-10-17 17:27:14 -0400, Andrew Dunstan wrote:
The MSVC compilers are whingeing about recent changes in snprintf.c:
src\port\snprintf.c(1051): warning C4146: unary minus operator
applied to unsigned type, result still unsigned
On Thu, Oct 18, 2018 at 9:43 AM Thomas Munro
wrote:
> On Thu, Oct 18, 2018 at 9:00 AM Tom Lane wrote:
> > I would argue that both dsm_postmaster_shutdown and dsm_postmaster_startup
> > are broken here; the former because it makes no attempt to unmap
> > the old control segment (which it oughta be
On 13/10/2018 04:01, Andres Freund wrote:
> I don't see how this could be argued. It has to be a self-conflicting
> lockmode, otherwise you'd end up doing renames of tables where you
> cannot see the previous state. And you'd get weird errors about updating
> invisible rows etc.
> I don't buy this
Andrew Dunstan writes:
> The MSVC compilers are whingeing about recent changes in snprintf.c:
> src\port\snprintf.c(1051): warning C4146: unary minus operator
> applied to unsigned type, result still unsigned
Yeah, see commit 4868e4468590bc32f9c3afed4ec795d6a7732c9d.
The law of conservat
On Thu, Oct 18, 2018 at 11:08:33AM +1300, Thomas Munro wrote:
> On Thu, Oct 18, 2018 at 9:43 AM Thomas Munro
> wrote:
> > On Thu, Oct 18, 2018 at 9:00 AM Tom Lane wrote:
> > > I would argue that both dsm_postmaster_shutdown and dsm_postmaster_startup
> > > are broken here; the former because it m
Larry Rosenman writes:
> On the original failure, I recompiled and reinstalled the 2 Python's I
> have on this box, and at least 9.3 went back to OK.
Hmm. I'd just finished pulling down FreeBSD-12.0-ALPHA9 and failing
to reproduce any problem with that ... and then I noticed your box
said it wa
On Wed, Oct 17, 2018 at 07:07:09PM -0400, Tom Lane wrote:
> Larry Rosenman writes:
> > On the original failure, I recompiled and reinstalled the 2 Python's I
> > have on this box, and at least 9.3 went back to OK.
>
> Hmm. I'd just finished pulling down FreeBSD-12.0-ALPHA9 and failing
> to repr
The LogCheckpointStart() call inside CreateCheckPoint() is done while
inside a critical section. The elog call could trigger errors due to
memory allocations or from a logging hook, resulting in a panic. It
seems better to postpone the logging until after the critical section
is done. It's only a f
From: Yang Jie [mailto:yang...@highgo.com]
> Delayed cleanup, resulting in performance degradation, what are the
> solutions recommended?
> What do you suggest for the flashback feature?
> Although postgres has excellent backup and restore capabilities, have you
> considered adding flashbacks?
Gre
Larry Rosenman writes:
> On Wed, Oct 17, 2018 at 07:07:09PM -0400, Tom Lane wrote:
>> ... Was your Python install built
>> with any special switches? I just used what came from "pkg install".
> It had been built on a previous FreeBSD build, I have my own poudriere
> infrastructure. I can probab
On Wed, Oct 17, 2018 at 08:10:28PM -0400, Tom Lane wrote:
> Larry Rosenman writes:
> > On Wed, Oct 17, 2018 at 07:07:09PM -0400, Tom Lane wrote:
> >> ... Was your Python install built
> >> with any special switches? I just used what came from "pkg install".
>
> > It had been built on a previous
Larry Rosenman writes:
> On Wed, Oct 17, 2018 at 08:10:28PM -0400, Tom Lane wrote:
>> However, I'm still slightly interested in how it
>> was that that broke DSM so thoroughly ... I pulled down your version of
>> python2.7 and will see if that reproduces it.
> It was built on a previous alpha, so
> I don't see why you'd get that error, if you re-add a column (with a
> different type), as I did above? Obviously the "replacement" column
> addition would need to be committed.
>
Here's my test case:
CREATE TABLE t3(i INTEGER);
BEGIN;
ALTER TABLE t3 ADD COLUMN blarg INT;
INSERT INTO t3(bla
On Thu, Oct 18, 2018 at 11:08 AM Thomas Munro
wrote:
> On Thu, Oct 18, 2018 at 9:43 AM Thomas Munro
> wrote:
> > On Thu, Oct 18, 2018 at 9:00 AM Tom Lane wrote:
> > > I would argue that both dsm_postmaster_shutdown and dsm_postmaster_startup
> > > are broken here; the former because it makes no
On Wed, Oct 17, 2018 at 08:55:09PM -0400, Tom Lane wrote:
> Larry Rosenman writes:
> > On Wed, Oct 17, 2018 at 08:10:28PM -0400, Tom Lane wrote:
> >> However, I'm still slightly interested in how it
> >> was that that broke DSM so thoroughly ... I pulled down your version of
> >> python2.7 and wil
On Thu, Oct 18, 2018 at 1:10 PM Tom Lane wrote:
> ... However, I'm still slightly interested in how it
> was that that broke DSM so thoroughly ...
Me too. Frustratingly, that vm object might still exist on Larry's
machine if it hasn't been rebooted (since we failed to shm_unlink()
it), so if we
On Thu, Oct 18, 2018 at 02:17:14PM +1300, Thomas Munro wrote:
> On Thu, Oct 18, 2018 at 1:10 PM Tom Lane wrote:
> > ... However, I'm still slightly interested in how it
> > was that that broke DSM so thoroughly ...
>
> Me too. Frustratingly, that vm object might still exist on Larry's
> machine
Thomas Munro writes:
> On Thu, Oct 18, 2018 at 1:10 PM Tom Lane wrote:
>> ... However, I'm still slightly interested in how it
>> was that that broke DSM so thoroughly ...
> Me too. Frustratingly, that vm object might still exist on Larry's
> machine if it hasn't been rebooted (since we failed
On Tue, Oct 9, 2018 at 1:46 PM Haribabu Kommi
wrote:
> On Wed, Oct 3, 2018 at 3:16 PM Andres Freund wrote:
>
>> On 2018-09-27 20:03:58 -0700, Andres Freund wrote:
>> > On 2018-09-28 12:21:08 +1000, Haribabu Kommi wrote:
>> > > Here I attached further cleanup patches.
>> > > 1. Re-arrange the GUC
Imai-san,
Thank you for reviewing.
On 2018/10/04 17:11, Imai, Yoshikazu wrote:
> Hi, Amit!
>
> On Thu, Sept 13, 2018 at 10:29 PM, Amit Langote wrote:
>> Attached is what I have at the moment.
>
> I also do the code review of the patch.
> I could only see a v3-0001.patch so far, so below are all
On Thu, Oct 18, 2018 at 2:36 PM Tom Lane wrote:
> Larry's REL_10_STABLE failure logs are interesting:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=peripatus&dt=2018-10-17%2020%3A42%3A17
>
> 2018-10-17 15:48:08.849 CDT [55240:7] LOG: dynamic shared memory control
> segment is corru
Sorry for the delay in replying.
On Wed, Oct 10, 2018 at 4:05 PM, David Rowley wrote:
> > It seems to me that there is no problem in this patch as far.
> > Is there another thing I have to do for the review?
>
> There's a checklist in [1]. Perhaps there's something mentioned there
> that you've m
On Thu, Oct 18, 2018 at 12:15 AM Peter Eisentraut
wrote:
>
> On 16/10/2018 06:33, Ashutosh Sharma wrote:
> > I think, the root cause of this problem is that CopyFrom() is using
> > the stale value of *has_before_insert_row_trig* to determine if the
> > current partition is okay for multi-insert or
On Tue, Oct 16, 2018 at 6:06 AM Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> Hi!
>
> On Wed, Oct 3, 2018 at 8:16 AM Andres Freund wrote:
> > I've pushed an updated version, with a fair amount of pending changes,
> > and I hope all your pending (and not redundant, by our concurrent
> >
On Thu, Oct 18, 2018 at 6:30 AM Thomas Munro
wrote:
>
> On Thu, Oct 18, 2018 at 11:08 AM Thomas Munro
> wrote:
> > On Thu, Oct 18, 2018 at 9:43 AM Thomas Munro
> > wrote:
> > > On Thu, Oct 18, 2018 at 9:00 AM Tom Lane wrote:
> > > > I would argue that both dsm_postmaster_shutdown and
> > > > d
On Thu, Oct 18, 2018 at 4:44 AM Ants Aasma wrote:
>
> The LogCheckpointStart() call inside CreateCheckPoint() is done while
> inside a critical section. The elog call could trigger errors due to
> memory allocations or from a logging hook, resulting in a panic.
>
Yeah, but we use logging hook ins
Hi,
On 2018-10-18 10:21:39 +0530, Amit Kapila wrote:
> On Thu, Oct 18, 2018 at 4:44 AM Ants Aasma wrote:
> >
> > The LogCheckpointStart() call inside CreateCheckPoint() is done while
> > inside a critical section. The elog call could trigger errors due to
> > memory allocations or from a logging
On Wed, Oct 17, 2018 at 08:19:52PM -0500, Larry Rosenman wrote:
> On Thu, Oct 18, 2018 at 02:17:14PM +1300, Thomas Munro wrote:
> > On Thu, Oct 18, 2018 at 1:10 PM Tom Lane wrote:
> > > ... However, I'm still slightly interested in how it
> > > was that that broke DSM so thoroughly ...
> >
> > Me
On Thu, Oct 18, 2018 at 10:27 AM Andres Freund wrote:
>
> Hi,
>
> On 2018-10-18 10:21:39 +0530, Amit Kapila wrote:
> > On Thu, Oct 18, 2018 at 4:44 AM Ants Aasma wrote:
> > >
> > > The LogCheckpointStart() call inside CreateCheckPoint() is done while
> > > inside a critical section. The elog call
Jakob Egger writes:
> Am 17.10.2018 um 16:28 schrieb Tom Lane :
>> It's also very odd,
>> if the compiler will search the sysroot automatically, why that seemingly
>> works for tcl.h but not perl.h. plperl definitely still fails if you
>> lobotomize the PG_SYSROOT logic.
> Because pl/tcl ends up
79 matches
Mail list logo
