On Mon, Jan 20, 2014 at 06:49:21PM -0300, Alvaro Herrera wrote:
> Marko Kreen escribió:
> > http://www.viva64.com/en/b/0227/ reported that on-stack memset()s
> > might be optimized away by compilers. Fix it.
>
> Just to clarify, this needs to be applied to all branches, righ
On Sat, Jan 25, 2014 at 12:25:30PM -0500, Tom Lane wrote:
> Alternatively, given that TLS has been around for a dozen years and
> openssl versions that old have not gotten security updates for a long
> time, why don't we just reject SSLv3 on the backend side too?
> I guess it's barely possible that
On Thu, Dec 12, 2013 at 04:32:07PM +0200, Marko Kreen wrote:
> Attached patch changes default ciphersuite to HIGH:MEDIUM:+3DES:!aNULL
> and also adds documentation about reasoning for it.
This is the last pending SSL cleanup related patch:
https://commitfest.postgresql.org/action/patch_v
On Sat, Feb 22, 2014 at 08:31:14PM -0500, Peter Eisentraut wrote:
> On 2/2/14, 7:16 AM, Marko Kreen wrote:
> > On Thu, Dec 12, 2013 at 04:32:07PM +0200, Marko Kreen wrote:
> >> Attached patch changes default ciphersuite to HIGH:MEDIUM:+3DES:!aNULL
> >> and also adds do
By default OpenSSL (and SSL/TLS in general) lets client cipher
order take priority. This is OK for browsers where the ciphers
were tuned, but few Postgres client libraries make cipher order
configurable. So it makes sense to make cipher order in
postgresql.conf take priority over client defaults
This sets up ECDH key exchange, when compiling against OpenSSL
that supports EC. Then ECDHE-RSA and ECDHE-ECDSA ciphersuites
can be used for SSL connections. Latter one means that EC keys
are now usable.
The reason for EC key exchange is that it's faster than DHE
and it allows to go to higher s
On Wed, Nov 06, 2013 at 09:57:32PM -0300, Alvaro Herrera wrote:
> Marko Kreen escribió:
>
> > By default OpenSSL (and SSL/TLS in general) lets client cipher
> > order take priority. This is OK for browsers where the ciphers
> > were tuned, but few Postgres client lib
On Sat, Jan 21, 2012 at 1:52 PM, Marc Mamin wrote:
>> >
>> > c. Refine error handling of dblink.c. I think it preserves the
>> > previous behavior for column number mismatch and type
>> > conversion exception.
>
> Hello,
>
> I don't know if this cover following issue.
> I just mention it for
On Sun, Jan 22, 2012 at 11:47 PM, Mikko Tiihonen
wrote:
> * introduced a new GUC variable array_output copying the current
> bytea_output type, with values "full" (old value) and
> "smallfixed" (new default)
> * added documentation for the new GUC variable
If this variable changes protocol-leve
On Mon, Jan 23, 2012 at 5:34 PM, Robert Haas wrote:
> On Mon, Jan 23, 2012 at 9:36 AM, Florian Weimer wrote:
>> * Robert Haas:
In this particular case, I knew that the change was coming and could
push updated Java and Perl client libraries well before the server-side
change hit our
On Mon, Jan 23, 2012 at 11:20:52AM -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Jan 23, 2012 at 9:59 AM, Marko Kreen wrote:
> >> Now that I think about it, same applies to bytea_output?
>
> > Probably so. But I think we need not introduce quite so many ne
On Mon, Jan 23, 2012 at 11:06 PM, Robert Haas wrote:
> On Mon, Jan 23, 2012 at 11:15 AM, Noah Misch wrote:
>> As I said upthread, and you appeared to agree, the protocol is independent of
>> individual data type send/recv formats. Even if we were already adding
>> protocol v4 to PostgreSQL 9.2,
On Tue, Jan 24, 2012 at 09:33:52PM -0500, Robert Haas wrote:
> Furthermore, while we haven't settled the question of exactly what a
> good negotiation facility would look like, we seem to agree that a GUC
> isn't it. I think that means this isn't going to happen for 9.2, so
> we should mark this p
On Wed, Jan 25, 2012 at 10:23:14AM -0500, Tom Lane wrote:
> Marko Kreen writes:
> > On Tue, Jan 24, 2012 at 09:33:52PM -0500, Robert Haas wrote:
> >> Furthermore, while we haven't settled the question of exactly what a
> >> good negotiation facility would look l
On Wed, Jan 25, 2012 at 11:40:28AM -0500, Tom Lane wrote:
> Marko Kreen writes:
> > On Wed, Jan 25, 2012 at 10:23:14AM -0500, Tom Lane wrote:
> >> Huh? How can that work? If we decide to change the representation of
> >> some other "well known type", sa
On Wed, Jan 25, 2012 at 12:58:15PM -0500, Tom Lane wrote:
> Marko Kreen writes:
> > On Wed, Jan 25, 2012 at 11:40:28AM -0500, Tom Lane wrote:
> >> Then why bother with the bit in the format code? If you've already done
> >> some other negotiation to establis
On Wed, Jan 25, 2012 at 12:54:00PM -0600, Merlin Moncure wrote:
> On Wed, Jan 25, 2012 at 11:24 AM, Marko Kreen wrote:
> > I specifically want to avoid any sort of per-connection
> > negotation, except the "max format version supported",
> > because it will mess
On Wed, Jan 25, 2012 at 01:43:03PM -0600, Merlin Moncure wrote:
> On Wed, Jan 25, 2012 at 1:24 PM, Marko Kreen wrote:
> > On Wed, Jan 25, 2012 at 12:54:00PM -0600, Merlin Moncure wrote:
> >> On Wed, Jan 25, 2012 at 11:24 AM, Marko Kreen wrote:
> >> > I specifically
On Wed, Jan 25, 2012 at 02:50:09PM -0600, Merlin Moncure wrote:
> On Wed, Jan 25, 2012 at 2:29 PM, Marko Kreen wrote:
> >> well, I see the following cases:
> >> 1) Vserver > Vapplication: server downgrades wire formats to
> >> applications version
> >>
On Fri, Jan 27, 2012 at 05:57:01PM +0900, Kyotaro HORIGUCHI wrote:
> Hello, This is a new version of the patch formerly known as
> 'alternative storage for libpq'.
>
> - Changed the concept to 'Alternative Row Processor' from
> 'Storage handler'. Symbol names are also changed.
>
> - Callback fu
On Fri, Jan 27, 2012 at 09:35:04AM -0600, Merlin Moncure wrote:
> On Fri, Jan 27, 2012 at 2:57 AM, Kyotaro HORIGUCHI
> > - The meaning of PGresAttValue is changed. The field 'value' now
> > contains a value withOUT terminating zero. This change seems to
> > have no effect on any other portion wit
On Mon, Jan 30, 2012 at 06:06:57PM +0900, Kyotaro HORIGUCHI wrote:
> The gain of performance is more than expected. Measure script now
> does query via dblink ten times for stability of measuring, so
> the figures become about ten times longer than the previous ones.
>
>sec
On Tue, Jan 31, 2012 at 4:59 AM, Kyotaro HORIGUCHI
wrote:
> This is fixed version of dblink.c for row processor.
>
>> i'll re-send the properly fixed patch for dblink.c later.
>
> - malloc error in initStoreInfo throws ERRCODE_OUT_OF_MEMORY. (new error)
>
> - storeHandler() now returns FALSE on ma
On Wed, Feb 1, 2012 at 10:32 AM, Kyotaro HORIGUCHI
wrote:
>> Another thing: if realloc() fails, the old pointer stays valid.
>> So it needs to be assigned to temp variable first, before
>> overwriting old pointer.
>
> mmm. I've misunderstood of the realloc.. I'll fix there in the
> next patch.
P
freePGconn() does not free sslcompression. Fix.
Found with valgrind.
--
marko
diff --git a/src/interfaces/libpq/fe-connect.c b/src/interfaces/libpq/fe-connect.c
index 5add143..4605e49 100644
--- a/src/interfaces/libpq/fe-connect.c
+++ b/src/interfaces/libpq/fe-connect.c
@@ -2803,6 +2803,8 @@ f
On Tue, Jan 31, 2012 at 8:56 PM, Robert Haas wrote:
> 2012/1/29 Kohei KaiGai :
>> Remote SQL: DECLARE pgsql_fdw_cursor_0 SCROLL CURSOR FOR SELECT
>> a, b FROM public.t1 WHERE (a > 2)
>> (3 rows)
>
> Shouldn't we be using protocol-level cursors rather than SQL-level cursors?
I think you want
On Thu, Feb 02, 2012 at 04:51:37PM +0900, Kyotaro HORIGUCHI wrote:
> Hello, This is new version of dblink.c
>
> - Memory is properly freed when realloc returns NULL in storeHandler().
>
> - The bug that free() in finishStoreInfo() will be fed with
> garbage pointer when malloc for sinfo->valbuf
On Fri, Feb 03, 2012 at 01:15:30PM +0100, Christian Ullrich wrote:
> * Peter Eisentraut wrote:
> >I noticed ecpglib still uses PQconnectdb() with a craftily assembled
> >connection string. Here is a patch to use PQconnectdbParams() instead.
>
> + const char *conn_keywords[6];
> + const ch
On Tue, Feb 07, 2012 at 07:25:14PM +0900, Shigeru Hanada wrote:
> (2012/02/02 23:30), Marko Kreen wrote:
> > On Thu, Feb 02, 2012 at 04:51:37PM +0900, Kyotaro HORIGUCHI wrote:
> >> Hello, This is new version of dblink.c
> >>
> >> - Memory is properly freed when
On Wed, Feb 08, 2012 at 02:44:13PM +0900, Shigeru Hanada wrote:
> (2012/02/07 23:44), Marko Kreen wrote:
> > On Tue, Feb 07, 2012 at 07:25:14PM +0900, Shigeru Hanada wrote:
> >> - What is the right (or recommended) way to prevent from throwing
> >> exceptoin in row-
On Tue, Feb 07, 2012 at 04:44:09PM +0200, Marko Kreen wrote:
> Although it seems we could allow exceptions, at least when we are
> speaking of Postgres backend, as the connection and result are
> internally consistent state when the handler is called, and the
> partial PGresult is
On Tue, Feb 14, 2012 at 05:59:06PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Mon, Feb 13, 2012 at 08:28:03PM -0500, Tom Lane wrote:
> >> +1, I was about to suggest the same thing. Running any of these tests
> >> for a fixed number of iterations will result in drastic degradation of
>
On Thu, Feb 16, 2012 at 02:24:19PM +0900, Kyotaro HORIGUCHI wrote:
> As far as I see, on an out-of-memory in getAnotherTuple() makes
> conn->result->resultStatus = PGRES_FATAL_ERROR and
> qpParseInputp[23]() skips succeeding 'D' messages consequently.
>
> When exception raised within row processor
On Thu, Feb 16, 2012 at 05:49:34PM +0900, Kyotaro HORIGUCHI wrote:
> I added the function PQskipRemainingResult() and use it in
> dblink. This reduces the number of executing try-catch block from
> the number of rows to one per query in dblink.
This implementation is wrong - you must not simply c
On Fri, Feb 17, 2012 at 10:54 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>>> Wait, we already have ALTER TRIGGER bob ON ANY COMMAND SET DISABLED;
>>
>> Eh, so what happens then if someone sets a command trigger on ALTER TRIGGER?
>
> We should remove support for command triggers on alter co
On Fri, Feb 17, 2012 at 4:04 PM, Dimitri Fontaine
wrote:
> Marko Kreen writes:
>> Btw, we already have a GUC for triggers: session_replication_role,
>> how will the command triggers follow that?
>
> Note that the replica here in my mind would have been an Hot Standby
&
Demos/tests of the new API:
https://github.com/markokr/libpq-rowproc-demos
Comments resulting from that:
- PQsetRowProcessorErrMsg() should take const char*
- callback API should be (void *, PGresult *, PQrowValue*)
or void* at the end, but not in the middle
I have not looked yet what need
On Sun, Feb 19, 2012 at 1:55 AM, Tom Lane wrote:
> Dimitri Fontaine writes:
>> Tom Lane writes:
>>> Yeah ... if you *don't* know the difference between a DFA and an NFA,
>>> you're likely to find yourself in over your head. Having said that,
>
>> So, here's a paper I found very nice to get star
On Tue, Feb 21, 2012 at 02:11:35PM +0900, Kyotaro HORIGUCHI wrote:
> I don't have any attachment to PQskipRemainingResults(), but I
> think that some formal method to skip until Command-Complete('C')
> without breaking session is necessary because current libpq does
> so.
We have such function: PQ
On Tue, Feb 21, 2012 at 11:42 AM, Kyotaro HORIGUCHI
wrote:
>> Also, as row handler is on connection, then changing it's
>> behavior is connection context, not result.
>
> OK, current implement copying the pointer to the row processor
> from PGconn to PGresult and getAnotherTuple() using it on
> PG
On Tue, Feb 21, 2012 at 12:13 PM, Kyotaro HORIGUCHI
wrote:
>> > - PQskipResult(conn, true) makes all consequent PQgetResult()'s
>> > to skip all the rows.
>
> Well, Is this right?
Yes, call getResult() until it returns NULL.
>> > If this is right, row processor should stay also in PGresult
>> >
On Wed, Feb 22, 2012 at 12:27:57AM +0900, Kyotaro HORIGUCHI wrote:
> fe-exec.c
> - PQskipResult() is added instead of PGskipRemainigResults().
It must free the PGresults that PQgetResult() returns.
Also, please fix 2 issues mentined here:
http://archives.postgresql.org/message-id/CACMqXCLvpkj
On Thu, Feb 23, 2012 at 07:14:03PM +0900, Kyotaro HORIGUCHI wrote:
> Hello, this is new version of the patch.
Looks good.
> By the way, I would like to ask you one question. What is the
> reason why void* should be head or tail of the parameter list?
Aesthetical reasons:
1) PGresult and PGrowVa
On Fri, Feb 24, 2012 at 07:53:14PM +0900, Kyotaro HORIGUCHI wrote:
> Hello, this is new version of the patch.
>
> > > By the way, I would like to ask you one question. What is the
> > > reason why void* should be head or tail of the parameter list?
> >
> > Aesthetical reasons:
>
> I got it. Tha
On Fri, Feb 24, 2012 at 02:11:45PM +0200, Marko Kreen wrote:
> On Fri, Feb 24, 2012 at 07:53:14PM +0900, Kyotaro HORIGUCHI wrote:
> > - I have no idea how to do test for protocol 2...
>
> I have a urge to test with "rm fe-protocol2.c"...
Now I tested with 7.3.21 and the
On Fri, Feb 24, 2012 at 4:26 PM, Merlin Moncure wrote:
> On Fri, Feb 24, 2012 at 7:52 AM, Marko Kreen wrote:
>> So could we like, uh, not do it and simply drop the V2 code?
>
> I think it's plausible that very old client libraries could connect to
> a modern server. But
On Tue, Feb 14, 2012 at 01:39:06AM +0200, Marko Kreen wrote:
> I tried imaging some sort of getFoo() style API for fetching in-flight
> row data, but I always ended up with "rewrite libpq" step, so I feel
> it's not productive to go there.
>
> Instead I added si
On Fri, Feb 24, 2012 at 11:46:19AM -0500, Tom Lane wrote:
> As for taking it out of libpq, I would vote against doing that as long
> as we have pg_dump support for pre-7.4 servers. Now, I think it would
> be entirely reasonable to kill pg_dump's support for pre-7.3 servers,
> because that would si
On Fri, Feb 24, 2012 at 05:46:16PM +0200, Marko Kreen wrote:
> - rename to PQrecvRow() and additionally provide PQgetRow()
I tried it and it seems to work as API - there is valid behaviour
for both sync and async connections.
Sync connection - PQgetRow() waits for data from network:
On Mon, Feb 27, 2012 at 05:20:30PM +0900, Kyotaro HORIGUCHI wrote:
> Hello,
>
> > On OOM, the old result is freed to have higher chance that
> > constructing new result succeeds. But if we want to transport
> > error message, we need to keep old PGresult around. Thus
> > two separate paths.
>
On Tue, Feb 28, 2012 at 05:04:44PM +0900, Kyotaro HORIGUCHI wrote:
> > There is still one EOF in v3 getAnotherTuple() -
> > pqGetInt(tupnfields), please turn that one also to
> > protocolerror.
>
> pqGetInt() returns EOF only when it wants additional reading from
> network if the parameter `bytes'
On Tue, Mar 06, 2012 at 11:13:45AM +0900, Kyotaro HORIGUCHI wrote:
> > But it's broken in V3 protocol - getAnotherTuple() will be called
> > only if the packet is fully read. If the packet contents do not
> > agree with packet header, it's protocol error. Only valid EOF
> > return in V3 getAnothe
Commit b5282aa893:
"Revise sinval code to remove no-longer-used tuple TID from inval messages."
dropped ItemPointer from callbacks and replaced it with "hashValue".
There seems to be 2 ways that new backend code calculates it:
- hashoid(oid), which seems to assume too much?
- CatalogCacheComput
On Tue, Mar 06, 2012 at 11:10:38AM -0500, Tom Lane wrote:
> Marko Kreen writes:
> > So my question is that after doing generic SearchSysCache() like:
>
> >tup = SearchSysCache(USERMAPPINGUSERSERVER,
> > ObjectIdGetDatum(user_mapping->userid),
&
On Tue, Mar 06, 2012 at 04:27:11PM -0500, Tom Lane wrote:
> Marko Kreen writes:
> > On Tue, Mar 06, 2012 at 11:10:38AM -0500, Tom Lane wrote:
> >> Why would you need to know that? The reason the calculation function
> >> is static is that there's no apparent
On Wed, Mar 07, 2012 at 11:16:06AM -0500, Tom Lane wrote:
> Marko Kreen writes:
> > On Tue, Mar 06, 2012 at 04:27:11PM -0500, Tom Lane wrote:
> >> Or you could do like setrefs.c does, and assume you know how to
> >> calculate the hash value for an OID-keyed cache.
&g
On Fri, Mar 09, 2012 at 05:28:20PM -0500, Andrew Dunstan wrote:
> Buildfarm member mussel (OS X 10.7.3, llvm-gcc 4.2.1, x86_64)seems
> to be getting consistent warnings when running the pgcrypto
> regression tests, that look like this:
>
>WARNING: detected write past chunk end in ExprContext 0
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 this work:
db = PQconnectdb("postgres://localhost");
?
--
marko
--
Sen
I saw Kyotaro already answered, but I give my view as well.
On Thu, Mar 22, 2012 at 06:07:16PM -0400, Tom Lane wrote:
> AFAICT it breaks async processing entirely, because many changes have been
> made that fail to distinguish "insufficient data available as yet" from
> "hard error". As an exampl
On Sat, Mar 24, 2012 at 02:22:24AM +0200, Marko Kreen wrote:
> Main advantage of including PQgetRow() together with low-level
> rowproc API is that it allows de-emphasizing more complex parts of
> rowproc API (exceptions, early exit, skipresult, custom error msg).
> And drop/undocu
On Wed, Mar 28, 2012 at 08:19:37AM -0400, Robert Haas wrote:
> On Tue, Mar 27, 2012 at 10:10 PM, Fujii Masao wrote:
> > On Wed, Mar 28, 2012 at 5:17 AM, Robert Haas wrote:
> >> pg_test_timing utility, to measure clock monotonicity and timing cost.
> >
> > When I compiled this, I got a compiler wa
On Wed, Mar 28, 2012 at 03:46:26PM +0300, Marko Kreen wrote:
> On Wed, Mar 28, 2012 at 08:19:37AM -0400, Robert Haas wrote:
> > On Tue, Mar 27, 2012 at 10:10 PM, Fujii Masao wrote:
> > > On Wed, Mar 28, 2012 at 5:17 AM, Robert Haas wrote:
> > >> pg_test_ti
On Wed, Mar 28, 2012 at 08:57:42AM -0400, Robert Haas wrote:
> On Wed, Mar 28, 2012 at 8:51 AM, Marko Kreen wrote:
> >> How about: ".. %10" INT64_FORMAT " .. " ?
> >
> > Well, it won't work because unlike , Postgres *_FORMAT
> > inclu
On Fri, Mar 23, 2012 at 08:52:40AM +, Simon Riggs wrote:
> Master pg_controldata - OK txid_current_snapshot() - OK
> Standby pg_controldata - OK txid_current_snapshot() - lower value
On Skytools list is report about master with slaves, but the
lower value appears on master too:
http://lists
On Wed, Mar 28, 2012 at 10:54:58PM +0100, Simon Riggs wrote:
> On Wed, Mar 28, 2012 at 10:24 PM, Simon Riggs wrote:
> > On Wed, Mar 28, 2012 at 9:48 PM, Marko Kreen wrote:
> >> On Fri, Mar 23, 2012 at 08:52:40AM +, Simon Riggs wrote:
> >>> Master pg_controld
On Thu, Mar 29, 2012 at 10:37:54AM +0100, Simon Riggs wrote:
> When the standby receives the checkpoint record, it stores the
> information in 2 places:
> i) directly into ControlFile->checkPointCopy
> ii) and then into XLogCtl when a safe restartpoint occurs
In RecoveryRestartPoint() I see:
- me
On Thu, Mar 29, 2012 at 02:46:23PM +0100, Simon Riggs wrote:
> On Thu, Mar 29, 2012 at 12:06 PM, Simon Riggs wrote:
> > Patch coming in a few hours.
>
> This is more straightforward than I was thinking. We just need to
> initialise XLogCtl at the right place.
Looks good to me. That should fix t
On Thu, Mar 29, 2012 at 03:23:01PM +0100, Simon Riggs wrote:
> On Thu, Mar 29, 2012 at 3:04 PM, Marko Kreen wrote:
> > Next question: how can flipping archive_mode on and off,
> > with restarts, near wraparound point, break epoch on master?
> >
> > http://lists.pgfou
On Thu, Mar 29, 2012 at 06:56:30PM -0400, Tom Lane wrote:
> Marko Kreen writes:
> > My conclusion is that row-processor API is low-level expert API and
> > quite easy to misuse. It would be preferable to have something more
> > robust as end-user API, the PQgetRow() is m
On Fri, Mar 30, 2012 at 11:59:12AM -0400, Tom Lane wrote:
> Marko Kreen writes:
> > On Thu, Mar 29, 2012 at 06:56:30PM -0400, Tom Lane wrote:
> >> Marko Kreen writes:
> >>> Second conclusion is that current dblink row-processor usage is broken
> >>>
On Fri, Mar 30, 2012 at 7:04 PM, Marko Kreen wrote:
> Have you looked at the examples? PQgetResult() is pretty good hint
> that one resultset finished...
Ok, the demos are around this long thread and hard to find,
so here is a summary of links:
Original design mail:
On Fri, Mar 30, 2012 at 05:18:42PM -0400, Tom Lane wrote:
> Marko Kreen writes:
> > On Wed, Mar 07, 2012 at 03:14:57PM +0900, Kyotaro HORIGUCHI wrote:
> >>> My suggestion - check in getAnotherTuple whether resultStatus is
> >>> already error and do nothing the
On Sat, Mar 31, 2012 at 1:13 AM, Tom Lane wrote:
> Marko Kreen writes:
>> On Fri, Mar 30, 2012 at 05:18:42PM -0400, Tom Lane wrote:
>>> I'm pretty dissatisfied with the error reporting situation for row
>>> processors. You can't just decide not to solve
On Sun, Apr 01, 2012 at 05:51:19PM -0400, Tom Lane wrote:
> I've been thinking some more about the early-termination cases (where
> the row processor returns zero or longjmps), and I believe I have got
> proposals that smooth off most of the rough edges there.
>
> First off, returning zero is real
On Sun, Apr 01, 2012 at 07:23:06PM -0400, Tom Lane wrote:
> Marko Kreen writes:
> > So the proper approach would be to have new API call, designed to
> > handle it, and allow early-exit only from there.
>
> > That would also avoid any breakage of old APIs. Also it would
On Tue, Apr 03, 2012 at 05:32:25PM -0400, Tom Lane wrote:
> Marko Kreen writes:
> > The fact remains that upper-level code must cooperate with callback.
> > Why is it useful to hijack PQgetResult() to do so?
>
> Because that's the defined communications channel. We&#x
On Wed, Apr 4, 2012 at 10:17 PM, Tom Lane wrote:
> Given the lack of consensus around the suspension API, maybe the best
> way to get the underlying libpq patch to a committable state is to take
> it out --- that is, remove the "return zero" option for row processors.
> Since we don't have a test
On Wed, Apr 04, 2012 at 06:41:00PM -0400, Tom Lane wrote:
> Marko Kreen writes:
> > On Wed, Apr 4, 2012 at 10:17 PM, Tom Lane wrote:
> >> Given the lack of consensus around the suspension API, maybe the best
> >> way to get the underlying libpq patch to a committable s
On Thu, Apr 05, 2012 at 12:49:37PM -0400, Tom Lane wrote:
> Marko Kreen writes:
> > Minor cleanups:
>
> > * Change callback return value to be 'bool': 0 is error.
> > Currently the accepted return codes are 1 and -1,
> > which is weird.
>
>
On Thu, Jun 13, 2013 at 12:35 PM, Dean Rasheed wrote:
> Attached is a patch implementing a new aggregate function md5_agg() to
> compute the aggregate MD5 sum across a number of rows. This is
> something I've wished for a number of times. I think the primary use
> case is to do a quick check that
On Mon, May 27, 2013 at 5:59 AM, Christopher Browne wrote:
> This situation falls from a problem that we noticed a mighty long time ago
> in Slony, where the set of XIDs outstanding gets very large, and, attendant
> to that, the set of "action id" values by which tuples are being filtered,
> gets
On Mon, Jun 17, 2013 at 11:34:52AM +0100, Dean Rasheed wrote:
> On 15 June 2013 10:22, Dean Rasheed wrote:
> > There seem to be 2 separate directions that this could go, which
> > really meet different requirements:
> >
> > 1). Produce an unordered sum for SQL to compare 2 tables regardless of
> >
On Mon, May 13, 2013 at 2:58 AM, Robins Tharakan wrote:
> Please find attached a patch that adds basic regression tests for DISCARD
> command.
>
> Any and all feedback is obviously welcome.
Perhaps existing tests in guc.sql should be merged into it?
--
marko
--
Sent via pgsql-hackers mailing
On Thu, Jun 27, 2013 at 11:28 AM, Dean Rasheed wrote:
> On 26 June 2013 21:46, Peter Eisentraut wrote:
>> On 6/26/13 4:04 PM, Dean Rasheed wrote:
>>> A quick google search reveals several people asking for something like
>>> this, and people recommending md5(string_agg(...)) or
>>> md5(string_agg
On Wed, Jul 3, 2013 at 8:07 PM, Andres Freund wrote:
> On 2013-07-02 16:29:56 -0400, Robert Haas wrote:
>> There's no possibility of getting confused here; if X is still around
>> at all, it's xmax is of the same generation as Y's xmin. Otherwise,
>> we've had an undetected XID wraparound.
>
> An
On Tue, Dec 11, 2012 at 6:59 AM, Josh Kupershmidt wrote:
> Would it be crazy to add an "already_freed" flag to the pg_result
> struct which PQclear() would set, or some equivalent safety mechanism,
> to avoid this hassle for users?
Such mechanism already exist - you just need to set
your PGresult
When there is 'ssl=on' then postmaster calls SSL_CTX_new(),
which asks for random number, thus requiring initialization
of randomness pool (RAND_poll). After that all forked backends
think pool is already initialized. Thus they proceed with same
fixed state they got from postmaster.
Output is no
On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch wrote:
> This should have gone to secur...@postgresql.org, instead.
It went and this could have been patched in 9.2.2 but they did not care.
> On Fri, Dec 21, 2012 at 06:05:10PM +0200, Marko Kreen wrote:
>> When there is 'ssl=on
On Sat, Dec 22, 2012 at 9:20 PM, Tom Lane wrote:
> I'm not thrilled with the suggestion to do RAND_cleanup() after forking
> though, as that seems like it'll guarantee that each session starts out
> with only a minimal amount of entropy.
No, that's actually the right fix - that forces OpenSSL to
On Sun, Dec 23, 2012 at 9:45 PM, Tom Lane wrote:
> Marko Kreen writes:
>> On Sat, Dec 22, 2012 at 9:20 PM, Tom Lane wrote:
> >> I'm not thrilled with the suggestion to do RAND_cleanup() after forking
> >> though, as that seems like it'll guarantee that eac
On Wed, Jan 2, 2013 at 5:11 PM, Boszormenyi Zoltan wrote:
> 2012-12-11 16:09 keltezéssel, Simon Riggs írta:
>
>> On 11 December 2012 12:18, Boszormenyi Zoltan wrote:
>>
> Such mechanism already exist - you just need to set
> your PGresult pointer to NULL after each PQclear().
So
On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch wrote:
> How about instead calling RAND_cleanup() after each backend fork?
Attached is a patch that adds RAND_cleanup() to fork_process().
That way all forked processes start with fresh state. This should
make sure the problem does not happen in any p
On Mon, Jan 14, 2013 at 12:46 AM, Tom Lane wrote:
> Marko Kreen writes:
>> On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch wrote:
>>> How about instead calling RAND_cleanup() after each backend fork?
>
>> Attached is a patch that adds RAND_cleanup() to fork_process().
&g
On Mon, Jan 14, 2013 at 3:00 PM, Noah Misch wrote:
> On Mon, Jan 14, 2013 at 02:21:00PM +0200, Marko Kreen wrote:
>> Note: reading from /dev/urandom does not affect /dev/random.
>
> Reading from /dev/urandom drains the pool that serves /dev/random:
>
> $ cat /proc/sys/kernel
On Tue, Apr 16, 2013 at 05:09:19PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > I think his point is why don't we clear currval() on DISCARD ALL? I
> > can't think of a good reason we don't.
>
> Because we'd have to invent a new suboperation DISCARD SEQUENCES,
> for one thing, in order to
RSA secret key extraction code uses wrong variable so
that decryption is skipped and only secret keys without
password work for pgp_pub_decrypt().
Attached patch fixes it and also adds regtest.
Please apply to all branches.
Reported-by: Keith Fiske
--
marko
diff --git a/contrib/pgcrypto/pgp
On Fri, May 10, 2013 at 12:52:55PM -0400, Tom Lane wrote:
> Marko Kreen writes:
> > RSA secret key extraction code uses wrong variable so
> > that decryption is skipped and only secret keys without
> > password work for pgp_pub_decrypt().
>
> > Attached patch
On Sat, May 04, 2013 at 10:57:44PM +0200, Dimitri Fontaine wrote:
> Other than adminpack, I know of PGQ installing their objects in
> pg_catalog. They only began doing that when switching to the CREATE
> EXTENSION facility. And they set relocatable to false.
FYI - PgQ and related modules install n
On Tue, May 14, 2013 at 09:29:38AM +0200, Dimitri Fontaine wrote:
> Stephen Frost writes:
> > * Marko Kreen (mark...@gmail.com) wrote:
> >> On Sat, May 04, 2013 at 10:57:44PM +0200, Dimitri Fontaine wrote:
> >> > Other than adminpack, I know of PGQ installing thei
On Wed, Jul 25, 2012 at 12:35 AM, Merlin Moncure wrote:
> On Tue, Jul 24, 2012 at 3:52 PM, Marko Kreen wrote:
>> * Is there better API than PQsetSingleRowMode()? New PQsend*
>> functions is my alternative.
>
> I would prefer to have PQsetSingleRowMode() over new fla
1 - 100 of 668 matches
Mail list logo
