Re: rw_redis_fdw: SQL Errors when statement is within a function

[Christoph Moench-Tegeder]

## GPT (gptmailingli...@gmail.com):

> - In PG10.5 I run, out of function, a simple statement for 5 times
> successfully and the 6th time I get an error "KEY is NULL". In the
> meantime of these times I added, removed code, packages got updated,
> etc. Suddenly, an error. Key is NULL!!!??? Check the key, write
> statements to check the value of the key. Eh, it is not NULL! Hm, undo
> all changes, start again! Oh, now it runs! Ok, redo the changes one by
> one. Ah, ok still run. Suddenly, error again! Check again and again.
> Ok check Redis. Uninstall packages, reinstall packages... Finally,
> install PG9.6 make it run, install fdw to the new system, check the
> environment. OK run. Keep it as it is!

Your testing/debugging/validating processes seem to be a little
erratic. Sometimes it does make sense to build minimal test cases;
and to understand why things don't work or seem to be working again.

> So, in order this thread to get over:
> - PG developers made a drastic change. Not problem at all, more then welcome.
> - I was the "lucky guy" who had a painful experience. These things
> happen as Adrian wrote, and life goes on.

Let me add another thing here: you're using software which is marked
as "not really ready" (rw_redis_fdw/README.md: "work in progress and may
have experience significant changes until it becomes stable") which
uses very low level, internal interfaces to PostgreSQL; in a perhaps
not-trivial project (there's PostgreSQL, Redis, rw_redis_fdw, you mentioned
node.js and microservices...). I'm not sure you really did calculate the
project risk of that. In some environments, such setup are called
"technology jenga": deep stack with an unstable equilibrium.

> What I would like to ask from developers is:
> 
> Please, if possible improve the error system!
> 
> Especially when there are internal changes which may affect
> dynamically the outcome (from expected results to ERROR or whatever)
> of a correct statement.

I'm not sure we can do very much when external (not under any of our's
control - I guess most people here wouldn't even have known about
rw_redis_fdw until you mentioned it) components use interfaces in
a fragile way. And as it was noted several times: the developer of
that component identified the problem with the debug output (nothing
fancy here) and fixed it.

Regards,
Christoph

-- 
Spare Space

Re: Fwd: Log file

[Tom Lane]

Igor Korot  writes:
> On Mon, Oct 29, 2018 at 1:56 PM Tom Lane  wrote:
>> You can set up the log files as readable by the OS group of the server
>> (see log_file_mode), and then grant membership in that group to whichever
>> OS accounts you trust.  You may also need to move the log directory
>> out from under $PGDATA to make that work, since PG doesn't like
>> world-readable data directories.

> I'm trying to make the log file of PG readable of the user who logs in
> to the current
> OS session. I don't need a write permission, just read.
> Because my program will not be started from the "postgres" account.

Well, any such setup is a serious security hole in itself, because
there is likely to be sensitive data in the postmaster log, eg
passwords.  (Remember that the log file is global to the whole cluster,
it will not contain just data relevant to the current session.)
You should only grant access to people who you trust at more or less
the level of trust you'd put in the installation DBA.

It may be that these concerns are all irrelevant to you because it's
a single-user installation anyway, but they're not irrelevant to
people running multi-user installations.  So that's why you can't
get Postgres to do it.  In a single-user installation, maybe you
should just launch the postmaster as that user.

regards, tom lane

Re: Fwd: Log file

[Igor Korot]

Hi, Tom,

On Mon, Oct 29, 2018 at 1:56 PM Tom Lane  wrote:
>
> Igor Korot  writes:
> > I'm trying to test the functionality of logging on my older Mac with
> > PostgreSQL 9.1.
> > I see that the logile is created with the owner of postgres and the
> > group of wheel.
>
> Well, more specifically, it's created under the OS user & group that
> the server is running under.

