pg.ddx.io pgsql-general@postgresql.org mailing list archive
help / color / mirror / Atom feedRetrieving query results
17+ messages / 4 participants
[nested] [flat]
* Retrieving query results
@ 2017-08-22 18:19 Igor Korot <ikorot01@gmail.com>
2017-08-23 00:32 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
0 siblings, 1 reply; 17+ messages in thread
From: Igor Korot @ 2017-08-22 18:19 UTC (permalink / raw)
To: pgsql-general
Hi, ALL,
[quote]
PQntuples
Returns the number of rows (tuples) in the query result. Because it
returns an integer result, large result sets might overflow the return
value on 32-bit operating systems.
int PQntuples(const PGresult *res);
[/quote]
Is there another way to not to overflow the result?
Thank you.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: Retrieving query results
2017-08-22 18:19 Retrieving query results Igor Korot <ikorot01@gmail.com>
@ 2017-08-23 00:32 ` Michael Paquier <michael.paquier@gmail.com>
2017-08-23 01:04 ` Re: Retrieving query results Igor Korot <ikorot01@gmail.com>
2017-08-24 12:51 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 17+ messages in thread
From: Michael Paquier @ 2017-08-23 00:32 UTC (permalink / raw)
To: Igor Korot <ikorot01@gmail.com>; +Cc: pgsql-general
On Wed, Aug 23, 2017 at 3:19 AM, Igor Korot <ikorot01@gmail.com> wrote:
> [quote]
> PQntuples
>
> Returns the number of rows (tuples) in the query result. Because it
> returns an integer result, large result sets might overflow the return
> value on 32-bit operating systems.
>
> int PQntuples(const PGresult *res);
> [/quote]
>
> Is there another way to not to overflow the result?
Not really with the existing API. Note that getting at 2 billion rows
is really a lot, and would cause performance issues on the application
side because a bunch of data would need to be processed, and getting
out this much data is not network-wise anyway.
--
Michael
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: Retrieving query results
2017-08-22 18:19 Retrieving query results Igor Korot <ikorot01@gmail.com>
2017-08-23 00:32 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
@ 2017-08-23 01:04 ` Igor Korot <ikorot01@gmail.com>
1 sibling, 0 replies; 17+ messages in thread
From: Igor Korot @ 2017-08-23 01:04 UTC (permalink / raw)
To: Michael Paquier <michael.paquier@gmail.com>; +Cc: pgsql-general
Hi, Michael,
On Tue, Aug 22, 2017 at 8:32 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Wed, Aug 23, 2017 at 3:19 AM, Igor Korot <ikorot01@gmail.com> wrote:
>> [quote]
>> PQntuples
>>
>> Returns the number of rows (tuples) in the query result. Because it
>> returns an integer result, large result sets might overflow the return
>> value on 32-bit operating systems.
>>
>> int PQntuples(const PGresult *res);
>> [/quote]
>>
>> Is there another way to not to overflow the result?
>
> Not really with the existing API.
What do you mean "not really"
> Note that getting at 2 billion rows
> is really a lot, and would cause performance issues on the application
> side because a bunch of data would need to be processed, and getting
> out this much data is not network-wise anyway.
That's OK, As long as my program works with arbitrary number of rows.
Thank you.
> --
> Michael
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: Retrieving query results
2017-08-22 18:19 Retrieving query results Igor Korot <ikorot01@gmail.com>
2017-08-23 00:32 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
@ 2017-08-24 12:51 ` Tom Lane <tgl@sss.pgh.pa.us>
2017-08-24 13:47 ` Re: Retrieving query results Igor Korot <ikorot01@gmail.com>
1 sibling, 1 reply; 17+ messages in thread
From: Tom Lane @ 2017-08-24 12:51 UTC (permalink / raw)
To: Michael Paquier <michael.paquier@gmail.com>; +Cc: Igor Korot <ikorot01@gmail.com>; pgsql-general
Michael Paquier <michael.paquier@gmail.com> writes:
> On Wed, Aug 23, 2017 at 3:19 AM, Igor Korot <ikorot01@gmail.com> wrote:
>> [quote]
>> PQntuples
>>
>> Returns the number of rows (tuples) in the query result. Because it
>> returns an integer result, large result sets might overflow the return
>> value on 32-bit operating systems.
>>
>> int PQntuples(const PGresult *res);
>> [/quote]
>>
>> Is there another way to not to overflow the result?
> Not really with the existing API.
Actually, that documentation note is pretty beside-the-point, if not
outright wrong. The real issue here is that libpq's internal row counter
is also a plain int. As are the rownumber arguments to PQgetvalue and so
on. While we could widen that internal counter, it's useless to do so
as long as these API choices prevent applications from dealing with
resultsets of more than 2G rows.
I think what we need is to (1) introduce some error checking in libpq so
that it reports an error if the resultset exceeds 2G rows --- right now
it'll just crash, I fear, and (2) change the documentation so that this
is explained as a library-wide limitation and not just a problem with
PQntuples.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: Retrieving query results
2017-08-22 18:19 Retrieving query results Igor Korot <ikorot01@gmail.com>
2017-08-23 00:32 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
2017-08-24 12:51 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
@ 2017-08-24 13:47 ` Igor Korot <ikorot01@gmail.com>
2017-08-24 14:56 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 17+ messages in thread
From: Igor Korot @ 2017-08-24 13:47 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Michael Paquier <michael.paquier@gmail.com>; pgsql-general
Hi, guys,
On Thu, Aug 24, 2017 at 8:51 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Michael Paquier <michael.paquier@gmail.com> writes:
>> On Wed, Aug 23, 2017 at 3:19 AM, Igor Korot <ikorot01@gmail.com> wrote:
>>> [quote]
>>> PQntuples
>>>
>>> Returns the number of rows (tuples) in the query result. Because it
>>> returns an integer result, large result sets might overflow the return
>>> value on 32-bit operating systems.
>>>
>>> int PQntuples(const PGresult *res);
>>> [/quote]
>>>
>>> Is there another way to not to overflow the result?
>
>> Not really with the existing API.
>
> Actually, that documentation note is pretty beside-the-point, if not
> outright wrong. The real issue here is that libpq's internal row counter
> is also a plain int. As are the rownumber arguments to PQgetvalue and so
> on. While we could widen that internal counter, it's useless to do so
> as long as these API choices prevent applications from dealing with
> resultsets of more than 2G rows.
>
> I think what we need is to (1) introduce some error checking in libpq so
> that it reports an error if the resultset exceeds 2G rows --- right now
> it'll just crash, I fear, and (2) change the documentation so that this
> is explained as a library-wide limitation and not just a problem with
> PQntuples.
Does this mean that querying a table with a big number of rows will
crash the psql?
Thank you.
>
> regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: Retrieving query results
2017-08-22 18:19 Retrieving query results Igor Korot <ikorot01@gmail.com>
2017-08-23 00:32 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
2017-08-24 12:51 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
2017-08-24 13:47 ` Re: Retrieving query results Igor Korot <ikorot01@gmail.com>
@ 2017-08-24 14:56 ` Tom Lane <tgl@sss.pgh.pa.us>
2017-08-24 22:57 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
0 siblings, 1 reply; 17+ messages in thread
From: Tom Lane @ 2017-08-24 14:56 UTC (permalink / raw)
To: Igor Korot <ikorot01@gmail.com>; +Cc: Michael Paquier <michael.paquier@gmail.com>; pgsql-general
Igor Korot <ikorot01@gmail.com> writes:
> On Thu, Aug 24, 2017 at 8:51 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I think what we need is to (1) introduce some error checking in libpq so
>> that it reports an error if the resultset exceeds 2G rows --- right now
>> it'll just crash, I fear, and (2) change the documentation so that this
>> is explained as a library-wide limitation and not just a problem with
>> PQntuples.
> Does this mean that querying a table with a big number of rows will
> crash the psql?
I haven't tried it, but it sure looks like it would, if you don't hit
OOM first. pqAddTuple() isn't doing anything to guard against integer
overflow. The lack of reports implies that no one has ever tried to
retrieve even 1G rows, let alone more ...
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: Retrieving query results
2017-08-22 18:19 Retrieving query results Igor Korot <ikorot01@gmail.com>
2017-08-23 00:32 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
2017-08-24 12:51 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
2017-08-24 13:47 ` Re: Retrieving query results Igor Korot <ikorot01@gmail.com>
2017-08-24 14:56 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
@ 2017-08-24 22:57 ` Michael Paquier <michael.paquier@gmail.com>
2017-08-24 23:05 ` Re: Retrieving query results Igor Korot <ikorot01@gmail.com>
2017-08-24 23:10 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 17+ messages in thread
From: Michael Paquier @ 2017-08-24 22:57 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Igor Korot <ikorot01@gmail.com>; pgsql-general
On Thu, Aug 24, 2017 at 11:56 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I haven't tried it, but it sure looks like it would, if you don't hit
> OOM first. pqAddTuple() isn't doing anything to guard against integer
> overflow. The lack of reports implies that no one has ever tried to
> retrieve even 1G rows, let alone more ...
Yeah, looking at the code we would just need to check if ntups gets
negative (well, equal to INT_MIN) after being incremented.
--
Michael
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: Retrieving query results
2017-08-22 18:19 Retrieving query results Igor Korot <ikorot01@gmail.com>
2017-08-23 00:32 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
2017-08-24 12:51 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
2017-08-24 13:47 ` Re: Retrieving query results Igor Korot <ikorot01@gmail.com>
2017-08-24 14:56 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
2017-08-24 22:57 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
@ 2017-08-24 23:05 ` Igor Korot <ikorot01@gmail.com>
2017-08-24 23:18 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 17+ messages in thread
From: Igor Korot @ 2017-08-24 23:05 UTC (permalink / raw)
To: Michael Paquier <michael.paquier@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-general
Michael et al,
On Thu, Aug 24, 2017 at 6:57 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Thu, Aug 24, 2017 at 11:56 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I haven't tried it, but it sure looks like it would, if you don't hit
>> OOM first. pqAddTuple() isn't doing anything to guard against integer
>> overflow. The lack of reports implies that no one has ever tried to
>> retrieve even 1G rows, let alone more ...
>
> Yeah, looking at the code we would just need to check if ntups gets
> negative (well, equal to INT_MIN) after being incremented.
So there is no way to retrieve an arbitrary number of rows from the query?
That sucks...
Thank you.
> --
> Michael
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: Retrieving query results
2017-08-22 18:19 Retrieving query results Igor Korot <ikorot01@gmail.com>
2017-08-23 00:32 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
2017-08-24 12:51 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
2017-08-24 13:47 ` Re: Retrieving query results Igor Korot <ikorot01@gmail.com>
2017-08-24 14:56 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
2017-08-24 22:57 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
2017-08-24 23:05 ` Re: Retrieving query results Igor Korot <ikorot01@gmail.com>
@ 2017-08-24 23:18 ` Tom Lane <tgl@sss.pgh.pa.us>
2017-08-25 00:00 ` Re: Retrieving query results Igor Korot <ikorot01@gmail.com>
0 siblings, 1 reply; 17+ messages in thread
From: Tom Lane @ 2017-08-24 23:18 UTC (permalink / raw)
To: Igor Korot <ikorot01@gmail.com>; +Cc: Michael Paquier <michael.paquier@gmail.com>; pgsql-general
Igor Korot <ikorot01@gmail.com> writes:
> So there is no way to retrieve an arbitrary number of rows from the query?
> That sucks...
The restriction is on the number of rows in one PGresult, not the total
size of the query result. You could use single-row mode, or use a cursor
and fetch some reasonable number of rows at a time. If you try to inhale
all of a many-gigarow result at once, you're going to have OOM problems
anyway, even if you had the patience to wait for it. So I don't think the
existence of a limit is a problem. Failure to check it *is* a problem,
certainly.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: Retrieving query results
2017-08-22 18:19 Retrieving query results Igor Korot <ikorot01@gmail.com>
2017-08-23 00:32 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
2017-08-24 12:51 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
2017-08-24 13:47 ` Re: Retrieving query results Igor Korot <ikorot01@gmail.com>
2017-08-24 14:56 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
2017-08-24 22:57 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
2017-08-24 23:05 ` Re: Retrieving query results Igor Korot <ikorot01@gmail.com>
2017-08-24 23:18 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
@ 2017-08-25 00:00 ` Igor Korot <ikorot01@gmail.com>
0 siblings, 0 replies; 17+ messages in thread
From: Igor Korot @ 2017-08-25 00:00 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Michael Paquier <michael.paquier@gmail.com>; pgsql-general
Hi,
On Thu, Aug 24, 2017 at 7:18 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Igor Korot <ikorot01@gmail.com> writes:
>> So there is no way to retrieve an arbitrary number of rows from the query?
>> That sucks...
>
> The restriction is on the number of rows in one PGresult, not the total
> size of the query result. You could use single-row mode, or use a cursor
> and fetch some reasonable number of rows at a time. If you try to inhale
> all of a many-gigarow result at once, you're going to have OOM problems
> anyway, even if you had the patience to wait for it. So I don't think the
> existence of a limit is a problem. Failure to check it *is* a problem,
> certainly.
Is there a sample of using single-row mode?
How to turn it on and turn it off?
Is there a cursor example with the Prepared Statements?
The one in the documentation doesn't use them - it uses PQexec().
Thank you.
>
> regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: Retrieving query results
2017-08-22 18:19 Retrieving query results Igor Korot <ikorot01@gmail.com>
2017-08-23 00:32 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
2017-08-24 12:51 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
2017-08-24 13:47 ` Re: Retrieving query results Igor Korot <ikorot01@gmail.com>
2017-08-24 14:56 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
2017-08-24 22:57 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
@ 2017-08-24 23:10 ` Tom Lane <tgl@sss.pgh.pa.us>
2017-08-26 13:29 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
1 sibling, 1 reply; 17+ messages in thread
From: Tom Lane @ 2017-08-24 23:10 UTC (permalink / raw)
To: Michael Paquier <michael.paquier@gmail.com>; +Cc: Igor Korot <ikorot01@gmail.com>; pgsql-general
Michael Paquier <michael.paquier@gmail.com> writes:
> On Thu, Aug 24, 2017 at 11:56 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I haven't tried it, but it sure looks like it would, if you don't hit
>> OOM first. pqAddTuple() isn't doing anything to guard against integer
>> overflow. The lack of reports implies that no one has ever tried to
>> retrieve even 1G rows, let alone more ...
> Yeah, looking at the code we would just need to check if ntups gets
> negative (well, equal to INT_MIN) after being incremented.
I think the real problem occurs where we realloc the array bigger.
tupArrSize needs to be kept to no more than INT_MAX --- and, ideally,
it should reach that value rather than dying on the iteration after
it reaches 2^30 (so that we support resultsets as large as we possibly
can). Without a range-check, it's not very clear what realloc will think
it's being asked for. Also, on 32-bit machines, we could overflow size_t
before tupArrSize even gets that big, so a test against
SIZE_MAX/sizeof(pointer) may be needed as well.
As long as we constrain tupArrSize to be within bounds, we don't
have to worry about overflow of ntups per se.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: Retrieving query results
2017-08-22 18:19 Retrieving query results Igor Korot <ikorot01@gmail.com>
2017-08-23 00:32 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
2017-08-24 12:51 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
2017-08-24 13:47 ` Re: Retrieving query results Igor Korot <ikorot01@gmail.com>
2017-08-24 14:56 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
2017-08-24 22:57 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
2017-08-24 23:10 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
@ 2017-08-26 13:29 ` Michael Paquier <michael.paquier@gmail.com>
2017-08-26 15:12 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 17+ messages in thread
From: Michael Paquier @ 2017-08-26 13:29 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Igor Korot <ikorot01@gmail.com>; pgsql-general
On Fri, Aug 25, 2017 at 8:10 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I think the real problem occurs where we realloc the array bigger.
> tupArrSize needs to be kept to no more than INT_MAX --- and, ideally,
> it should reach that value rather than dying on the iteration after
> it reaches 2^30 (so that we support resultsets as large as we possibly
> can). Without a range-check, it's not very clear what realloc will think
> it's being asked for. Also, on 32-bit machines, we could overflow size_t
> before tupArrSize even gets that big, so a test against
> SIZE_MAX/sizeof(pointer) may be needed as well.
>
> As long as we constrain tupArrSize to be within bounds, we don't
> have to worry about overflow of ntups per se.
I just poked more seriously at this code, and we could use something like that:
@@ -868,6 +868,16 @@ pqAddTuple(PGresult *res, PGresAttValue *tup)
int newSize = (res->tupArrSize > 0) ? res->tupArrSize * 2 : 128;
PGresAttValue **newTuples;
+ if (res->tupArrSize == INT_MAX)
+ return FALSE;
+ if (new_size == INT_MIN)
+ new_size = INT_MAX;
+ if (newSize > SIZE_MAX / sizeof(PGresAttValue *))
+ return FALSE;
Looking at the surroundings, I think that it would be nice to have
pqAddTuple and PQsetvalue set an error message with this patch. The
user can see now that those would only properly report on OOM, but if
we add more types of errors proper error messages would be nice for
users.
--
Michael
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: Retrieving query results
2017-08-22 18:19 Retrieving query results Igor Korot <ikorot01@gmail.com>
2017-08-23 00:32 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
2017-08-24 12:51 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
2017-08-24 13:47 ` Re: Retrieving query results Igor Korot <ikorot01@gmail.com>
2017-08-24 14:56 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
2017-08-24 22:57 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
2017-08-24 23:10 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
2017-08-26 13:29 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
@ 2017-08-26 15:12 ` Tom Lane <tgl@sss.pgh.pa.us>
2017-08-28 06:05 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
0 siblings, 1 reply; 17+ messages in thread
From: Tom Lane @ 2017-08-26 15:12 UTC (permalink / raw)
To: Michael Paquier <michael.paquier@gmail.com>; +Cc: Igor Korot <ikorot01@gmail.com>; pgsql-general
Michael Paquier <michael.paquier@gmail.com> writes:
> On Fri, Aug 25, 2017 at 8:10 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I think the real problem occurs where we realloc the array bigger.
> Looking at the surroundings, I think that it would be nice to have
> pqAddTuple and PQsetvalue set an error message with this patch.
Yeah, I was thinking about that myself - the existing design presumes
that the only possible reason for failure of pqAddTuple is OOM, but
it'd be better to distinguish "too many tuples" from true OOM. So
we should also refactor to make pqAddTuple responsible for setting
the error message. Might be best to do the refactoring first.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: Retrieving query results
2017-08-22 18:19 Retrieving query results Igor Korot <ikorot01@gmail.com>
2017-08-23 00:32 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
2017-08-24 12:51 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
2017-08-24 13:47 ` Re: Retrieving query results Igor Korot <ikorot01@gmail.com>
2017-08-24 14:56 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
2017-08-24 22:57 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
2017-08-24 23:10 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
2017-08-26 13:29 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
2017-08-26 15:12 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
@ 2017-08-28 06:05 ` Michael Paquier <michael.paquier@gmail.com>
2025-12-17 05:26 ` Re: [GENERAL] Retrieving query results Igor Korot <ikorot01@gmail.com>
0 siblings, 1 reply; 17+ messages in thread
From: Michael Paquier @ 2017-08-28 06:05 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Igor Korot <ikorot01@gmail.com>; pgsql-general
On Sun, Aug 27, 2017 at 12:12 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Michael Paquier <michael.paquier@gmail.com> writes:
>> On Fri, Aug 25, 2017 at 8:10 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I think the real problem occurs where we realloc the array bigger.
>
>> Looking at the surroundings, I think that it would be nice to have
>> pqAddTuple and PQsetvalue set an error message with this patch.
>
> Yeah, I was thinking about that myself - the existing design presumes
> that the only possible reason for failure of pqAddTuple is OOM, but
> it'd be better to distinguish "too many tuples" from true OOM. So
> we should also refactor to make pqAddTuple responsible for setting
> the error message. Might be best to do the refactoring first.
Attached are two patches:
1) 0001 refactors the code around pqAddTuple to be able to handle
error messages and assign them in PQsetvalue particularly.
2) 0002 adds sanity checks in pqAddTuple for overflows, maximizing the
size of what is allocated to INT_MAX but now more.
pqRowProcessor() still has errmsgp, but it is never used on HEAD. At
least with this set of patches it comes to be useful. We could rework
check_field_number() to use as well an error message string, but I
have left that out to keep things simple. Not sure if any complication
is worth compared to just copying the error message in case of an
unmatching column number.
Attached is as well a small program I have used to test PQsetvalue
through PQcopyResult to see if results get correctly allocated at each
call, looking at the error message stacks on the way.
--
Michael
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Attachments:
[text/x-csrc] pg_copy_res.c (1.1K, ../../CAB7nPqRnDMMKybjdC5fFd4XyDaE65UkMB2kAZ_NRm1T=AcZgCQ@mail.gmail.com/2-pg_copy_res.c)
download | inline:
/*
* Script to test PQcopyResult and subsequently PQsetvalue.
* Compile with for example:
* gcc -lpq -g -o pg_copy_res pg_copy_res.c
*/
#include <stdio.h>
#include <stdlib.h>
#include "libpq-fe.h"
#define DEFAULT_PORT "5432"
#define DEFAULT_HOST "/tmp"
#define DEFAULT_DB "postgres"
int
main()
{
char *port = getenv("PGPORT");
char *host = getenv("PGHOST");
char *dbname = getenv("PGDATABASE");
char connstr[512];
PGconn *conn;
PGresult *res, *res_copy;
if (port == NULL)
port = DEFAULT_PORT;
if (host == NULL)
host = DEFAULT_HOST;
if (dbname == NULL)
dbname = DEFAULT_DB;
snprintf(connstr, sizeof(connstr), "port=%s host=%s dbname=%s",
port, host, dbname);
conn = PQconnectdb(connstr);
if (PQstatus(conn) != CONNECTION_OK)
{
fprintf(stderr, "Connection to database failed: %s",
PQerrorMessage(conn));
return 1;
}
res = PQexec(conn, "SELECT 1");
/* Copy the resuld wanted, who care what that is... */
res_copy = PQcopyResult(res, PG_COPYRES_TUPLES | PG_COPYRES_ATTRS);
PQclear(res);
PQclear(res_copy);
PQfinish(conn);
return 0;
}
[application/octet-stream] 0001-Refactor-error-message-handling-in-pqAddTuple.patch (4.9K, ../../CAB7nPqRnDMMKybjdC5fFd4XyDaE65UkMB2kAZ_NRm1T=AcZgCQ@mail.gmail.com/3-0001-Refactor-error-message-handling-in-pqAddTuple.patch)
download | inline diff:
From 0661ed15366b921e73b5c2317bdefb848d00e100 Mon Sep 17 00:00:00 2001
From: Michael Paquier <michael@paquier.xyz>
Date: Mon, 28 Aug 2017 14:41:14 +0900
Subject: [PATCH 1/2] Refactor error message handling in pqAddTuple()
This routine is used by the plain PQsetvalue for example to copy a full
result set or by pqRowProcessor to process a new row received from the
backend on the frontend.
Thanks to this refactoring, this routine can allocate a proper error
message that the caller can use for proper sanity checks. This is now
rather useless, but additional sanity checks related to counter overflows
in pqAddTuple() will make use of this.
Per original complain from Igor Korot, which led to a patch suggested
by Tom Lane, written by Michael Paquier.
Discussion: http://postgr.es/m/CA+FnnTxyLWyjY1goewmJNxC==HQCCF4fKkoCTa9qR36oRAHDPw@mail.gmail.com
---
src/interfaces/libpq/fe-exec.c | 64 +++++++++++++++++++++++++++++++++++-------
1 file changed, 54 insertions(+), 10 deletions(-)
diff --git a/src/interfaces/libpq/fe-exec.c b/src/interfaces/libpq/fe-exec.c
index e1e2d18e3a..10961e679b 100644
--- a/src/interfaces/libpq/fe-exec.c
+++ b/src/interfaces/libpq/fe-exec.c
@@ -51,7 +51,8 @@ static bool static_std_strings = false;
static PGEvent *dupEvents(PGEvent *events, int count);
-static bool pqAddTuple(PGresult *res, PGresAttValue *tup);
+static bool pqAddTuple(PGresult *res, PGresAttValue *tup,
+ const char **errmsgp);
static bool PQsendQueryStart(PGconn *conn);
static int PQsendQueryGuts(PGconn *conn,
const char *command,
@@ -421,13 +422,27 @@ int
PQsetvalue(PGresult *res, int tup_num, int field_num, char *value, int len)
{
PGresAttValue *attval;
+ PQExpBufferData errorBuf;
+ const char *errmsg = NULL; /* NULL means "out of memory" */
+
+ initPQExpBuffer(&errorBuf);
if (!check_field_number(res, field_num))
- return FALSE;
+ {
+ printfPQExpBuffer(&errorBuf,
+ libpq_gettext("column number %d is out of range 0..%d"),
+ field_num, res->numAttributes - 1);
+ goto fail;
+ }
/* Invalid tup_num, must be <= ntups */
if (tup_num < 0 || tup_num > res->ntups)
- return FALSE;
+ {
+ printfPQExpBuffer(&errorBuf,
+ libpq_gettext("tuple number %d is out of range 0..%d"),
+ tup_num, res->ntups);
+ goto fail;
+ }
/* need to allocate a new tuple? */
if (tup_num == res->ntups)
@@ -440,7 +455,7 @@ PQsetvalue(PGresult *res, int tup_num, int field_num, char *value, int len)
TRUE);
if (!tup)
- return FALSE;
+ goto fail;
/* initialize each column to NULL */
for (i = 0; i < res->numAttributes; i++)
@@ -450,8 +465,16 @@ PQsetvalue(PGresult *res, int tup_num, int field_num, char *value, int len)
}
/* add it to the array */
- if (!pqAddTuple(res, tup))
- return FALSE;
+ if (!pqAddTuple(res, tup, &errmsg))
+ {
+ /*
+ * Note that pqAddTuple() has already applied libpq_gettext,
+ * and that the error message is NULL on out-of-memory.
+ */
+ if (errmsg)
+ appendPQExpBufferStr(&errorBuf, errmsg);
+ goto fail;
+ }
}
attval = &res->tuples[tup_num][field_num];
@@ -471,13 +494,23 @@ PQsetvalue(PGresult *res, int tup_num, int field_num, char *value, int len)
{
attval->value = (char *) pqResultAlloc(res, len + 1, TRUE);
if (!attval->value)
- return FALSE;
+ goto fail;
attval->len = len;
memcpy(attval->value, value, len);
attval->value[len] = '\0';
}
+ termPQExpBuffer(&errorBuf);
return TRUE;
+
+fail:
+ /* save any error, nothing saved means "out of memory" */
+ if (errorBuf.len == 0)
+ printfPQExpBuffer(&errorBuf, libpq_gettext("out of memory"));
+
+ pqSetResultError(res, errorBuf.data);
+ termPQExpBuffer(&errorBuf);
+ return FALSE;
}
/*
@@ -847,10 +880,13 @@ pqInternalNotice(const PGNoticeHooks *hooks, const char *fmt,...)
/*
* pqAddTuple
* add a row pointer to the PGresult structure, growing it if necessary
- * Returns TRUE if OK, FALSE if not enough memory to add the row
+ * Returns TRUE if OK, FALSE if an error happened when adding the row.
+ *
+ * On error, *errmsgp can be set to an error string to be returned. If it
+ * is left NULL, the error is presumed to be "out of memory".
*/
static bool
-pqAddTuple(PGresult *res, PGresAttValue *tup)
+pqAddTuple(PGresult *res, PGresAttValue *tup, const char **errmsgp)
{
if (res->ntups >= res->tupArrSize)
{
@@ -875,7 +911,14 @@ pqAddTuple(PGresult *res, PGresAttValue *tup)
newTuples = (PGresAttValue **)
realloc(res->tuples, newSize * sizeof(PGresAttValue *));
if (!newTuples)
+ {
+ /*
+ * malloc or realloc failed, let caller know about that
+ * with a NULL error message.
+ */
+ *errmsgp = NULL;
return FALSE; /* malloc or realloc failed */
+ }
res->tupArrSize = newSize;
res->tuples = newTuples;
}
@@ -1093,7 +1136,8 @@ pqRowProcessor(PGconn *conn, const char **errmsgp)
}
/* And add the tuple to the PGresult's tuple array */
- if (!pqAddTuple(res, tup))
+ *errmsgp = NULL;
+ if (!pqAddTuple(res, tup, errmsgp))
goto fail;
/*
--
2.14.1
[application/octet-stream] 0002-Improve-overflow-checks-of-pqAddTuple-in-libpq.patch (2.1K, ../../CAB7nPqRnDMMKybjdC5fFd4XyDaE65UkMB2kAZ_NRm1T=AcZgCQ@mail.gmail.com/4-0002-Improve-overflow-checks-of-pqAddTuple-in-libpq.patch)
download | inline diff:
From cc9b97e3c742bbc0781eb48aff3b055820e04305 Mon Sep 17 00:00:00 2001
From: Michael Paquier <michael@paquier.xyz>
Date: Mon, 28 Aug 2017 14:57:39 +0900
Subject: [PATCH 2/2] Improve overflow checks of pqAddTuple() in libpq
When adding a tuple to an existing PQresult, libpq has been lacking
with checks on the maximum number of tuples it can assign within it.
First, it has forgotten the case where the number of tuples allocated
to a result reaches INT_MAX, in which case things would crash.
Secondly, the size allocated when increasing the room for of tuple
pointers could overflow, so add a sanity check on that.
Per original complain from Igor Korot, which led to a patch suggested
by Tom Lane, written by Michael Paquier.
Discussion: http://postgr.es/m/CA+FnnTxyLWyjY1goewmJNxC==HQCCF4fKkoCTa9qR36oRAHDPw@mail.gmail.com
---
src/interfaces/libpq/fe-exec.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/src/interfaces/libpq/fe-exec.c b/src/interfaces/libpq/fe-exec.c
index 10961e679b..797335742f 100644
--- a/src/interfaces/libpq/fe-exec.c
+++ b/src/interfaces/libpq/fe-exec.c
@@ -904,6 +904,31 @@ pqAddTuple(PGresult *res, PGresAttValue *tup, const char **errmsgp)
int newSize = (res->tupArrSize > 0) ? res->tupArrSize * 2 : 128;
PGresAttValue **newTuples;
+ /*
+ * Do not let the array size grow higher than INT_MAX. If the new
+ * size estimated is overflowing for the first time, enforce the
+ * size to its maximum possible. If the maximum is already reached
+ * when arriving at this point, just fail, there is nothing more to
+ * do.
+ */
+ if (res->tupArrSize == INT_MAX)
+ {
+ *errmsgp = libpq_gettext("already too many tuples for row addition");
+ return FALSE;
+ }
+ if (newSize < 0)
+ newSize = INT_MAX;
+
+ /*
+ * This is more a safe-keeper particularly on 32-bit platforms where
+ * things could overflow.
+ */
+ if (newSize > SIZE_MAX / sizeof(PGresAttValue *))
+ {
+ *errmsgp = libpq_gettext("size overflow");
+ return FALSE;
+ }
+
if (res->tuples == NULL)
newTuples = (PGresAttValue **)
malloc(newSize * sizeof(PGresAttValue *));
--
2.14.1
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: [GENERAL] Retrieving query results
2017-08-22 18:19 Retrieving query results Igor Korot <ikorot01@gmail.com>
2017-08-23 00:32 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
2017-08-24 12:51 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
2017-08-24 13:47 ` Re: Retrieving query results Igor Korot <ikorot01@gmail.com>
2017-08-24 14:56 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
2017-08-24 22:57 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
2017-08-24 23:10 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
2017-08-26 13:29 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
2017-08-26 15:12 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
2017-08-28 06:05 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
@ 2025-12-17 05:26 ` Igor Korot <ikorot01@gmail.com>
2025-12-17 08:38 ` Re: [GENERAL] Retrieving query results Laurenz Albe <laurenz.albe@cybertec.at>
0 siblings, 1 reply; 17+ messages in thread
From: Igor Korot @ 2025-12-17 05:26 UTC (permalink / raw)
To: Michael Paquier <michael.paquier@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-general
Hi, ALL,
On Sun, Aug 27, 2017 at 11:05 PM Michael Paquier
<michael.paquier@gmail.com> wrote:
>
> On Sun, Aug 27, 2017 at 12:12 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Michael Paquier <michael.paquier@gmail.com> writes:
> >> On Fri, Aug 25, 2017 at 8:10 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >>> I think the real problem occurs where we realloc the array bigger.
> >
> >> Looking at the surroundings, I think that it would be nice to have
> >> pqAddTuple and PQsetvalue set an error message with this patch.
> >
> > Yeah, I was thinking about that myself - the existing design presumes
> > that the only possible reason for failure of pqAddTuple is OOM, but
> > it'd be better to distinguish "too many tuples" from true OOM. So
> > we should also refactor to make pqAddTuple responsible for setting
> > the error message. Might be best to do the refactoring first.
>
> Attached are two patches:
> 1) 0001 refactors the code around pqAddTuple to be able to handle
> error messages and assign them in PQsetvalue particularly.
> 2) 0002 adds sanity checks in pqAddTuple for overflows, maximizing the
> size of what is allocated to INT_MAX but now more.
>
> pqRowProcessor() still has errmsgp, but it is never used on HEAD. At
> least with this set of patches it comes to be useful. We could rework
> check_field_number() to use as well an error message string, but I
> have left that out to keep things simple. Not sure if any complication
> is worth compared to just copying the error message in case of an
> unmatching column number.
>
> Attached is as well a small program I have used to test PQsetvalue
> through PQcopyResult to see if results get correctly allocated at each
> call, looking at the error message stacks on the way.
Is this now part of the main libpq codebase?
Thank you.
> --
> Michael
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: [GENERAL] Retrieving query results
2017-08-22 18:19 Retrieving query results Igor Korot <ikorot01@gmail.com>
2017-08-23 00:32 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
2017-08-24 12:51 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
2017-08-24 13:47 ` Re: Retrieving query results Igor Korot <ikorot01@gmail.com>
2017-08-24 14:56 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
2017-08-24 22:57 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
2017-08-24 23:10 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
2017-08-26 13:29 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
2017-08-26 15:12 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
2017-08-28 06:05 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
2025-12-17 05:26 ` Re: [GENERAL] Retrieving query results Igor Korot <ikorot01@gmail.com>
@ 2025-12-17 08:38 ` Laurenz Albe <laurenz.albe@cybertec.at>
2025-12-17 17:42 ` Re: [GENERAL] Retrieving query results Igor Korot <ikorot01@gmail.com>
0 siblings, 1 reply; 17+ messages in thread
From: Laurenz Albe @ 2025-12-17 08:38 UTC (permalink / raw)
To: Igor Korot <ikorot01@gmail.com>; Michael Paquier <michael.paquier@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-general
On Tue, 2025-12-16 at 21:26 -0800, Igor Korot wrote:
> Is this now part of the main libpq codebase?
Yes; you can find [1] and [2] in the commit log.
Yours,
Laurenz Albe
[1]: https://postgr.es/c/2e70d6b5e99b7e7b53336b1838f869bbea1b5024
[2]: https://postgr.es/c/6cbee65eee20c144bb4de169c6802f20e76785b0
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: [GENERAL] Retrieving query results
2017-08-22 18:19 Retrieving query results Igor Korot <ikorot01@gmail.com>
2017-08-23 00:32 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
2017-08-24 12:51 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
2017-08-24 13:47 ` Re: Retrieving query results Igor Korot <ikorot01@gmail.com>
2017-08-24 14:56 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
2017-08-24 22:57 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
2017-08-24 23:10 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
2017-08-26 13:29 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
2017-08-26 15:12 ` Re: Retrieving query results Tom Lane <tgl@sss.pgh.pa.us>
2017-08-28 06:05 ` Re: Retrieving query results Michael Paquier <michael.paquier@gmail.com>
2025-12-17 05:26 ` Re: [GENERAL] Retrieving query results Igor Korot <ikorot01@gmail.com>
2025-12-17 08:38 ` Re: [GENERAL] Retrieving query results Laurenz Albe <laurenz.albe@cybertec.at>
@ 2025-12-17 17:42 ` Igor Korot <ikorot01@gmail.com>
0 siblings, 0 replies; 17+ messages in thread
From: Igor Korot @ 2025-12-17 17:42 UTC (permalink / raw)
To: Laurenz Albe <laurenz.albe@cybertec.at>; +Cc: Michael Paquier <michael.paquier@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; pgsql-general
Thx for confirmation.
On Wed, Dec 17, 2025 at 12:38 AM Laurenz Albe <laurenz.albe@cybertec.at>
wrote:
> On Tue, 2025-12-16 at 21:26 -0800, Igor Korot wrote:
> > Is this now part of the main libpq codebase?
>
> Yes; you can find [1] and [2] in the commit log.
>
> Yours,
> Laurenz Albe
>
>
> [1]: https://postgr.es/c/2e70d6b5e99b7e7b53336b1838f869bbea1b5024
> [2]: https://postgr.es/c/6cbee65eee20c144bb4de169c6802f20e76785b0
>
^ permalink raw reply [nested|flat] 17+ messages in thread
end of thread, other threads:[~2025-12-17 17:42 UTC | newest]
Thread overview: 17+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2017-08-22 18:19 Retrieving query results Igor Korot <ikorot01@gmail.com>
2017-08-23 00:32 ` Michael Paquier <michael.paquier@gmail.com>
2017-08-23 01:04 ` Igor Korot <ikorot01@gmail.com>
2017-08-24 12:51 ` Tom Lane <tgl@sss.pgh.pa.us>
2017-08-24 13:47 ` Igor Korot <ikorot01@gmail.com>
2017-08-24 14:56 ` Tom Lane <tgl@sss.pgh.pa.us>
2017-08-24 22:57 ` Michael Paquier <michael.paquier@gmail.com>
2017-08-24 23:05 ` Igor Korot <ikorot01@gmail.com>
2017-08-24 23:18 ` Tom Lane <tgl@sss.pgh.pa.us>
2017-08-25 00:00 ` Igor Korot <ikorot01@gmail.com>
2017-08-24 23:10 ` Tom Lane <tgl@sss.pgh.pa.us>
2017-08-26 13:29 ` Michael Paquier <michael.paquier@gmail.com>
2017-08-26 15:12 ` Tom Lane <tgl@sss.pgh.pa.us>
2017-08-28 06:05 ` Michael Paquier <michael.paquier@gmail.com>
2025-12-17 05:26 ` Igor Korot <ikorot01@gmail.com>
2025-12-17 08:38 ` Laurenz Albe <laurenz.albe@cybertec.at>
2025-12-17 17:42 ` Igor Korot <ikorot01@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox