On Wed, Nov 8, 2017 at 11:03 AM, Peter Eisentraut
wrote:
> On 11/8/17 11:11, Merlin Moncure wrote:
>> On Wed, Nov 8, 2017 at 9:13 AM, Peter Eisentraut
>> wrote:
>>> I have already submitted a separate patch that addresses these questions.
>>
>> Maybe I'
patch I'll read it there. Thanks for doing this.
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
low control but I'm not too
concerned about that.
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
manage the GUC.
Tom upthread (for pretty good reasons) extending SET to pl/pgsql
specific scoping but TBH I'm struggling as to why we need to implement
new syntax for this; the only thing missing is being able to scope SET
statements to a code block FWICT.
merlin
--
Sent vi
prefer syntax without FOR keyword - because following keyword
> must be reserved keyword
>
> SET x = .., y = .. SELECT ... ;
This seems pretty ugly from a syntax perspective.
We already have 'SET LOCAL', which manages scope to the current
transaction. How about SET BLOCK which would set until you've left
the current statement block?
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t seems like an awful lot of work (new version agnostic
serialization format) for very little benefit (version independent
type serialization for remote aggregate pushdown). How about forcing
the version to be the same for the feature to be used?
merlin
--
Sent via pgsql-hackers mailing list (p
ng
> that into these functions, when a separate function or module could do.
Well, doesn't that also apply to scientific notation ()?
'RN' is documented as an accepted formatting string, and nowhere does
it mention that it only works for input. So we ought to allow for it
On Thu, Aug 10, 2017 at 12:01 PM, Ants Aasma wrote:
> On Wed, Jan 18, 2017 at 4:33 PM, Merlin Moncure wrote:
>> On Wed, Jan 18, 2017 at 4:11 AM, Ants Aasma wrote:
>>> On Wed, Jan 4, 2017 at 5:36 PM, Merlin Moncure wrote:
>>>> Still getting checksum failures. Ov
s; there is
no concept of a master server. Conflict resolution must be handled
completely by the application. For more information on...
what do you think?
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
disadvantage with jsonb WRT to
hstore is that you can't do simple retransformations that these
operations allow for. Too often you end up doing multiple '->'
operations against the same object followed by a rebundling which is a
real performance killer.
I understand that t
On Thu, Jun 29, 2017 at 9:12 AM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Thu, Jun 29, 2017 at 8:23 AM, Michal Novotny
>> wrote:
>>> Could you please help me based on information provided above?
>
>> You might want to run your code through some analysi
On Thu, Jun 29, 2017 at 8:23 AM, Michal Novotny
wrote:
> Hi,
>
> comments inline ...
>
>
>
> On 06/29/2017 03:08 PM, Merlin Moncure wrote:
>>
>> On Thu, Jun 29, 2017 at 4:01 AM, Michal Novotny
>> wrote:
>>>
>>> Hi all,
>>>
>&
e-exec.c:1871
> No locals.
>
> Unfortunately we didn't have more information from the crash, at least for
> now.
>
> Is this a known issue and can you help me with this one?
Is your application written in C? We would need to completely rule
out your code (say, by doub
On Tue, Jun 27, 2017 at 10:12 AM, Colin 't Hart wrote:
> On 27 Jun 2017, at 17:06, Merlin Moncure wrote:
>>
>>> On Tue, Jun 27, 2017 at 10:01 AM, Colin 't Hart
>>> wrote:
>>> Hi,
>>>
>>> The following rather contrived example
nt.
>
> Would there be any way to implement an automatic conversion?
>
> On the off-chance that this is actually a bug, this is on 9.6.3, but
> it also occurs on 9.3.17
Why not cast the arguments? The first and the third argument have to
be the same, and the second argument is always in
On Tue, Jun 20, 2017 at 2:58 PM, Merlin Moncure wrote:
> On Tue, Jun 20, 2017 at 2:34 PM, David G. Johnston
> wrote:
>> On Tue, Jun 20, 2017 at 12:22 PM, Chapman Flack
>> wrote:
>>> I get the reported result (DELETE 0 and a table containing 2 and 3)
>>>
y speaking those are a single transaction isolation mode.
>
> https://www.postgresql.org/docs/10/static/transaction-iso.html
>
> I think Merlin has mis-read the article he linked to. The example
> being used there never claims to be done under serialization and seems
> to
spec?
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ompatibility issue
since performance is generally not really fairly described as
compatibility criteria. If this feature drops we ought to warn people
in the release notes though.
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ction
perspective does not exist (for me) until 10.0. Point being, an
important threshold has been crossed.
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
elcome for a large number of
queries, but forced materialization is a real need and I use it often.
This comes off as a very reasonable compromise in my opinion unless it
requires major coding gymnastics to implement.
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> I fail to see how this introduces anything new.
>
> In fact, if you see the optimization fence as an implicit query hint, this
> actually *removes* a hint (although most users are unaware of that behavior
> and use it unintentionally).
+1 down the line. More to the point, for severa
n
implementation detail is also subject to change.
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
n you paste
the relevant log snippet?
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
www.postgresql.org/docs/devel/static/sql-altertable.html states:
"The trigger firing mechanism is also affected by the configuration
variable session_replication_role. Simply enabled triggers will fire
when the replication role is “origin” (the default) or “local”."
merlin
--
Sent via pg
seem already able to
> take such values as inputs. Also there should be regression tests for
> this (none of intarray's existing tests have any empty arrays at all).
Are there any impacts outside of intarray?
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Apr 7, 2017 at 12:54 PM, Tom Lane wrote:
> Tomas Vondra writes:
>> On 04/07/2017 06:31 PM, Merlin Moncure wrote:
>>> I think your math is off. Looking at your attachments, planning time
>>> is 0.056ms, not 0.56ms. This is in no way relevant to performan
ms, not 0.56ms. This is in no way relevant to performance on
the order of your measured TPS. How are you measuring TPS?
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e is faster but foists a lot of the work on the user, so it's
kind of cheating in a way (although very carefully written
applications might be able to benefit).
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ax for
that approach. I use the 'double EXCEPT' tactic fairly often and
understand the need, but the bar for non-standard syntax is pretty
high (and has been getting higher over the years, I think).
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
pen, the checksum code might
> "detect" it in some sense, but it would be remarkably unhelpful at
> identifying the actual cause.
Hm, but at least in some cases wouldn't it protect people from further
damage? End user data damage ought to prevented at all costs IMO.
merlin
-
but they sure saved my ass with that pl/sh
issue. So I'm inclined to lightly disagree; there are good arguments
either way.
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jan 18, 2017 at 4:11 AM, Ants Aasma wrote:
> On Wed, Jan 4, 2017 at 5:36 PM, Merlin Moncure wrote:
>> Still getting checksum failures. Over the last 30 days, I see the
>> following. Since enabling checksums FWICT none of the damage is
>> permanent and rolls back
a BY(...) clause or not. If it
> doesn't have a BY(...) clause the usage is as follows.
This is great stuff. Does the syntax only apply to UNION? I would
imagine it would also apply to INTERSECT/EXCEPT? What about UNION
ALL?
merlin
--
Sent via pgsql-hackers mailing list (pgsql
of time for
> PostgreSQL work.
>
> For that reason, as of today, I am stepping down from the PostgreSQL
> Core Team.
Thanks for all your hard work. FWIW, your blog posts, 'Primary
Keyvil' are some of my favorite of all time!
merlin
--
Sent via pgsql-hackers mailing list (p
e computing world so on balance
we did the right thing. Having said that, It's always good to do the
math and the calculation is primarily an economic one, I think,
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
arious ideas and pain points presented in a wiki along with
conclusions, and in some cases if there is no solution that is
compatible with the current syntax.
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.
uld like to
add some color. SQL is verbose in the sense of "let's make everything
an english language sentence" but incredibly terse relative to other
language implementations of the same task. Embedded SQL tends to be
uniformly clumsy due to all of the extra handling of errrors,
p
ermined
it's not suitable to move forward with. It's got a different set of
headaches, but is really fast, and sometimes wonder if with some
alternative preprocessing (like coffeescript but geared towards SQL)
could have some long term promise.
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
tandard here.
Changes did have to be made, like getting rid of the notoriously
broken and insecure gets(), but they were made very, very slowly and
unobtrusively.
(I do think lpad should except "any" FWIW) :-D
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
PL/SQL style - probably easy implementation
>>
>> Regards
>>
>> Pavel
>
>
> some examples based on Ada doc
>
> FUNCTION xxx RETURN int AS
> PRAGMA yyy -- pragma has function scope
> BEGIN
>
> FUNCTION xxx RETURN int AS
> BEGIN
> DECLAR
On Tue, Jan 3, 2017 at 2:15 PM, Pavel Stehule wrote:
>
>
> 2017-01-03 20:54 GMT+01:00 Merlin Moncure :
>>
>> On Tue, Jan 3, 2017 at 9:58 AM, Pavel Stehule
>> wrote:
>> > 2017-01-03 16:23 GMT+01:00 Merlin Moncure :
>> >> *) Would also like to have
On Tue, Jan 3, 2017 at 1:05 PM, Peter Eisentraut
wrote:
> On 11/7/16 5:31 PM, Merlin Moncure wrote:
>> Regardless, it seems like you might be on to something, and I'm
>> inclined to patch your change, test it, and roll it out to production.
>> If it helps or at least na
On Tue, Jan 3, 2017 at 9:58 AM, Pavel Stehule wrote:
> 2017-01-03 16:23 GMT+01:00 Merlin Moncure :
>> So -1 to strict mode, unless we can make a case why this can't be done
>> as part of checking/validation.
>
> Can be plpgsq.extra_errors and plpgsql.extra_warnings solu
On Tue, Dec 27, 2016 at 10:09 PM, Jim Nasby wrote:
> On 12/27/16 4:56 PM, Merlin Moncure wrote:
>>
>> On Tue, Dec 27, 2016 at 1:54 AM, Pavel Stehule
>> wrote:
>>>
>>> First I describe my initial position. I am strongly against introduction
>>>
quot;IN BACKGOUND" moved execution to a background worker one
could do just about everything in SQL in tasks that do nothing but
read and write to the database that today need significant support
from outside language (primarily bash for me).
With respect to stuff you mentioned, like smarter ha
roblem is a highly reduced character set and a
pre-processor or an extension.
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
acter to be
directly. In the computer science world we generally call this
escaping strings and it a very common and well understood practice.
For some odd reason however the authors of java various frameworks
seem to be impervious to the utility of the concept.
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
down, we ought to give it
consideration for inclusion (unless someone else can think of a good
reason not to do that, heh!).
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Nov 1, 2016 at 8:56 AM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Mon, Oct 31, 2016 at 10:32 AM, Oskari Saarenmaa wrote:
>>> Your production system's postgres backends probably have a lot more open
>>> files associated with them than the simple
On Mon, Oct 31, 2016 at 10:32 AM, Oskari Saarenmaa wrote:
> 27.10.2016, 21:53, Merlin Moncure kirjoitti:
>>
>> As noted earlier, I was not able to reproduce the issue with
>> crashme.sh, which was:
>>
>> NUM_FORKS=16
>> do_parallel psql -p
On Fri, Oct 28, 2016 at 3:16 PM, Jim Nasby wrote:
> On 10/28/16 8:23 AM, Merlin Moncure wrote:
>>
>> On Thu, Oct 27, 2016 at 6:39 PM, Greg Stark wrote:
>>>
>>> On Thu, Oct 27, 2016 at 9:53 PM, Merlin Moncure
>>> wrote:
>>>>
>>>&
On Thu, Oct 27, 2016 at 6:39 PM, Greg Stark wrote:
> On Thu, Oct 27, 2016 at 9:53 PM, Merlin Moncure wrote:
>> I think we can rule out faulty storage
>
> Nobody ever expects the faulty storage
Believe me, I know. But the evidence points elsewhere in this case;
this is clea
On Thu, Oct 27, 2016 at 2:31 AM, Ants Aasma wrote:
> On Wed, Oct 26, 2016 at 8:43 PM, Merlin Moncure wrote:
>> /var/lib/pgsql/9.5/data/pg_log/postgresql-26.log | grep "page
>> verification"
>> 2016-10-26 11:26:42 CDT [postgres@castaging]: WARNING: page
>
On Wed, Oct 26, 2016 at 3:06 PM, Jim Nasby wrote:
> On 10/26/16 2:25 PM, Merlin Moncure wrote:
>>
>> I don't think that's the case. sqsh is a psql-like utility. it
>> writes to stdout and stderr only which is captured by plsh and sent.
>> In this context
On Wed, Oct 26, 2016 at 2:12 PM, Andres Freund wrote:
> On 2016-10-26 13:49:12 -0500, Merlin Moncure wrote:
>> On Wed, Oct 26, 2016 at 1:45 PM, Andres Freund wrote:
>> >
>> >
>> > On October 26, 2016 9:38:49 PM GMT+03:00, Merlin Moncure
>> > wrote:
On Wed, Oct 26, 2016 at 1:45 PM, Andres Freund wrote:
>
>
> On October 26, 2016 9:38:49 PM GMT+03:00, Merlin Moncure
> wrote:
>>On Wed, Oct 26, 2016 at 1:34 PM, Andres Freund
>>wrote:
>>> Any chance that plsh or the script it executes does anything with t
om/petere/plsh/blob/master/plsh.c
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Oct 26, 2016 at 1:09 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> *) I've now strongly correlated this routine with the damage.
>
> Hmm. Do you have any way to replace the non-core calls with something
> else? The "shexec('rm -f ' ||
On Wed, Oct 26, 2016 at 12:43 PM, Merlin Moncure wrote:
> On Wed, Oct 26, 2016 at 11:35 AM, Merlin Moncure wrote:
>> On Tue, Oct 25, 2016 at 3:08 PM, Merlin Moncure wrote:
>>> Confirmation of problem re-occurrence will come in a few days.I'm
>>> muc
On Wed, Oct 26, 2016 at 11:35 AM, Merlin Moncure wrote:
> On Tue, Oct 25, 2016 at 3:08 PM, Merlin Moncure wrote:
>> Confirmation of problem re-occurrence will come in a few days.I'm
>> much more likely to believe 6+sigma occurrence (storage, freak bug,
>> etc) s
On Tue, Oct 25, 2016 at 3:08 PM, Merlin Moncure wrote:
> Confirmation of problem re-occurrence will come in a few days.I'm
> much more likely to believe 6+sigma occurrence (storage, freak bug,
> etc) should it prove the problem goes away post rebuild.
ok, no major reported o
On Tue, Oct 25, 2016 at 2:31 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> What if the subsequent dataloss was in fact a symptom of the first
>> outage? Is in theory possible for data to appear visible but then be
>> eaten up as the transactions making the data visi
On Tue, Oct 25, 2016 at 12:57 PM, Alvaro Herrera
wrote:
> Merlin Moncure wrote:
>
>> After last night, I rebuilt the cluster, turning on checksums, turning
>> on synchronous commit (it was off) and added a standby replica. This
>> should help narrow the problem dow
On Mon, Oct 24, 2016 at 9:18 PM, Alvaro Herrera
wrote:
> Merlin Moncure wrote:
>> On Mon, Oct 24, 2016 at 6:01 PM, Merlin Moncure wrote:
>
>> > Corruption struck again.
>> > This time got another case of view busted -- attempting to create
>> > gives miss
On Mon, Oct 24, 2016 at 6:01 PM, Merlin Moncure wrote:
> On Thu, Oct 20, 2016 at 1:52 PM, Merlin Moncure wrote:
>> On Wed, Oct 19, 2016 at 2:39 PM, Merlin Moncure wrote:
>>> On Wed, Oct 19, 2016 at 9:56 AM, Bruce Momjian wrote:
>>>> On Wed, Oct 19, 2016 at 08
On Thu, Oct 20, 2016 at 1:52 PM, Merlin Moncure wrote:
> On Wed, Oct 19, 2016 at 2:39 PM, Merlin Moncure wrote:
>> On Wed, Oct 19, 2016 at 9:56 AM, Bruce Momjian wrote:
>>> On Wed, Oct 19, 2016 at 08:54:48AM -0500, Merlin Moncure wrote:
>>>> > Yeah. Believe me
On Fri, Oct 21, 2016 at 1:37 PM, Merlin Moncure wrote:
> On Fri, Oct 21, 2016 at 8:03 AM, Kevin Grittner wrote:
>> On Tue, Oct 18, 2016 at 8:45 AM, Merlin Moncure wrote:
>>
>>> Most or all the damage seemed to be to the system catalogs with
>>> at lea
On Fri, Oct 21, 2016 at 8:03 AM, Kevin Grittner wrote:
> On Tue, Oct 18, 2016 at 8:45 AM, Merlin Moncure wrote:
>
>> Most or all the damage seemed to be to the system catalogs with
>> at least two critical tables dropped or inaccessible in some
>> fashion. A lot
On Thu, Oct 20, 2016 at 3:16 PM, Alvaro Herrera
wrote:
> Merlin Moncure wrote:
>
>> single user mode dumps core :(
>>
>> bash-4.1$ postgres --single -D /var/lib/pgsql/9.5/data castaging
>> LOG: 0: could not change directory to "/root": Permission denie
On Thu, Oct 20, 2016 at 2:07 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> single user mode dumps core :(
>
> You've got a mess there :-(
>
>> Missing separate debuginfos, use: debuginfo-install
>> postgresql95-server-9.5.2-1PGDG.rhel6.x86_64
>
>
On Thu, Oct 20, 2016 at 1:52 PM, Merlin Moncure wrote:
> On Wed, Oct 19, 2016 at 2:39 PM, Merlin Moncure wrote:
>> On Wed, Oct 19, 2016 at 9:56 AM, Bruce Momjian wrote:
>>> On Wed, Oct 19, 2016 at 08:54:48AM -0500, Merlin Moncure wrote:
>>>> > Yeah. Believe me
On Wed, Oct 19, 2016 at 2:39 PM, Merlin Moncure wrote:
> On Wed, Oct 19, 2016 at 9:56 AM, Bruce Momjian wrote:
>> On Wed, Oct 19, 2016 at 08:54:48AM -0500, Merlin Moncure wrote:
>>> > Yeah. Believe me -- I know the drill. Most or all the damage seemed
>>> > to
On Wed, Oct 19, 2016 at 9:56 AM, Bruce Momjian wrote:
> On Wed, Oct 19, 2016 at 08:54:48AM -0500, Merlin Moncure wrote:
>> > Yeah. Believe me -- I know the drill. Most or all the damage seemed
>> > to be to the system catalogs with at least two critical tables dropped
&g
On Tue, Oct 18, 2016 at 8:45 AM, Merlin Moncure wrote:
> On Mon, Oct 17, 2016 at 2:04 PM, Alvaro Herrera
> wrote:
>> Merlin Moncure wrote:
>>
>>> castaging=# CREATE OR REPLACE VIEW vw_ApartmentSample AS
>>> castaging-# SELECT ...
>>> ERROR: 42809
On Mon, Oct 17, 2016 at 2:04 PM, Alvaro Herrera
wrote:
> Merlin Moncure wrote:
>
>> castaging=# CREATE OR REPLACE VIEW vw_ApartmentSample AS
>> castaging-# SELECT ...
>> ERROR: 42809: "pg_cast_oid_index" is an index
>> LINE 11: FROM ApartmentS
On Mon, Oct 17, 2016 at 2:04 PM, Alvaro Herrera
wrote:
> Merlin Moncure wrote:
>
>> castaging=# CREATE OR REPLACE VIEW vw_ApartmentSample AS
>> castaging-# SELECT ...
>> ERROR: 42809: "pg_cast_oid_index" is an index
>> LINE 11: FROM ApartmentS
On Mon, Oct 17, 2016 at 1:39 PM, Merlin Moncure wrote:
> On Thu, Oct 13, 2016 at 4:13 PM, Tom Lane wrote:
>> Merlin Moncure writes:
>>> Today I had an emergency production outage on a server.
>>> ...
>>> Adding all this up it smells like processes w
On Thu, Oct 13, 2016 at 4:13 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> Today I had an emergency production outage on a server.
>> ...
>> Adding all this up it smells like processes were getting stuck on a spinlock.
>
> Maybe. If it happens again, probably the m
ry functions. If there were a way to handle wrapping I'd
withdraw this minor objection -- this has come up in dblink
discussions a few times).
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ed VARBITMAXLEN. anybit_typmodin() enforces
> that, but there are places where a user can shove in an arbitrary integer,
> eg
>
> regression=# select "bit"(42, 2147483647);
> ERROR: invalid memory alloc request size 18446744073441116169
>
> I fixed those too and pushed
upgraded to 9.5 somewhat recently but ran
on 9.2 for years with no issues.
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Oct 12, 2016 at 5:18 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> ISTM all this silliness is pretty much unique to linux anyways.
>> Instead of reading the filesystem, what about doing test map and test
>> unmap?
>
> And if mmap succeeds and munmap fails,
/sys/kernel/mm/hugepages.
via: http://man7.org/linux/man-pages/man2/mmap.2.html#NOTES
ISTM all this silliness is pretty much unique to linux anyways.
Instead of reading the filesystem, what about doing test map and test
unmap? We could zero in on the page size for
On Tue, Oct 11, 2016 at 10:06 AM, Petr Jelinek wrote:
> On 10/10/16 16:44, Merlin Moncure wrote:
>> On Thu, Oct 6, 2016 at 3:53 PM, Simon Riggs wrote:
>>> On 6 October 2016 at 21:27, Robert Haas wrote:
>>>> I think we should implement background transactions
. What about other session based stuff
like prepared statements? Expectations around those cases out to
clarify the implementation.
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
gh not
nearly so famous as uber :-).
In the few modern cases I've seen I've not been able to trace it back
to any bug in postgres (in particular multixact was ruled out) and
I've chalked it up to media or (more likely I think) filesystem
problems in the face of a -9 reset.
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
) hs/sr simplicity of configuration and operation is a big issue.
it's continually gotten better and still needs to
*) bad QC can cost you customers. how much regression coverage do we
have of hs/sr?
*) postgres may not be the ideal choice for those who want a thin and
simple database
merlin
--
really long transactions (pg_dump?) could
> be pretty disastrous, but there are ways around that, like doing pg_dump
> on a slave.
>
> Or in short, this seems like an annoyance, not a time-for-a-new-database
> kind of problem.
Well, the real annoyance as I understand it is the raw
record variable is a
distinct thing from its contents and the spec does not treat it that
was. For my part, I think the spec is totally out to lunch on this
point but we've been stuck with the status quo for quite some time now
-- there's been no compelling narrative that suggests how things
sh
On Mon, Jul 18, 2016 at 8:59 AM, Jan Wieck wrote:
>
>
> On Mon, Jul 18, 2016 at 9:43 AM, Tom Lane wrote:
>>
>> Merlin Moncure writes:
>> > BTW, while the fix does address the cleanup performance issue, it's
>> > still the case that anonymous code blo
On Sat, Jul 16, 2016 at 2:47 PM, Jan Wieck wrote:
> On Tue, Jul 12, 2016 at 3:29 PM, Merlin Moncure wrote:
>>
>> I've noticed that pl/pgsql functions/do commands do not behave well
>> when the statement resolves and frees memory. To be clear:
>>
>> FOR i
ions) it's much more likely to want to do something like
insert a lot of statements and a impossible to utilize any cached
plans.
This is not an academic gripe -- I just exploded production :-D.
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Jul 11, 2016 at 3:09 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> Currently pl/pgsql interprets the mandatory INTO of IMPORT FOREIGN
>> SCHEMA as INTO variable.
>
> Ugh, that's definitely a bug.
>
>> I estimate this to be minor oversight in
>
Currently pl/pgsql interprets the mandatory INTO of IMPORT FOREIGN
SCHEMA as INTO variable. I estimate this to be minor oversight in
pl/pgsql parsing with respect to the introduction of this statement.
Assuming it's easily fixed, would a patch to fix pl/pgsql parsing be
accepted?
m
e.
In summary, I think the future of MVCC and transactional systems is
very bright, and the data management systems that discard
transactional safety in order to get some short term performance gains
is, uh, not so bright. Transactions are essential in systems where
data integrity matters.
merlin
On Fri, Jul 1, 2016 at 11:45 AM, Alvaro Herrera
wrote:
> Merlin Moncure wrote:
>
>> It's pretty easy to craft a query where you're on the winning side,
>> but what's the worst case of doing two pass...is constant folding a
>> non trivial fraction of pla
On Fri, Jul 1, 2016 at 10:27 AM, Robert Haas wrote:
> On Fri, Jul 1, 2016 at 10:20 AM, Merlin Moncure wrote:
>> Yeah. Also, even if you could parse out those cases, it's major
>> optimization fence. Consider if you have an ORDER BY clause here:
>>
>> SELECT
* FROM foo
WHERE
('a' = 'a' AND EXISTS ...)
OR ('a' = 'b' AND EXISTS ...)
OR ('a' = 'c' AND EXISTS ...)
...where the left side of the equality is a parameterized 'filter
mode' flag. That way the query can introduce filtering behaviors
without doing dynamic acrobatics.
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
er logic be
expanded such the first query can be functionally be written into the
second one? This type of query happens a lot when trying to mix
multiple different filtering expressions (a 'filter mode' if you will)
in a single query based on a user supplied switch. Food for thought.
1 - 100 of 1955 matches
Mail list logo
