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'
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'm obtuse, but I'm not seeing it? In very interested in the
general approach to transaction management; if you've described it in
the patch I'll read it there
On Tue, Oct 31, 2017 at 12:23 PM, Peter Eisentraut
wrote:
> - Transaction control in procedure bodies
This feature is really key, since it enables via SQL lots of things
that are not possible without external coding, including:
*) very long running processes in a single routine
*) transaction iso
On Tue, Sep 19, 2017 at 1:37 PM, Robert Haas wrote:
> On Tue, Sep 19, 2017 at 12:45 PM, Pavel Stehule
> wrote:
>>> You can already set a GUC with function scope. I'm not getting your
>>> point.
>>
>> yes, it is true. But implementation of #option is limited to PLpgSQL - so
>> there is not any t
On Fri, Sep 8, 2017 at 2:48 PM, Pavel Stehule wrote:
>
>
> 2017-09-08 21:21 GMT+02:00 Daniel Gustafsson :
>>
>> > On 08 Sep 2017, at 19:14, Simon Riggs wrote:
>> >
>> > On 6 September 2017 at 07:43, Robert Haas wrote:
>> >
>> >> LET custom_plan_tries = 0 IN SELECT ...
>> >
>> > Tom has pointed m
On Thu, Aug 17, 2017 at 10:22 AM, Antonin Houska wrote:
> Antonin Houska wrote:
> output type. For other aggregates (like avg()) the remote nodes will have to
> return the transient state value in an appropriate form (maybe bytea type),
> which does not depend on PG version.
Hm, that seems like
On Mon, Aug 14, 2017 at 2:48 PM, Peter Eisentraut
wrote:
> On 8/3/17 13:45, Robert Haas wrote:
>> On Thu, Aug 3, 2017 at 9:25 AM, Oliver Ford wrote:
>>> Adds to the to_number() function the ability to convert Roman numerals
>>> to a number. This feature is on the formatting.c TODO list. It is not
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
On Sun, Jul 30, 2017 at 8:34 PM, Steve Singer wrote:
>
> We don't seem to describe logical replication on
>
> https://www.postgresql.org/docs/10/static/different-replication-solutions.html
>
> The attached patch adds a section.
This is a good catch. Two quick observations:
1) Super pedantic poi
On Tue, Jul 18, 2017 at 12:49 PM, David Fetter wrote:
> On Tue, Jul 18, 2017 at 01:36:32PM +0200, david.tu...@linuxbox.cz wrote:
>> Hi,
>>
>> some users and me used hstore - hstore for example storing only changed
>> rows in trigger like:
>>
>> hsore(NEW) - hstore(OLD)
>>
>> There isn't same opera
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,
>>>
>&
On Thu, Jun 29, 2017 at 4:01 AM, Michal Novotny
wrote:
> Hi all,
>
> we've developed an application using libpq to access a table in the PgSQL
> database but we're sometimes experiencing segmentation fault on
> resetPQExpBuffer() function of libpq called from PQexecParams() with
> prepared query.
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
On Tue, Jun 27, 2017 at 10:01 AM, Colin 't Hart wrote:
> Hi,
>
> The following rather contrived example illustrates that lag(), lead()
> (and probably other functions) can't automatically cast an integer to
> a bigint:
>
> select lag(sum,1,0) over () from (select sum(generate_series) over
> (order
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)
>>>
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)
>> in both 'read committed' and 'read uncommitted'.
>
> Practically speaking those are a single transaction iso
Michael Malis via:
http://malisper.me/postgres-transactions-arent-fully-isolated/ has
determined that postgresql transactions are not fully isolated even
when using serializable isolationl level.
If I prep a table, ints via:
postgres=# create table ints (n int);
CREATE TABLE
postgres=# insert int
On Fri, May 12, 2017 at 3:39 PM, Bruce Momjian wrote:
> On Tue, May 9, 2017 at 05:14:19PM -0400, Tom Lane wrote:
>> Ilya Shkuratov writes:
>> > Ok, it seems that most people in discussion are agree that removing
>> > optimization
>> > fence is a right thing to do.
>> > Nonetheless I still hopin
On Mon, May 1, 2017 at 7:02 AM, Robert Haas wrote:
> On Tue, Apr 25, 2017 at 11:01 AM, Bruce Momjian wrote:
>> I didn't think logical decoding was really more than a proof-of-concept
>> until now.
>
> /me searches for jaw on floor.
>
> I would not in any way refer to logical decoding as being onl
On Wed, May 3, 2017 at 12:33 PM, Alvaro Herrera
wrote:
> David Fetter wrote:
>
>> When we add a "temporary" GUC, we're taking on a gigantic burden.
>> Either we support it forever somehow, or we put it on a deprecation
>> schedule immediately and expect to be answering questions about it for
>> ye
\On Tue, May 2, 2017 at 12:05 PM, Tomas Vondra
wrote:
> On 5/2/17 6:34 PM, David Fetter wrote:
>>
>> On Tue, May 02, 2017 at 02:40:55PM +0200, Andreas Karlsson wrote:
>>>
>>> On 05/02/2017 04:38 AM, Craig Ringer wrote:
On 1 May 2017 at 22:26, Andreas Karlsson wrote:
>
>>>
>>>
>>> ...
>>
On Sun, Apr 30, 2017 at 6:21 PM, Andres Freund wrote:
> On 2017-04-30 07:19:21 +0200, Pavel Stehule wrote:
>> why we cannot to introduce GUC option - enable_cteoptfence ?
>
> Doesn't really solve the issue, and we've generally shied away from GUCs
> that influence behaviour after a few bad experie
On Tue, Apr 25, 2017 at 8:44 AM, K S, Sandhya (Nokia - IN/Bangalore)
wrote:
> Hello,
>
> Did you get a chance to take a look into the issue?
>
> Please consider it with high priority. We will be awaiting your inputs.
This email is heavily cross posted, which is obnoxious. Can you paste
the relev
On Fri, Apr 21, 2017 at 5:08 AM, Egor Rogov wrote:
> Hello,
> It seams that tiggers don't fire on subscriber's tables during logical
> replication. Is it a bug?
Reading the documentation (which is TBH a bit hard to follow) it
appears that it is expected behavior.
https://www.postgresql.org/docs/
On Mon, Apr 10, 2017 at 11:17 PM, Andrew Gierth
wrote:
>> "Tom" == Tom Lane writes:
>
> >> First is contrib/intarray, _AGAIN_ (see past bugs such as #7730):
> >> ...
> >> I plan to fix this one properly, unless anyone has any objections.
>
> Tom> Just to clarify, what do you think is "pro
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
On Fri, Apr 7, 2017 at 5:16 AM, Prakash Itnal wrote:
> Hello,
>
> We currently use psotgres 9.3 in our products. Recently we upgraded to
> postgres 9.6. But with 9.6 we have seen a drastic reduction in throughput.
> After analyzing carefully I found that "planner time" in 9.6 is very high.
> Below
On Mon, Feb 13, 2017 at 8:46 AM, Kyle Gearhart
wrote:
> On 2/9/17 7:15 PM, Jim Nasby wrote:
>> Can you run a trace to see where all the time is going in the single row
>> case? I don't see an obvious time-suck with a quick look through the code.
>> It'd be interesting to see how things change if
1On Tue, Feb 7, 2017 at 9:46 PM, Joel Jacobson wrote:
> On Tue, Feb 7, 2017 at 4:58 PM, Tom Lane wrote:
>> Joel Jacobson writes:
>>> Currently there is no simple way to check if two sets are equal.
>>
>> Uh ... maybe check whether SELECT set1 EXCEPT SELECT set2
>> and SELECT set2 EXCEPT SELECT s
On Mon, Jan 23, 2017 at 8:07 PM, Tom Lane wrote:
> Peter Geoghegan writes:
>> I thought that checksums went in in part because we thought that there
>> was some chance that they'd find bugs in Postgres.
>
> Not really. AFAICS the only point is to catch storage-system malfeasance.
>
> It's barely
On Sat, Jan 21, 2017 at 12:35 PM, Tom Lane wrote:
> Andres Freund writes:
>> Sure, it might be easy, but we don't have it. Personally I think
>> checksums just aren't even ready for prime time. If we had:
>> - ability to switch on/off at runtime (early patches for that have IIRC
>> been posted
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
On Tue, Jan 17, 2017 at 12:37 AM, Surafel Temsgen wrote:
> I am new here and I really want to contribute, I have read same resource
> that help understanding database system and postgresql. I would like to
> start implementing sql syntax corresponding by clause because I believe
> implementing sql
On Wed, Jan 11, 2017 at 6:29 PM, Josh Berkus wrote:
> Hackers:
>
> You will have noticed that I haven't been very active for the past year.
> My new work on Linux containers and Kubernetes has been even more
> absorbing than I anticipated, and I just haven't had a lot of time for
> PostgreSQL wor
On Wed, Jan 11, 2017 at 2:57 PM, Robert Haas wrote:
> - The E'' syntax and the standard_conforming_strings GUC were added in
> PostgreSQL 8.0. The only legal value of standard_conforming_strings
> was "false".
>
> - In PostgreSQL 8.1, it became possible to set
> standard_conforming_strings to "tr
On Wed, Jan 11, 2017 at 11:11 AM, Peter Eisentraut
wrote:
> The current syntax was chosen because it is SQL-compatible. Adding
> redundant syntax to save a few characters without any new functionality
> (performance, resource usage, safety, etc.) is a weak argument in the
> overall scheme of thin
On Tue, Jan 10, 2017 at 7:44 AM, Marko Tiikkaja wrote:
> On Tue, Jan 10, 2017 at 2:26 PM, Peter Eisentraut
> wrote:
>>
>> It's not like PL/pgSQL is the king of brevity.
>
>
> This is essentially saying "PL/PgSQL isn't perfect, so we shouldn't try and
> make it better". I hear this argument a lot
On Sun, Jan 8, 2017 at 2:52 AM, Joel Jacobson wrote:
> On Sat, Jan 7, 2017 at 8:56 PM, Pavel Stehule wrote:
>>
>> Jim, Marko, Joel - is there a place, features where we can find a partial
>> agreement? If it is, then we can move our view there.
>
> I have decided I definitively want a new langua
On Thu, Jan 5, 2017 at 11:03 AM, Robert Haas wrote:
> Now, that's not to say we should never break backward compatibility.
> Sometimes we should. I think the problem with PL/pgsql is that many
> of the compatibility breaks that people want are likely to lead to
> subtle misbehavior rather than ou
On Wed, Jan 4, 2017 at 1:49 PM, Pavel Stehule wrote:
>
>>
>> so some possible design can be:
>>
>> DECLARE
>> PRAGMA UNCACHED_PLANS;
>> BEGIN
>> SELECT ... INTO ;
>> SELECT ... INTO ;
>> END;
>>
>> This respects Ada and PL/SQL style - probably easy implementation
>>
>> Regards
>>
>> Pavel
>
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
>>>
On Tue, Dec 27, 2016 at 1:54 AM, Pavel Stehule wrote:
> Hi
>
> I reread ideas described on page https://github.com/trustly/plpgsql2
>
> Some points are well and can be benefit for PlpgSQL.
>
> First I describe my initial position. I am strongly against introduction
> "new" language - plpgsql2 or n
On Sun, Dec 11, 2016 at 10:59 PM, Craig Ringer wrote:
> PgJDBC allows you to write ??, which is ugly, but tolerable, since the
> JDBC spec doesn't have an escape syntax for it.
This is the core problem; *JDBC* is busted. SQL reserves words but
not punctuation marks so any assumption by client si
On Fri, Dec 9, 2016 at 5:50 AM, Jordan Gigov wrote:
> There is this problem with the jsonb operators "? text" "?| text[]"
> and "?& text[]" that the question mark is typically used for prepared
> statement parameters in the most used abstraction APIs in Java and
> PHP.
>
> This really needs an alt
On Wed, Nov 2, 2016 at 10:45 AM, Oskari Saarenmaa wrote:
> 26.10.2016, 21:34, Andres Freund kirjoitti:
>>
>> Any chance that plsh or the script it executes does anything with the file
>> descriptors it inherits? That'd certainly one way to get into odd corruption
>> issues.
>>
>> We processor real
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
On Wed, Oct 26, 2016 at 1:34 PM, Andres Freund wrote:
> Any chance that plsh or the script it executes does anything with the file
> descriptors it inherits? That'd certainly one way to get into odd corruption
> issues.
not sure. it's pretty small -- see
https://github.com/petere/plsh/blob/mas
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
On Fri, Sep 30, 2016 at 9:56 PM, Tom Lane wrote:
> Craig Ringer writes:
>> On 1 Oct. 2016 05:20, "Tom Lane" wrote:
>>> I think the last of those suggestions has come up before. It has the
>>> large advantage that you don't have to remember a different syntax for
>>> copy-as-a-function.
>
>> Tha
On Fri, Oct 14, 2016 at 3:31 PM, Tom Lane wrote:
> Andreas Seltenreich writes:
>> Tom Lane writes:
>>> Seems sane, though I wonder if it'd be better to use -INT_MAX rather
>>> than -VARBITMAXLEN.
>
>> I am undecided between those two. -INT_MAX might be a more precise fix
>> for the problem, but
Today I had an emergency production outage on a server. This
particular server was running 9.5.2. The symptoms were interesting
so I thought I'd report. Here is what I saw:
*) User CPU was pegged 100%
*) Queries reading data would block and not respond to cancel or terminate
*) pg_stat_activit
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,
On Wed, Oct 12, 2016 at 5:10 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Tom Lane wrote:
>>> According to
>>> https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt
>>> looking into /proc/meminfo is the longer-standing API and thus is
>>> likely to work on more kernel versions. Also, if
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
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 and call them
>> background transactions. That allows us to expose additional
>> functionality which is useful, like the ability to kick some
On Wed, Aug 17, 2016 at 5:18 PM, Jim Nasby wrote:
> On 8/17/16 2:51 PM, Simon Riggs wrote:
>> On 17 August 2016 at 12:19, Greg Stark wrote:
>>> Yes, this is exactly what it should be doing and exactly why it's
>>> useful. Physical replication accurately replicates the data from the
>>> master inc
On Thu, Jul 28, 2016 at 8:16 AM, pgwhatever wrote:
> Statement-Based replication has a lot of problems with it like indeterminate
> UDFs. Here is a link to see them all:
> https://dev.mysql.com/doc/refman/5.7/en/replication-sbr-rbr.html#replication-sbr-rbr-sbr-disadvantages
Sure. It's also incr
On Tue, Jul 26, 2016 at 5:07 PM, Tom Lane wrote:
> Josh Berkus writes:
>> To explain this in concrete terms, which the blog post does not:
>
>> 1. Create a small table, but one with enough rows that indexes make
>> sense (say 50,000 rows).
>
>> 2. Make this table used in JOINs all over your datab
On Fri, Jul 22, 2016 at 1:39 PM, David G. Johnston
wrote:
> On Fri, Jul 22, 2016 at 2:13 PM, Tom Lane wrote:
>>
>> There is a rather squishy question as to whether NULL::composite_type
>> should be semantically equivalent to ROW(NULL,NULL,...)::composite_type.
>> If it is, then the SELECT should
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
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 in 1..100
LOOP
INSERT INTO foo VALUES (i);
END LOOP;
...runs just fine while
BEGIN
INSERT INTO foo VALUES (1);
INSERT INTO foo VALUES (2);
...
INSE
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?
merlin
--
Sen
On Thu, Jul 7, 2016 at 11:45 AM, Pete Stevenson
wrote:
> Hi postgresql hackers -
>
> I would like to find some analysis (published work, blog posts) on the
> overheads affiliated with the guarantees provided by MVCC isolation. More
> specifically, assuming the current workload is CPU bound (as o
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
On Fri, Jul 1, 2016 at 9:11 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jul 1, 2016 at 9:52 AM, Tom Lane wrote:
>>> Maybe, but neither UNION nor UNION ALL would duplicate the semantics
>>> of OR, so there's some handwaving here that I missed.
>
>> SELECT * FROM foo WHERE a = 5 OR a = 4
Hello hackers,
Observe the following test case (apologies if this is a well
understood problem):
create temp table foo as select generate_series(1,100) id;
create index on foo(id);
create temp table bar as select id, id % 10 = 0 as good from
generate_series(1,100) id;
create index on
1 - 100 of 1954 matches
Mail list logo