OK, that clarifies it a little.
I thought I could just crate a user called "igor", give him all
"postgres" permissions
and login to the server as "igor" and not "postgres" every time I test.
But since the server will probably run from the "postgres" account
during the machine
start-up that won't work.

>
> > Is there a way to make it open with ""?
>
> What current user?  The SQL user name might not correspond to any
> OS-level entity at all.  Even if it did, it's quite unlikely that
> the OS would permit the server process to create files owned by
> some other OS user --- doing so would be a giant security risk.

The current_user = user who logged in to the machine and open the
current session.
If I log in to the machine as "igor" and try to create a file in vi/nano/notepad
I will be the owner of this file and the group will be the group to which
I belong as a user.

And I'm talking about specifically to the result of the "ls -la"
output from the *nix/OSX
POV.

>
> > Or I will have to change the owner/group manuall every time I will
> > access the file?
>
> You can set up the log files as readable by the OS group of the server
> (see log_file_mode), and then grant membership in that group to whichever
> OS accounts you trust.  You may also need to move the log directory
> out from under $PGDATA to make that work, since PG doesn't like
> world-readable data directories.

I'm trying to make the log file of PG readable of the user who logs in
to the current
OS session. I don't need a write permission, just read.
Because my program will not be started from the "postgres" account.

Thank you.

>
> regards, tom lane

Re: Redirecting select() output generates error [FIXED]

[Rich Shepard]

On Mon, 29 Oct 2018, Rich Shepard wrote:


willamette-river-hg-# select param, site_nbr, sampdate, min(quant),


  Yep. I kept missing this. Closed that status and it does work within
emacs. Thanks all.

Rich

Re: Redirecting select() output generates error

[Rob Sargent]

> On Oct 29, 2018, at 1:37 PM, David G. Johnston  
> wrote:
> 
> On Mon, Oct 29, 2018 at 12:30 PM Rich Shepard  > wrote:
> willamette-river-hg-# \out data-summary-by-form.txt
> willamette-river-hg-# select param, site_nbr, sampdate, min(quant), 
> max(quant), unit from concentrations group by param, site_nbr, sampdate, unit 
> order by param, site_nbr, sampdate, unit;
> 
> The "-#" prompt in psql means you are in line continuation mode.  The \out 
> meta-command should be issued while sitting at an initial prompt "=#".
> 
> Being in line-continuation mode means you are typing something else above it 
> that doesn't constitute a full command - and you are still not showing us 
> what that is.  This is the reason I asked for basically a self-contained 
> example.
> 
> David J.
> 
Being inside emacs buffer has nothing to do with the problem. I do it all the 
time.  As David points out, continuation in play.

Re: Redirecting select() output generates error

[David G. Johnston]

On Mon, Oct 29, 2018 at 12:30 PM Rich Shepard 
wrote:

> willamette-river-hg-# \out data-summary-by-form.txt
> willamette-river-hg-# select param, site_nbr, sampdate, min(quant),
> max(quant), unit from concentrations group by param, site_nbr, sampdate,
> unit order by param, site_nbr, sampdate, unit;
>

The "-#" prompt in psql means you are in line continuation mode.  The \out
meta-command should be issued while sitting at an initial prompt "=#".

Being in line-continuation mode means you are typing something else above
it that doesn't constitute a full command - and you are still not showing
us what that is.  This is the reason I asked for basically a self-contained
example.

David J.

Re: Redirecting select() output generates error

[Rich Shepard]

On Mon, 29 Oct 2018, David G. Johnston wrote:


I'd say that emacs is doing something funky then.  Running your script
using:


David,

  Yes, it is something related to running the commands within an emacs bash
shell.

Thanks for isolating the problem,

Rich

Re: Redirecting select() output generates error

[Rich Shepard]

On Mon, 29 Oct 2018, David G. Johnston wrote:


You can either use \out or \copy within psql script or redirect the shell
output using shell features.


David,

