Re: [HACKERS] WIP: long transactions on hot standby feedback replica / proof of concept

essExclusive reached standby and max_standby_streaming_delay > -1 you definitely 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://

Re: [HACKERS] Parallel COPY FROM execution

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

Re: [HACKERS] Parallel COPY FROM execution

On Fri, Jun 30, 2017 at 3:35 PM, Pavel Stehule <pavel.steh...@gmail.com> wrote: > > > 2017-06-30 14:23 GMT+02:00 Alex K <kondratov.alek...@gmail.com>: >> >> Thus, it results in a ~60% performance boost per each x2 multiplication of >> parallel processe

[HACKERS] Parallel COPY FROM execution

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

Re: [HACKERS] Why restore_command is called for existing files in pg_xlog?

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

Re: [HACKERS] GSOC'17 project introduction: Parallel COPY execution with errors handling

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

Re: [HACKERS] GSOC'17 project introduction: Parallel COPY execution with errors handling

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

Re: [HACKERS] Back-patch use of unnamed POSIX semaphores for Linux?

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

Re: [HACKERS] Back-patch use of unnamed POSIX semaphores for Linux?

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

Re: [HACKERS] Parallel sec scan in plpgsql

On 18.09.2016 06:54, Amit Kapila wrote: On Fri, Sep 16, 2016 at 8:48 PM, Alex Ignatov <a.igna...@postgrespro.ru> 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 work

Re: [HACKERS] Parallel sec scan in plpgsql

On 16.09.2016 16:50, Amit Kapila wrote: On Fri, Sep 16, 2016 at 6:57 PM, Alex Ignatov <a.igna...@postgrespro.ru> wrote: No it doesn't. Paralleling neither sql function nor plpgsql: Here is example : ipdr=> show max_worker_processes ; max_worker_processes -- 1

Re: [HACKERS] Parallel sec scan in plpgsql

