Hi,
Consider the following test scenario:
create table test ( c1 serial, c2 int not null ) partition by list (c2);
create table test_p1 partition of test for values in ( 1);
create table test_p2 partition of test for values in ( 2);
rushabh@rushabh:postgresql$ ./db/bin/pg_dump db1 > dump.sql
On Mon, May 6, 2019 at 3:44 PM Tom Lane wrote:
> Thomas Munro writes:
> > On Mon, May 6, 2019 at 11:07 AM Tom Lane wrote:
> >> ... You're not doing future
> >> hackers any service by failing to include a comment that explains that
> >> DSM detach MUST BE LAST, and explaining why.
>
> > Ok,
Andres Freund writes:
> On May 5, 2019 8:56:58 PM PDT, Tom Lane wrote:
>> On this coast, "tonight" is running into "tomorrow" ... you planning
>> to do that soon?
> I'd planned to finish cooking and eating, and then doing it. Seems like
> that'd be plenty early?
Sure, dinner can take
Hi,
On May 5, 2019 8:56:58 PM PDT, Tom Lane wrote:
>Andres Freund writes:
>> On 2019-05-04 11:04:07 -0400, Tom Lane wrote:
>>> I don't think we discussed exactly what "come out" means. My
>thought is
>>> to leave the test scripts in place (so they can be invoked manually
>with
>>> EXTRA_TESTS)
Andres Freund writes:
> On 2019-05-04 11:04:07 -0400, Tom Lane wrote:
>> I don't think we discussed exactly what "come out" means. My thought is
>> to leave the test scripts in place (so they can be invoked manually with
>> EXTRA_TESTS) but remove them from the schedule files.
> Yea, that
Thomas Munro writes:
> On Mon, May 6, 2019 at 11:07 AM Tom Lane wrote:
>> ... You're not doing future
>> hackers any service by failing to include a comment that explains that
>> DSM detach MUST BE LAST, and explaining why.
> Ok, here's a version that provides a specific reason (the Windows
On Wed, May 1, 2019 at 12:57 PM Noah Misch wrote:
> On Tue, Apr 30, 2019 at 10:47:37PM +1200, Thomas Munro wrote:
> > --- a/src/test/perl/PostgresNode.pm
> > +++ b/src/test/perl/PostgresNode.pm
> > @@ -1098,17 +1098,12 @@ sub get_new_node
> > # native Perl
On Mon, May 6, 2019 at 11:07 AM Tom Lane wrote:
> One thing I don't care for about this patch is that the original code
> looked like it didn't matter what order we did the resource releases in,
> and the patched code still looks like that. You're not doing future
> hackers any service by
Update: I have moved the previously contributed "pg_ssl" package to a
formal git, and have renamed it to "pg_ssl_init"
(at the request of initial reviewers, who were concerned about future
name collisions...)
"pg_ssl_init" is a set of command line scripts that conveniently
configures
Thomas Munro writes:
> If it does produce the log message, then the attached patch should
> make it go away.
One thing I don't care for about this patch is that the original code
looked like it didn't matter what order we did the resource releases in,
and the patched code still looks like that.
Hi,
good point !
wal2Json seems to correspond to your needs,
this is first designed for Change Data Capture,
taht could generate a (very) big size of logs.
You didn't tell us much about your use case ...
and maybe, if the number of data modifications
is not too big, and the number of tables
On Fri, May 3, 2019 at 2:15 AM Tom Lane wrote:
> Thomas Munro writes:
> > A while back I posted a patch[1] to change the order of resowner
> > cleanup so that DSM handles are released last. That's useful for the
> > error cleanup path on Windows, when a SharedFileSet is cleaned up (a
> >
Hi Legrand & Bruce,
Thanks for your thoughts. I think MariaDB's temporal queries could work.
If I want to use it in PostgreSQL, I could use Logical Decoding plugins for recording all INSERT/UPDATE/DELETE history of each table:
- https://debezium.io/docs/install/postgres-plugins/
-
I wrote:
> Michael Paquier writes:
>> What do you think about something like the attached then? HEAD does
>> not check after system indexes with REINDEX INDEX CONCURRENTLY, and I
>> have moved all the catalog-related tests to reindex_catalog.sql.
> OK as far as the wording goes, but now that I
On Fri, Apr 26, 2019 at 5:13 PM Peter Geoghegan wrote:
> On Fri, Apr 26, 2019 at 5:05 PM Tom Lane wrote:
> > Yeah, I'd be fine with that, although the disconnect between the type
> > name and the comment terminology might confuse some people.
>
> Maybe, but the fact that the ItemIdData struct
Hi, Meskes-san
I'm sorry for my long blank. I restarted.
Review of previous discussion:
I made a patch that makes ecpglib to send "PREPARE st(typelist) AS
PreparableStmt"
with PQexec(), because the type resolution is difficult.
I tried to merge PREPARE FROM that uses PQprepare() to the PREPARE
Hi,
On 2019-05-04 11:04:07 -0400, Tom Lane wrote:
> I don't think we discussed exactly what "come out" means. My thought is
> to leave the test scripts in place (so they can be invoked manually with
> EXTRA_TESTS) but remove them from the schedule files.
Yea, that sounds sensible. I'll do so by
Hi
I am Raghav Jajodia, a software engineer from Bangalore, India. I have been
a diligent open source contributor and have been a student under the
following:
1. Google Summer of Code 2017 student
2. OWASP Code Sprint Winner
3. FOSSASIA CodeHeat 2018 Grand Prize winner
I have mentored more that
Michael Paquier writes:
> The message you are referring to in index_create() has been introduced
> as of e093dcdd with the introduction of CREATE INDEX CONCURRENTLY, and
> it can be perfectly hit without REINDEX:
> =# show allow_system_table_mods;
> allow_system_table_mods
>
On Thu, 2 May 2019 at 14:35, Tomas Vondra wrote:
> >From the client side perspective, it confirmed everything that it
> >should, but from the postgres side, this is not enough to shut down
> >cleanly. Maybe it is possible to change the check (sentPtr ==
> >replicatedPtr) to something like
On Sat, May 04, 2019 at 11:00:11AM -0400, Tom Lane wrote:
> I'm not excited about rewording longstanding errors. These two are
> new though (aren't they?)
The message you are referring to in index_create() has been introduced
as of e093dcdd with the introduction of CREATE INDEX CONCURRENTLY, and
On Sat, May 4, 2019 at 2:55 PM Amit Kapila wrote:
>
> On Fri, May 3, 2019 at 2:14 PM Amit Kapila wrote:
> >
> > On Fri, May 3, 2019 at 11:43 AM John Naylor
> > wrote:
>
> Attached is a revert patch. John, can you please once double-check to
> ensure I have not missed anything?
>
> To
On Sat, May 4, 2019 at 02:32:06PM +0900, Ronny Ko wrote:
> Hi,
>
> I am trying to efficiently rollback a manually selectedd subset of committed
> SQL transactions by scanning an SQL transaction log. This feature is useful
> when a database administrator wants to rollback not the entire database
Hello,
may be you can find more informations regarding WAL concepts in
Write Ahead Logging — WAL
http://www.interdb.jp/pg/pgsql09.html
It seems very complicated to change WAL format ...
Maybe there are other solutions to answer your need,
I found many interesting solutions in postgres archives
24 matches
Mail list logo