willamette-river-hg-# \out data-summary-by-form.txt
willamette-river-hg-# select param, site_nbr, sampdate, min(quant), max(quant), 
unit from concentrations group by param, site_nbr, sampdate, unit order by 
param, site_nbr, sampdate, unit;
ERROR:  syntax error at or near "|"
LINE 1: | 1980-05-08 |0.5 |0.5 | ug/L

  Still not working.

Rich

Re: Redirecting select() output generates error

[David G. Johnston]

On Mon, Oct 29, 2018 at 12:21 PM Rich Shepard 
wrote:

> On Mon, 29 Oct 2018, David G. Johnston wrote:
>
> > You seem to need to distinguish between the command line options to psql
> > and the meta commands that can be used within a script that is being
> > executed by psql.
>
> David,
>
>I'm running psql in a shell buffer within emacs, not at the shell
> prompt. The entire script is:
>

I'd say that emacs is doing something funky then.  Running your script
using:

psql <

Re: Redirecting select() output generates error

[Rich Shepard]

On Mon, 29 Oct 2018, David G. Johnston wrote:


You seem to need to distinguish between the command line options to psql
and the meta commands that can be used within a script that is being
executed by psql.


David,

  I'm running psql in a shell buffer within emacs, not at the shell prompt. The 
entire script is:

\o data-summary-by-form.txt
select param, site_nbr, sampdate, min(quant), max(quant), unit from 
concentrations group by param, site_nbr, sampdate, unit order by param, 
site_nbr, sampdate, unit;
\o

  This generates the error.

  Other backslash commands, such as \d  work, but both \o and \g
produce the error when followed by the select command.

Rich

Re: Redirecting select() output generates error

[David G. Johnston]

On Monday, October 29, 2018, Rich Shepard  wrote:

> On Mon, 29 Oct 2018, Rich Shepard wrote:
>
> But, when I try to redirect output to a disk file like this,
>> \o data-summary-by-form.txt
>> the result is an error:
>>
>
>   The \o came from a stackexchange thread I found with a web search. Within
> psql the \? help command indicates there is no \o option, but \g should do
> the same thing. It doesn't. I'm still confused on how to redirect output to
> a file.
>
>   A clue stick is needed.
>
>
You seem to need to distinguish between the command line options to psql
and the meta commands that can be used within a script that is being
executed by psql.

You should probably show all shell and commands and the psql script in full
instead of bits and pieces.

This stuff does work and nothing you’ve shown as having executed is wrong
so that error is coming from something you haven’t shown.

Read the psql documentation.

You can either use \out or \copy within psql script or redirect the shell
output using shell features.

David J.

Re: Redirecting select() output generates error

[Rich Shepard]

On Mon, 29 Oct 2018, Rich Shepard wrote:


But, when I try to redirect output to a disk file like this,
\o data-summary-by-form.txt
the result is an error:


  The \o came from a stackexchange thread I found with a web search. Within
psql the \? help command indicates there is no \o option, but \g should do
the same thing. It doesn't. I'm still confused on how to redirect output to
a file.

  A clue stick is needed.

Rich

Re: Fwd: Log file

[Tom Lane]

Igor Korot  writes:
> I'm trying to test the functionality of logging on my older Mac with
> PostgreSQL 9.1.
> I see that the logile is created with the owner of postgres and the
> group of wheel.

Well, more specifically, it's created under the OS user & group that
the server is running under.

> Is there a way to make it open with ""?

What current user?  The SQL user name might not correspond to any
OS-level entity at all.  Even if it did, it's quite unlikely that
the OS would permit the server process to create files owned by
some other OS user --- doing so would be a giant security risk.

> Or I will have to change the owner/group manuall every time I will
> access the file?

You can set up the log files as readable by the OS group of the server
(see log_file_mode), and then grant membership in that group to whichever
OS accounts you trust.  You may also need to move the log directory
out from under $PGDATA to make that work, since PG doesn't like
world-readable data directories.

