Re: [PATCH] Log CSV by default

2018-12-02 Thread Arkhena
Hi all,


> Also, in addition to the objections you noted, there's the problem that
> this change requires changing logging_collector to default to "on".
> That's an *enormous* compatibility break, because of the effects on
> where the log output goes.
>

As a consultant with so many customers that simply install Postgres "out of
the box", I think that changing log_destination to 'csvlog' and
logging_collector to 'on' needs changing at least log_truncate_on_rotation
(but certainly also log_filename and log_rotation_age) if we don't want my
customers to run out of space sooner or later.

So, that's a "-1" for me to change the log_destination default to 'csvlog'.

Personally, I use one of my colleague's python script that "change" the
standard text output to csv (and even create the table and insert rows in
it by connecting to my database), so I can use my SQL queries to perform
log analyzes.
So I think the idea of a 'pg_logparse' is wonderfull.

Cheers,

Lætitia

Le sam. 1 déc. 2018 à 01:03, David Fetter  a écrit :

> On Fri, Nov 30, 2018 at 04:55:30PM -0500, Tom Lane wrote:
> > Andres Freund  writes:
> > > On 2018-11-30 19:53:18 +0100, David Fetter wrote:
> > >> This makes it much simpler for computers to use the logs while not
> > >> making it excessively difficult for humans to use them.
> >
> > > While perhaps not excessively so, I think it increases the difficulty
> > > sufficiently that I'm against such a proposal.
> >
> > I don't like this either.  People who prefer CSV format can select it
> > trivially.  Those who don't are going to be annoyed at us for changing
> > behavior that's stood for many years.
> >
> > Also, in addition to the objections you noted, there's the problem that
> > this change requires changing logging_collector to default to "on".
> > That's an *enormous* compatibility break, because of the effects on
> > where the log output goes.  Not to mention having performance impacts
> > that can be significant.
> >
> > I think we should reject this out of hand.
>
> It's been far too long since I got one of these!
>
> > > I think having a bin/pg_logparse tool that can parse postgres' config
> > > file and attempt to parse the log contents in whatever format they are
> > > would be much much more useful. Obviously not every log_line_prefix can
> > > be parsed unambiguously, but a lot of formats can, and a lot more
> > > formats can be made unambiguous (e.g. adding escape logic to
> application
> > > name logging would be very useful).
> >
> > Yeah, it might be possible to make some progress in those directions.
>
> So application names need better handling, and possibly reviews for
> security considerations, and pg_logparse ?
>
> OK.
>
> Best,
> David.
> --
> David Fetter  http://fetter.org/
> Phone: +1 415 235 3778
>
> Remember to vote!
> Consider donating to Postgres: http://www.postgresql.org/about/donate
>
>

-- 
Adoptez l'éco-attitude
N'imprimez ce mail que si c'est vraiment nécessaire


Re: What to name the current heap after pluggable storage / what to rename?

2018-12-19 Thread Arkhena
>
>
> I'm wondering where the choice of the name "heap" originally came from
> and what it refers to.


It seems to me that "heap" is an Oracle word (as explained here[1]).

> By default, a table is organized as a heap, which means that the database
places rows where they fit best rather than in a user-specified order.

[1]:
https://docs.oracle.com/en/database/oracle/oracle-database/18/tgsql/optimizer-access-paths.html#GUID-53905BCD-3EAD-4B44-8CCC-C442A80647E8


-- 
Adoptez l'éco-attitude
N'imprimez ce mail que si c'est vraiment nécessaire


Re: [Sender Address Forgery]Re: error message when subscription target is a partitioned table

2019-01-10 Thread Arkhena
> > On Tue, Jan 08, 2019 at 04:42:35PM +0900, Michael Paquier wrote:
> >> I can see your point, though I would stick with
> >> ERRCODE_WRONG_OBJECT_TYPE for consistency with the existing code and
> >> because the code is intended to not work on anything else than plain
> >> tables, at least now.
> >
> > Attached are my suggestions shaped as a patch.  Thoughts?
>
> Thanks for updating the patch and sorry couldn't reply sooner.
>
> Your rewritten version is perhaps fine, although I remain a bit concerned
> that some users might be puzzled when they see this error, that is, if
> they interpret the message as "it's impossible to use a partitioned table
> as logical replication target".
>
>
>From [documentation](
https://www.postgresql.org/docs/current/logical-replication-restrictions.html
) :
> Attempts to replicate tables other than base tables will result in an
error.

That's basicaly what I had understood about logicial replication...

Cheers,

Lætitia
-- 
Adoptez l'éco-attitude
N'imprimez ce mail que si c'est vraiment nécessaire