finitely sooner or later get this Fatal
on recovery .
With this patch we try to get rid of AccessEclusiveLock applied on standby
while we have active statement on it.
--
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-h
Greetings pgsql-hackers,
I have completed the general infrastructure for parallel COPY FROM execution,
consisting of Main (master) process and multiple BGWorkers connected with master
using a personal message query (shm_mq).
Master process does:
- Dynamic shared memory allocation with parallel st
On Fri, Jun 30, 2017 at 3:35 PM, Pavel Stehule wrote:
>
>
> 2017-06-30 14:23 GMT+02:00 Alex K :
>>
>> Thus, it results in a ~60% performance boost per each x2 multiplication of
>> parallel processes, which is consistent with the initial estimation.
>>
>
> t
Greetings pgsql-hackers,
I am a GSOC student this year, my initial proposal has been discussed
in the following thread
https://www.postgresql.org/message-id/flat/7179F2FD-49CE-4093-AE14-1B26C5DFB0DA%40gmail.com
Patch with COPY FROM errors handling seems to be quite finished, so
I have started thi
m it.>
> When recovery_conf is there, starting of a replica could become a real
> problem, especially if restore_command is slow.>
> Is it possible to change this behavior somehow? First look into
> pg_xlog and only if file is missing or "corrupted" call
> restore_command.>
>
> Regards,
> ---
> Alexander Kukushkin
Sincerely,
Alex
Hi pgsql-hackers,
Thank you again for all these replies. I have started working under this
project
and learnt a lot of new stuff last month, so here are some new thoughts
about
ERRORS handling in COPY. I decided to stick to the same thread, since it
has a neutral subject.
(1) One of my mentors--A
Hi Alexander!
I've missed your reply, since proposal submission deadline have passed last
Monday and I didn't check hackers mailing list too frequently.
(1) It seems that starting new subtransaction at step 4 is not necessary.
We can just gather all error lines in one pass and at the end of input
On Wed, Dec 7, 2016 at 3:42 PM, Tom Lane wrote:
>
>
> Hmm ... after further experimentation, I still can't get this version of
> systemd (231) to do anything evil. It turns out that Fedora ships it with
> KillUserProcesses turned off by default, and maybe having that on is a
> prerequisite for t
On Wed, Dec 7, 2016 at 1:12 PM, Tom Lane wrote:
> But this is all kind of moot if Peter is right that systemd will zap
> POSIX shmem along with SysV semaphores. I've been trying to reproduce
> the issue on a Fedora 25 installation, and so far I can't get it to
> zap anything, so I'm a bit at a
On 18.09.2016 06:54, Amit Kapila wrote:
On Fri, Sep 16, 2016 at 8:48 PM, Alex Ignatov wrote:
On 16.09.2016 16:50, Amit Kapila wrote:
Can you try by setting force_parallel_mode = off;? I think it is
sending the whole function execution to worker due to
force_parallel_mode.
No changes
On 16.09.2016 16:50, Amit Kapila wrote:
On Fri, Sep 16, 2016 at 6:57 PM, Alex Ignatov wrote:
No it doesn't.
Paralleling neither sql function nor plpgsql:
Here is example :
ipdr=> show max_worker_processes ;
max_worker_processes
--
128
(1 row)
ip
gregate (cost=288697.59..288847.74 rows=15015 width=28)
Group Key: test.a, test.b, test.c, test.d, test.e
-> Seq Scan on test (cost=0.00..163696.15 rows=1115
width=20)
So as we can see parallel secscan doesn't works in plpgsql and sql functions.
Can somebody explains m
Hello!
Does parallel secscan works in plpgsql?
--
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
suck
performance out particularly for rotating disks.
Rotating disks is not a problem - you can always raid them and etc. 8k
allocation per relation once per half an hour that is the problem. Seq
scan is this way = random scan...
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
amount of WAL
(less indices will need be updated). Of course it will make index scan
a bit worse, however it looks like at least Uber is fine with that
extra cost of index scan.
Does it make sense to implement that kind of index as an access method?
Vladimir
You mean IOT like Oracle have
On 29.06.2016 15:30, David G. Johnston wrote:
More specifically...
On Wed, Jun 29, 2016 at 7:34 AM, Michael Paquier
mailto:michael.paqu...@gmail.com>>wrote:
On Wed, Jun 29, 2016 at 7:43 PM, Alex Ignatov
mailto:a.igna...@postgrespro.ru>> wrote:
> Hello!
&
on at every row where its value is needed."
Something wrong with executor? Is it bug or executor feature related
with subquery?
--
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 20.06.2016 17:09, Albe Laurenz wrote:
Tom Lane wrote:
I don't necessarily have an opinion yet. I would like to see more than
just an unsupported assertion about what Oracle's behavior
--
12
(1 row)
On the our side we have some discussions about to write a patch that
will change this incorrect behavior. So stay tuned.
--
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On 23.06.2016 19:37, David G. Johnston wrote:
On Thu, Jun 23, 2016 at 12:16 PM, Alex Ignatov
mailto:a.igna...@postgrespro.ru>>wrote:
On 23.06.2016 16:30, Bruce Momjian wrote:
On Thu, Jun 23, 2016 at 07:41:26AM +, amul sul wrote:
On Monday, 20 June 2016 8
On 23.06.2016 16:30, Bruce Momjian wrote:
On Thu, Jun 23, 2016 at 07:41:26AM +, amul sul wrote:
On Monday, 20 June 2016 8:53 PM, Alex Ignatov wrote:
On 13.06.2016 18:52, amul sul wrote:
And it wont stop on some simple whitespace. By using to_timestamp you
can get any output results by
eters values:
postgres=# SELECT TO_TIMESTAMP('2016-06-13 99:99:99', 'YYYYMMDD
HH24:MI:SS');
to_timestamp
2016-01-06 14:40:39+03
(1 row)
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent
providing illegal input parameters we have no
any exceptions or errors about that.
I think that to_timestamp() need to has more format checking than it has
now.
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsq
ase consistency violation.
Can anybody explain this situation with clogs?
--
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
review as a bug fix.
Regards,
Hi!
Do we have any confidence that data file is not being corrupted? I.e
contains some corrupted page? Can pg_basebackup check page checksum (db
init with initdb -k) while backing up files?
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russ
On 05.05.2016 7:16, Amit Kapila wrote:
On Wed, May 4, 2016 at 8:03 PM, Tom Lane mailto:t...@sss.pgh.pa.us>> wrote:
>
> Amit Kapila mailto:amit.kapil...@gmail.com>> writes:
> > On Wed, May 4, 2016 at 4:02 PM, Alex Ignatov
mailto:a.igna...@postgrespro.ru>>
>
On 06.05.2016 0:42, Greg Stark wrote:
On 5 May 2016 12:32 am, "Tom Lane" mailto:t...@sss.pgh.pa.us>> wrote:
>
> To repeat, I'm pretty hesitant to change this logic. While this is not
> the first report we've ever heard of loss of pg_control, I believe I
could
> count those reports without r
On 03.05.2016 2:17, Tom Lane wrote:
Alex Ignatov writes:
I think that rename can help a little bit. At least on some FS it is
atomic operation.
Writing a single sector ought to be atomic too. I'm very skeptical that
it'll be an improvement to just move the risk from one
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 03.05.2016 2:21, Andres Freund wrote:
Hi,
On 2016-04-28 21:58:00 +, Alex Ignatov wrote:
We have some issue with truncated pg_control file on Windows after
power failure.My questions is : 1
On 01.05.2016 0:55, Bruce Momjian wrote:
On Thu, Apr 28, 2016 at 09:58:00PM +, Alex Ignatov wrote:
Hello everyone!
We have some issue with truncated pg_control file on Windows after power
failure.
My questions is :
1) Is pg_control protected from say , power crash or partial write?
2) How
y by using pg_resetxlog and setting it
parameters to values taken from wal file (pg_xlogdump)we can at least start PG
and saw that PG state is at the moment of last check point. But we have no real
confidence that PG is in consistent state(also docs on pg_resetxlogs told us
about it too)
Alex Ignat
On Mon, Apr 4, 2016 at 1:06 AM, Tom Lane wrote:
> Alex Shulgin writes:
> > On Sun, Apr 3, 2016 at 10:53 PM, Tom Lane wrote:
> >> The reason for checking toowide_cnt is that if it's greater than zero,
> >> then in fact the track list does NOT include all val
On Sun, Apr 3, 2016 at 10:53 PM, Tom Lane wrote:
> Alex Shulgin writes:
> > This recalled observation can now also explain to me why in the
> regression
> > you've seen, the short path was not followed: my bet is that stadistinct
> > appeared negative.
>
> Ye
On Sun, Apr 3, 2016 at 8:24 AM, Alex Shulgin wrote:
>
> On Sun, Apr 3, 2016 at 7:49 AM, Tom Lane wrote:
>>
>> Alex Shulgin writes:
>> > On Sun, Apr 3, 2016 at 7:18 AM, Tom Lane wrote:
>> >> Well, we have to do *something* with the last (possibly only) va
On Sun, Apr 3, 2016, 18:40 Tom Lane wrote:
> Alex Shulgin writes:
>
> > Well, if it's the only value it will be accepted simply because we are
> > checking that special case already and don't even bother to loop through
> > the track list.
>
> That was
On Sun, Apr 3, 2016, 18:32 Tom Lane wrote:
> Peter Geoghegan writes:
> > On Thu, Feb 11, 2016 at 9:50 AM, Robert Haas
> wrote:
> >> Wow, that's a fabulous idea. I see Oleksandr has tried to implement
> >> it, although I haven't looked at the patch. But I think this would be
> >> REALLY helpfu
On Sun, Apr 3, 2016 at 7:49 AM, Tom Lane wrote:
> Alex Shulgin writes:
> > On Sun, Apr 3, 2016 at 7:18 AM, Tom Lane wrote:
> >> Well, we have to do *something* with the last (possibly only) value.
> >> Neither "include always" nor "omit always"
On Sun, Apr 3, 2016 at 7:18 AM, Tom Lane wrote:
> Alex Shulgin writes:
> > On Sun, Apr 3, 2016 at 3:43 AM, Alex Shulgin
> wrote:
> >> I'm not sure yet about the 1% rule for the last value, but would also
> love
> >> to see if we can avoid the arbitrary l
On Sun, Apr 3, 2016 at 3:43 AM, Alex Shulgin wrote:
>
> I'm not sure yet about the 1% rule for the last value, but would also love
> to see if we can avoid the arbitrary limit here. What happens with a last
> value which is less than 1% popular in the current code anyway?
&g
nts?
>
Ah, neat, that's even better. :-)
What about regression tests? My assumption was that we won't be able to
add them with the usual expected file approach, but that we also don't need
it that hard. Everyone's in favor?
--
Alex
ng on the presence
of an order operator for the type, the resulting MCV lists after the
ANALYZE would be different (I mean not only due to the random nature of the
sample).
I'm not sure yet about the 1% rule for the last value, but would also love
to see if we can avoid the arbitrary limit here. What happens with a last
value which is less than 1% popular in the current code anyway?
Cheers!
--
Alex
, disallows
leading zero, empty string, or non-digit chars. Error messages looks good.
Marking this Ready for Committer.
--
Alex
The new status of this patch is: Ready for Committer
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On Mon, Mar 7, 2016 at 11:32 PM, Andres Freund wrote:
> Hi,
>
> Per the new valgrind animal we get:
>
>
> http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=skink&dt=2016-03-08%2004%3A22%3A00
> 2016-03-08 05:56:05.566 UTC [56de6971.723:5] LOG: statement: select
> plperl_sum_array('{}');
> ==1827== In
tead of drop support of it
entirely?
--
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Sat, Jun 6, 2015 at 7:03 PM, Peter Eisentraut wrote:
> With the recently released Perl 5.22.0, the tests fail thus:
>
> -ERROR: Global symbol "$global" requires explicit package name at line 3.
> -Global symbol "$other_global" requires explicit package name at line 4.
> +ERROR: Global symbol
On Tue, Mar 10, 2015 at 10:11 AM, Tom Lane wrote:
> I wrote:
>
> This thread seems to have died off without any clear resolution. I'd
> hoped somebody would try the patch on some nontrivial application to
> see if it broke anything or caused any warnings, but it doesn't seem
> like that is happe
..
vmstat
zoneinfo
postgres=#
Limited performance testing shows no significant difference between
error-catching and plain code path. For example, timing
copy test_copy1 from program 'seq 100' [exceptions to stdout]
shows similar numbers with or without the added "exceptions to&
Alex Shulgin writes:
> Petr Jelinek writes:
>>
>> I had a quick look, the patch does not apply cleanly anymore but it's
>> just release notes so nothing too bad.
>
> Yes, there were some ongoing changes that touched some parts of this and
> I must have mi
that you then call
> StartupXLOG() as StartupXLOG() is crazy long already so I think it's
> preferable to not make it worse.
We can move it at top of CheckStartingAsStandby() obviously.
> - I wonder if we should rename trigger_file to standby_tigger_file
I was also suggesting that, jus
Craig Ringer writes:
> On 12/19/2014 11:41 PM, Alex Shulgin wrote:
>> I don't think so. The scenario this patch relies on assumes that the
>> DBA will remember to look in the log if something goes wrong
>
> Well, actually, the whole point was that the user who'
Steve Singer writes:
> On 12/15/2014 11:38 AM, Alex Shulgin wrote:
>
>> These are all valid concerns IMHO. Attached is the modified version
>> of the original patch by Craig, addressing the handling of the new
>> hint_log error data field and removing the client-side
Alvaro Herrera writes:
> Alex Shulgin wrote:
>
>> OK, I think I have now all bases covered, though the updated patch is
>> not that "pretty".
>>
>> The problem is that we don't know in advance if the (sub)transaction is
>> going to succeed o
need to
use the stats gathered prior to truncate. Thus the need to track
insert/update/deletes that happened before first truncate separately.
To the point of making a dedicated pgstat testing tool: let's have
another TODO item?
--
Alex
>From 0b3161191a3ddb999cd9d0da08e1b6088ce07a84 Mon Sep
Alvaro Herrera writes:
> Alex Shulgin wrote:
>
>> Alvaro Herrera writes:
>> >>
>> >> Another idea would be exposing pgstat_report_stat(true) at SQL level.
>> >> That would eleminate the need for explicit pg_sleep(>=0.5), but we'll
nce to verify correctness due to side-effects of
rollback (ins/upd/del counters are still updated), and the way stats are
affecting the dead tuples counter.
I'll try to see if the checks can be converged though.
--
Alex
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
T
l have a test failure and won't have any
> indication why.
Oh, good catch. Since I've copied this function from stats.sql, we
might want to update that one too in a separate commit.
> I've attached a patch that adds logging on timeout and contains a test
> case that demons
patch by Craig,
addressing the handling of the new hint_log error data field and
removing the client-side HINT.
I'm also moving this to the current CF.
--
Alex
>From 702e0ac31f3d8023ad8c064d90bdf5a8441fddea Mon Sep 17 00:00:00 2001
From: Craig Ringer
Date: Fri, 17 Oct 2014 11:18:18
feedback because of a lack of activity in
> the last couple of weeks. Feel free to update if you think that's not
> correct, and please move this patch to commit fest 2014-12.
Attached is a new version that addresses the earlier feedback: renamed
the added
Alex Shulgin writes:
> Alex Shulgin writes:
>>
>> Here's an attempt to revive this patch.
>
> Here's the patch rebased against current HEAD, that is including the
> recently committed action_at_recovery_target option.
>
> The default for
port->peer)
+ strlcpy(ptr,
X509_NAME_to_cstring(X509_get_subject_name(port->peer)), NAMEDATALEN);
The NAMEDATALEN constant is passed in the calling code in
pgstat_bestart().
Other than that, looks good to me.
--
Alex
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
; they exist; see check_for_prepared_transactions().
Alright, that's good to know. So I'm just adding a new bool field to
the 2PC pgstat record instead of the bit magic.
Attached is v0.2, now with a regression test included.
--
Alex
>From 4c8fae27ecd9c94e7c3da0997f03099045a152d9
Alex Shulgin writes:
>
> Bruce Momjian writes:
>>
>> Added to TODO:
>>
>> o Clear table counters on TRUNCATE
>>
>> http://archives.postgresql.org/pgsql-hackers/2008-04/msg00169.php
>
> Hello,
>
> Attached is a WIP patch
17 00:00:00 2001
From: Alex Shulgin
Date: Tue, 9 Dec 2014 16:35:14 +0300
Subject: [PATCH] WIP: track TRUNCATEs in pgstat transaction stats.
The n_live_tup and n_dead_tup counters need to be set to 0 after a
TRUNCATE on the relation. We can't issue a special message to the stats
collector becau
Alvaro Herrera writes:
> Alex Shulgin wrote:
>
>> DEBUG: inserting column 7 value "varchar_transform"
>>
>> Breakpoint 1, GetSnapshotData (snapshot=0xdb2d60 )
>> at /home/ash/src/postgresql/src/backend/storage/ipc/procarray.c:1413
&
Alvaro Herrera writes:
> Alex Shulgin wrote:
>
>> DEBUG: inserting column 7 value "varchar_transform"
>>
>> Breakpoint 1, GetSnapshotData (snapshot=0xdb2d60 )
>> at /home/ash/src/postgresql/src/backend/storage/ipc/procarray.c:1413
&
Alex Shulgin writes:
>
> Figured it out with a pg_usleep in bootstrap.c anyway. Does this look sane?
>
>
> DEBUG: inserting column 6 value "0"
> DEBUG: inserted -> 0
> DEBUG: inserting column 7 value "varchar_transform"
> TRAP: FailedAsser
Craig Ringer writes:
> On 12/04/2014 10:50 PM, Alex Shulgin wrote:
>> Is there a way to pause the bootstrap process so I can attach gdb to it?
>
> With a newer gdb, you can instead tell gdb to follow all forks. I wrote
> some notes on it recently.
>
> http://blog.2
Alvaro Herrera writes:
>
> Uh, that's odd. Can you please get a stack trace? Do you have unusual
> settings or a patched build?
Is there a way to pause the bootstrap process so I can attach gdb to it?
--
Alex
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
Alvaro Herrera writes:
> Alex Shulgin wrote:
>
>> Also this commit breaks initdb of `make check' for me:
>>
>> creating template1 database in
>> /home/ash/build/postgresql/HEAD/src/test/regress/./tmp_check/data/base/1
>> ... TRAP: FailedAssertion(&quo
ipc/procarray.c", Line: 1414)
Aborted (core dumped)
child process exited with exit code 134
--
Alex
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andres Freund writes:
> On 2014-12-02 17:25:14 +0300, Alex Shulgin wrote:
>> I'd be in favor of a solution that works the same way as before the
>> patch, without the need for extra trigger files, etc., but that doesn't
>> seem to be nearly possible. Whatever tri
Michael Paquier writes:
> On Tue, Dec 2, 2014 at 1:58 AM, Alex Shulgin wrote:
>> Here's the patch rebased against current HEAD, that is including the
>> recently committed action_at_recovery_target option.
> If this patch gets in, it gives a good argument to jump to 1
Alex Shulgin writes:
>
> Here's an attempt to revive this patch.
Here's the patch rebased against current HEAD, that is including the
recently committed action_at_recovery_target option.
The default for the new GUC is 'pause', as in HEAD, and
pause_at_recovery_targe
rty, but wouldn't
>
> recovery_target_action = ...
>
> have been a better name for this? It'd be in line with the other
> recovery_target_* parameters, and also a bit shorter than the imho
> somewhat ugly "action_at_recovery_target".
FWIW, I too think that "recov
rsion, but I notice we've
added mat. views since then, so it looks like we now also need this:
ALTER MATERIALIZED VIEW SET [VIEW | TOAST] TABLESPACE
Should I add this patch to the next CommitFest?
--
Alex
set_toast_tablespace_v0.11.patch.gz
Description: application/gzip
--
Sent via
Dag-Erling Smørgrav writes:
> Alex Shulgin writes:
>> OK, looks like I've come up with something workable: I've added
>> sslprotocol connection string keyword similar to pre-existing
>> sslcompression, etc. Please see attached v2 of the original patch.
>>
Alex Shulgin writes:
>>>
>>> I can do that too, just need a hint where to look at in libpq/psql to
>>> add the option.
>>
>> The place to *enforce* the option is src/interfaces/libpq/fe-secure.c
>> (look for SSLv23_method() and SSL_CTX_set_option
Andrew Gierth writes:
>>>>>> "Alex" == Alex Shulgin writes:
>
> > Tom Lane writes:
> >> Must've been my evil twin.
>
> Alex> Sorry, I must be under false impression that RhodiumToad is
> Alex> *your* nick on #postgresql
Tom Lane writes:
> Stephen Frost writes:
>> * Alex Shulgin (a...@commandprompt.com) wrote:
>>> Tom,
>>>
>>> First of all, thanks for your help on IRC last time with that CREATE
>>> INDEX memory consumption problem.
>
>> Doubt it was Tom,
o wait before 9.4 is released?
Thanks.
--
Alex
[1]
http://dba.stackexchange.com/questions/83600/postgresql-create-index-memory-requirement
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
changes. It's necessary to
> say "connection string or URI" everywhere, the URI format is just one
> kind of a connection string. I also edited the code that builds the
> keyword/value array, to make it a bit more readable.
Yay, many thanks! :-)
--
Alex
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t different.
Great. Are you looking at the actual replication URI patch? Or should
I add it to commitfest so we don't lose track of it?
--
Alex
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Heikki Linnakangas writes:
> On 11/24/2014 06:05 PM, Alex Shulgin wrote:
>> The first patch is not on topic, I just spotted this missing check.
>
>> *** a/src/interfaces/libpq/fe-connect.c
>> --- b/src/interfaces/libpq/fe-connect.c
>> *** conninfo
Alex Shulgin writes:
> Heikki Linnakangas writes:
>>>
>>> It appears that replication connection doesn't support URI but only the
>>> traditional conninfo string.
>>>
>>> src/backend/replication/libpqwalreceiver/libpqwalreceiver.c:
; OK, and that's required for replication too? I'm OK with that if it
> gets the patch in.
In the current form of the patch, yes. Thought I don't think I like it.
--
Alex
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
argue that it's not
> required for PITR either, provided that we can use the auto.conf method.
>
> Before I go into my ideas, though, what does the current patch do
> regarding non-replication PITR?
It removes that $PGDATA/standby.enable trigger file it relies on to
start the P
ut if instead of removing the
trigger file upon successful recovery the server would set
standby_mode=off, that would also work.
--
Alex
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I just spotted this missing check.
The second one is a self-contained fix, but the third one which is the
actual patch depends on the second one, because it specifies the dbname
keyword two times: first to parse the conninfo/URI, then to override any
dbname provided by the user with "replicatio
eplication replication=true
fallback_application_name=walreceiver",
conninfo);
A patch to fix this welcome?
--
Alex
PS: I wrote the original URI parser used in libpq.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
has a number of advantages as a method,
> the main one being that recovery.conf is unlikely to be overwritten by
> the contents of the backup.
>
> HOWEVER, there's a clear out for this with conf.d. If we enable conf.d
> by default, then we can simply put recovery settings in conf.d, and
> since that specific file (which can have whatever name the user chooses)
> will not be part of backups, it would have the same advantage as
> recovery.conf, without the drawbacks.
>
> Discuss?
Well, I don't readily see how conf.d is special with regard to base
backup, wouldn't you need to exclude it explicitly still?
--
Alex
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Alex Shulgin writes:
>
>>> > * Why do you include xlog_internal.h in guc.c and not xlog.h?
>>
>>> we actually need both but including xlog_internal.h also includes xlog.h
>>> i added xlog.h and if someone things is enough only putting
>>> xlog_i
GET_XID;
>> +else if (recovery_target_name[0])
>> +recovery_target = RECOVERY_TARGET_NAME;
>> +else if (recovery_target_time != 0)
>> +recovery_target = RECOVERY_TARGET_TIME;
>> +else
>> +recovery_target = RECOVERY_TAR
Dag-Erling Smørgrav writes:
> Alex Shulgin writes:
>> I can do that too, just need a hint where to look at in libpq/psql to
>> add the option.
>
> The place to *enforce* the option is src/interfaces/libpq/fe-secure.c
> (look for SSLv23_method() and SSL_CTX_set_optio
mitFest entry is the latest
on the subject, right?
https://commitfest.postgresql.org/action/patch_view?id=1293
Should/may I move it to the next Open fest?
--
Alex
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Dag-Erling Smørgrav writes:
> Alex Shulgin writes:
>> * The patch works as advertised, though the only way to verify that
>> connections made with the protocol disabled by the GUC are indeed
>> rejected is to edit fe-secure-openssl.c to only allow specific TLS
&
rectly.
I would try to apply patches for older branches if there is consensus
that we really need this patch and we want to back-patch it.
Thanks.
--
Alex
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
read from it
and no attempt is made to verify this on startup. This might be not a
very useful check since if the file is not missing, but corrupted the
check doesn't buy you much. (I am likely kicking a dead horse here.)
Thank you.
--
Alex
[1] http://svana.org/kleptog/pgsql/pgfsck.html
--
the client when in
ProcessInterrupts() and DoingCommandRead is true. I think[1] it was
expected to be delivered instantly, but actually the client (psql) only
displays it after sending the next statement.
While I'm reading on FE/BE protocol someone might want to share his
wisdom on this subject.
Andres Freund writes:
> On 2014-11-15 00:11:36 +0300, Alex Shulgin wrote:
>> After reading up through archives on the two $subj related TODO items
>> I'm under impression that the patches[1,2] didn't make it mainly because
>> of the risk of breaking SSL interna
Andres Freund writes:
>
> On 2014-11-15 00:11:36 +0300, Alex Shulgin wrote:
>> After reading up through archives on the two $subj related TODO items
>> I'm under impression that the patches[1,2] didn't make it mainly because
>> of the risk of breaking SSL inte
1 - 100 of 654 matches
Mail list logo