regards, tom lane

Redirecting select() output generates error

[Rich Shepard]

  This is puzzling and I've no idea what to do to fix it.

  The table looks like this:

# select * from concentrations limit 2;
 site_nbr |  sampdate  | medium  | form  |   param   | quant | unit | cen | floor | ceiling 
--++-+---+---+---+--+-+---+-

 10332| 1979-11-06 | surface | total | inorganic |   0.5 | ug/L |   1 | 
0 | 0.5
 10332| 1980-02-07 | surface | total | inorganic | 0.001 | ug/L |   1 | 
0 |   0.001

Running this statement within psql works just fine (it's entered as a single
line but wrapped by alpine to fit the line limit):

select param, site_nbr, sampdate, min(quant), max(quant), unit from
concentrations group by param, site_nbr, sampdate, unit order by param,
site_nbr, sampdate, unit;

the output ends this way:

 organic   | 34198| 2010-10-21 |   0.02 |  0.025 | ng/L
 organic   | 34198| 2011-01-14 |   0.02 |  0.046 | ng/L
(585 rows)

  But, when I try to redirect output to a disk file like this,
\o data-summary-by-form.txt
the result is an error:

# select param, site_nbr, sampdate, min(quant), max(quant), unit from 
concentrations group by param, site_nbr, sampdate, unit order by param, 
site_nbr, sampdate, unit;
ERROR:  syntax error at or near "|"
LINE 1: | 1980-05-08 |0.5 |0.5 | ug/L

  That line is not number 1 and I don't understand this behavior. Could it
be related to using hyphens in the filename rather than underscores?

Rich

Re: rw_redis_fdw: SQL Errors when statement is within a function

[Adrian Klaver]

On 10/29/18 3:58 AM, GPT wrote:

Hi, I had a wonderful Sunday, and have no intention to change that sense!

Dear PG developers, young and/or middle age, and rest users, please
check the errors the PG gave me.



happen as Adrian wrote, and life goes on.

What I would like to ask from developers is:

Please, if possible improve the error system!


The improvement is already there:

https://github.com/nahanni/rw_redis_fdw/issues/14

"Turning on debugging, the first 5 tries parses the where clause as:"

For more information see:

https://www.postgresql.org/docs/10/static/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHEN

In particular: Table 19.1. Message Severity Levels.



Especially when there are internal changes which may affect
dynamically the outcome (from expected results to ERROR or whatever)
of a correct statement. For example, the error would include a
note/warning similar to "... after change of plan" or "... . Plan was
changed". Such a note/warning would have saved the whole situation and
I would have something in my hand to search and ask for help from the
very beginning.

As a simple end-user and not an IT folk, I have absolutely no word on
what and how things happen under the hood. But I expect the best
response, even if an error has appeared, which will safely enlighten
me at the shortest time. Your time is valuable, my time, too. So,
let´s respect our times and do the best to protect them against waste
in future.

Thanks and have a nice day and a wonderful week!






--
Adrian Klaver
adrian.kla...@aklaver.com

Function for Exception Logging

[Patrick FICHE]

Hi community,

I would like to implement a function that would log managed Exceptions into a 
dedicated table.
For example, I have some code like :
BEGIN
Code generation exception
EXCEPTION
  WHEN OTHERS THEN Log_Error();
END;

The Log_Error function would be able to get the exception context / parameters 
to log the exception parameters into a table.
Is there any way to manage this without providing the Exception parameters as 
parameters to the Log_Error function ?

Thanks,
Patrick


Patrick Fiche
Database Engineer, Aqsacom Sas.
c. 33 6 82 80 69 96
e. patrick.fi...@aqsacom.com

[01-03_AQSA_Main_Corporate_Logo_JPEG_White_Low.jpg]

Function for Exception Logging

[Patrick FICHE]

Hi community,