te (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 me where I

[HACKERS] Parallel sec scan in plpgsql

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

Re: [HACKERS] Block level parallel vacuum WIP

ential scan that this would 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

Re: [HACKERS] Why we lost Uber as a user

s 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? Alex Ignatov Postgres Profes

Re: [HACKERS] Strange behavior of some volatile function like random(), nextval()

On 29.06.2016 15:30, David G. Johnston wrote: More specifically... On Wed, Jun 29, 2016 at 7:34 AM, Michael Paquier <michael.paqu...@gmail.com <mailto:michael.paqu...@gmail.com>>wrote: On Wed, Jun 29, 2016 at 7:43 PM, Alex Ignatov <a.igna...@postgrespro.ru

[HACKERS] Strange behavior of some volatile function like random(), nextval()

e 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

Re: [HACKERS] Bug in to_timestamp().

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 is. Also

Re: [HACKERS] Bug in to_timestamp().

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@postgresq

Re: [HACKERS] Bug in to_timestamp().

On 23.06.2016 19:37, David G. Johnston wrote: On Thu, Jun 23, 2016 at 12:16 PM, Alex Ignatov <a.igna...@postgrespro.ru <mailto:a.igna...@postgrespro.ru>>wrote: On 23.06.2016 16:30, Bruce Momjian wrote: On Thu, Jun 23, 2016 at 07:41:26AM +, am

Re: [HACKERS] Bug in to_timestamp().

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 <a.igna...@postgrespro.ru> wrote: On 13.06.2016 18:52, amul sul wrote: And it wont stop on some simple whitespace. By using to_timestamp y

Re: [HACKERS] Bug in to_timestamp().

99', 'MMDD 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 via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to you

Re: [HACKERS] Bug in to_timestamp().

rameters 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 (pgsql-hackers@postgresql.org

[HACKERS] Why we don't have checksums on clog files

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.postgresql.org

Re: [HACKERS] pg_basebackup, pg_receivexlog and data durability (was: silent data loss with ext4 / all current versions)

. 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 Russian Postgres Company

Re: [HACKERS] Is pg_control file crashsafe?

On 05.05.2016 7:16, Amit Kapila wrote: On Wed, May 4, 2016 at 8:03 PM, Tom Lane <t...@sss.pgh.pa.us <mailto:t...@sss.pgh.pa.us>> wrote: > > Amit Kapila <amit.kapil...@gmail.com <mailto:amit.kapil...@gmail.com>> writes: > > On Wed, May 4, 2

Re: [HACKERS] Is pg_control file crashsafe?

On 06.05.2016 0:42, Greg Stark wrote: On 5 May 2016 12:32 am, "Tom Lane" > 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

Re: [HACKERS] Is pg_control file crashsafe?

On 03.05.2016 2:17, Tom Lane wrote: Alex Ignatov <a.igna...@postgrespro.ru> 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 th

Re: [HACKERS] Is pg_control file crashsafe?

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

Re: [HACKERS] Is pg_control file crashsafe?

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

[HACKERS] Is pg_control file crashsafe?

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

Re: [HACKERS] More stable query plans via more predictable column statistics

On Mon, Apr 4, 2016 at 1:06 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Alex Shulgin <alex.shul...@gmail.com> writes: > > On Sun, Apr 3, 2016 at 10:53 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> The reason for checking toowide_cnt is that if it's greater th

Re: [HACKERS] More stable query plans via more predictable column statistics

On Sun, Apr 3, 2016 at 10:53 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Alex Shulgin <alex.shul...@gmail.com> 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 sta

Re: [HACKERS] More stable query plans via more predictable column statistics

On Sun, Apr 3, 2016 at 8:24 AM, Alex Shulgin <alex.shul...@gmail.com> wrote: > > On Sun, Apr 3, 2016 at 7:49 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> >> Alex Shulgin <alex.shul...@gmail.com> writes: >> > On Sun, Apr 3, 2016 at 7:18 AM, Tom Lane &l

Re: [HACKERS] More stable query plans via more predictable column statistics

On Sun, Apr 3, 2016, 18:40 Tom Lane <t...@sss.pgh.pa.us> wrote: > Alex Shulgin <alex.shul...@gmail.com> 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 l

Re: [HACKERS] Add schema-qualified relnames in constraint error messages.

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

Re: [HACKERS] More stable query plans via more predictable column statistics

On Sun, Apr 3, 2016 at 7:49 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Alex Shulgin <alex.shul...@gmail.com> writes: > > On Sun, Apr 3, 2016 at 7:18 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> Well, we have to do *something* with the last (possibly only) valu

Re: [HACKERS] More stable query plans via more predictable column statistics

On Sun, Apr 3, 2016 at 7:18 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Alex Shulgin <alex.shul...@gmail.com> writes: > > On Sun, Apr 3, 2016 at 3:43 AM, Alex Shulgin <alex.shul...@gmail.com> > wrote: > >> I'm not sure yet about the 1% rule for the last v

Re: [HACKERS] More stable query plans via more predictable column statistics

On Sun, Apr 3, 2016 at 3:43 AM, Alex Shulgin <alex.shul...@gmail.com> 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 c

Re: [HACKERS] Add schema-qualified relnames in constraint error messages.

ed at the psql part of your patch. > > Comments? > 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

Re: [HACKERS] More stable query plans via more predictable column statistics

rator 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

Re: [HACKERS] Sanity checking for ./configure options?

, 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

Re: [HACKERS] empty array case in plperl_ref_from_pg_array not handled correctly

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=2016-03-08%2004%3A22%3A00 > 2016-03-08 05:56:05.566 UTC [56de6971.723:5] LOG: statement: select >

Re: [HACKERS] Remove Windows crash dump support?

i right? May be we need to add this functionality instead of drop support of it entirely? -- Alex Ignatov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: [HACKERS] error message diff with Perl 5.22.0

On Sat, Jun 6, 2015 at 7:03 PM, Peter Eisentraut pete...@gmx.net 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

Re: [HACKERS] Precedence of standard comparison operators

On Tue, Mar 10, 2015 at 10:11 AM, Tom Lane t...@sss.pgh.pa.us 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

[HACKERS] POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)

comment about the need for subtransaction around every loaded line still holds. Any example of what would be not properly rolled back by just PG_TRY? Happy hacking! -- Alex From 50f7ab0a503a0d61776add8a138abf2622fc6c35 Mon Sep 17 00:00:00 2001 From: Alex Shulgin a...@commandprompt.com Date: Fri, 19

Re: [HACKERS] Turning recovery.conf into GUCs

Alex Shulgin a...@commandprompt.com writes: Petr Jelinek p...@2ndquadrant.com 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 missed

Re: [HACKERS] [PATCH] HINT: pg_hba.conf changed since last config reload

Steve Singer st...@ssinger.info 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 HINT. I'm also

Re: [HACKERS] [PATCH] HINT: pg_hba.conf changed since last config reload

Craig Ringer cr...@2ndquadrant.com 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's connecting

Re: [HACKERS] REVIEW: Track TRUNCATE via pgstat

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 17 00:00:00 2001 From: Alex Shulgin a...@commandprompt.com Date: Tue, 9 Dec

Re: [HACKERS] REVIEW: Track TRUNCATE via pgstat

Alvaro Herrera alvhe...@2ndquadrant.com 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 or abort, and in case of aborted truncate we

Re: [HACKERS] REVIEW: Track TRUNCATE via pgstat

! -- Alex PS: re: your CF comment: I'm producing the patches using git format-patch --ext-diff where diff.external is set to '/bin/bash src/tools/git-external-diff'. Now that I try to apply it using git, looks like git doesn't like the copied context diff very much... From

Re: [HACKERS] REVIEW: Track TRUNCATE via pgstat

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) To make changes to your subscription: http

