> 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?
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
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
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
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
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
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
> >
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
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:
В письме от 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
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
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
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
>
>
> 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
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
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
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
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 ...
> >
> >
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
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
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
> > > >
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 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=2018-10-17%2020%3A42%3A17
>
> 2018-10-17 15:48:08.849 CDT [55240:7] LOG: dynamic shared memory control
> segment is corrupt
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
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
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 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
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
> 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
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:
>
>
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
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
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 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
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?
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
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
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
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
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
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
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
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
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,
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
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:
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
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
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
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
>>
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
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 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
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
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 *,
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
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
> Interesting. That's with an optimized build, or an assertion build?
Hello,
That was an optimized build.
However I've just done some extra time tests and didn't notice so significant
difference as early.
Even more - avg origin 1272, avg patched 1303.
Maybe there was the autovacuum / analyze /
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
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
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
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
Hi,
On 2018-10-17 09:48:19 +0300, Andrey Klychkov wrote:
> > Interesting. That's with an optimized build, or an assertion build?
>
> Hello,
> That was an optimized build.
>
> However I've just done some extra time tests and didn't notice so significant
> difference as early.
> Even more - avg
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
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
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
> 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
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 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
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
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
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
76 matches
Mail list logo