I would like to implement a function that would log managed Exceptions into a 
dedicated table.
For example, I have some code like :
BEGIN
Code generation exception
EXCEPTION
  WHEN OTHERS THEN Log_Error();
END;

The Log_Error function would be able to get the exception context / parameters 
to log the exception parameters into a table.
Is there any way to manage this without providing the Exception parameters as 
parameters to the Log_Error function ?

Thanks,
Patrick

Fwd: Log file

[Igor Korot]

I initially sent this to the ODBC list.'

Thank you for any suggestions.

-- Forwarded message -
From: Igor Korot 
Date: Sun, Oct 28, 2018 at 11:03 PM
Subject: Log file
To: PostgreSQL ODBC list 


Hi, ALL,
I'm trying to test the functionality of logging on my older Mac with
PostgreSQL 9.1.

I see that the logile is created with the owner of postgres and the
group of wheel.

Is there a way to make it open with ""?
Or I will have to change the owner/group manuall every time I will
access the file?

Thank you.

Research survey

[Diego Andres Ruiz Gomez]

Hi community,

I'm a software developer fascinated with open source, I've participated in
several OSS projects, mainly in iDempiere ,
which uses postgresql heavily. Therefore, I am familiar with the project
and have a great image of it.

I'm doing a research on marketing in community-driven open source software
projects. The objective of this research project is to understand why it
appears that marketing has not been an important topic in open source
software communities, and why in most of the cases privative software
continues being the market-leaders, even though there are better solutions.

Therefore, I'm inviting all the community members who wants to participate
in the study to help me by answering an online survey that would take
around 10 minutes.

You can find the interview here:
https://goo.gl/forms/LAM1DiTsDRHb34bF2

My goal is to publish the results and try to use them to benefit the OSS
communities.

Kindly also distribute this survey to your friends or colleagues which are
members from open source communities (regardless of the project).

Thanks in advance!

Kind Regards,
DIego Ruiz

Re: Select "todays" timestamps in an index friendly way

[Steven Lembark]

> create temporary table t (
>   id SERIAL primary key,
>   ts timestamp not null default now()
> );

* add date( ts ) as a field and index date = now()::date.

* Depending on the amount of data in your table the date
  may not be seletive enough to be worth using, at which 
  point the index may be present and ignored. Only way to
  be sure is analyze it.

* Might be worth looking at a partial index using >= 00:00:00 
  and < 24:00:00 (PG grocks the 2400 notation for "midnight at 
  the end of today) or