Re: [HACKERS] REVIEW: Track TRUNCATE via pgstat

Alvaro Herrera alvhe...@2ndquadrant.com writes: Alex Shulgin wrote: Alvaro Herrera alvhe...@2ndquadrant.com 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 still need the wait_for_

Re: [HACKERS] [PATCH] add ssl_protocols configuration option

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 *.[ch] files and removed incorrect copyright line. I'm moving this to the current CF. -- Alex From

Re: [HACKERS] [PATCH] HINT: pg_hba.conf changed since last config reload

. -- Alex From 702e0ac31f3d8023ad8c064d90bdf5a8441fddea Mon Sep 17 00:00:00 2001 From: Craig Ringer cr...@2ndquadrant.com Date: Fri, 17 Oct 2014 11:18:18 +0800 Subject: [PATCH 1/2] Add an errhint_log, akin to errdetail_log This allows a different HINT to be sent to the server error log

Re: [HACKERS] Turning recovery.conf into GUCs

Alex Shulgin a...@commandprompt.com writes: Alex Shulgin a...@commandprompt.com 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

Re: [HACKERS] SSL information view

)), 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

Re: [HACKERS] Small TRUNCATE glitch

to the 2PC pgstat record instead of the bit magic. Attached is v0.2, now with a regression test included. -- Alex From 4c8fae27ecd9c94e7c3da0997f03099045a152d9 Mon Sep 17 00:00:00 2001 From: Alex Shulgin a...@commandprompt.com Date: Tue, 9 Dec 2014 16:35:14 +0300 Subject: [PATCH] WIP: track TRUNCATEs

Re: [HACKERS] Small TRUNCATE glitch

From: Alex Shulgin a...@commandprompt.com 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

Re: [HACKERS] Small TRUNCATE glitch

Alex Shulgin a...@commandprompt.com writes: Bruce Momjian br...@momjian.us 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 for this TODO. This part went

Re: [HACKERS] [COMMITTERS] pgsql: Keep track of transaction commit timestamps

) 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

Re: [HACKERS] [COMMITTERS] pgsql: Keep track of transaction commit timestamps

