Josh Kupershmidt writes:
> 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?
Yes, it would. Once the memory has been freed, malloc() is at liberty
to give it out for some ot
I agree with Jeff.
Options that change the language at initdb or create-database time just fragment
the language.
It is best to just have 1 language where options are providable either
dynamically per connection or otherwise lexically, so that then they are really
just shorthands for the cur
Hello, I've also found this does not fix this problem.
> >> So I'd say we should update minRecoveryPoint first, then
> >> truncate/delete. But we should still keep the XLogFlush() at the end of
> >> xact_redo_commit_internal(), for the case where files/directories are
> >> created. Patch attached.
On Mon, 2012-12-10 at 14:07 -0500, Robert Haas wrote:
> And we not only don't give them the behavior they want; we
> don't even have a meaningful way to give the option of opting into
> that behavior at initdb or create-database time.
I strongly object to offering options that change the language
On Mon, 2012-12-10 at 08:16 -0500, Stephen Frost wrote:
> I'm trying to figure out why there are all the constraints around this
> command to begin with. If we're going to support this, why do we
> require the user to create or truncate the table in the same
> transaction? Clearly that's going t
The documentation for PQclear() doesn't say whether it is safe to call
PQclear() more than once on the same PGresult pointer. In fact, it is
not safe, but apparently only because of this last step:
/* Free the PGresult structure itself */
free(res);
The other members of PGresult which may
On Mon, Dec 10, 2012 at 7:02 PM, Stephen Frost wrote:
>
> I continue to hold that this could end up being a slippery slope for us
> to go down wrt 'correctness' vs. 'do whatever the user wants'. If we
> keep this to only COPY and where the table has to be truncated/created
> in the same transact
On Tue, Dec 11, 2012 at 12:17:11AM +0200, Marti Raudsepp wrote:
> Hi!
>
> It seems that PostgreSQL 9.2.2 has a regression in pg_upgrade, the -o
> and -O options forget to add a space before passing on user options,
> thereby generating unparsable command lines.
>
> For example:
> pg_upgrade -b /u
On Mon, Dec 10, 2012 at 08:54:04PM -0500, Stephen Frost wrote:
> I agree that it's unlikely that
> applications are depending on today's behavior of TRUNCATE making
> concurrent transactions see an empty table, but it does *not* follow
> that applications *won't* start depending on this new behavio
On 10/30/2012 10:14:19 PM, Josh Kupershmidt wrote:
> I went ahead and cooked up a patch to allow pg_restore, clusterdb,
> vacuumdb, and reindexdb to accept multiple --table switches. Hope I
> didn't overlook a similar tool, but these were the only other
> commands
> I found taking a --table argum
On Mon, Dec 10, 2012 at 08:04:55PM -0500, Robert Haas wrote:
> I think the current behavior, where we treat FREEZE as a hint, is just
> awful. Regardless of whether the behavior is automatic or manually
> requested, the idea that you might get the optimization or not
> depending on the timing of r
On 11/14/2012 02:35:54 PM, Karl O. Pinc wrote:
> On 11/13/2012 08:50:55 PM, Peter Eisentraut wrote:
> > On Sat, 2012-09-29 at 01:16 -0500, Karl O. Pinc wrote:
> > > This patch makes some sweeping statements.
> >
> > Unfortunately, they are wrong.
>
> I will see if anything can be salvaged.
Here'
* Robert Haas (robertmh...@gmail.com) wrote:
> You know, I hadn't been taking that option terribly seriously, but
> maybe we ought to reconsider it. It would certainly be simpler, and
> as you point out, it's not really any worse from an MVCC point of view
> than anything else we do. Moreover, it
Noah,
* Noah Misch (n...@leadboat.com) wrote:
> I agree we should be reticent to compromise correctness for convenience.
> Compromising mere bug-compatibility, trading one incorrect behavior for
> another incorrect behavior, is not as bad. Furthermore, today's behavior in
> question is not someth
On Mon, Dec 3, 2012 at 9:59 AM, Kohei KaiGai wrote:
> As we discussed before, it is hard to determine which attributes shall
> be informed to extension via object_access_hook, so the proposed
> post-alter hook (that allows to compare older and newer versions)
> works fine on 99% cases.
> However,
On Sun, Dec 9, 2012 at 3:06 PM, Noah Misch wrote:
> I favor[1] unconditionally letting older snapshots see the new rows after the
> CREATE+COPY transaction commits. To recap, making affected scans see an empty
> table is as wrong as making them see those rows. Robert also listed[2] that
> as a c
On Mon, Dec 10, 2012 at 11:51 PM, Andres Freund wrote:
> Btw, as an example of the problems caused by renaming:
>
> postgres=# CREATE TABLE a (id serial primary key); CREATE TABLE b(id
> serial primary key, a_id int REFERENCES a);
> CREATE TABLE
> Time: 137.840 ms
> CREATE TABLE
> Time: 143.500 ms
On Mon, Dec 10, 2012 at 08:32:53AM -0500, Stephen Frost wrote:
> * Noah Misch (n...@leadboat.com) wrote:
> > On Fri, Dec 07, 2012 at 06:51:18PM -0500, Stephen Frost wrote:
> > > Now, what I've honestly been hoping for on this thread was for someone
> > > to speak up and point out why I'm wrong abou
On Fri, Nov 23, 2012 at 4:56 AM, Amit Kapila wrote:
> On Thursday, November 22, 2012 10:09 PM Fujii Masao wrote:
>
>> Is it helpful to output the notice message like 'Run pg_reload_conf() or
>> restart the server if you want new settings to take effect' always after
>> SET PERSISTENT command?
>
>
Robert Haas writes:
> FWICS, this kind of problem is endemic in OpenSSL, which
> also doesn't seem to believe in comprehensive documentation or code
> comments. It would be nice if we had an API to some other, less
> crappy encryption library; or maybe even some generic API that lets
> you easily
On Sat, Dec 8, 2012 at 11:07 AM, Andres Freund wrote:
> As there hasn't been any new input since this comment I am marking the
> patch as "Rejected" in the CF application.
Sounds good. FWIW, even if we were going to accept this, I can't
imagine back-patching it. Users will come after us with pi
On Sat, Dec 8, 2012 at 10:40 AM, Daniel Farina wrote:
> Hello all,
>
> I am approaching this from the angle of increasing power by exposing
> the log collector ("syslogger") pipe protocol.
I just spotted a better, already-committed patch. Thanks to Hannu for
pointing it out:
https://commitfest.
On Mon, Dec 10, 2012 at 10:56 AM, Xin Pan wrote:
> However, I still witness large amount of page writes.
> Can anyone tell where are the page writes come from?
Probably not without more details. Things like VACUUM, COPY, and
sequential scans use ring-buffers that are smaller than
shared_buffers,
On 2012-12-10 22:33:50 +, Simon Riggs wrote:
> On 10 December 2012 22:27, Peter Eisentraut wrote:
> > On 12/10/12 5:21 PM, Simon Riggs wrote:
> >> On 10 December 2012 22:18, Peter Eisentraut wrote:
> >>> On 12/8/12 9:40 AM, Tom Lane wrote:
> I'm tempted to propose that REINDEX CONCURRENT
On 2012-12-10 17:27:45 -0500, Peter Eisentraut wrote:
> On 12/10/12 5:21 PM, Simon Riggs wrote:
> > On 10 December 2012 22:18, Peter Eisentraut wrote:
> >> On 12/8/12 9:40 AM, Tom Lane wrote:
> >>> I'm tempted to propose that REINDEX CONCURRENTLY simply not try to
> >>> preserve the index name exa
On 10 December 2012 22:27, Peter Eisentraut wrote:
> On 12/10/12 5:21 PM, Simon Riggs wrote:
>> On 10 December 2012 22:18, Peter Eisentraut wrote:
>>> On 12/8/12 9:40 AM, Tom Lane wrote:
I'm tempted to propose that REINDEX CONCURRENTLY simply not try to
preserve the index name exactly.
On 12/10/12 5:21 PM, Simon Riggs wrote:
> On 10 December 2012 22:18, Peter Eisentraut wrote:
>> On 12/8/12 9:40 AM, Tom Lane wrote:
>>> I'm tempted to propose that REINDEX CONCURRENTLY simply not try to
>>> preserve the index name exactly. Something like adding or removing
>>> trailing underscore
On 10 December 2012 22:18, Peter Eisentraut wrote:
> On 12/8/12 9:40 AM, Tom Lane wrote:
>> I'm tempted to propose that REINDEX CONCURRENTLY simply not try to
>> preserve the index name exactly. Something like adding or removing
>> trailing underscores would probably serve to generate a nonconfli
On 12/8/12 9:40 AM, Tom Lane wrote:
> I'm tempted to propose that REINDEX CONCURRENTLY simply not try to
> preserve the index name exactly. Something like adding or removing
> trailing underscores would probably serve to generate a nonconflicting
> name that's not too unsightly.
If you think you
Hi!
It seems that PostgreSQL 9.2.2 has a regression in pg_upgrade, the -o
and -O options forget to add a space before passing on user options,
thereby generating unparsable command lines.
For example:
pg_upgrade -b /usr/local/pg91/bin -B /usr/bin -d /tmp/91 -D /tmp/92 -O -F
[...]
Creating catalog
On 10 December 2012 20:52, David Johnston wrote:
> Just skimming this topic but if these enhanced error fields are going to be
> used by software, and we have 99% adherence to a standard, then my first
> reaction is why not just supply "" (or "" as
> appropriate) instead of suppressing the field a
Hello
2012/12/10 Robert Haas :
> On Tue, Nov 27, 2012 at 4:36 PM, Peter Eisentraut wrote:
>> On 11/25/12 6:36 PM, Robert Haas wrote:
>>> I think that is true. But for whatever it's worth, and at the risk of
>>> beating a horse that seems not to be dead yet in spite of the fact
>>> that I feel I'
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Peter Geoghegan
> Sent: Monday, December 10, 2012 3:29 PM
> To: Pavel Stehule
> Cc: PostgreSQL Hackers; Alvaro Herrera; Tom Lane
> Subject: Re: [HACKERS] enhanced erro
On 10 December 2012 17:56, Heikki Linnakangas wrote:
> Any objections?
No objections, though I'm concerned to make as few changes as possible. Thanks
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-ha
On 10.12.2012 22:22, Heikki Linnakangas wrote:
(Offlist)
Just a quick note that I'm working on this patch now. I pushed some
trivial fixes to my git repository at
git://git.postgresql.org/git/users/heikki/postgres.git, xlogreader_v3
branch.
Oops, wasn't offlist :-). Well, if anyone wants to ta
(Offlist)
Just a quick note that I'm working on this patch now. I pushed some
trivial fixes to my git repository at
git://git.postgresql.org/git/users/heikki/postgres.git, xlogreader_v3
branch.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
On 12/10/2012 02:42 PM, Karl O. Pinc wrote:
I made a tarball from head, but did not look at it. :-(
Note that the INSTALL file is not present in the git repository, it's
generated and included in the tarball. See README.git.
That's my problem, I had checked out from git.
Thanks and sorry to
On 11/08/2012 11:55:19 AM, Karl O. Pinc wrote:
> On 11/08/2012 11:10:39 AM, Robert Haas wrote:
> > Ah, well, as to that, I think you'd have to take that suggestion to
> > pgsql-www. The style sheets used for the web site are - just to
> make
> > things exciting - stored in a completely different
On 12/10/2012 01:29:03 PM, Heikki Linnakangas wrote:
> On 10.12.2012 21:19, Karl O. Pinc wrote:
> > The top-level README in the source tarball says:
> >
> > -
> > See the file INSTALL for instructions on how to build and install
> > PostgreSQL. That file
On 10.12.2012 21:19, Karl O. Pinc wrote:
The top-level README in the source tarball says:
-
See the file INSTALL for instructions on how to build and install
PostgreSQL. That file also lists supported operating systems and
hardware platforms and conta
It looks like there are still some problems with this patch.
CREATE TABLE foo(ir int4range);
insert into foo select 'empty' from generate_series(1,1);
insert into foo select int4range(NULL, g, '(]')
from generate_series(1,100) g;
insert into foo select int4range(g, NULL, '[)')
Hi,
The top-level README in the source tarball says:
-
See the file INSTALL for instructions on how to build and install
PostgreSQL. That file also lists supported operating systems and
hardware platforms and contains information regarding any other
so
On Tue, Nov 27, 2012 at 4:36 PM, Peter Eisentraut wrote:
> On 11/25/12 6:36 PM, Robert Haas wrote:
>> I think that is true. But for whatever it's worth, and at the risk of
>> beating a horse that seems not to be dead yet in spite of the fact
>> that I feel I've already administered one hell of a
Hi all,
The usage of the pg_database_size function generate a lot of "permission
denied" log errors.
Typical message is: ERROR: could not stat file "base/16384/20041":
Permission denied.
As a short description:
- PostgreSQL 9.2.1/64 bits
- our system is running on windows platform (W7, W2008)
- f
Hi,
The xlog_fn.h patch was Alvaro's idea (and patch) btw, I previously had
used an ugly typedef for Datum to get arround defining
FRONTEND/including postgres.h...
On 2012-12-10 19:56:49 +0200, Heikki Linnakangas wrote:
> We still need the "#define FRONTEND 1" ugly hack in pg_controldata and
> pg
On 12/09/2012 10:33:59 PM, Karl O. Pinc wrote:
> Hi,
>
> I don't feel particularly qualified to comment, but in the
> interest of (hopefully) helping with the patch review process
> I'm going to comment anyway.
I've gone ahead and signed up to review this patch.
I can confirm that it compiles ag
On Tue, Dec 11, 2012 at 1:33 AM, Heikki Linnakangas
wrote:
> On 10.12.2012 13:50, Heikki Linnakangas wrote:
>>
>> So I'd say we should update minRecoveryPoint first, then
>> truncate/delete. But we should still keep the XLogFlush() at the end of
>> xact_redo_commit_internal(), for the case where f
Andres Freund's xlogreader patch contains a change to move the
declarations of SQL-callable functions in xlogfuncs.c to a new header
file, xlog_fn.h. The purpose is to allow xlog_internal.h to be included
in a frontend program, as the PG_FUNCTION_ARGS and Datum used in the
prototypes require fm
Dne 10.12.2012 16:38, Andres Freund napsal:
On 2012-12-08 17:07:38 +0100, Tomas Vondra wrote:
I've done some test and yes - once there are other objects the
optimization falls short. For example for tables with one index, it
looks like this:
1) unpatched
one by one: 28.9 s
100 batches:
On 12/10/2012 04:56 PM, Xin Pan wrote:
Assumption: I have enough memory to cache all the database pages.
Goal:
Master never write pages. Slave replays logs from master and writes
pages.
Benefits:
Reduce the page IO overhead at master, save money in EC2 cloud.
I have suggested something simila
On 10.12.2012 13:50, Heikki Linnakangas wrote:
So I'd say we should update minRecoveryPoint first, then
truncate/delete. But we should still keep the XLogFlush() at the end of
xact_redo_commit_internal(), for the case where files/directories are
created. Patch attached.
Committed and backpatche
Assumption: I have enough memory to cache all the database pages.
Goal:
Master never write pages. Slave replays logs from master and writes pages.
Benefits:
Reduce the page IO overhead at master, save money in EC2 cloud.
Question:
Can you give me some comments on this idea?
And I cannot turn of p
Michael Paquier writes:
> On 2012/12/10, at 18:28, Simon Riggs wrote:
>> If I have to choose between (1) keeping the same name OR (2) avoiding
>> an AccessExclusiveLock then I would choose (2). Most other people
>> would also, especially when all we would do is add/remove an
>> underscore. Even i
On 2012-12-08 17:07:38 +0100, Tomas Vondra wrote:
> On 8.12.2012 15:49, Tomas Vondra wrote:
> > On 8.12.2012 15:26, Andres Freund wrote:
> >> On 2012-12-06 23:38:59 +0100, Tomas Vondra wrote:
> >>> I've re-run the tests with the current patch on my home workstation, and
> >>> the results are these
On 2012-12-10 09:22:25 +0530, Amit Kapila wrote:
> On Sunday, December 09, 2012 9:27 PM Simon Riggs
> > On 16 November 2012 07:20, Greg Smith wrote:
> >
> >
> > Let's bring balance to the situation through our own actions. Please
> > review one patch now for every one you submitted.
>
> In CF-3, I
On 2012-12-10 15:51:40 +0100, Andres Freund wrote:
> On 2012-12-10 15:03:59 +0900, Michael Paquier wrote:
> > I have updated the patch (v4) to take care of updating reltoastidxid for
> > toast parent relations at the swap step by using index_update_stats. In
> > prior versions of the patch this was
On 2012-12-10 15:03:59 +0900, Michael Paquier wrote:
> I have updated the patch (v4) to take care of updating reltoastidxid for
> toast parent relations at the swap step by using index_update_stats. In
> prior versions of the patch this was done when concurrent index was built,
> leading to toast r
Hi,
On 2012-11-19 09:50:30 +0100, Andres Freund wrote:
> On 2012-11-19 16:28:55 +0900, Michael Paquier wrote:
> > After launching some SQLs, the logical receiver is stuck just after sending
> > INIT_LOGICAL_REPLICATION, please see bt of process waiting:
>
> Its waiting till it sees initial an init
* Noah Misch (n...@leadboat.com) wrote:
> On Fri, Dec 07, 2012 at 06:51:18PM -0500, Stephen Frost wrote:
> > Now, what I've honestly been hoping for on this thread was for someone
> > to speak up and point out why I'm wrong about this concern and explain
> > how this patch addresses that issue. If
Simon,
* Simon Riggs (si...@2ndquadrant.com) wrote:
> Agreed, but that is also be a silent change of current behaviour.
Sure, proper MVCC for catalog entries would be a change, but I think
it's one which would actually reduce the surprises for our users. Today
we tell people we have transactiona
> From: Heikki Linnakangas [mailto:hlinnakan...@vmware.com]
> Sent: Friday, December 07, 2012 9:22 PM
> To: Amit Kapila
> Cc: 'PostgreSQL-development'; 'Thom Brown'
> Subject: Re: [HACKERS] Switching timeline over streaming replication
>
> On 06.12.2012 15:39, Amit Kapila wrote:
> > On Thursday, D
On Monday, December 10, 2012 2:41 PM Kyotaro HORIGUCHI wrote:
> Thank you.
>
> > >heap_attr_get_length_and_check_equals:
> ..
> > >- This function returns always false for attrnum <= 0 as whole
> > > tuple or some system attrs comparison regardless of the real
> > > result, which is a bit di
On 10.12.2012 03:52, Kyotaro HORIGUCHI wrote:
I think that minRecoveryPoint should be updated before the data-file
changes, so XLogFlush() should be called before smgrtruncate(). No?
Mmm.. As far as I saw in xact_redo_commit_internal, XLogFlush
seems should be done AFTER redo substantial operat
--
Michael Paquier
http://michael.otacoo.com
On 2012/12/10, at 18:28, Simon Riggs wrote:
> On 10 December 2012 06:03, Michael Paquier wrote:
>>> On 2012-12-08 09:40:43 -0500, Tom Lane wrote:
Andres Freund writes:
I'm tempted to propose that REINDEX CONCURRENTLY simply not try to
>>
On 10 December 2012 06:03, Michael Paquier wrote:
>> On 2012-12-08 09:40:43 -0500, Tom Lane wrote:
>> > Andres Freund writes:
>> > I'm tempted to propose that REINDEX CONCURRENTLY simply not try to
>> > preserve the index name exactly. Something like adding or removing
>> > trailing underscores
On Sat, Dec 1, 2012 at 1:14 PM, Pavel Stehule wrote:
> Hello
>
> >
> > Hi Pavel.
> >
> > I am trying to review this patch and on my work computer everything
> compiles
> > and tests perfectly. However, on my laptop, the regression tests don't
> pass
> > with "cache lookup failed for type XYZ" wher
Thank you.
> >heap_attr_get_length_and_check_equals:
..
> >- This function returns always false for attrnum <= 0 as whole
> > tuple or some system attrs comparison regardless of the real
> > result, which is a bit different from the anticipation which
> > the name gives. If you need to keep
Monday, December 10, 2012 7:16 AM Kyotaro HORIGUCHI wrote:
> Thank you.
>
> > I think moving CheckRecoveryConsistency() after redo apply loop might
> cause
> > a problem.
> > As currently it is done before recoveryStopsHere() function, which can
> allow
> > connections
> > on HOTSTANDY. But now if
68 matches
Mail list logo
