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
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
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
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
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
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
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
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
On Sat, Apr 2, 2016 at 11:41 PM, Tom Lane wrote:
> "Shulgin, Oleksandr" writes:
> > On Mon, Mar 14, 2016 at 7:55 PM, Tom Lane wrote:
> >> Yeah, I don't much like that either. But I don't think we can avoid
> >> some
On Sat, Apr 2, 2016 at 8:57 PM, Shulgin, Oleksandr <
oleksandr.shul...@zalando.de> wrote:
> On Apr 2, 2016 18:38, "Tom Lane" wrote:
>
>> I did not like the fact that the compute_scalar_stats logic
>> would allow absolutely anything into the MCV list once num_hist falls
>>
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
Looks good to me. It only allows valid number between 1 and 65535,
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
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
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
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
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
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
cc51823a01a194ef6fcd90bc763fa26498837322 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 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
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_... call to make sure the collector has picked
it up.
We already have a stats
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_
18388300f9ed34fa47c66b8a2da098aeb19a7f71 Mon Sep 17 00:00:00 2001
From: Alex Shulgin a...@commandprompt.com
Date: Wed, 19 Nov 2014 19:49:29 +0300
Subject: [PATCH] DRAFT: ssl_protocols GUC
---
doc/src/sgml/config.sgml | 29 ++
doc/src/sgml/libpq.sgml | 25 ++
src/backend/libpq
Peter Eisentraut pete...@gmx.net writes:
On 10/16/14 11:34 PM, Craig Ringer wrote:
psql: FATAL: Peer authentication failed for user fred
HINT: See the server error log for additional information.
I think this is wrong for many reasons.
I have never seen an authentication system that
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
Magnus Hagander mag...@hagander.net writes:
You should add it to the next CF for proper tracking, there are already many
patches in the queue waiting for reviews :)
Absolutely - I just wanted those that were already involved in the
thread to get a chance to look at it early :) didn't want
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
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
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
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 12/03/2014 04:54 PM, Alvaro Herrera wrote:
ir commit timestamp directly as they commit,
or an external transaction c
Sorry, I'm late to the party, but here's some random comments on this
after a quick review:
Also this commit breaks
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
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
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
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
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
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
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
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
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
Julien Tachoires jul...@gmail.com writes:
2011/12/15 Alvaro Herrera alvhe...@commandprompt.com:
Uhm, surely you could compare the original toast tablespace to the heap
tablespace, and if they differ, handle appropriately when creating the
new toast table? =A0Just pass down the toast
Christoph Berg c...@df7cb.de writes:
Re: Petr Jelinek 2014-11-25 5474efea.2040...@2ndquadrant.com
Patch committed.
Before I go and rebase that recovery.conf - GUC patch on top of
this... is it final?
Thanks!
I'm a bit late to the party, but wouldn't
recovery_target_action = ...
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
Tom,
First of all, thanks for your help on IRC last time with that CREATE
INDEX memory consumption problem.
As has been pointed out in a stackexchange answer to my question[1], it
is indeed the limitation of pre-9.4 versions, but the limit is imposed
on memtuples array, rather than total memory
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
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
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
Heikki Linnakangas hlinnakan...@vmware.com writes:
I think we need to fix all of those, and backpatch. Per attached.
Yikes! Looks sane to me.
Ok thanks, committed. It didn't apply cleanly to 9.0, 9.1 and 9.2, so
the patch for those branches looks a bit different.
Great. Are you looking
Heikki Linnakangas hlinnakan...@vmware.com writes:
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
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
Josh Berkus j...@agliodbs.com writes:
Well, the latest version of this patch fails to start when it sees
'recovery.conf' in PGDATA:
FATAL: recovery.conf is not supported anymore as a recovery method
DETAIL: Refer to appropriate documentation about migration methods
I've missed
Hackers,
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():
snprintf(conninfo_repl, sizeof(conninfo_repl),
%s dbname=replication
From: Alex Shulgin a...@commandprompt.com
Date: Mon, 24 Nov 2014 16:55:50 +0300
Subject: [PATCH 1/3] Add missing check on OOM in expand_dbname path of
conninfo_array_parse().
---
src/interfaces/libpq/fe-connect.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/interfaces/libpq/fe
Jaime Casanova ja...@2ndquadrant.com writes:
Either way, from the code it is clear that we only stay in recovery if
standby_mode is directly turned on. This makes the whole check for a
specially named file unnecessary, IMO: we should just check the value of
standby_mode (which is off by
Josh Berkus j...@agliodbs.com writes:
only that you need to start in recovery mode to start replication
Right, but my point is that having a trigger file *is not necessary for
replication, only for PITR* -- and maybe not necessary even for PITR.
That is, in a streaming replication
Josh Berkus j...@agliodbs.com writes:
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.
OK, and that's required for replication too? I'm
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
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
de59408e524e3818a7cea98a7c1f049e09eb9f79 Mon Sep 17 00:00:00 2001
From: Alex Shulgin a...@commandprompt.com
Date: Fri, 21 Nov 2014 12:22:22 +0300
Subject: [PATCH] DRAFT: rebased recovery_guc_v5.2.patch
---
contrib/pg_archivecleanup/pg_archivecleanup.c | 2 +-
contrib/pg_standby/pg_standby.c | 2 +-
doc/src
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
Andres Freund and...@2ndquadrant.com writes:
On 2014-11-19 15:09:10 -0800, Josh Berkus wrote:
One patch that got deferred from 9.4 was the merger of recovery.conf and
postgresql.conf, due to conflicts with ALTER SYSTEM SET. However, this
is still a critical TODO, because recovery.conf is
Dag-Erling Smørgrav d...@des.no writes:
The attached patches add an ssl_protocols configuration option which
control which versions of SSL or TLS the server will use. The syntax is
similar to Apache's SSLProtocols directive, except that the list is
colon-separated instead of
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
Andres Freund and...@2ndquadrant.com writes:
I've invested some more time in this:
0002 now makes sense on its own and doesn't change anything around the
interrupt handling. Oh, and it compiles without 0003.
In this patch, the endif appears to be misplaced in PostgresMain:
+ if
Hello Hackers,
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 to longjump out of the
signal handler in the middle of a blocking SSL read and/or if we try
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
Dave Page dp...@pgadmin.org writes:
On Tue, Jun 19, 2012 at 4:43 AM, Robert Haas robertmh...@gmail.com wrote:
Please add this patch here so that it doesn't get lost in the shuffle:
https://commitfest.postgresql.org/action/commitfest_view/open
Hmm, that raises an interesting question
Dave Page dp...@pgadmin.org writes:
On Tue, Jun 19, 2012 at 11:04 AM, Alex Shulgin a...@commandprompt.com wrote:
In a real bug-tracking system we would create a new bug/ticket and set
it's target version to 'candidate for next minor release' or something
like that. This way, if we don't
Alex a...@commandprompt.com writes:
Peter Eisentraut pete...@gmx.net writes:
I have been reviewing how our new libpq URL syntax compares against
existing implementations of URL syntaxes in other drivers or
higher-level access libraries. In the case of SQLAlchemy, there is an
Robert Haas robertmh...@gmail.com writes:
On Tue, Apr 17, 2012 at 1:47 AM, Magnus Hagander mag...@hagander.net wrote:
That's probably one reason people aren't jumping on this. Because
there is no tracker out there that people actually *like*...
I think this is a point worth serious thought.
Jay Levitt jay.lev...@gmail.com writes:
(A quick Google shows redmine and especially Trac having spam issues
of their own.)
Ugh, redmine (or trac for that matters) has nothing to with handling
spam. I believe a typical bug tracker doesn't handle spam itself, it
lets the mailing system do
Jay Levitt jay.lev...@gmail.com writes:
No meaningful search, eh? Works for me.
Redmine searches return partial-word matches, and there's no way to
disable that. Searching for test finds latest. To me, that's
broken.
Well, I believe one can plug in a different search engine, like lucene
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 22.03.2012 23:42, Alex wrote:
Okay, at last here's v9, rebased against current master branch.
Some quick comments on this patch:
Heikki, thank you for taking a look at this!
I see a compiler warning:
fe-connect.c: In
Alex a...@commandprompt.com writes:
Marko Kreen mark...@gmail.com writes:
On Thu, Mar 15, 2012 at 11:29:31PM +0200, Alex wrote:
https://github.com/a1exsh/postgres/commits/uri
The point of the patch is to have one string with all connection options,
in standard format, yes? So why does not
Daniel Farina dan...@heroku.com writes:
I reviewed this and so far have not found any serious problems,
although as is par for the course it contains some of the fiddly bits
involved in any string manipulations in C. I made a few edits -- none
strictly necessary for correctness -- that the
Peter Eisentraut pete...@gmx.net writes:
I've included a (separate) test shell script based on Greg's cases in
one of the updates. What would be preferred place to plug it in?
Override installcheck in libpq Makefile?
I think that would be the right place.
I figured that adding this right
Greg Smith g...@2ndquadrant.com writes:
Thank you for the review, Greg!
Given that, there really isn't a useful path forward that helps out
all those developers without supporting both prefixes. That's where
this left off before, I just wanted to emphasize how clear that need
seems now.
Florian Weimer fwei...@bfk.de writes:
* Alex Shulgin:
Yeah, this is really appealing, however how do you tell if the part
after the last slash is a socket directory name or a dbname? E.g:
psql postgres:///path/to/different/socket/dir(default dbname)
psql postgres:///path
Harold Giménez harold.gime...@gmail.com writes:
I have interest in the URI connection string support patch[1], so I'm
in the process of reviewing it. I have a couple of comments and
questions:
Hello, thank you for your interest and the review!
1. I see no tests in the patch.
Hello,
This is my first patch review ever, so please bear with me.
The patch[1] is in the context diff format and applies cleanly to
current git HEAD. Documentation is updated by the patch.
The code does implement what's the patch is supposed to do.
Do we want that? According to Greg's
Greg Smith g...@2ndquadrant.com writes:
One unicorn I would like to have here would give the CF app a database
of recent e-mails to pgsql-hackers. I login to the CF app, click on
Add recent submission, and anything matching my e-mail address
appears with a checkbox next to it. Click on the
Nick Roosevelt nro...@gmail.com writes:
I am sorry, seems like my new MUA was misconfigured so the two previous
attempts to reply to -hackers@ failed. So here goes again.
Just reviewed the patch for adding URI connection string support for
libpg.
Thank you for taking your time on
Andrew Dunstan and...@dunslane.net writes:
On 01/19/2012 12:59 PM, Alex Shulgin wrote:
Another idea: introduce some simple tag system in mails sent to -hackers
to be treated specially, e.g:
@fest add-to-current
to add new patch to the commit fest currently in progress, or
@fest add
On Mon, Oct 3, 2011 at 00:05, Tom Lane t...@sss.pgh.pa.us wrote:
So at this point I'd vote for just dropping it and always allowing
custom (that is, qualified) GUC names to be set, whether the prefix
corresponds to any loaded module or not.
Comments, other proposals?
While working on E.164
81 matches
Mail list logo