Alvaro Herrera alvhe...@2ndquadrant.com 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(!(((xmax) = ((TransactionId) 3

Re: [HACKERS] [COMMITTERS] pgsql: Keep track of transaction commit timestamps

Alvaro Herrera alvhe...@2ndquadrant.com 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

Re: [HACKERS] [COMMITTERS] pgsql: Keep track of transaction commit timestamps

Craig Ringer cr...@2ndquadrant.com 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.2ndquadrant.com

Re: [HACKERS] [COMMITTERS] pgsql: Keep track of transaction commit timestamps

Alvaro Herrera alvhe...@2ndquadrant.com writes: Alex Shulgin wrote: DEBUG: inserting column 7 value varchar_transform Breakpoint 1, GetSnapshotData (snapshot=0xdb2d60 CatalogSnapshotData) at /home/ash/src/postgresql/src/backend/storage/ipc/procarray.c:1413 1413 xmax

Re: [HACKERS] [COMMITTERS] pgsql: Keep track of transaction commit timestamps

Alex Shulgin a...@commandprompt.com 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: FailedAssertion(!(((xmax) = ((TransactionId) 3))), File

Re: [HACKERS] [COMMITTERS] pgsql: Keep track of transaction commit timestamps

Alvaro Herrera alvhe...@2ndquadrant.com writes: Alex Shulgin wrote: DEBUG: inserting column 7 value varchar_transform Breakpoint 1, GetSnapshotData (snapshot=0xdb2d60 CatalogSnapshotData) at /home/ash/src/postgresql/src/backend/storage/ipc/procarray.c:1413 1413 xmax

Re: [HACKERS] Turning recovery.conf into GUCs

Michael Paquier michael.paqu...@gmail.com writes: On Tue, Dec 2, 2014 at 1:58 AM, Alex Shulgin a...@commandprompt.com 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

Re: [HACKERS] Turning recovery.conf into GUCs

Andres Freund and...@2ndquadrant.com 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 tricks we might

Re: [HACKERS] Turning recovery.conf into GUCs

Alex Shulgin a...@commandprompt.com 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_target

Re: [HACKERS] patch : Allow toast tables to be moved to a different tablespace

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 pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Add shutdown_at_recovery_target option to recovery.conf

= ... 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 recovery_target_action is a better name. -- Alex -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] [PATCH] add ssl_protocols configuration option

Dag-Erling Smørgrav d...@des.no writes: Alex Shulgin a...@commandprompt.com 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. I'm having

[HACKERS] Follow up to irc on CREATE INDEX vs. maintenance_work_mem on 9.3

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

Re: [HACKERS] Follow up to irc on CREATE INDEX vs. maintenance_work_mem on 9.3

Andrew Gierth and...@tao11.riddles.org.uk writes: Alex == Alex Shulgin a...@commandprompt.com writes: Tom Lane t...@sss.pgh.pa.us writes: Must've been my evil twin. Alex Sorry, I must be under false impression that RhodiumToad is Alex *your* nick on #postgresql at freenode. I don't

Re: [HACKERS] [PATCH] add ssl_protocols configuration option

Alex Shulgin a...@commandprompt.com 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_options()). I haven't looked into how to set

Re: Missing OOM checks in libpq (was Re: [HACKERS] Replication connection URI?)

Heikki Linnakangas hlinnakan...@vmware.com 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_array_parse(const char

Re: Missing OOM checks in libpq (was Re: [HACKERS] Replication connection URI?)

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

Re: [HACKERS] Replication connection URI?

. 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

Re: [HACKERS] Turning recovery.conf into GUCs

Alex Shulgin a...@commandprompt.com 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_internal.h let me know What's required from

Re: [HACKERS] Turning recovery.conf into GUCs

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

[HACKERS] Replication connection URI?

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.postgresql.org

Re: [HACKERS] Replication connection URI?

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 replication pseudo-database name. Have a nice day! -- Alex From 156e6faa96ad6a2ce58055ad72883ed78c576e5b Mon Sep 17 00:00:00 2001

Re: [HACKERS] Turning recovery.conf into GUCs

=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

Re: [HACKERS] Turning recovery.conf into GUCs

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 PITR in the first place. -- Alex -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] Turning recovery.conf into GUCs

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

Re: [HACKERS] Replication connection URI?

Alex Shulgin a...@commandprompt.com writes: Heikki Linnakangas hlinnakan...@vmware.com writes: It appears that replication connection doesn't support URI but only the traditional conninfo string. src/backend/replication/libpqwalreceiver/libpqwalreceiver.c:99: in libpqrcv_connect

Re: [HACKERS] [PATCH] add ssl_protocols configuration option

Dag-Erling Smørgrav d...@des.no writes: Alex Shulgin a...@commandprompt.com 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_options

Re: [HACKERS] Turning recovery.conf into GUCs

and complain if it's out of range, like this: LOG: starting point-in-time recovery to XID 4294967295 LOG: invalid primary checkpoint record LOG: invalid secondary checkpoint record Allowing negative values makes even less sense for timelines, IMO. -- Alex From

Re: [HACKERS] [PATCH] add ssl_protocols configuration option

Dag-Erling Smørgrav d...@des.no writes: Alex Shulgin a...@commandprompt.com 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

Re: [HACKERS] Merging recovery.conf into PostgreSQL.conf -- where did this go?

://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

Re: [HACKERS] [PATCH] add ssl_protocols configuration option

of different values and all seem to be parsed correctly. 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

Re: [HACKERS] Idle transaction cancel/timeout and SSL revisited

Andres Freund and...@2ndquadrant.com 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 internals if we try

Re: [HACKERS] Escaping from blocked send() reprised.

(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. My guess: psql blocks on readline/libedit call and can't effectively poll the server socket before complete input from user. -- Alex [1] http

[HACKERS] Idle transaction cancel/timeout and SSL revisited

IdleTransactionCancelPending and I'm not sure what would be the best way to let it see that (is it too much of a shortcut anyway?) -- Alex [1] http://www.postgresql.org/message-id/1262268211.19367.10736.camel@ebony [2] http://www.postgresql.org/message-id/538dc843.2070...@dalibo.com diff --git a/src

Re: [HACKERS] Idle transaction cancel/timeout and SSL revisited

Andres Freund and...@2ndquadrant.com 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 internals if we try

Re: [HACKERS] Trailing comma support in SELECT statements

SQL statements for various purposes, e.g. for dependency analysis. This is a misfeature for the benefit of edit-lazy users only. -- Alex

Re: [HACKERS] [BUGS] BUG #9223: plperlu result memory leak

On Wed, Mar 5, 2014 at 12:22 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Can I bug you into verifying what supported releases need this patch, and to which does it backpatch cleanly? And if there's any to which it doesn't, can I further bug you into providing one that does? Sure! Not

  1   2   3   4   5   6   7   >