> "Thomas" == Thomas Munro writes:
Thomas> * it's also been claimed that readahead heuristics are not
Thomas> defeated on Linux or FreeBSD, which isn't too surprising
Thomas> because you'd expect it to be about blocks being faulted in,
Thomas> not syscalls
I don't know about linux, but o
On Fri, Jun 23, 2017 at 4:50 AM, Andres Freund wrote:
> On 2017-06-22 12:43:16 -0400, Robert Haas wrote:
>> On Wed, Jan 25, 2017 at 2:52 PM, Andres Freund wrote:
>> > You'll, depending on your workload, still have a lot of lseeks even if
>> > we were to use pread/pwrite because we do lseek(SEEK_E
At Thu, 12 Apr 2018 17:23:42 +0300, Alexander Kuzmenkov
wrote in
> On 11.04.2018 00:00, Tom Lane wrote:
> > So we need a mechanism that's narrowly targeted
> > to reopening the logfile, without SIGHUP'ing the entire database.
>
> We can send SIGUSR1 to the syslogger process. To make its pid ea
On Sun, Apr 15, 2018 at 01:54:13PM +0200, Magnus Hagander wrote:
> I have applied this patch along with the documentation patch from Michael.
Thanks, I saw the commits. That's fine by me.
--
Michael
signature.asc
Description: PGP signature
On Thu, Apr 12, 2018 at 05:47:29AM +0900, Michael Paquier wrote:
> On Wed, Apr 11, 2018 at 10:21:29PM +0200, Daniel Gustafsson wrote:
>> Naming it pg_checksums, with only verification as an option, seems to me to
>> imply future direction for 12 more than what pg_verify_checksums does. I
>> would
2018-04-15 6:13 GMT+09:00 Andres Freund :
> On 2018-04-14 17:10:21 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > On April 14, 2018 1:56:08 PM PDT, Tom Lane wrote:
> > >> The project policy is to use exactly the GNU distribution of autoconf.
> >
> > > Fwiw, I see one copyright year relat
Awhile back, Alvaro Herrera wrote:
>> Pushed to all affected branches, along with a somewhat lame
>> isolationtester test for the condition (since we've already broken this
>> twice and not noticed for long).
> Buildfarm member okapi just failed this test in 9.4:
okapi has continued to fail that
On Thu, Apr 12, 2018 at 9:21 AM, Teodor Sigaev wrote:
> Agree, I prefer to add more Assert, even. may be, more than actually needed.
> Assert-documented code :)
Absolutely. The danger with a feature like this is that we'll miss one
place. I suppose that you could say that I am in the Poul-Henning
> I'd argue that the first line of attack on that should be to explain to
those consumers of logs that they are making some unwarranted assumptions
about the kind of inputs they'll be seeing. PostgreSQL's CSV log formats
are not a particular bizarre format, or very difficult to parse. The
standar
> On Apr 15, 2018, at 12:16, David Arnold wrote:
>
> Core-Problem: "Multi line logs are unnecessarily inconvenient to parse and
> are not compatible with the design of some (commonly used) logging
> aggregation flows."
I'd argue that the first line of attack on that should be to explain to th
Hi Tom,
On Thu, 2018-04-12 at 14:36 -0400, Tom Lane wrote:
> I don't have F27 at hand, but I tried F26 and F28, and I can't reproduce
> on either one.
I uploaded the SRPM for you:
https://gunduz.org/temp/postgresql11-11.0-20180415_1PGDG.f27.src.rpm
I built this SRPM using daily snapshot at:
h
>Have you asked that question? You seem to at least have opened the source
code - did you try to figure out what the logging format is?
1. -> No. 2. -> Yes.
I might be wrong, but something in my head tells me to have them seen the
other way round. Unfortunately, I'm not experienced enough to be ab
On Sun, Apr 15, 2018 at 11:08 AM, David Arnold wrote:
> >This would appear to solve multiline issues within Fluent.
> >https://docs.fluentd.org/v0.12/articles/parser_multiline
>
> I definitely looked at that, but what guarantees do I have that the
> sequence is always ERROR/STATEMENT/DETAIL?
>Why? The newlines aren't meaningfully different from other characters
you need to parse? The data isn't actually stored in a newline separated
fashion, that's just one byte with that meaning
I miss the details, but I believe that stdout is usually parsed and
streamed simply line by line. Like in:
>This would appear to solve multiline issues within Fluent.
>https://docs.fluentd.org/v0.12/articles/parser_multiline
I definitely looked at that, but what guarantees do I have that the
sequence is always ERROR/STATEMENT/DETAIL? And not the other way round?
And it only works with tail logging
> On Apr 15, 2018, at 11:00, David Arnold wrote:
>
> CSV Logs: https://pastebin.com/uwfmRdU7
Is the issue that there are line breaks in things like lines 7-9?
--
-- Christophe Pettus
x...@thebuild.com
On 2018-04-15 18:00:05 +, David Arnold wrote:
> CSV shows line breaks, STDOUT shows ERROR/FATAL and detail on different
> lines, not an easy problem to stream-parse reliably (without some kind of a
> buffer, etc)...
Why? The newlines aren't meaningfully different from other characters
you need
>It looks like the thread skipped over the problem space for the solution
space pretty fast
OK, I apologize, it seemed to me from the feedback that the problem was
already uncontested. To verify/falsify that was the objective of my
previous mail :)
>Can you elaborate?
Sure.
CSV Logs: https://pas
On Sun, Apr 15, 2018 at 10:39 AM, David Arnold wrote:
> >More specifically, JSON logging does seem to be a solution in search of a
> problem. PostgreSQL's CSV logs are very easy to machine-parse, and if
> there are corrupt lines being emitted there, the first step should be to
> fix those, rathe
> On Apr 15, 2018, at 10:39, David Arnold wrote:
>
> In the light of the specific use case / problem for this thread to be born,
> what exactly would you suggest?
It looks like the thread skipped over the problem space for the solution space
pretty fast; I see your note:
> I have reviewed so
>More specifically, JSON logging does seem to be a solution in search of a
problem. PostgreSQL's CSV logs are very easy to machine-parse, and if
there are corrupt lines being emitted there, the first step should be to
fix those, rather than introduce a new "this time, for sure" logging method.
>I
> On Apr 15, 2018, at 10:07, Christophe Pettus wrote:
>
>
>> On Apr 15, 2018, at 09:51, David Arnold wrote:
>>
>> 1. Throughout this vivid discussion a good portion of support has already
>> been manifested for the need of a more structured (machine readable) logging
>> format. There has be
> On Apr 15, 2018, at 09:51, David Arnold wrote:
>
> 1. Throughout this vivid discussion a good portion of support has already
> been manifested for the need of a more structured (machine readable) logging
> format. There has been no substantial objection to this need.
I'm afraid I don't see
Does everyone more or less agree with the following intermediate résumé?
1. Throughout this vivid discussion a good portion of support has already
been manifested for the need of a more structured (machine readable)
logging format. There has been no substantial objection to this need.
2. It has b
> Exactly - arrays, maps, nested json objects. It's more organized and
easier to reason about. As postgresql becomes more and more sophisticated
over time, I see flat logging becoming more unwieldy. With tools like jq,
reading and querying json on the command line is simple and user friendly,
and u
> Exactly what are you logging here ??? Why would I need to see a
> multi-dimensional array in the log ?
If I wanted to capture the location of errors my clients are encountering on
their postgres clusters in detail, I would need to parse the 'LOCATION' string
in their log entries, parse out th
On 15 April 2018 at 11:27, Jordan Deitch wrote:
> > > I would suggest that the community consider whether postgres will log
> > multidimensional data. That will weigh into the decision of json vs.
> > another format quite significantly. I am a fan of the json5 spec (
> > https://json5.org/), tho
> > I would suggest that the community consider whether postgres will log
> multidimensional data. That will weigh into the decision of json vs.
> another format quite significantly. I am a fan of the json5 spec (
> https://json5.org/), though adoption of this is quite poor.
>
> What do you mean
>A slightly larger lift would include escaping newlines and ensuring that JSON
output is always single lines, however long.
I think that's necessary, actually I was implicitly assuming that as a
prerequisite. I cannot imagine anything else beeing actually useful.
Alternatively, I'm sure logfmt ha
On Tue, Apr 10, 2018 at 6:18 PM, Robert Haas wrote:
> On Fri, Apr 6, 2018 at 8:59 PM, Andres Freund wrote:
> > This is PROPARALLEL_RESTRICTED. That doesn't strike me right, shouldn't
> > they be PROPARALLEL_UNSAFE? It might be fine, but I'd not want to rely
> > on it.
>
> Just a fine-grained not
On Tue, Apr 10, 2018 at 11:45 PM, David Steele wrote:
> On 4/10/18 5:24 PM, Tomas Vondra wrote:
>
>>
>> I think there's a bug in sendFile(). We do check checksums on all pages
>> that pass this LSN check:
>>
>> /*
>> * Only check pages which have not been modified since the
>> *
On Sun, Apr 15, 2018 at 11:08 AM, Christoph Berg wrote:
> Re: Magnus Hagander 2018-04-09
> > Revert "Allow on-line enabling and disabling of data checksums"
> >
> > Modified Files
> > --
> > doc/src/sgml/reference.sgml | 1 -
>
> This removed "&pgVerifyChecksum
On Sun, Apr 15, 2018 at 9:49 AM, Daniel Gustafsson wrote:
> > On 15 Apr 2018, at 09:36, Michael Paquier wrote:
> >
> > On Tue, Apr 10, 2018 at 10:27:19PM +0200, Daniel Gustafsson wrote:
> >> Thinking more on this, I don’t think the -f option should be in the
> tool until
> >> we have the ability
Re: Magnus Hagander 2018-04-09
> Revert "Allow on-line enabling and disabling of data checksums"
>
> Modified Files
> --
> doc/src/sgml/reference.sgml | 1 -
This removed "&pgVerifyChecksums;" which causes pg_verify_checksums.1
not to be built anymore.
The sec
> On 15 Apr 2018, at 09:36, Michael Paquier wrote:
>
> On Tue, Apr 10, 2018 at 10:27:19PM +0200, Daniel Gustafsson wrote:
>> Thinking more on this, I don’t think the -f option should be in the tool
>> until
>> we have the ability to turn on/off checksums. Since checksums are always on,
>> or al
On Tue, Apr 10, 2018 at 10:27:19PM +0200, Daniel Gustafsson wrote:
> Thinking more on this, I don’t think the -f option should be in the tool until
> we have the ability to turn on/off checksums. Since checksums are always on,
> or always off, -f is at best confusing IMO. The attached patch remov
Hello
Attached updated patch follows recent Reorganize partitioning code commit.
regards, Sergeidiff --git a/doc/src/sgml/ref/alter_table.sgml b/doc/src/sgml/ref/alter_table.sgml
index bd22627..db98a98 100644
--- a/doc/src/sgml/ref/alter_table.sgml
+++ b/doc/src/sgml/ref/alter_table.sgml
@@ -215,8
37 matches
Mail list logo