where ts && tsrange( ... 00:00:00, ... 24:00:00, '[)] )

  Nice thing about the partial index is that you can create it
  on all of the non-ts fields for fast lookup by whatever and 
  only index the portion for today. 

* Think about using a materialized view rather than a temp
  table. May prove simpler to query.


-- 
Steven Lembark 3920 10th Ave South
Workhorse Computing   Birmingham, AL 35222
lemb...@wrkhors.com+1 888 359 3508

RE: Which index is used in the index scan.

[Sakai, Teppei]

Hi, Andreas

Thank you your reply.

This problem was solved.
I revalidated your advice, source code and the statistics.
As a result, the cost was changing due to the difference in the index height.

Regards,
SAKAI Teppei

> On 17 October 2018 07:39:48 CEST, "Sakai, Teppei"
>  wrote:
> >Hi
> >
> >We have question about index scan.
> >
> >We created table and indexes and executed SQL, but the index used by
> >day is different.
> >One day the index of c1 was used, and on another day the index of c2
> >was used.
> > - CREATE TABLE tbl1 (c1 varchar, c2 varchar, c3 timestamptz);
> > - CREATE INDEX tbl1_idx_c1 ON tbl1(c1);
> > - CREATE INDEX tbl1_idx_c2 ON tbl2(c2);
> >- SELECT * FROM tbl1 WHERE c1 = 'XXX' AND C2 = 'YYY' AND C3 >=
> >'/mm/dd' AND C3 <= '/mm/dd';
> >
> >We calculated cost from the source code using pg_class and
> >pg_statistic, but the cost values at each index were the same.
> >We did not rebuild or update indexes.
> >
> >What are the reasons why the index has been changed besides the
> >following factors?
> > - cost values
> > - Index creation order
> 
> 
> there are a lot of things which planner has to consider, for instance data
> distribution, the age of the statistics, table and index bloat. You should
> compare the plans (using explain analyse with buffers). an combined index
> over all the columns would be better for this query.
> 
> 
> >
> >PostgreSQL version : 9.5.2
> 
> there are several minor updates available.
> 
> 
> Regards, Andreas
> 
> 
> --
> 2ndQuadrant - The PostgreSQL Support Company
> 

Re: rw_redis_fdw: SQL Errors when statement is within a function

[GPT]

Hi, I had a wonderful Sunday, and have no intention to change that sense!

Dear PG developers, young and/or middle age, and rest users, please
check the errors the PG gave me.

- In PG10.5 I run, out of function, a simple statement for 5 times
successfully and the 6th time I get an error "KEY is NULL". In the
meantime of these times I added, removed code, packages got updated,
etc. Suddenly, an error. Key is NULL!!!??? Check the key, write
statements to check the value of the key. Eh, it is not NULL! Hm, undo
all changes, start again! Oh, now it runs! Ok, redo the changes one by
one. Ah, ok still run. Suddenly, error again! Check again and again.
Ok check Redis. Uninstall packages, reinstall packages... Finally,
install PG9.6 make it run, install fdw to the new system, check the
environment. OK run. Keep it as it is!
-  What a very very bad timing! PG11 comes into the light. OK let´s
try with PG11. Install PG11, too. A system with PG11, 10.5, 9.6. Run
the statement (for bad luck, only out of functions). One time, two
times, ...tenth time. Yup works. Uninstall 9.6, uninstall
10.5, create foreign environment in the PG11, and start working again.
Call functions, one time ok, sixth time ERROR. Dup, dup, dup the head
over the wall. Grrr, why did I remove the previous versions and
system setup which worked fine??? That´s big mistake!!!. "ERROR:
unrecognized node type: 222" node!?!?!?!?!?!?!
- What a coincidence, I use microservices. Check the nodes! Is there
222 node? Check errors related to nodes. Does one is similar with what
I get? All seems good.
- Oh, man, I use pg-promise. Check if there is any error documented
which is similar with that I get. No, there is not.
- Oh, man, node.js itself!?!? Error may come from node.js. Check if
there is any error documented similar with what I get. N.
- In the meantime, check again error: [XX000] This is an internal
error, [HV004] This is a fdw related error. (I am not writing from my
laptop so the above line maybe not accurate. It is what I remember.)
Both errors are listed in PG document. But I shall try again, again,
and again!

So, in order this thread to get over:
- PG developers made a drastic change. Not problem at all, more then welcome.
- I was the "lucky guy" who had a painful experience. These things
happen as Adrian wrote, and life goes on.

What I would like to ask from developers is:

Please, if possible improve the error system!

Especially when there are internal changes which may affect
dynamically the outcome (from expected results to ERROR or whatever)
of a correct statement. For example, the error would include a
note/warning similar to "... after change of plan" or "... . Plan was
changed". Such a note/warning would have saved the whole situation and
I would have something in my hand to search and ask for help from the
very beginning.

As a simple end-user and not an IT folk, I have absolutely no word on
what and how things happen under the hood. But I expect the best
response, even if an error has appeared, which will safely enlighten
me at the shortest time. Your time is valuable, my time, too. So,
let´s respect our times and do the best to protect them against waste
in future.

Thanks and have a nice day and a wonderful week!


On 10/28/18, Christoph Moench-Tegeder  wrote:
> ## GPT (gptmailingli...@gmail.com):
>
>> Why this incident has been observed when the statement is only within
>> a function with variable as input parameter and not when they run
>> directly with explicitly defined parameter/ In the first case, plan
>> remains stable and does not change; but in the second case plan
>> changes.
>
> There you have it: that's exactly the plan caching behaviour described
> in the link I posted upthread. PL/pgSQL created a prepared statement
> on the first execution of a statement/expression inside a function,
> and, to quote that documentation:
>   If the statement has no parameters, or is executed many times, the
>   SPI manager will consider creating a generic plan that is not dependent
>   on specific parameter values[...]
>
>> Anyway, this is too technical for me and even if you respond most
>> probably I am not gonna get it.
>
> But perhaps the next person researching similar question will profit
> from the mailing list archives.
>
> Regards,
> Christoph
>
> --
> Spare Space.
>
>

Re: Portworx snapshots

[Ghislain ROUVIGNAC]

Stephen,


Our application don't write lot of data, so i don't think the time taken on
replaying the WAL will be an issue for us.


For reliability, as you said, i was thinking in running a large pgbench
which writes a lot of data, while taking snapshots.
Then my idea was to restart from snapshots and see if everything works as
expected.
I thought that based on the feedback from the community, maybe i wouldn't
need to run these tests.


Thank you.

Cordialement,

*Ghislain Rouvignac*


Email : g...@sylob.com

Bureau : + 33 (0)5 63 53 08 18


7, rue Marcel Dassault

ZA de la Mouline

81990 Cambon d’Albi

France


Le dim. 28 oct. 2018 à 16:35, Stephen Frost  a écrit :

> Greetings,
>
> * Ghislain ROUVIGNAC (g...@sylob.com) wrote:
> > Portworx says that on a running PostgreSQL it can:
> >
> >- replicate volumes for failover
> >- take snapshots of volumes
> >- backup volumes
>
> The downside with any snapshot-style approach is that it means that when
> you have a failure, you have to go through and replay all the WAL since
> the last checkpoint, which is single-threaded and can take a large
> amount of time.
>
> This is why PostgreSQL has streaming replication, where we are
> constantly sending WAL to the replica and replaying it immediately, and
> that also allows us to have synchronous replication that is quorum based
> and works with PostgreSQL, unlike what a snapshot level system would
> provide.
>
> When doing your testing, I'd strongly recommend that you have a large
> max_wal_size, run a large pgbench which writes a lot of data, and see
> how long a failover takes with this system.
>
> > Does someone use them in production ?
> > How reliable are these features ?
> > Are there performance impacts of snapshots ?
>
> I don't know anything about the actual utilization of this in production
> or if this implementation is reliable, just to be clear.  My comments
> specifically are about the performance of using a snapshot-based
> approach (which could be this solution or various other ones).
>
> Thanks!
>
> Stephen
>

-- 
Notice de confidentialité : Les informations contenues dans ce courriel 
sont strictement confidentielles et réservées à l'usage de la ou des 
personne(s) identifiée(s) comme destinataire(s). L'usage, la publication, 
la copie, la divulgation ou la transmission des informations contenues dans 
ce message ou les documents qui y sont attachés est interdit à moins d'y 
avoir été expressément autorisé par l'émetteur. Si vous avez reçu ce 
message par erreur, merci de le supprimer et d'en avertir immédiatement son 
expéditeur.

Re: Portworx snapshots

[Laurenz Albe]

Stephen Frost wrote:
> The downside with any snapshot-style approach is that it means that when
> you have a failure, you have to go through and replay all the WAL since
> the last checkpoint, which is single-threaded and can take a large
> amount of time.
> 
> When doing your testing, I'd strongly recommend that you have a large
> max_wal_size, run a large pgbench which writes a lot of data, and see
> how long a failover takes with this system.

Then "checkpoint_timeout" should also be large, right?

Yours,
Laurenz Albe
-- 
Cybertec | https://www.cybertec-postgresql.com